Thanks for the comments, James. Comments inline marked with "Mike>".
-----Original Message----- From: OAuth [mailto:[email protected]] On Behalf Of John Bradley Sent: Wednesday, April 02, 2014 6:45 AM To: Manger, James Cc: [email protected] Subject: Re: [OAUTH-WG] Proof-Of-Possession Semantics for JSON Web Tokens (JWTs) Thanks for the feedback. inline On Apr 2, 2014, at 1:50 AM, Manger, James <[email protected]<mailto:[email protected]>> wrote: >> 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. This is the first draft so this needs to be fleshed out. The idea is to have a single object that contains what in SAML would be the subject confirmation information. I expect hat the protocols using this are going to determine what claims need to go in cnf. As an example for bearer tokens there might be an expirey time for presentment that is separate from the tokens lifetime as represented by "exp" at the top level. This may not be a great example as people in general don't understand the difference between the two exp in SAML:) But in general cnf contains claims that are required to confirm that the presenter is the subject/issuer or a designated agent. Mike> Another possible example is that a "kid" (Key ID) value might be used in the "cnf" (confirmation) object, rather than including the key directly. This actually matches the SAML construct in which the SubjectConfirmation element contains a KeyInfo element that contains a KeyName element, rather than the key value. In this case, you need the "kid" to be within the "cnf" object to distinguish it from the "kid" referring to the signing key. > > > "(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. This is one thing we have been wrangling over the wording of. In the simple case where there is a "sub" then the key represents the proof key of the presenter or a authorized agent on there behalf. There are some slippery bits even in that as it is the recipient that is trusting the issuer to put in the correct cnf information. Especially in cases where there may be multiple hops the key may be that of a RS that the user has no direct trust relationship with. In the case where there is no subject, I tend to think of the JWT as having a implicit subject that is the issuer as that is really the only thing the claims could be about in the absence of a explicit subject. A JWT without a subject could have a claim about a user that is logged into me but the me is the issuer. So as in the case of there being no explicit subject the cnf is of the iss or a agent it has designated. In principal if a intermediary receives the token and sends it to a STS like service the resulting JWT would then have the STS as the iss and the original iss as the sub. Though that is outside of this spec. Trying to come up with a simple explanation without dragging a bunch of other stuff in to the spec is not easy. Perhaps something more like the cnf must evaluate to true for the presenter of the JWT otherwise the token is not being presented by a party authorized by the issuer, given that the recipient's primary trust relationship is with the issuer. Trying to say who the presenter is may just be too confusing at this level. Thoughts and wording input appreciated. Mike> I agree with John that it's up to applications using this spec to say who the presenter is - just like it's up to applications using JWT to specify what the values of the "iss" and "sub" fields are for that application, and which of them are required. That said, suggestions on how to make this clearer would of course be welcomed. > > > 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?] Yes it should include a "kid" Mike> You mean adding a "kid" to the JWE Header? Yes, I can do that in the next revision. (No "kid" is needed in the proof-of-possession key because it's passed by value, so there's no ambiguity what the key is.) > > 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. > It may be useful to libraries processing the JWE. Mike> I agree with James that, in context, it's already known that the content type of the JWE Plaintext is a JWK, and so this can be dropped (which is allowed in the JWK spec). > > 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] As you have pointed out connect self Issued needs an errata to address a problem anyway. They are similar though the self issued case is more like a JWT that would be used as a proof mechanism rather than as a pop token itself. Perhaps there is a case where the iss is using it's signing key for signing the token and via tls channel binding for presentment as an example. The connect case doesn't require a presentment proof so is a bit different. I take your point and will think about it a bit more. > > > 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. > I think the protocol using the JWT would likely be where the requirement would be enforced along with the presentment mechanism. Mike> I agree with John here. I can easily imagine use cases in which it's up to the recipient how often to check possession. For instance, it might decide to incur the additional overhead only if possession hadn't been checked for longer than a certain time threshold. We don't want to preclude those use cases. -- Mike John B. > -- > James Manger > _______________________________________________ > OAuth mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
