The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)

Summary: Has a DISCUSS. Needs one more YES or NO OBJECTION position to pass.

Benjamin Kaduk Discuss

Discuss (2019-07-03)
My apologies; my previous position was incomplete.  Updated to note
namespacing issues, and one minor terminology nit about "DNS-ID".

There seem to be some pretty serious namespacing issues that are not
discussed at all in this document.  Specifically, using JWT as a
container for OAuth 2.0 authorization request parameters (including
extension parameters) introduces the usage of many new names (of JSON
name/value pairs) into the JWT claims namespace.  Furthermore, the
addition is not bounded, as any new OAuth extension parameters are
implicitly permitted to be used as well!  The IANA Considerations make
no mention of the collapsed namespace for JWT claims and OAuth 2.0
(authorization request) parameters, leaving substantial potential for
collisions in the future.
Relatedly, using "application/jwt" as the Content-type of the
HTTP response from dereferencing the request_uri with no explicit
indication of the type/profile of JWT used (whether in the content type
or in the JWT claims themselves) gives some risk of misinterpretation of
the content.  Consider, for example, when that request_uri is
dereferenced not by the authorization server in the process of
fulfilling an authorization request, but instead by some other service
that expects a different type of JWT.

This second point is a "discuss discuss" -- it's an important question
and I'd like to talk about it, but it's not clear that any change to the
document will be needed.

The introduction notes as an advantage of JWT that:

   (d)  (collection minimization) The request can be signed by a third
        party attesting that the authorization request is compliant with
        a certain policy.  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 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.

I'm pretty uncomfortable about suggesting that the authorization
dialogue can/should be skipped; do we need to keep this example?
Comment (2019-07-03)
Section 1

   While it is easy to implement, the encoding in the URI does not allow
   application layer security with confidentiality and integrity
   protection to be used.  While TLS is used to offer communication

nit: this wording is a little hard to read; it might be easier to
reorder to "does not allow application layer security to be used to
provide confidentiality and integrity protection".

   The use of application layer security allows requests to be prepared
   by a third party so that a client application cannot request more
   permissions than previously agreed.  This offers an additional degree
   of privacy protection.

