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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
