Hi
On 26/06/14 13:42, Hannes Tschofenig wrote:
Hi all,
I read through three of the OAuth proof-of-possession documents and made
a few minor changes here and there (mostly editorial & updated references).
Here are the three docs:
http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02
http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01
http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01
While there are a few open issues I believe that these three documents
are in fairly good shape.
Is someone willing to do a review?
Few comments to
https://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01:
- it is unclear what the new token_type if any is introduced, for
example, the section 6 says no new token type is introduced, while the
symmetric example uses a "pop" value and the assymetric key response
example says:
"The new token type "public_key" is placed into the 'token_type' parameter"
Is the new type is actually introduced and it is "pop" and the clients
making the requests to RS should use a "POP"/"pop" scheme ?
http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-01
uses "pop" but I'm not 100% sure...
- The assymetric key example suggests that just a JWS-signed access
token is returned. This implies a client can easily introspect it -
which is not a big problem in this case - but it leads the client toward
writing a code that is bound to an access token structure - therefore
such a client code won't inter-operate with the AS sending a bearer
token; IMHO the access token structure should absolutely be opaque to
the clients, i.e, if it is JWT then it must be JWE protected
Thanks, Sergey
Ciao
Hannes
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
