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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
