[secdir] Secdir Review of draft-ietf-oauth-jwt-bearer-10

[Radia Perlman <[e-mail]>]

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