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

Paul Madsen paul.madsen at gmail.com
Mon Jul 7 09:59:44 UTC 2014


hi Emily, my understanding is that the scope parameter serves to 
identify the application and distinguish it from others. But there may 
well be more specific sets of operations for each application, eg read 
vs write etc.

Consequently the TA may need to be able to specify these additional 
scopes in its requests of the AS. The default_scopes array informs the 
TA of what these additional 'scopes' are. The TA would insert these as 
additional (space delimited) parameters when it asked the AS for a 
secondary access token

I suspect the value of the mechanism is in supporting 3rd party ASs.

John?

paul

On 7/7/14, 12:39 AM, Emily Xu wrote:
> Hi John,
>
> I don't think I follow you completely on this. What is the difference 
> between scope and default_scopes? Why the values for the two are so 
> different?
>
> I assume one of them will contain list of resource servers that this 
> native app could ask token for. The default scope could be the one if 
> TA pushes access token to client app (without client app asks first), 
> token for that scope will be returned.
>
> Another question, who should be the one who validates the native app 
> (custom url and bundle id)? I assume AS should do the validation. If 
> this is true, then custom url and bundle id should be passed to AS by 
> TA when asking  access token for native app.
>
> Thanks,
> Emily
>
> From: John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>>
> Date: Sunday, July 6, 2014 4:49 PM
> To: Emily Xu <exu at vmware.com <mailto:exu at vmware.com>>
> Cc: "openid-specs-native-apps at lists.openid.net 
> <mailto:openid-specs-native-apps at lists.openid.net>" 
> <openid-specs-native-apps at lists.openid.net 
> <mailto:openid-specs-native-apps at lists.openid.net>>
> Subject: Re: native app validation
>
> Looking at this again the scope value returned from app_info is a 
> special scope that identifies the client app making the request to the 
> TA.
>
> It is a single string value that gets added to the scope parameter in 
> the request.
>
> I have updated the text to make that clearer.
>
> I added a new parameter that allows the app_info endpoint to specify 
> default scopes for applications. This can be used when the TA is 
> requesting a token to push to the app without
> having the app call the TA first.
>
> So to revisit your question.
>
> It would look like
> "apps": [
>              {
>                  "name": "TestApp1",
>                  "type": "native",
>                  "scope": "urn:oauth:testapp1",
>                 "default_scopes": ["com.testrs1"],
>                  "icon_uri": "http://www.example.com/pic1.png  <https://urldefense.proofpoint.com/v1/url?u=http://www.example.com/pic1.png&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=IOcogj9VVYIVG08Q5exet3ZcjD14eQZ74sW8TzsMe2w%3D%0A&s=8d88d0f30400fc8e2ebb6da27f97087042901f488d07933245f94322b9d22477>",
>                  "custom_uri": "testapp1://callback-uri/",
>        "bundle_id": "nkdf9hfknfih9enfen"      
>              },
>              {
>                  "name": "TestApp2",
>                  "type": "native",
>                  "scope": "urn:oauth:testapp1",
>                  "default_scopes": ["com.testrs2"]
>                  "icon_uri": "http://www.example.com/pic2.png  <https://urldefense.proofpoint.com/v1/url?u=http://www.example.com/pic2.png&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=IOcogj9VVYIVG08Q5exet3ZcjD14eQZ74sW8TzsMe2w%3D%0A&s=b773acca3bc95051fd4f690cec8fe08f7131a2dcc3b6761c224a77be30b92571>",
>                  "custom_uri": "testapp2://callback-uri/"
>                  "bundle_id": "jdfejfemfefpoemkflen"
>               }
>          ]
>
> What if a third native app (TestApp3) needs token to access to TestRS1 
> and TestRS2. What the AppInfo will look like?
>           {
>                  "name": "TestApp3",
>                  "type": "native",
>                   "scope": "urn:oauth:testapp3",
>                  "default_scopes": ["com.testrs1"," com.testrs2"],
>                  "icon_uri": "http://www.example.com/pic3.png  <https://urldefense.proofpoint.com/v1/url?u=http://www.example.com/pic3.png&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=IOcogj9VVYIVG08Q5exet3ZcjD14eQZ74sW8TzsMe2w%3D%0A&s=53243901b8e92d8b52aacc98e188eaed013ff064f0df481ed2bfadfc9701efe7>",
>                  "custom_uri": "testapp3://callback-uri/"
>                  "bundle_id": "oejfiejfefjpefefefeifie"
>  }
>
> An app may request other scopes in it's call to the TA, and the AS 
> would need to validate those.
>
> It may be that we should rename scope to something like app_id_scope 
> or something like that to make the use clearer.
> I didn't change the name just clarified the use.
>
> John B.
>
>
> On Jul 5, 2014, at 10:21 AM, John Bradley <ve7jtb at ve7jtb.com 
> <mailto:ve7jtb at ve7jtb.com>> wrote:
>
>> Yes that is correct.
>>
>> The one thing that your example points out that needs to be clarified 
>> is what separator to use between scopes in the scope parameter.
>>
>> I had assumed that it would be the same as OAuth being a space 
>> separated list.
>> The other alternative to be more JSON friendly is to make it an array.
>>
>> There are advantages both ways.   I don't think comma separated is a 
>> good idea.
>>
>> Do people have a view on this.  I can update the text for the 
>> parameter today to make it clear one way or the other.
>> I think people have used space separated in the earlier interop 
>> though it was not specified in the earlier aza spec as far as I can see.
>>
>> John B.
>>
>> On Jul 5, 2014, at 12:37 AM, Emily Xu <exu at vmware.com 
>> <mailto:exu at vmware.com>> wrote:
>>
>>> Hi John,
>>>
>>> Thank you for sending me the latest spec. Hopefully my online 
>>> signing of the contributor agreement would work so I can post the 
>>> questions to the list.
>>>
>>> Actually the latest spec answered many of my questions. With one 
>>> thing that needs clarification.
>>>
>>> If I have two native apps, let's name them TestApp1 and TestApp2, 
>>> both need access token to access the same Resource Server (TestRS1). 
>>> Let's say the scope for TestRS1 is com.testrs1. What will be 
>>> returned from the AppInfo endpoint? Like something below? Please pay 
>>> special attention about the name and scope field.
>>>
>>> "apps": [
>>>              {
>>>                  "name": "TestApp1",
>>>                  "type": "native",
>>>                  "scope": "com.testrs1",
>>>                  "icon_uri": "http://www.example.com/pic1.png  <https://urldefense.proofpoint.com/v1/url?u=http://www.example.com/pic1.png&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=IOcogj9VVYIVG08Q5exet3ZcjD14eQZ74sW8TzsMe2w%3D%0A&s=8d88d0f30400fc8e2ebb6da27f97087042901f488d07933245f94322b9d22477>",
>>>                  "custom_uri": "testapp1://callback-uri/",
>>>        "bundle_id": "nkdf9hfknfih9enfen"      
>>>              },            {
>>>                  "name": "TestApp2",
>>>                  "type": "native",
>>>                  "scope": "com.testrs1",
>>>                  "icon_uri": "http://www.example.com/pic2.png  <https://urldefense.proofpoint.com/v1/url?u=http://www.example.com/pic2.png&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=IOcogj9VVYIVG08Q5exet3ZcjD14eQZ74sW8TzsMe2w%3D%0A&s=b773acca3bc95051fd4f690cec8fe08f7131a2dcc3b6761c224a77be30b92571>",
>>>                  "custom_uri": "testapp2://callback-uri/"
>>>                  "bundle_id": "jdfejfemfefpoemkflen"
>>>               }
>>>          ]
>>>
>>> What if a third native app (TestApp3) needs token to access to 
>>> TestRS1 and TestRS2. What the AppInfo will look like?
>>>           {
>>>                  "name": "TestApp3",
>>>                  "type": "native",
>>>                  "scope": "com.testts1, com.testrs2",
>>>                  "icon_uri": "http://www.example.com/pic3.png  <https://urldefense.proofpoint.com/v1/url?u=http://www.example.com/pic3.png&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=IOcogj9VVYIVG08Q5exet3ZcjD14eQZ74sW8TzsMe2w%3D%0A&s=53243901b8e92d8b52aacc98e188eaed013ff064f0df481ed2bfadfc9701efe7>",
>>>                  "custom_uri": "testapp3://callback-uri/"
>>>                  "bundle_id": "oejfiejfefjpefefefeifie"
>>>          }
>>>
>>> Thanks,
>>> Emily
>>>
>>> From: John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>>
>>> Date: Friday, July 4, 2014 1:40 PM
>>> To: Emily Xu <exu at vmware.com <mailto:exu at vmware.com>>
>>> Cc: Ashish Jain <ashishjain at vmware.com 
>>> <mailto:ashishjain at vmware.com>>, Paul Madsen 
>>> <pmadsen at pingidentity.com <mailto:pmadsen at pingidentity.com>>
>>> Subject: Fwd: Openid-specs-native-apps post from exu at vmware.com 
>>> <mailto:exu at vmware.com> requires approval
>>>
>>> You will need to submit a contribution agreement to post to the list.
>>> The one Ashish put in only covers him 
>>> http://openid.net/wordpress-content/uploads/2013/11/Ashish-Jain-Native-App-WG-Contribution-Agreement.pdf 
>>> <https://urldefense.proofpoint.com/v1/url?u=http://openid.net/wordpress-content/uploads/2013/11/Ashish-Jain-Native-App-WG-Contribution-Agreement.pdf&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=qIzRydcbKK0gy5xOc475BldnodzIIhQpKNG5XgyrnkI%3D%0A&s=a4265c94e7b15e19e77fcb669a0616168004a0df8017c7086664ad5df059e815>
>>>
>>> The link for the contributor agreement is at: 
>>> http://openid.net/intellectual-property/ 
>>> <https://urldefense.proofpoint.com/v1/url?u=http://openid.net/intellectual-property/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=qIzRydcbKK0gy5xOc475BldnodzIIhQpKNG5XgyrnkI%3D%0A&s=de0d6c9d029cfd5084fdf3b2a3fe2479dd5edcb97e0d8071e140293ba6aeb36f>
>>>
>>> Once you do that I can release the post to the list.
>>>
>>> I have some comments inline
>>>
>>> The current Spec is at: 
>>> http://openid.bitbucket.org/draft-native-application-agent-core-01.html 
>>> <https://urldefense.proofpoint.com/v1/url?u=http://openid.bitbucket.org/draft-native-application-agent-core-01.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=qIzRydcbKK0gy5xOc475BldnodzIIhQpKNG5XgyrnkI%3D%0A&s=f297fc78e206a9cbcd353cc5beeab8eca15647cbc3f1843fded8a3fdd2b20c33>
>>>
>>> Begin forwarded message:
>>>
>>>> *From: *openid-specs-native-apps-owner at lists.openid.net 
>>>> <mailto:openid-specs-native-apps-owner at lists.openid.net>
>>>> *Subject: **Openid-specs-native-apps post from exu at vmware.com 
>>>> <mailto: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 
>>>> <mailto: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 
>>>> <mailto:Openid-specs-native-apps at lists.openid.net>
>>>>    From: exu at vmware.com <mailto: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 
>>>> <https://urldefense.proofpoint.com/v1/url?u=http://lists.openid.net/mailman/admindb/openid-specs-native-apps&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=qIzRydcbKK0gy5xOc475BldnodzIIhQpKNG5XgyrnkI%3D%0A&s=c14b20f7d866a1def4b3fe7602557909d895305fde25120675e6f2b6586b88f3>
>>>>
>>>> to approve or deny the request.
>>>>
>>>> *From: * Emily Xu <exu at vmware.com <mailto: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 
>>>> <mailto:openid-specs-native-apps at lists.openid.net>" 
>>>> <openid-specs-native-apps at lists.openid.net 
>>>> <mailto: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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From: * openid-specs-native-apps-request at lists.openid.net 
>>>> <mailto:openid-specs-native-apps-request at lists.openid.net>
>>>> *Subject: **confirm 076f42cf7666c4fb6036fcd427d6cad59b11b641*
>>>> *Date: * July 4, 2014 at 11:34:44 AM GMT-4
>>>>
>>>>
>>>> If you reply to this message, keeping the Subject: header intact,
>>>> Mailman will discard the held message.  Do this if the message is
>>>> spam.  If you reply to this message and include an Approved: header
>>>> with the list password in it, the message will be approved for posting
>>>> to the list.  The Approved: header can also appear in the first line
>>>> of the body of the reply.
>>>>
>>>
>>
>
>
>
> _______________________________________________
> 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/20140707/0465a3af/attachment-0001.html>


More information about the Openid-specs-native-apps mailing list