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

[Michael Thomas <[e-mail]>]

On 12/19/2011 09:50 AM, Paul Madsen wrote:
> Hi Mike, to some extent I think my question is not about specific 
> security characteristics, but rather whether its realistic for our 
> group to mandate that both server & native clients have the *same* 
> security characteristics - particularly the ability to 'securely' 
> authenticate to the AS on the token endpoint.

Well given the explanation Justin just gave, they do not. As I understand
your initial query, redefining a native/embedded app as "confidential" 
doesn't
alter that reality. But my first question about requirements still is 
relevant:
what are you trying to protect from whom, and what is the level of risk that
your profile of oauth is willing to tolerate?

Mike

>
> thanks
>
> paul
>
> On 12/19/11 12:18 PM, Michael Thomas wrote:
>> On 12/19/2011 04:19 AM, Paul Madsen wrote:
>>> 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?
>>
>> Hi,
>>
>> Can you say exactly what your security requirements are before trying 
>> to determine which
>> (if either) is the right answer? I've got some concerns in this area 
>> that I'm trying to understand
>> and am not sure if they're related to your concern or not. Part of 
>> this is that I really don't
>> understand what the difference is between a "public" client and a 
>> "confidential client" and
>> rereading the draft isn't helping me. In particular, can a iPhone app 
>> with a UIWebView *ever*
>> be a "confidential" client, and if so how?
>>
>> Mike