[Openid-specs-native-apps] TA Discovery

[John Bradley]

At IIW this was one of the questions that we didn’t get to other than to say that it is required in some way.

A napps client needs to know what TA to invoke.  

If there can only be  one TA on the device and they all use the same custom scheme then I suppose that discovery is moot.

If we have a SAAS app like box then I could see wanting to customize the TA per enterprise.
The app could call a well known endpoint and get the config for the enterprise eg custom URI to invoke.  (The app wouldn’t have credentials at that point so this would be public.)

The other sort of app may be a generic app that uses a standard API at the enterprise, but doesn’t know who the enterprise is without some bootstrap.

One way to deal with this is to have the user enter a domain to bootstrap the app.

It can then use a similar  process to Connect discovery to find the enterprise napps config file in .well-known.
The file would list the client_id and custom scheme for a token agent and a fallback https: URI for using the browser.

This requires the same infrastructure as they would already have in place for Connect Discovery. 

This also works for the saas app as long as the enterprise publishes the discovery doc the saas app could pick up the config info.

The downside of the SAAS publishing it, is that they generally don’t like publishing lists of customers.

Are there other things that need to be discovery at this stage. 

I think NAPPS discovery should start as a separate document and we can merge them later if we want to.

Not all apps will need it, some can be hard coded if they are developed by an enterprise directly.

Thoughts

John B.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20141126/f328e44e/attachment.p7s>