[Openid-specs-native-apps] A few questions

[John Bradley]

On Jan 22, 2014, at 2:49 AM, Preibisch, Sascha H <Sascha.Preibisch at ca.com> wrote:

> Hi Paul, John and others!
> 
> I read through the second draft of the „draft-native-application-agent-core-01“ document. I find it very interesting and I like the idea of a TA. I think on a long run it is difficult to implement mobile SSO without that if multiple plattforms should be supported.
> 
> I would like to leave some comments and ask a few questions though. If they have been discussed please let me know. I have ordered the questions by chapter:
> 
> 7.2.1 
> - sounds like the RS needs a list of "associated" secondary apps for each TA. This sounds like a challenging task

The AppInfo endpoint is associated with the AS and is probably used in a more enterprise or Personal data-locker type environment where there is a curated list of apps that the AS supports issuing tokens for.   For unknown apps you would probably ask for a id_token with the apps AS as the audience.
> 
> 7.2.2
> - typo? refresh_token should probably be access_token?

Yes Fixed
> - who and how is the list of apps mainted that is accessible for the end-user?
> - "if" using a custom url scheme? What else should be used when "code" is in use?

That is referring to using a custom URL scheme for passing the token from the TA to the app.  The "customurl" value is the same as the one that the native app client has registered.
This may need to move to bindings.
> - is "scope" nescessary if a custom url is also and already configured to identify a secondary app?

Yes the scope is used in the refresh token flow to get the access token for the app.  That is separate from the custom scheme used as a app callback.
> 
> 7.4 Not sure if I really understand it:
> - why is the primary refresh_token used to request secondary tokens?
If the TA doesn't need to re-authenticate the user it can use it's refresh token along with the scope from the appInfo endpoint.
> - does the secondary app need to povide any credentials?
That is probably a question for bindings.  In some environments it may be possible to check the bundle signature.   For a native app I don't know that burning a secret into the app accomplishes any real security.
> - do the secondary apps and the TA need some kind of relationship, trust?
YEs the TA should ideally be able to check the app bundle sig.  I don't know if the secondary app needs to have trust beyond the user installing the correct TA or MDM.   The secondary apps are not sending secrets to the TA.

> - why should the secondary app not request its own tokens directly using the id_token of the TA to authenticate the user?
> 
That is a use case where the secondary app requests a id_token with a 3rd party as the audience and itself as the "azp" ,  It probably depends on the trust model.  This is how Google Play store apps work.   The secondary app should use a assertion flow to get the access token.   There may need to be a OAuth extension to pass the id_token in a authorization flow if user interaction is required.

> 7.4.2 "binding the secondary token to the secondary app cryptographically". Sounds difficult

If the environment has secure storage then it may be possible for the app to expose it's public key to the TA and then have the AS generate proof of possession access tokens.
That token format is being developed in the OAuth WG http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-03 

> 
> I think one of the biggest callenges will be the secure connection between the TA, the secondary apps and the AS/ RS.

The secondary apps should only be talking directly to the TA and RS if they are known to the TA,  We should consider an advanced case where one TA talks to a number of AS.
> 
> In order to have a separation of concerns I would appreciate a solution which separates between tokens for an app and tokens identifying an authenticated user. Technically there may not be a big difference but I do believe that semantically wise there is. 
> 
Is that differentiating between a id_token passed to a secondary app vs a access token? 
I think we have that but perhaps it needs to be clearer.
> I believe that whenever an app requests an access_token it needs the users consent. This in form of username/ password or an id_token. I am not so sure about a refresh_token which wasn't issued to the requesting app.

I think the idea is to get consent when a app asks for a access token the first time if there is not some sort of pre-consent mechanism in place. That consent might be collected locally on the device or require a redirect to the AS for authentication and consent depending on the model.


We can discuss further on today's call.

> 
> This is it for the moment. I will try to take part at the next telco.
> 
> Regards,
> Sascha
> _______________________________________________
> Openid-specs-native-apps mailing list
> Openid-specs-native-apps at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps

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