(side note) what would an example of such a third party be.  (We already
have the resource owner, the client, and the authorization server ...
maybe it's a fourth party?)

   Furthermore, the request by reference allows the reduction of over-
   the-wire overhead.

We only barely mentioned by-reference at this point (one line in the
Abstract), so I'd suggest "passing the request by reference".

   (4)  its development status that it is an RFC and so is its
        associated signing and encryption methods as [RFC7515] and

nit: I'd suggest "its development status as a Proposed Standard, along
with the associated signing and encryption methods [RFC7515] [RFC7516]."

   (c)  (confidentiality protection) The request can be encrypted so
        that end-to-end confidentiality can be provided even if the TLS
        connection is terminated at one point or another.

nit: TLS is always terminated at or before the user-agent, though.  So
maybe the user agent needs to get called out here as well (there could
of course be TLS termination earlier than the user-agent in some cases,

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

How can you "not want to do [the] crypto" but still be doing TLS (with
crypto)?  Perhaps we're looking for "not want to pay the additional
overhead of JWS/JWE cryptography on top of TLS"?

Section 1.1

RFC 8174 has updated BCP 14 boilerplate text to use.

Section 3

nit: should this section be 2.3 to get wrapped into "terminology"?

It might also be worth putting references in for the terms, though they
are largely common knowledge at this point.

Section 4

   A Request Object (Section 2.1) is used to provide authorization
   request parameters for an OAuth 2.0 authorization request.  It MUST
   contains all the OAuth 2.0 [RFC6749] authorization request parameters
   including extension parameters.  The parameters are represented as

nit: "all the parameters" kind of sounds like "all that are defined".
But I think the intent here is "any parameter used to process the
request must come from the request object and URL query parameters are
ignored", so maybe "MUST contain all the parameters (including extension
parameters) used to process the OAuth 2.0 [RFC6749] authorization
request; parameters from other sources MUST NOT be used", akin to what
we say down in Sections 5 and 6.3.
But we need to be careful about the wording to not exclude the usage of
the "request" and "request_uri" query parameters to  find the Request

   the JWT claims.  Parameter names and string values MUST be included

nit: maybe "the JWT claims of the object"?

   any extension parameters.  This JSON [RFC7159] constitutes the JWT
   Claims Set defined in JWT [RFC7519].  The JWT Claims Set is then
   signed or signed and encrypted.

nit: I  think we want "This JSON [RFC7159] object".

(Long quote incoming)

   The following is an example of the Claims in a Request Object before
   base64url encoding and signing.  Note that it includes extension
   variables such as "nonce" and "max_age".

      "iss": "s6BhdRkqt3",
      "aud": "",
      "response_type": "code id_token",
      "client_id": "s6BhdRkqt3",
      "redirect_uri": "",
      "scope": "openid",
      "state": "af0ifjsldkj",
      "nonce": "n-0S6_WzA2Mj",
      "max_age": 86400

   Signing it with the "RS256" algorithm results in this Request Object
   value (with line wraps within values for display purposes only):


Decoding the base64 of the body, we see:
 "iss": "s6BhdRkqt3",
 "aud": "",
 "response_type": "code id_token",
 "client_id": "s6BhdRkqt3",
 "redirect_uri": "",
 "scope": "openid",
 "state": "af0ifjsldkj",
 "nonce": "n-0S6_WzA2Mj",
 "max_age": 86400,
     "given_name": {"essential": true},
     "nickname": null,
     "email": {"essential": true},
     "email_verified": {"essential": true},
     "picture": null
     "gender": null,
     "birthdate": {"essential": true},
     "acr": {"values": ["urn:mace:incommon:iap:silver"]}

I'm not sure where the "claims" claim is coming from -- 6749 doesn't
seem to talk about it.  (Note that this example is used later on as

Section 5.2.1

   It is possible for the Request Object to include values that are to
   be revealed only to the Authorization Server.  As such, the
   "request_uri" MUST have appropriate entropy for its lifetime.  For
   the guidance, refer to of [RFC6819].  It is RECOMMENDED
   that it be removed after a reasonable timeout unless access control
   measures are taken.

It sounds like a link to might
also be useful.

Section 5.2.2

Do we want to remind the reader that the other query parameters are just
for backwards compatibility?

Section 5.2.3

   The following is an example of this fetch process:

     GET /request.jwt HTTP/1.1

It's useful to show good hygeine in examples; can we get the extra
entropy in this request that we have in the previous example(s)?

Section 6.2

   The Authorization Server MUST perform the signature validation of the
   JSON Web Signature [RFC7515] signed request object.  For this, the
   "alg" Header Parameter in its JOSE Header MUST match the value of the
   pre-registered algorithm.  The signature MUST be validated against
   the appropriate key for that "client_id" and algorithm.

Does "the pre-registered algorithm" concept exist in the specs outside
of draft-ietf-oauth-jwt-bcp?

Section 8

   HTTP clients MUST also verify the TLS server certificate, using
   subjectAltName dNSName identities as described in [RFC6125], to avoid
   man-in-the-middle attacks.  The rules and guidelines defined in

It's probably easier to just say "using DNS-ID [RFC6125], to avoid
man-in-the-middle attacks".

Section 9

The error codes we list in Section 7 are already registered, for the
OIDC usage.  Do we want to say anything about that?   (I guess it would
be disallowed by process to try to update the existing registration to
also point at this document.)

Section 10

We probably also want to reference draft-ietf-oauth-jwt-bcp.

Section 10.1

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

Up in Section 5 we only allow (a) signed and (b) signed then encrypted;
similarly, in Section 4 we reiterate "signed then encrypted".  Why is it
okay to talk about just "signed or encrypted" here?

Section 10.2

   (b)  Verifying that the symmetric key for the JWE encryption is the
        correct one if the JWE is using symmetric encryption.

Similarly to the previous point, you also need to check the signature,
which will always be there.

   (d)  Authorization Server is providing an endpoint that provides a
        Request Object URI in exchange for a Request Object.  In this

I don't think this is a complete sentence (and it's definitely not a
parallel construction with (a)-(c)!).  I think perhaps a crisp one-line
summary of this method would be "Delegating the authorization check to a
separate "Request Object to Request Object URI" endpoint on the
Authorization Server".  (The writing in the rest of this paragraph could
also use an editing pass.)

   (e)  A third party, such as a Trust Framework Provider, provides an
        endpoint that provides a Request Object URI in exchange for a
        Request Object.  The same requirements as (b) above apply.  In
        addition, the Authorization Server MUST know out-of-band that
        the Client utilizes the Trust Framework Operator.

The Authorization Server also has to trust the third-party provider to
actually do its job and not misbehave, right?

Section 10.3

I'm not entirely sure what "[t]he endpoints ithat come into question in
this specification" is supposed to mean -- is it just "the OAuth 2.0
endpoints presently defined in Standards-Track RFCs"?

   In [RFC6749], while Redirection URI is included, others are not
   included in the Authorization Request.  As the result, the same
   applies to Authorization Request Object.

nit: included in what?

Section 10.4

It's probably also worth citing the generic URI security considerations
from RFC 3986, here.

Section 10.4.1

   "request_uri", and (d) do not perform recursive GET on the

nit: remove the "do" in order to make the construction parallel.

Section 12.1

   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
   certification, the Client, when making an Authorization Request, can
   submit Authorization Request to the Trust Framework Provider to
   obtain the Request Object URI.

side note: In my head the act of certification was the act of making the
translation to a Request Object URI, so I'm kind of curious where my
vision differs from reality.

The third paragraph seems to mostly just be describing the procedure of
how this flow works, which would not necessarily be specific to the
privacy considerations section.

Section 12.2.2

   Even if the protected resource does not include a personally
   identifiable information, it is sometimes possible to identify the
   user through the Request Object URI if persistent per-user Request
   Object URI is used.  A third party may observe it through browser
nit: need an article for "persistent per-user Request Object URI" (or
make it plural, as "URIs are used").

   Therefore, per-user Request Object URI should be avoided.

nit: I think this is better as "static per-user Requeste Object URIs".

Section 13

Are there two different paragraphs for "contributions from the OAuth WG
members"?  Are they reflecting different types of contribution?

(Ben Campbell) Yes

Comment (2017-02-15 for -12)
- 4, "Since it is a JWT, JSON strings MUST be represented
   in UTF-8. ": Is that a new requirement, or a statement of fact about an existing JWT requirement?

- 5.2: I'm not sure all readers will understand the meaning of "feature phone".  Also, WAP and 2G don't seem all that relevant in 2017.

- 5.2.1, first sentence, "The URL MUST
   be HTTPS URL.": Is that redundant to the similar requirement in the previous section? That instance had an "unless" clause, but this one does not.

--2nd paragraph: "... MUST have appropriate entropy for its lifetime."
Can you offer discussion (or a reference) for what constitutes "appropriate entropy"?

-- 3rd paragraph: Is it reasonable that one would know if TLS would offer adequate authentication at the time of the signing decision?

- 5.2.3, 2nd paragraph: "SHOULD use a unique URI": Why not MUST? Would it ever be reasonable to not do this?

- 6.1, 2nd paragraph: What if validation fails?

- 13: Do you want this in the final RFC? If not, it would be wise to add a note to the RFC editor to that effect.

Roman Danyliw Yes

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2017-02-15 for -12)
- intro: "attacks... have been identified." yells out for a
reference - it'd be a good bit better if implementers could
easily find details of some such attacks, so I hope you add
some refs here.

