Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

[Justin Richer <[e-mail]>]

Prateek,

My point was that a public client could very easily and safely be issued 
a secret in the form of an OAuth token. This includes any type of 
signing key that the MAC/etc token would want to use. What public 
client's can't have are configuration-time keys, like a client_secret. 
It's important to not conflate the two.

  -- Justin

On 02/14/2013 02:20 PM, Prateek Mishra wrote:
> Justin - my comment was scoped to *key distribution* - not to the 
> general use of public clients.
>
> I was wondering how one can distribute keys or have key agreement 
> between an AS and a client, if there is no existing trust relationship 
> between them. Maybe there is some
> clever crypto way of achieving this, but I personally dont understand 
> how this might happen.
>
> - prateek
>
>>
>>>> 2) Regarding (symmetric) key distribution, dont we need some kind 
>>>> of existing trust relationship between the client and AS to make 
>>>> this possible? I guess it
>>>> would be enough to require use of a "confidential" client, that 
>>>> would make it possible for the two parties to agree on a session 
>>>> key at the point where an access token
>>>> is  issued by the AS.
>>> That's a very good question. I have not formed an option about this 
>>> issue yet particularly given the recent capability to dynamically 
>>> register clients.
>>
>> I don't think that signing tokens should require confidential 
>> clients. This was one of the implementation issues with OAuth 1, as 
>> it required a "consumer_secret" at all times. This led to Google 
>> telling people to use "anonymous" as the "consumer_secret" for what 
>> were effectively public clients. Even with dynamic registration, 
>> there's still a place for public clients, in my opinion.
>>
>