Skip to main content

Last Call Review of draft-ietf-oauth-jwt-bearer-10
review-ietf-oauth-jwt-bearer-10-secdir-lc-perlman-2014-10-02-00

Request Review of draft-ietf-oauth-jwt-bearer
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-09-29
Requested 2014-09-18
Authors Michael B. Jones , Brian Campbell , Chuck Mortimore
I-D last updated 2014-10-02
Completed reviews Genart Last Call review of -10 by Joel M. Halpern (diff)
Secdir Last Call review of -10 by Radia Perlman (diff)
Opsdir Last Call review of -10 by Tim Wicinski (diff)
Assignment Reviewer Radia Perlman
State Completed
Request Last Call review on draft-ietf-oauth-jwt-bearer by Security Area Directorate Assigned
Reviewed revision 10 (document currently at 12)
Result Has nits
Completed 2014-10-02
review-ietf-oauth-jwt-bearer-10-secdir-lc-perlman-2014-10-02-00
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