- section 3; WAP? Really? I'm surprised any WAP technology
would still be in use, even on feature-phones. Do you really
need this?

- section 4: I think it will turn out to be an error to allow
for mixing query parameters and protected parameters (in a
Request Object) in a single request. Do you really need that
level of flexibility? It'd be simpler and less likely to be
attackable to insist that all parameters be in the Request
Object if one is used. (See also section 11.2.1 below.)

- section 10: Is there nothing to be said about the new
indirection caused by the request_uri? I'd have thought there
were some corner cases that'd warrant a mention, e.g. if some
kind of deadlock or looping could happen, or if one client (in
OAuth terms) could use a request_uri value as a way to attempt
attacks (to be assisted by an innocent browser) against some
resource owner.

- section 11: thanks for that, it's good.

- section 11: Saying that an ISO thing is "good to follow" is
quite weak IMO. (And is that ISO spec accessible? Hmm...  it
seems that one needs to accept cookies to get it which is
wonderfully ironic;-) If the authors have the energy, I'd
suggest trying to find better guidance that's more publically
available in a privacy-friendly manner. (Or just drop the ISO
reference if 6973 is good enough.)

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2019-06-05 for -18)
"NoObj" in the "I read the protocol action, and I trust the sponsoring AD so have no problem and / or this is outside my area of expertise or have no cycles" sense of the term.
I'm largely relying on the  fact that the previous Ops&Mgmt AD's, Kathleen, Jari, Ben, et al balloted Yes or NoObj.

Mirja Kühlewind No Objection

Comment (2017-02-16 for -12)
Should this document maybe update rfc6749?

Barry Leiba No Objection

(Terry Manderson) No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2017-07-21 for -14)
Thank you for addressing my DISCUSS point.

New nit: URN needs a reference to RFC 8141.

Alvaro Retana No Objection

Ignas Bagdonas No Record

Adam Roach No Record

Martin Vigoureux No Record

Éric Vyncke No Record

Magnus Westerlund No Record