[Openid-specs-native-apps] Identifying applications.

Tue Oct 7 00:32:08 UTC 2014

So we are thinking about using audience parameter to identify Resource Server/Downstream AS, and using scope to identity the actual scope such as read or write for that audience(Resource Server). Is my understanding correct? Do we have a draft reflexing these changes?

Thanks,
Emily

From: John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>
Date: Monday, October 6, 2014 5:20 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: [Openid-specs-native-apps] Identifying applications.

Some API may have standardized scopes.   If you have multiple places that support the same API you wind up trying to create structured scope names again.
Also in the case of asking for a id_token to be used at a downstream AS you need to specify an audience for that token.

In a tightly controlled enterprise perhaps overloading scope will work, but once you allow any sort of federation I think you need to separate the resource provider from the permissions.

We are having to do that for proof of possession tokens in OAuth anyway, as scope is not specific enough for the AS to know what keying material to use without inventing structured scopes.

John B.

On Oct 6, 2014, at 5:14 AM, Emily Xu <exu at vmware.com<mailto:exu at vmware.com>> wrote:

Is it reasonable to assume that we agree that we need some kind of mechanism to identify an application? We can call it app identifier, azp, or something else. Its value is to be specified. In the minimum, we could use iOS bundle_id or Android package name as its value because this is something that a TA could verify.

Also, do we agree that we could move app identifier out of scope parameter? By doing so, scope can be used to identify token scope therefore there would be no need for the default_scope parameter.

Thanks,
Emily

From: William Denniss <wdenniss at google.com<mailto:wdenniss at google.com>>
Date: Friday, August 8, 2014 2:07 PM
To: Mike Varley <mike.varley at securekey.com<mailto:mike.varley at securekey.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: [Openid-specs-native-apps] Identifying applications.

I think we can rely on the OS-level assertions to a certain extent – Bundle ID on iOS, Package Name + Signature on Android.  Google does this today in its OAuth for Installed Applications implementation.

John's point about an attacker potentially being able to upload an app with a bundle-id matching an enterprise app to the App store is valid. To counter that, it may be recommended for the enterprise to create a normal Developer Account (~$100/yr) just to register the bundle ID (enterprise accounts don't have this functionality it seems<https://urldefense.proofpoint.com/v1/url?u=http://stackoverflow.com/a/8879763/72176&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=JgtwqYPnJDh1Lz6okAsTOj4ursW3h5fdLL4h2jq4jpw%3D%0A&s=b9fcebcc3c63d80448de7ea9643ff94eea849362d634de44ba522664f99a2d54>).  In general I'd say it's fairly safe even without doing that – for the attack to work, you'd have to get through Apple's review process, and still convince the user to download & use the app.

William

On Fri, Aug 8, 2014 at 6:24 AM, Mike Varley <mike.varley at securekey.com<mailto:mike.varley at securekey.com>> wrote:
Verifying an App identity on any given mobile platform seems to be a challenge - should the spec define its own mechanism for verifying an App identity? or is that too much scope creep?

(something like the proof-of-possession spec for OAuth 2.0…)

MV

On Aug 7, 2014, at 2:46 PM, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:

Hi William,

Thanks that is useful information.

My concern is that a large user of this may be enterprises.
A enterprise creating app x for there enterprise store might be subverted by a app in a public store.

I can see an attacker sending a email link to an employee at company x saying down load this one time free app, that impersonates the app name of some internal HR or finance application.

It will at minimum need to be a security consideration, I think.

Regards
John B.

On Aug 6, 2014, at 8:58 PM, William Denniss <wdenniss at google.com<mailto:wdenniss at google.com>> wrote:

On Wed, Aug 6, 2014 at 4:15 PM, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:

Can people comment on what needs to be passed to uniquely identify an app on iOS , Android and Windows mobile.

For iOS it is the bundle identifier. These are globally unique within the Apple ecosystem.  I verified this by attempting to create a new app using a known bundle identifier of another app, and got the error: "The Bundle ID you entered has already been used.".

The bundle identifier is passed by the OS during inter-app communication in the UIApplicationDelegate/application:openURL:sourceApplication:annotation:<https://urldefense.proofpoint.com/v1/url?u=https://developer.apple.com/library/ios/documentation/uikit/reference/UIApplicationDelegate_Protocol/Reference/Reference.html%23//apple_ref/occ/intfm/UIApplicationDelegate/application:openURL:sourceApplication:annotation:&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=JgtwqYPnJDh1Lz6okAsTOj4ursW3h5fdLL4h2jq4jpw%3D%0A&s=4803172c5cc6945c87a2e78cbe447eff72e89091948bcba9bfecd161f621eeae>  method which can be used to restrict which apps you interact with. This has applications similar to whitelisting javascript origins and redirect URIs.

On Android, the package name – very similar in concept to the iOS bundle identifier – is also globally unique (docs<https://urldefense.proofpoint.com/v1/url?u=http://developer.android.com/guide/topics/manifest/manifest-element.html%23package&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=JgtwqYPnJDh1Lz6okAsTOj4ursW3h5fdLL4h2jq4jpw%3D%0A&s=804445de26d9997902160280f7df552df19d6b35543a6f6417791550c9c63134>). Two apps on the Play Store cannot have the same package name.

As Android allows apps from unknown sources, the OS level assertion of the bundle identifier is less authoritative than on iOS, which is why it may be advisable to also verify the application signature. It is theoretically possible to distribute an iOS app with a conflicting bundle identifier, but it would have to be distributed outside the App Store which is hard (Enterprise, AdHoc or development builds – none which can achieve wide distribution).

William

_______________________________________________
Openid-specs-native-apps mailing list
Openid-specs-native-apps at lists.openid.net<mailto:Openid-specs-native-apps at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-native-apps<https://urldefense.proofpoint.com/v1/url?u=http://lists.openid.net/mailman/listinfo/openid-specs-native-apps&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=JgtwqYPnJDh1Lz6okAsTOj4ursW3h5fdLL4h2jq4jpw%3D%0A&s=d35d90f7cdcb9e3c8f0c2390a613664285b6db3c671c43a81f8f3437e72da443>

_______________________________________________
Openid-specs-native-apps mailing list
Openid-specs-native-apps at lists.openid.net<mailto:Openid-specs-native-apps at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-native-apps<https://urldefense.proofpoint.com/v1/url?u=http://lists.openid.net/mailman/listinfo/openid-specs-native-apps&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=JgtwqYPnJDh1Lz6okAsTOj4ursW3h5fdLL4h2jq4jpw%3D%0A&s=d35d90f7cdcb9e3c8f0c2390a613664285b6db3c671c43a81f8f3437e72da443>

_______________________________________________
Openid-specs-native-apps mailing list
Openid-specs-native-apps at lists.openid.net<mailto: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/20141007/96217c20/attachment-0001.html>