Thanks for your review, Radia. I've added the working group to the thread so that they're aware of your comments.
> From: Radia Perlman [mailto:radiaperl...@gmail.com] > Sent: Monday, September 29, 2014 4:46 PM > To: sec...@ietf.org; The IESG; draft-ietf-oauth-jwt-bearer....@tools.ietf.org > Subject: Secdir Review of draft-ietf-oauth-jwt-bearer-10 > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document is one of a set of documents specifying how to use JSON > formatted OAuth bearer tokens in the context of HTTP requests. > > It specifies two contexts in which these JSON tokens can be used: as > Authorization Grants or for Client Authentication. It specifies the > to-be-IANA-registered parameters used to specify that the type of token > presented is a JSON token (within the HTTP header). It also specifies the > checks to be done to validate that the JSON token is valid (though I would > expect this information would also be specified in the JSON token > specification itself). You're right that some of the validation rules are in draft-ietf-oauth-json-web-token, which defines the basic JWT token format, however this specification adds some additional validation rules because it requires that some fields be present that are optional in the JWT spec, and it specifies that they be used in a particular way. > There are security considerations and privacy considerations sections, but > they are very light. That is because it refers to > draft-ietf-oauth-assertions-17, which has a more complete security > considerations section. I guess it's appropriate to have more detailed > security considerations there, since all this specification adds is some > labels. Yes, this was the intent. Most of the security considerations are independent of the token type. > Would it make sense to merge this document with the other specs, rather than > having this be so redundant with the others? No, because while there's semantic commonality, the syntax of the SAML profile and the JWT profile are different. Merging them would make it much harder to read because it would be full of conditionals depending upon which token format was being described. > Some details: > > On page 3 para 2, it says “The format and processing rules for the JWT > defined in this specification are intentionally similar, though not > identical, to those in the closely related SAML 2.0 Profile for OAuth.” It > would be good if they specified what the differences are, and why they > couldn't be identical. That's a fair point. I'll look into this with the other editors and the working group. The following comments in the JWT profile spec record SAML features used for which no equivalent JWT feature exists. This might be good material to put into an appendix. <!-- No equivalent to SubjectConfirmation Method "urn:oasis:names:tc:SAML:2.0:cm:bearer at present --> <!-- No equivalent to SubjectConfirmationData Recipient at present --> <!-- No equivalent to SubjectConfirmationData Address at present --> <!-- No equivalent to AuthnStatement at present --> > Some background guidance on when you would want to use a token for client > authentication vs. when you would want to use one for an authorization grant > would be useful. In practice, the distinction between the two is subtle. It > is common for a token to contain the caller’s identity as well as group > memberships and perhaps roles. I suspect the reality is that the client has > to figure out which protocol slot the server wants to get the token in and > provide it there, where service designers make the decision more or less > arbitrarily. This guidance really belongs in the generic assertions specification draft-ietf-oauth-assertions. I'll plan on reviewing that spec with the other editors and the working group to see whether the guidance provided there needs to be improved. > Page 6 item 4: “The authorization server MAY reject JWTs with an “expiration” > claim that is unreasonably far in the future.” This is saying that the > validator of the token might choose to reject tokens that are long lived. > It’s not clear what the user of this spec can do with this information. It > calls for some out-of-band communication between the token issuer and the > token validator on what is an acceptable expiration period. Unless the > protocol has some way of reporting this back so that the caller can get a > shorter-lived token, it seems like a fragile design. What you write is true, but it' also a consequence of the fact that applications are free to impose additional requirements on the usage of this specification, provided their usage is still conforming. I believe that the text above should be modified to begin "Note that ..." to make it clear that this is informative, and not normative text. > Radia Thanks again, -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
