Telechat Review of draft-ietf-oauth-jwsreq-09

Request Review of draft-ietf-oauth-jwsreq
Requested rev. no specific revision (document currently at 30)
Type Telechat Review
Team Ops Directorate (opsdir)
Deadline 2017-01-31
Requested 2017-01-06
Authors Nat Sakimura, John Bradley, Michael Jones
Draft last updated 2017-01-25
Completed reviews Opsdir Telechat review of -09 by Warren Kumari (diff)
Secdir Telechat review of -09 by Stephen Kent (diff)
Genart Telechat review of -09 by Joel Halpern (diff)
Opsdir Last Call review of -11 by Warren Kumari (diff)
Secdir Last Call review of -11 by Stephen Kent (diff)
Genart Last Call review of -11 by Joel Halpern (diff)
Secdir Last Call review of -30 by Watson Ladd
Genart Last Call review of -30 by Joel Halpern
Assignment Reviewer Warren Kumari 
State Completed
Review review-ietf-oauth-jwsreq-09-opsdir-telechat-kumari-2017-01-25
Reviewed rev. 09 (document currently at 30)
Review result Has Nits
Review completed: 2017-01-25


)Be ye not afraid -- I have reviewed this document as part of the
operations directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the operation area directors.  Document editors and
WG chairs should treat these comments just like any other last call

For OpsAD: Ready with nits / after IETF LC.

Version reviewed:  draft-ietf-oauth-jwsreq-09

Purely from OpsDir side it looks OK. From an editorial side
though there are lots of nits / places where I found the text to
be less than clear.

AFAICT, this has not yet gone through IETF LC (last I saw was
from Kathleen putting it on the telechat and saying a IETF LC
would happen after a new version is posted -
This version was last updated September 28, 2016) -
just mentioning because a: more comments might come in LC,
and to make sure it isn't accidentally missed.)

I'm not quite sure why there is a sales pitch for 29100 (
"ISO/IEC 29100 [ISO29100] is a freely accessible
International Standard and its Privacy Principles are
good to follow.") - I'd suggest dropping at least the
"freely accessible" part, or adding it to all of the
IETF references as well :-P


   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be JWS
[R] -- I don't think that JWS / JWE are in the well-known acronym
   list. I think, especially for an abstract that these should be
   made clear.

   signed and/or JWE encrypted so that the integrity, source
   authentication and confidentiallity property of the Authorization
[O] confidentiallity
[P] confidentiality
[R] spelling

1.  Introduction

   The Authorization Request in OAuth 2.0 [RFC6749] utilizes query
   parameter serialization and typically sent through user agents such
[O] and typically sent
[P] and is typically sent
[R] missing a verb.

   While TLS is used to offer communication
   security between the Client and the user-agent and the user-agent and
   the Authorization Server, TLS sessions are terminated in the user-
[O] the Client and the user-agent and the user-agent and the
Authorization Server,
[P] the Client and the user-agent as well as the user-agent and the
Authorization Server,
[R] readability; the initial version with "and" almost makes it sound
as though all four things are connected, vs two sets of two.
   agent.  In addition, TLS sessions may be terminated prematurely at
   some middlebox (such as a load balancer).

   As the result, the Authorization Request of [RFC6749] has a property
[O] has a property that
[P] has the following limitations [or concerns]
[R] the list that follows aren't really "properties," and it sounds a
little awkward -- but I'm not sure what exactly to replace it with.

   Because of these weaknesses, several attacks against the protocol,
   such as Redirection URI rewriting, has been discovered.
[O] several attacks [...] has been discovered.
[R] at a minimum, we need to change "has" to "have" -- but beyond
that, are attacks discovered? Or is the issue that attacks are open?
Maybe, "Because of these weaknesses, the protocol is vulnerable to
various attacks, including Redirection URI rewriting."
   The use of application layer security mitigates these issues.

   In addition, it allows requests to be prepared by a third party so
[O] In addition, it allows
[P] The use of application layer security also allows
[R] readability

   that a client application cannot request more permissions than
   previously agreed.  This offers an additional degree of privacy

   Furthermore, the request by reference allows the reduction of over-
   the- wire overhead.
