[Openid-specs-native-apps] Bundle ID?

John Bradley ve7jtb at ve7jtb.com
Fri Aug 1 16:13:47 UTC 2014


If the app_info endpoint returns multiple values for the app on different platforms and the TA normalizes that to a single value to send as scope or "azp" the AS will need to reverse that out to figure out that the request is for app x on OS y based on the client_id of the TA.   

That is certainly possible,  however I suspect Emily will likely take the view that sending the value directly to the AS saves the TA having to normalize the value and the token_endpoint reversing the process by looking at the OS for the TA client_id.

If sending the value directly then we probably need to prepend a namespace to the value to avoid collisions though one suspects the values have enough entropy to avoid collisions naturally,  it is best to namespace them from the start.

I don't hold a strong view one way or another.

Yes applications registering redirect_uri for other apps with the OS creates the opportunity for them to intercept responses.

We had talked about using a mechanism like https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/ 
That has just been accepted as a OAuth WG item.

While being slightly different in that it is focused on code it is essentially the same issue.

I agree that adding a method to prevent token interception in the callback is important.

The other thing that can be used in a environment requiring higher security is to use PoP tokens.
https://datatracker.ietf.org/doc/draft-bradley-oauth-pop-key-distribution/
https://datatracker.ietf.org/doc/draft-richer-oauth-signed-http-request/

In that a client could provide a thumbprint of a public key/ or the key itself to the TA and have that bound to the access token and proof of possession provided on access to the RS.

I haven't added that to the draft yet.

If people have thoughts, please send them to the list.

John B.





On Aug 1, 2014, at 10:00 AM, Lloyd Burch <LBurch at netiq.com> wrote:

