[Openid-specs-native-apps] native app validation
John Bradley
ve7jtb at ve7jtb.com
Sun Jul 6 23:49:38 UTC 2014
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",
"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",
"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",
"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> 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> 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",
>> "custom_uri": "testapp1://callback-uri/",
>> "bundle_id": "nkdf9hfknfih9enfen"
>> },
>> {
>> "name": "TestApp2",
>> "type": "native",
>> "scope": "com.testrs1",
>> "icon_uri": "http://www.example.com/pic2.png",
>> "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",
>> "custom_uri": "testapp3://callback-uri/"
>> "bundle_id": "oejfiejfefjpefefefeifie"
>> }
>>
>> Thanks,
>> Emily
>>
>> From: John Bradley <ve7jtb at ve7jtb.com>
>> Date: Friday, July 4, 2014 1:40 PM
>> To: Emily Xu <exu at vmware.com>
>> Cc: Ashish Jain <ashishjain at vmware.com>, Paul Madsen <pmadsen at pingidentity.com>
>> Subject: Fwd: Openid-specs-native-apps post from 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
>>
>> The link for the contributor agreement is at: http://openid.net/intellectual-property/
>>
>> 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
>>
>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: 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.
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140706/69ed9738/attachment-0001.html>
More information about the Openid-specs-native-apps
mailing list