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

From: Eran Hammer <[email-masked]>
Date: Mon, 9 Jan 2012 09:17:30 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Madsen
Sent: Monday, December 19, 2011 4:19 AM
To: [email-masked]
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

---

From: Paul Madsen <[email-masked]>
Date: Mon, 09 Jan 2012 13:54:48 -0500

Thanks Eran and others for their responses

FWIW & FYI, OMAP decided to phrase requirements more directly in terms 
of authentication to the AS (MUST for web app clients & SHOULD for 
native clients) rather than use the confidential/public distinction.

Thanks again for your input

Paul

On 1/9/12 11:17 AM, Eran Hammer wrote:
>
> 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:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Paul Madsen
> *Sent:* Monday, December 19, 2011 4:19 AM
> *To:* [email-masked]
> *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.
>
> Give this discretion, is itpractical 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?
>