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