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

Tue Oct 7 00:06:56 UTC 2014

Thank you for the reply John.

Could you clarify on the audience part? What is the difference between scope and audience?

Thanks,
Emily

From: John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>
Date: Monday, October 6, 2014 5:04 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.

On Android package name is not unique, it needs to be used with the signer.

The bundleID is unique on iOS as long as you are using the apple store,  side-loaded apps from enterprise app stores may have duplicate bundleID.

The sense I get is that people think the issue on iOS can be managed by some sort of enterprise policy enforcement, so we should't fixate on it.

So yes on some sort of mechanism to identify an application to the AS.

Yes moving that identifier out of a scope into a dedicated parameter seems to be relatively uncontroversial.
The same thing with moving audience into a dedicated parameter.

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/7da3699b/attachment-0001.html>