Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)

["Manger, James" <[e-mail]>]

> http://tools.ietf.org/html/draft-jones-oauth-proof-of-possession-00


A new registry for "cnf" members is a bit strange. A JWT Claim Set has so far been a flat structure, with metadata such expiry date "exp" alongside claims such as "given_name". This spec starts introducing structure by wrapping members in a "cnf" (confirmation) object. It is not clear to me which new things would go in "cnf" versus going in to the top-level of the JWT claim set. Both locations have a "MUST ignore" policy for unrecognized members.


   "(In some applications, the subject identifier will be relative
   to the issuer identified by the "iss" (issuer) claim.)"

This isn’t very helpful as it gives no hint about when this is or isn’t the case. I guess this is just rewording a flaw from JWT.


Could the JWE example please include a "kid"? The recipient needs to know which key to use to decrypt the message. JWS says we SHOULD do this [JWS §6 2nd paragraph]. [P.S. Weren’t we going to include "kid" is almost all the examples in JWE?]

You may as well drop the "cty":"jwk+json" member as this is implied by the JOSE message being the value of a "jwk" member.


OpenID Connect has already defined a "sub_jwk" field that performs a similar role to "cnf":{"jwk"}.
[http://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedResponse]


Perhaps the biggest security consideration is missing: "cnf" may be ignored. A recipient that doesn't understanding "cnf" is likely to accept a JWT as a bearer token without doing any proof-of-possession.

--
James Manger