Re: [OAUTH-WG] Native clients & 'confidentiality'

[Eran Hammer <[e-mail]>]

The text is pretty straight forward in its intentions. A confidential client must had a secret - what's open is how well the secret needs to be protected (e.g. hard to extract) to qualify as 'capable of keeping' secrets. You can require all clients to be confidential, but without specifying what qualifies as confidential, this requirement is pretty useless. It eliminates clients without secrets, or open source clients with the client id hardcoded and visible, but some can claim that a obfuscated secret in a native application binary is good enough. They will be wrong, but the spec allows them to make that decision.

EHL

From: [e-mail] [mailto:[e-mail]] On Behalf Of Paul Madsen
Sent: Monday, December 19, 2011 4:19 AM
To: [e-mail]
Subject: [OAUTH-WG] Native clients & 'confidentiality'

Hi, the Online Media Authorization Protocol (OMAP) is a (as yet unreleased) profile of OAuth 2.0 for online delivery of video content based on a user's subscriptions (the TV Everywhere use case)

We want to support both server & native mobile clients. It is for the second class of clients that I'd appreciate some clarification of 'confidentiality' as defined in OAuth 2.

OAuth 2 distinguishes confidential & public clients based on their ability to secure the credentials they'd use to authenticate to an AS - confidential clients can protect those credentials, public clients can't.

Notwithstanding the above definition, the spec gives a degree of discretion to the AS



   The client type designation is based on the authorization server's

   definition of secure authentication and its acceptable exposure

   levels of client credentials.




Give this discretion, is it practical for the OMAP spec to stipulate that 'All Clients (both server & native mobile), MUST be confidential', ie let each individual OMAP AS specify its own requirements of clients and their ability to securely authenticate?

Is this consistent with the OAuth definition of confidentiality?

Thanks

Paul