John - two separate issues here -
(i) for the symmetric key case, whether we need a key distribution
method for the client and AS/RS, and if so, what form should it take?
(ii) asymmetric case is quite different, I agree with your point - the
client could be pre-provisioned with a managed key pair (many enterprise
cases)
or generate them ephemerally. We dont need a key distribution method here.
Unfortunately, its hard to get away from the symmetric key case, maybe
this will change once we have widespread support for ecc.
- prateek
Remember that proof of possession is intended to prove that the client that was
issued the token is the one presenting it.
We tend to mix that up with replay and other protection issues.
To do this you don't need to authenticate the client.
The client can prove it controls a key by signing something for the
Authorization server, the AS then includes the public key in the JWS access
token. The client then produces a hash over some number of elements and signs
that with its private key in a JWS.
With asymmetric there is no need for the AS to produce the key. Having the
client produce the key pair is quite traditional proof of possession.
The RS only needs to verify the access token in the way a RS would normally all
the key distribution can be public as it is public keys.
I have always found the symmetric proof of possession mechanisms to be
painfully complex to do properly with DH etc.
Encrypting the symmetric key to the RS would work but relays on an implicit
assumption about what RS the client may present the token to otherwise all the
RS have to share private keys(probably a bad thing)
John B.
On 2013-02-14, at 4:20 PM, Prateek Mishra <prateek.mis...@oracle.com> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
