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).

 

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.  

Would it make sense to merge this document with the other specs, rather than having this be so redundant with the others?

 

 

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.

 

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.

 

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.

Radia