[Openid-specs-native-apps] native app validation

[John Bradley]

I have some comments inline

The current Spec is at: http://openid.bitbucket.org/draft-native-application-agent-core-01.html

Begin forwarded message:

> From: openid-specs-native-apps-owner at lists.openid.net
> Subject: Openid-specs-native-apps post from exu at vmware.com requires approval
> Date: July 4, 2014 at 11:34:44 AM GMT-4
> To: openid-specs-native-apps-owner at lists.openid.net
> 
> As list administrator, your authorization is requested for the
> following mailing list posting:
> 
>    List:    Openid-specs-native-apps at lists.openid.net
>    From:    exu at vmware.com
>    Subject: native app validation
>    Reason:  Post to moderated list
> 
> At your convenience, visit:
> 
>    http://lists.openid.net/mailman/admindb/openid-specs-native-apps
> 
> to approve or deny the request.
> 
> From: Emily Xu <exu at vmware.com>
> Subject: native app validation
> Date: July 4, 2014 at 11:34:22 AM GMT-4
> To: "openid-specs-native-apps at lists.openid.net" <openid-specs-native-apps at lists.openid.net>
> 
> 
> Hello,
> 
> I have a few questions regarding native app validation in the NAPPS flow. I'm not sure whether it has been discussed before or not since I cannot find  any discussion with relevant topic from the list.
> 
> 1. Who should validate native app
> 
> In existing NAPPS flow, a native app will obtain an access token to access a Resource Server from AS through TA. Whose responsibility it is to verify whether this particular native app can be given an access token? 
> 
> TA may be able to verify that a request indeed came from a native app. However, TA cannot verify that this native app is authorized to obtain access token to access RS. I assume this validation needs to be done at AS.
> 
> I remember in the very first draft of the spec (Summer, last year), customUrl was used by AS to verify the requesting native app. When a native app sends a token request to TA, it passes in scope and customUrl. TA will pass the scope and customUrl to AS. AS then verifies customUrl and make sure the customUrl is pre-registered for an authorized native app.
> 
The info coming back from the app_info endpoint contains the scopes that the app can request.   The TA needs to filter the requested scopes.

The app_info endpoint response has optional "bundle_id" and "custom_uri" for identifying the app.   In the original spec customurl was in an example but not the normative text.  I have added it to the normative text describing the elements returned in the response.

> 2. customUrl vs. Bundle ID
> 
> One potential issue with the customUrl approach is that TA usually could not validate a native app's customUrl. Instead, TA usually knows a requesting native app's bundle ID. So TA could pass a native app's bundle id to AS for AS to validating whether the native app associated with the bundle id is authorized to receive access token.

The TA should probably do both.   The custom_uri doesn't validate the request but it prevents the response from going to the wrong app if you can't validate the app signature.

Validating the redirect_uri alone is equivalent to standard OAuth 2 security for public apps.  I agree we should try and better that.
> 
> 3. Multiple native apps to one Resource Server
> 
> The original customUrl approach assumes one Resource Server (scope) could have only one native app (customUrl) associated with it. If we decide to ask AS to validate native app using either customUrl or bundle id, then we need to cover the situation where multiple native apps running on the same device may ask access token from AS through TA to access the same RS. In this situation, one RS(scope) at AS side may have multiple  native apps registered.

I don't think I get the question.  The app info response is an array of app objects.  There is nothing I can see that stops multiple apps from asking for the same scope.   It is the TA that knows what the client app is and filter the scopes.

This will be good to take to the list once we have the IPR dealt with.

Thanks

John B.
> 
> Any thoughts?
> 
> Thanks,
> Emily
> 
> Emily Xu
> Identity Management
> VMware 
>>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140705/d54c59a0/attachment.html>