>  I think that it is important that the AS knows what platform the application is on.  The policy could be different from iOS to Android or some other platform.  This would mean that there would be multiple tag names not one, such as bundle_id, package_name, or some_other_id.  This also takes care of name space conflicts. 
>  
> This brings up my next question.  The TA can use the bundle_id (iOS) to know the identity of the calling application, but when the TA calls the application to return the authentication token there is a problem with spoofing and a hacker application make get a valid authentication token.  Application could setup a shared secret with the AS, and the authentication token could be encrypted, but that require more setup, and key sharing on the mobile application and AS.
>  
> Here is an method that may provide a solution.
>  
> 1. Each time the application calls the TA and request a authentication token, it generates a random key and selects a encryption method such as AES, XOR or any standards base encryption.  As part of the call to the TA the application sends the random key and encryption method to the TA.  The TA verifies that it and use the encryption requested and remembers the key for this request.
>  
> 2. When the TA sends the authentication token back to the application it uses the random key and encryption method to encrypt the token.  If the application is not the application that sent the request it can not use the authentication token, if it is, it decrypts the token and uses it as define.
>  
> These fields may be optional for the application to send.  This solution does require that the application makes a request of the TA before the TA returns a authentication token.
>  
> Does this solve the problem of application spoofing, is there a better way?
>  
> Lloyd Burch
>  
>  
>  
>  
> Openid-specs-native-apps mailing list
> Openid-specs-native-apps at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
> 
> 
> >>> Emily Xu <exu at vmware.com> 7/31/2014 7:44 PM >>>
> I would prefer the raw identifier because this way, we could avoid the requirement of TA to always download app info first.
> Thanks,
> Emily
> From: John Bradley <ve7jtb at ve7jtb.com>
> Date: Thursday, July 31, 2014 4:59 PM
> To: Emily Xu <exu at vmware.com>
> Cc: "Preibisch, Sascha H" <Sascha.Preibisch at ca.com>, "openid-specs-native-apps at lists.openid.net" <openid-specs-native-apps at lists.openid.net>
> Subject: Re: [Openid-specs-native-apps] Bundle ID?
> If we always pass the value to the AS then I suppose that sending the value to the TA via the appinfo endpoint becomes mostly used as a key to look up information about the app for creating a UI, rather than as a security check in itself.
> If we follow that line of thought we would need rules for encoding the various versions of package name as a URI safe parameter and avoid naming collisions between the namespaces.
> eg ios-(base64url encoded bundle_id)
> So the question is if the identifier for the app form a OS perspective is derefrenced to a app name in the TA by a lookup from the app_unfo endpoint, or the raw identifier passed to the AS and mapped to a app at that end?
> John B.
> On Jul 31, 2014, at 7:47 PM, Emily Xu <exu at vmware.com> wrote:
> 
>> Right. I just confirmed from my AirWatch colleague, TA could validate a native app's bundle id or package name. However, it is AS who holds the truth about which native app (identified by bundle id or package name) is authorized to receive tokens. So we should allow an AS to do the authorization check, but let TA do the bundle id/package name validation.
>> Thanks,
>> Emily
>> From: John Bradley <ve7jtb at ve7jtb.com>
>> Date: Thursday, July 31, 2014 2:46 PM
>> To: "Preibisch, Sascha H" <Sascha.Preibisch at ca.com>
>> Cc: "openid-specs-native-apps at lists.openid.net" <openid-specs-native-apps at lists.openid.net>
>> Subject: Re: [Openid-specs-native-apps] Bundle ID?
>> In the draft I worked on prior to CIS, I put in the bundle_id value in the app_info response as a way to identify a native app.
>> The previous draft relied only on the redirect_uri for the app and that is not as secure as one would hope.
>> bundle_id i think came from the IOS demo app we were looking at.
>> We have a couple of choices given that the AS needs to likely support the same app across multiple OS.
>> The app Info can return multiple os specific values eg bundle_id for iOS and package_name for android, or we could make the AS responsible for informing the app_info endpoint what OS the TA making the request is running on so it can put the correct value in a generic parameter like app_id.
>> Using a generic app_id will make the app_info endpoint a bit more complicated as it needs to return a response per user+platform vs just per user.
>> When I picked the name I was personally thinking that multiple values were the way to go.
>> As a WG we can go either way.
>> The other thing to consider is that VMWare was thinking that some TA won't be building a desktop to invoke apps.  
>> They would like to have a simple option of using the verified bundle_id or package_name as the identifier for the app in the request to the token endpoint rather than having the TA mapping from bundle_id to scope.
>>  
>> Note I am currently working to update the draft to move the identifier for the client app from a scope value to a separate "azp" (authorized party) parameter in the request to the token endpoint.
>> Some people felt that overloading scope to identify the app making the request to the TA was a bit too much overloading.
>> John B
>> On Jul 31, 2014, at 4:57 PM, Preibisch, Sascha H <Sascha.Preibisch at ca.com> wrote:
>> 
>>> I personally think that, whenever possible and appropriate, the goal should be to keep the terminology simple. If the spec. should be generic enough for "any" plattfom I still think a generic name like app_id would work fine.
>>> As you said, the value may not be the same, but the concept behind it is the same (identifying an app).
>>> Sascha
>>> CA Technologies
>>> Sascha Preibisch, Principal Software Engineer
>>> Mobile Access Gateway
>>> sascha.preibisch at ca.com
>>> From: David Waite [david at alkaline-solutions.com]
>>> Sent: Thursday, July 31, 2014 1:04 PM
>>> To: Preibisch, Sascha H
>>> Cc: Chuck Mortimore; Paul Madsen; openid-specs-native-apps at lists.openid.net
>>> Subject: Re: [Openid-specs-native-apps] Bundle ID?
>>> It sounds like the value would not likely be the same on both platforms, so perhaps bundle id is appropriate on iOS and package name (or signing fingerprint) would be appropriate on android?
>>> -DW
>>> On Jul 31, 2014, at 12:18 PM, Preibisch, Sascha H <Sascha.Preibisch at ca.com> wrote:
>>> 
>>>> I had a chat with our iOS and Android developers.
>>>> bundle_id is only known on iOS. On Android the equivalent is package_name. The Android developer said that bundle_id would be very confusing in his environment.
>>>> Both suggested a generic term  like "app_id" which would be explained in the "Terminology" section.
>>>> Regards,
>>>> Sascha
>>>> CA Technologies
>>>> Sascha Preibisch, Principal Software Engineer
>>>> Mobile Access Gateway
>>>> sascha.preibisch at ca.com
>>>> From: openid-specs-native-apps-bounces at lists.openid.net [openid-specs-native-apps-bounces at lists.openid.net] on behalf of Chuck Mortimore [cmortimore at salesforce.com]
>>>> Sent: Thursday, July 31, 2014 8:23 AM
>>>> To: Paul Madsen
>>>> Cc: openid-specs-native-apps at lists.openid.net
>>>> Subject: Re: [Openid-specs-native-apps] Bundle ID?
>>>> iOS.   I believe on Android we'd capture a cert hash, but it's been awhile so the platform may have evolved since our last research 
>>>> On Jul 31, 2014, at 4:23 AM, Paul Madsen <paul.madsen at gmail.com> wrote:
>>>>> the latest spec introduces the bundle id parameter as a means of distinguishing applications
>>>> 
>>>> http://openid.bitbucket.org/draft-native-application-agent-core-01-working-draft.html
>>>> bundle_id
>>>> OPTIONAL (String). This is a string that the TA uses to validate the identity of the invoking application. This is RECOMMENDED if the "type" is "native"
>>>> Is this term appropriately generic across the mobile OSs? or is it specific to iOS?
>>>> paul
>>>> _______________________________________________
>>> 
>>> Openid-specs-native-apps mailing list
>>> Openid-specs-native-apps at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
>> _______________________________________________
>> 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/20140801/a2d2e38b/attachment-0001.html>
-------------- 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/20140801/a2d2e38b/attachment-0001.p7s>


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