[O]  the- wire
[P] the-wire
[R] punctuation/grammar

   The JWT [RFC7519] encoding has been chosen because of

   (1)  its close relationship with JSON, which is used as OAuth's
        response format;

   (2)  its developer friendliness due to its textual nature;

   The parameters "request" and "request_uri" are introduced as
   additional authorization request parameters for the OAuth 2.0
   [RFC6749] flows.  The "request" parameter is a JSON Web Token (JWT)
   [RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0
   authorization request parameters.  This JWT is integrity protected
   and source authenticated using JWS.

   The JWT [RFC7519] can be passed to the authorization endpoint by
   reference, in which case the parameter "request_uri" is used instead
 For example, a request can be pre-examined by a
        third party that all the personal data requested is strictly
        necessary to perform the process that the end-user asked for,
        and statically signed by that third party.  The client would
        then send the request along with dynamic parameters such as
        state.  The authorization server then examines the signature and
        shows the conformance status to the end-user, who would have
        some assurance as to the legitimacy of the request when
        authorizing it.  In some cases, it may even be desirable to skip
        the authorization dialogue under such circumstances.
[O]  ;
[R] the semicolons are not necessary -- the list is already separated
by lines and letters.

   There are a few cases that request by reference are useful such as:

   4.  When the client does not want to do the crypto: The Authorization
       Server may provide an endpoint to accept the Authorization
       Request through direct communication with the Client so that the
       Client is authenticated and the channel is TLS protected.

[O] : The
[P] . The
[R] #1 & 2 have no colon after the initial sentence; 3 & 4. It is not
necessary, and I suggest that it's removed for consistency.
   This capability is in use by OpenID Connect [OpenID.Core].

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

4.  Request Object

   This JSON [RFC7159] constitutes
   the JWT Claims Set [RFC7519].  The JWS Claims Set is then signed,
   encrypted, or signed and encrypted.
[O] then signed, encrypted, or signed and encrypted.
[P] then signed, or encrypted, or signed and encrypted.
[R] I am *guessing* this is what's meant" Otherwise, it's not clear
whether "signed, encrypted" is supposed to be an OR or an and. Upon
further reading of the document, I think this is supposed to mean,
"signed, or encrypted, or signed and encrypted."

   If the parameter exists in both the query string and the
   Authorization Request Object, the values in the Request Object take
   precedence.  This means that if it intends to use a cached request
   object, it cannot include parameters such as "state" that are
   expected to differ in every request.  It is fine to include them in

[O] It is fine
[P] It is recommended (or acceptable, or expected..."fine" doesn't
mean much in this context.)
[R] clarity
   the request object if it is going to be prepared afresh every time.

5.2.1.  URL Referencing the Request Object

   The Client stores the Request Object resource either locally or
   remotely at a URL the Authorization Server can access.  The URL MUST
   be HTTPS URL.  This URL is the Request Object URI, "request_uri".

   It is possible for the Request Object to include values that is to be
[O]  values that is
[P] values that are
[R] grammar

   revealed only to the Authorization Server.  As such, the
   "request_uri" MUST have appropriate entropy for its lifetime.  It is
   RECOMMENDED that it be removed if it is known that it will not be
   used again or after a reasonable timeout unless access control
   measures are taken.

6.2.  JWS Signed Request Object

   To perform JWS Signature Validation, the "alg" Header Parameter in
   the JOSE Header MUST match the value of the pre-registered algorithm.
[R] No idea who JOSE is, or where he came from; this is the only
reference to JOSE in this document. I'd suggest reference to the WG or
one of the JOSE RFCs.

7.  Authorization Server Response

   Authorization Server Response is created and sent to the client as in
   Section 4 of OAuth 2.0 [RFC6749] .

   In addition, this document uses these additional error values:

   invalid_request_uri  The "request_uri" in the Authorization Request
      returns an error or contains invalid data.

   invalid_request_object  The request parameter contains an invalid
      Request Object.

   request_not_supported  The Authorization Server does not support the
      use of the "request" parameter.

   request_uri_not_supported  The Authorization Server does not support
      use of the "request_uri" parameter.

8.  TLS Requirements

   Client implementations supporting the Request Object URI method MUST
   support TLS as recommended in Recommendations for Secure Use of
   Transport Layer Security (TLS) and Datagram Transport Layer Security
   (DTLS) [RFC7525].

Sakimura & Bradley        Expires April 1, 2017                [Page 14]
Internet-Draft                  OAuth JAR                 September 2016

   To protect against information disclosure and tampering,
   confidentiality protection MUST be applied using TLS with a
   ciphersuite that provides confidentiality and integrity protection.

   Whenever TLS is used, the identity of the service provider encoded in
   the TLS server certificate MUST be verified using the procedures
   described in Section 6 of [RFC6125].

9.  IANA Considerations

   This specification requests no actions by IANA.

10.  Security Considerations

   In addition to the all the security considerations discussed in OAuth
   2.0 [RFC6819], the following security considerations should be taken
   into account.

10.1.  Choice of Algorithms

   When sending the authorization request object through "request"
   parameter, it MUST either be JWS signed with then considered
   appropriate algorithm or encrypted using [RFC7516].

10.2.  Choice of Parameters to include in the Request Object

   Unless there is a compelling reasons to do otherwise, it is strongly
   recommended to create a request object that covers all the parameters
   so that the entire request is integrity protected.

   This means that the request object is going to be prepared fresh each
   time an authorization request is made and caching cannot be used.  It

10.4.  Explicit Endpoints

   Although this specification does not require them, researchs such as
[O] researchs
[P] research
[R] spelling

11.  Privacy Considerations

   When the Client is being granted access to a protected resource
   containing personal data, both the Client and the Authorization
   Server need to adhere to Privacy Principles.  ISO/IEC 29100
   [ISO29100] is a freely accessible International Standard and its
   Privacy Principles are good to follow.

   Most of the provision would apply to The OAuth 2.0 Authorization
   Framework [RFC6749] and The OAuth 2.0 Authorization Framework: Bearer
   Token Usage [RFC6750] and not specific to this specification.  In
[O] and not specific
[P] and are not specific
[R] grammar

   what follows, only the specific provisions to this specification are

11.1.  Collection limitation

   When the Client is being granted access to a protected resource
   containing personal data, the Client SHOULD limit the collection of
   personal data to that which is within the bounds of applicable law
   and strictly necessary for the specified purpose(s).

   It is often hard for the user to find out if the personal data asked
   for is strictly necessary.  A Trust Framework Provider can help the
   user by examining the Client request and comparing to the proposed
   processing by the Client and certifying the request.  After the

11.2.2.  Tracking using Request Object URI

   is in a way a data disclosure as well and should be avoided.
[O] It is in a way a data disclosure as well and should be avoided.
[P] In a way, it is a data disclosure as well, and thus should be avoided.
[R] readability
   Therefore, per-user Request Object URI should be avoided.

12.  Acknowledgements

   The following people contributed to the creation of this document in
   the OAuth WG.  (Affiliations at the time of the contribution is
[O] contribution is
[P] contribution are
[R] grammar/subject verb agreement