The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)
draft-ietf-oauth-jwsreq-34

[Ballot comment]
EDIT (09-04-2021)

Thank you for addressing all my comments in v-34.

Francesca

=============== Original ballot - 07-04-2021

Thank you for the work on this document. I only have minor comments, the most interesting is probably 4. about if additional failure behavior should be defined at the AS.

Francesca

1. -----

  A Request Object (Section 2.1) has the "mime-type" "application/

FP: Please use "media type" instead of "mime-type" and reference https://tools.ietf.org/html/rfc6838

2. -----


  The following is an example of the Claims in a Request Object before
  base64url encoding and signing.  Note that it includes the extension

FP: This example is the first time "base64url" appears in the document. I think it would make sense to mention that base64url is used when JWT is introduced, for example in the first paragraph of section 4.

3. -----

  If decryption fails, the Authorization Server MUST return an
  "invalid_request_object" error.

...

  If signature validation fails, the Authorization Server MUST return
  an "invalid_request_object" error.

...

  If the validation fails, then the Authorization Server MUST return an
  error as specified in OAuth 2.0 [RFC6749].

FP: very minor, but I suggests you add "to the client, in response to the request defined in 5.2.2. of this specification". The reason is that the doc specifies that the AS might be having other exchanges (to fetch the Request Object) at the same time, and it can't hurt to be precise.
Also regarding the reference to RFC 6749 - can you add a specific section to reference?

4. -----

  specified in the "alg" Header Parameter.  If a "kid" Header Parameter
  is present, the key identified MUST be the key used, and MUST be a
  key associated with the client.  Algorithm verification MUST be

...

  same parameter is provided in the query parameter.  The Client ID
  values in the "client_id" request parameter and in the Request Object
  "client_id" claim MUST be identical.  The Authorization Server then

FP: "MUST be a key associated with the client" - what if it is not? does the AS return an error to the client then?
Same comment "... MUST be identical" - is any error returned if it's not?

5. -----


  location, (b) check the content type of the response is "application/

FP: For consistency, please change "content type" to "media type".

[Ballot comment]
Ah, jwsreq.  We meet again.  Fortunately, looking only at the diff from my last ballot comments to this one, I only have a couple of minor things this time:

Sections 9.2 and 9.3 each say they are registering "values", but each registers only one.

"+1" to Francesca's points #1 and #5.

Thanks for changing the media type name to use hyphens instead of dots.  That avoided a big mess.

[Ballot comment]
Thank you for the work on this document. I only have minor comments, the most interesting is probably 4. about if additional failure behavior should be defined at the AS.

Francesca

1. -----

  A Request Object (Section 2.1) has the "mime-type" "application/

FP: Please use "media type" instead of "mime-type" and reference https://tools.ietf.org/html/rfc6838

2. -----


  The following is an example of the Claims in a Request Object before
  base64url encoding and signing.  Note that it includes the extension

FP: This example is the first time "base64url" appears in the document. I think it would make sense to mention that base64url is used when JWT is introduced, for example in the first paragraph of section 4.

3. -----

  If decryption fails, the Authorization Server MUST return an
  "invalid_request_object" error.

...

  If signature validation fails, the Authorization Server MUST return
  an "invalid_request_object" error.

...

  If the validation fails, then the Authorization Server MUST return an
  error as specified in OAuth 2.0 [RFC6749].

FP: very minor, but I suggests you add "to the client, in response to the request defined in 5.2.2. of this specification". The reason is that the doc specifies that the AS might be having other exchanges (to fetch the Request Object) at the same time, and it can't hurt to be precise.
Also regarding the reference to RFC 6749 - can you add a specific section to reference?

4. -----

  specified in the "alg" Header Parameter.  If a "kid" Header Parameter
  is present, the key identified MUST be the key used, and MUST be a
  key associated with the client.  Algorithm verification MUST be

...

  same parameter is provided in the query parameter.  The Client ID
  values in the "client_id" request parameter and in the Request Object
  "client_id" claim MUST be identical.  The Authorization Server then

FP: "MUST be a key associated with the client" - what if it is not? does the AS return an error to the client then?
Same comment "... MUST be identical" - is any error returned if it's not?

5. -----


  location, (b) check the content type of the response is "application/

FP: For consistency, please change "content type" to "media type".

[Ballot comment]
After reading Sec 10.5, I was a little unclear how the client and auth server necessarily achieve interoperability, but I think it's just an editorial fix.

If the server advertises that a signed object is required, then it cannot communicate with a client that does not support the extension. But if the object_required metadata is missing, then what is the metadata that tells the client to use a signed object if it can?

IIUC the answer is that the server metadata includes the request_object_signing_alg_values_supported and/or request_object_encryption_alg_values_supported parameter in the metadata. It might be helpful to spell that out here.

Is this correct?

[Ballot comment]
Thank you for the new security considerations text in Sections 10.7 and
10.8 since I last reviewed; it does a great job capturing my comments
(and the current deployed reality).

Thanks also to Watson Ladd for the latest secdir review and the authors
for their responses to it.

Section 6.2

  The Authorization Server MUST validate the signature of the JSON Web
  Signature [RFC7515] signed Request Object.  The signature MUST be
  validated using a key associated with the client and the algorithm
  specified in the "alg" Header Parameter.  [...]

The last version I reviewed had some language tying the algorithm used
for verification back to a registration (and I commented that perhaps a
registration might not always exist).  This language seems to set the
recipient up to blindly use the "alg" header parameter, even if it's
"none", and we should probably have some hedging language here (I see we
do have language elsewhere that bans "none" specifically)...

                                            If a "kid" Header Parameter
  is present, the key identified MUST be the key used, and MUST be a
  key associated with the client.  Algorithm verification MUST be
  performed, as specified in Sections 3.1 and 3.2 of [RFC8725].

... and maybe that would just take the form of swapping the order of
these two sentences, now that I keep reading.

Section 10.2

Do any of the procedures listed for steps (c) and/or (d) need to be
performed in step (e) as well?  (In particular, the requirements on the
returned URI seem like they would still apply, and possibly the need for
client authentication.

Section 10.3

Nat's response at
https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ to my
previous review suggested that there might be value in future work that
specifies the linkage across these endpoints to try to address the
cross-phase attacks discussed in [FETT].  However, the paragraph that I
had commented on (that mentions "an extension specification") has since
been removed, and I failed to track down why just from a quick
mailarchive search.  There may well have been a good reason for removing
it (and the reference to [FETT]), so please help refresh my memory if
that's the case.

Section 10.4

  The introduction of "request_uri" introduces several attack
  possibilities.  Consult the security considerations in Section 7 of
  RFC3986 [RFC3986] for more information regarding risks associated
  with URIs.

My previous comments had mentioned that because of time skew the
dereferenced request URI might actually have the contents of a different
request than the one intended, and Nat's response at
https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/
pointed out that OIDC actually does use a nonce that would prevent such
an occurrence.  Hopefully Nat did get a chance to think about whether
there was anything else that we should mention in this document, on this
topic.  ("There isn't anything else to mention here" is a fine answer; I
just wanted to close the loop on that thread, since I didn't find one in
the mail archive.)

Section 11.1

nit: s/TFP/trusted third-party service/ (multiple instances), since we
stopped using "Trust Framework Provider" in the main body.

Sction 14.1

Not your fault, but BCP 195 now includes both RFC 7525 and RFC 8996 --
thank you for referencing it as BCP 195!  I expect the RFC Editor will
catch the new reference if you don't want to figure out how to notate it
properly.

[Ballot comment]
Thank you for the work put into this document. Not too many differences since my review on the -26 (hence I reviewed mainly the diff).

Please find below some non-blocking COMMENT points (but replies would be appreciated).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
Is it normal that the abstract has a) and b) while the introduction has a), b), and c) ?

-- Section 5.2 --
I see that "Many phones in the market as of this writing" is still in the text... Does this assertion still hold in 2021 ? Is it backed by some references ?

[Ballot comment]
Section 5.2, paragraph 5, comment:
>    The entire Request URI MUST NOT exceed 512 ASCII characters.  There
>    are three reasons for this restriction.
>
>    1.  Many phones in the market as of this writing still do not accept
>        large payloads.  The restriction is typically either 512 or 1024
>        ASCII characters.
>
>    2.  On a slow connection such as 2G mobile connection, a large URL
>        would cause the slow response and therefore the use of such is
>        not advisable from the user experience point of view.

What is the third reason? Also, 512 bytes at 2G speeds (~40Kb/s) take ~100ms to
transmit; it's not clear that larger payloads would therefore be so much worse,
given that the 2G latencies are probably the overriding issue here. Would a
SHOULD NOT suffice?

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 4, paragraph 10, nit:
-    Signing it with the "RS256" algorithm results in this Request Object
+    Signing it with the "RS256" algorithm [RFC7518] results in this Request Object
+                                          ++++++++++

Shepherd Write-Up for
"The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)"


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This specification is proposed as a 'Standards Track' document. The
type of RFC is indicated. It changes the encoding of the authorization
request message.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The authorization request in OAuth 2.0 described in RFC 6749 utilizes
  query parameter serialization, which means that Authorization Request
  parameters are encoded in the URI of the request and sent through
  user agents such as web browsers.  While it is easy to implement, it
  means that (a) the communication through the user agents is not
  integrity protected and thus the parameters can be tainted, and (b)
  the source of the communication is not authenticated.  Because of
  these weaknesses, several attacks to the protocol have now been put
  forward.

  This document introduces the ability to send request parameters in a
  JSON Web Token (JWT) instead, which allows the request to be signed
  with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
  (JWE) so that the integrity, source authentication and
  confidentiality property of the Authorization Request is attained.
  The request can be sent by value or by reference.

Working Group Summary

  The document changes the encoding of the parameters in the
  authorization request to a JSON-based encoding.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The request object and the request uri is an optional feature in
the OpenID Connect Core specification and two working groups
in the OpenID Foundation (namely the Modrna WG and the FAPI WG)
are considering using this extension.

The following implementations are availble.

As part of the OpenID Foundation certification program the following
implementations of OpenID Connect Core indicate support for this
functionality:
* CZ.NIC mojeID,
* Thierry Habart's SimpleIdentitySever v.2.0.0,
* Roland Hedberg's pyoidc 0.7.7,
* Peercraft ApS's Peercarft,
* MIT's MITREidConnect,
* Gluue Server 2.3,
* Filip Skokan's node-oidc pre supports.

Authlete (https://www.authlete.com/), a commerical, closed source
server implementation, has also implemented this specification and
is offering it.

There is an open source implementation from NRI in PHP and Scala.
NRI's Open Source PHP: https://bitbucket.org/PEOFIAMP/phpoidc

IdentityServer implements JAR: https://github.com/IdentityServer

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Hannes Tschofenig is the document shepherd and the responsible area
director is Roman Danyliw.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd was involved in the working group review process
and verified the document for correctness.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

There are no concerns regarding the document reviews. The document has
been two IETF LCs.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

There are no specific reviews needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The document shepherd has no concerns with the document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

The authors have confirmed full conformance with the provisions of BCP 78
and BCP 79:

Nat: https://mailarchive.ietf.org/arch/msg/oauth/XvUwsdygsuOB7xY5-ah-VXkQUuY/
John: https://mailarchive.ietf.org/arch/msg/oauth/IYsgKLiBJxtMK3KKTkoKLlxm7WM/
Mike: https://mailarchive.ietf.org/arch/msg/oauth/35QQzS4Mdf_HyU4rRhAoLcGh800/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed for this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There is solid consensus in the working group for publishing this
document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Nobody threatened an appeal or expressed extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The shepherd checked the document.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review is needed.

(13) Have all references within this document been identified as
either normative or informative?

Yes. The references are split into normative and informative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are published RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are no downward references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document does not change the status of an existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document adds several entries to the OAuth Parameters IANA registry.
The entries have been verified by the shepherds in their roles as experts
for those registries.

The document also registers a media type, namely "application/oauth-authz-req+jwt".
This request has been reviewed already.

The document adds values to two more registries, namely to
- the "OAuth Dynamic Client Registration Metadata" registry, and
- the "OAuth Authorization Server Metadata" registry.

The registries are clearly identified.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

There are no new registries created by this specification.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

The document contains JSON examples and those have been verified
by the shepherd.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-oauth-jwsreq-30. If any part of this review is inaccurate, please let us know.

We understand that when the IESG approves this document for publication, IANA will have two actions to complete.

(Please note that because we do not yet have confirmation from the expert for Section 9.1, OAuth Parameters, that version 30 is approved, we are marking this document "IANA Not OK," even though the assignments have already been made.)

First, IANA will update the references for the following existing registrations at https://www.iana.org/assignments/oauth-parameters to point to the current version of this document.

In OAuth Parameters:

iss
authorization request
IETF
[RFC7519, Section 4.1.1][RFC-ietf-oauth-jwsreq-30]

sub
authorization request
IETF
[RFC7519, Section 4.1.2][RFC-ietf-oauth-jwsreq-30]

aud
authorization request
IETF
[RFC7519, Section 4.1.3][RFC-ietf-oauth-jwsreq-30]

exp
authorization request
IETF
[RFC7519, Section 4.1.4][RFC-ietf-oauth-jwsreq-30]

nbf
authorization request
IETF
[RFC7519, Section 4.1.5][RFC-ietf-oauth-jwsreq-30]

iat
authorization request
IETF
[RFC7519, Section 4.1.6][RFC-ietf-oauth-jwsreq-30]

jti
authorization request
IETF
[RFC7519, Section 4.1.7][RFC-ietf-oauth-jwsreq-30]

In OAuth Authorization Server Metadata:

require_signed_request_object
Indicates where authorization request needs to be protected as Request Object and provided through either "request" or "request_uri parameter".
IETF
[RFC-ietf-oauth-jwsreq-30, Section 10.5]

In OAuth Dynamic Client Registration Metadata:

require_signed_request_object
Indicates where authorization request needs to be protected as Request Object and provided through either "request" or "request_uri parameter".
IETF
[RFC-ietf-oauth-jwsreq-30, Section 10.5]

Second, IANA will add the following entry to the media type registry at https://www.iana.org/assignments/media-types:

application/oauth-authz-req+jwt [RFC-ietf-oauth-jwsreq-30]

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-10-02):

From: The IESG
To: IETF-Announce
CC: rdd@cert.org, oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org, Hannes.Tschofenig@gmx.net, oauth@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)) to Proposed Standard


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'The OAuth 2.0 Authorization
Framework: JWT Secured Authorization
  Request (JAR)'
  as Proposed Standard

This document is being brought back for a second IETF Last Call to confirm
consensus on changes made in response to multiple IESG Reviews in 2017 and 2019.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-10-02. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The authorization request in OAuth 2.0 described in RFC 6749 utilizes
  query parameter serialization, which means that Authorization Request
  parameters are encoded in the URI of the request and sent through
  user agents such as web browsers.  While it is easy to implement, it
  means that (a) the communication through the user agents is not
  integrity protected and thus the parameters can be tainted, and (b)
  the source of the communication is not authenticated.  Because of
  these weaknesses, several attacks to the protocol have now been put
  forward.

  This document introduces the ability to send request parameters in a
  JSON Web Token (JWT) instead, which allows the request to be signed
  with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
  (JWE) so that the integrity, source authentication and
  confidentiality property of the Authorization Request is attained.
  The request can be sent by value or by reference.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



No IPR declarations have been submitted directly on this I-D.

[Ballot comment]
[updating again to link to https://mailarchive.ietf.org/arch/msg/oauth/POfiIMFXpUQTl5nPvgb7YDcLkE0/
to note that my first update kind of missed the point.]
[updated to note that, per https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0eaE/
and the JWT BCP (RFC 8725), some discussion of why explicit typing is not used would be in order]

Thanks for the many updates as we worked through the issues.

Let's also add a note about "whose JWT Claims Set holds the JSON encoded
OAuth 2.0 authorization request parameters" to the definition of Request
Object in Section 2.1 (in addition to the note in the Introduction); my
apologies for not including that when I suggested the change to the
Introduction.

Please update the Content-Length in the example in Section 5.2.3.


Section 4

  The client determines the algorithms used to sign and encrypt request
  objects.  This decision can be based on metadata the client
  registered via dynamic client registration [RFC7591] using the
  parameters "request_object_signing_alg",
  "request_object_encryption_alg", "request_object_encryption_enc" as
  defined in the the IANA "OAuth Dynamic Client Registration Metadata"
  registry [IANA.OAuth.Parameters] established by [RFC7591].

I had to read this ("this decision can be based on [...]") a few times
to understand it.  If I understand correctly, the idea is that the
client will register with the AS the keys it will use for constructing
the JAR, and in that way the AS has a binding from JAR-signing key to
the specific client and request.  So it's true that the decision of what
key to use "can be based on" the metadata that the client registered, in
that deciding to use a different key than the registered one(s) is
likely to cause the AS to reject the request, but that's perhaps not the
main point.  Would it work to instead just say that "The keys used to
sign and encrypt request objects (and thus, the algorithms that can be
used with those keys) can be registered via dynamic client registration
[...]"?

Section 5.2

  The contents of the resource referenced by the URI MUST be a Request
  Object, unless the URI was provided to the client by the
  Authorization Server.  The "request_uri" value MUST be either URN as
  defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of
  RFC7230 [RFC7230] .  The "request_uri" value MUST be reachable by the
  Authorization Server.

I defer to my ART-area colleagues, but I'm not sure what it means for a
URN URI to be "reachable"; is this requirement intended to only apply to
the "https:" case?

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

Is there a good reference for what the lifetime of such a request might
be?  Perhaps I've been reading too much of GNAP, but my intuition is
that much of the time these requests will be single-use, and I don't
have as clear of a picture for when they might persist longer.  There
are also potential security considerations for long-lived request
objects, in terms of making sure that there is a binding between the
client's intent to use a given request object for a given request, the
user's authorization, etc.

Section 5.2.3

(side note) I'd consider updating the timestamps in the example response
(and perhaps moving to Apache 2.4+ as well?).

Section 6.x

(nit) I suggest consistency in subsection headings, so, e.g., "JWE
Encrypted Request Object" and "JWS Signed Request Object".

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.

This text suggests that pre-registration is mandatory, whereas up in
Section 4 the client's choice of algorithm was merely something that
"can be based on [metadata registered via dynamic registration]".  I
know that dynamic registration is not the only kind of registration
possible, but we may want to wordsmith one (or both) location to improve
the consistency.

Section 6.3

I'd suggest reiterating here the requirement to verify "client_id"
consistency between Request Object and request parameters.

Section 10

I'd consider reiterating the security importance (i.e., what breaks if
you don't apply the check) of a few key compliance requirements and
which entity is responsible for enforcing them:

- the "request" and "request_uri" parameters MUST NOT be included in
  request objects, from Section 4

- The request object has the mime-type
  "application/oauth.authz.req+jwt", also from Section 4

- The client_id in the request object has to match the client_id from
  the request query parameters, from Section 5

- The AS must only use parameters from the request object, even if the
  client has duplicated them in the query parameters, also from Section 5

Section 10.2

  (e)  When a third party, such as a Trust Framework Provider(TFP),
        provides an endpoint that provides a Request Object URI in
        exchange for a Request Object.  The same requirements as (b) and
        (c) above apply.  In addition, the Authorization Server MUST

The (b) case is "the symmetric key for JWE encryption"; do we mean "(c)
and (d)" here?

Section 10.3

I'm not sure whether the key point of this section is "the following
endpoints are RECOMMENDED [...] to use this practice" or "an extension
specification should be created as a measure to address the risk".  That
is, can a deployment unilaterally apply the message-position and
intended-interaction-endpoint protections now, or is there need for
additional specification work first?

Section 10.4

I'm not sure how much of this is distinct from the Request URI Rewrite
discussed in Section 10.4.2, but having the request object contents be
in a separately dereferenceable URI introduces risk of the dereferenced
Request Object being dissociated from the triggering request.  (This
could happen due to internal error on the client or service hosting the
requested URI or content skew over time, in addition to a request URI
rewrite.)  Having an externally provided single-use nonce in the reqest
object would provide a mitigation, but it also (if I understand
correctly) not compatible with all of the envisioned use cases for JAR.

Section 10.5

Should the rejection of "alg":"none" be limited to the
require_signed_request_object case, or universally applied?

Section 12.1

  (2)  (Translation Process) The client uses the client credential that
        it got to push the request object to the TFP to get the
        "request_uri".

If I understand correctly, the TFP also verifies that the request object
is consistent with the claims the client is eligible for based on the
certification step in (1).

Section 12.2.2

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

If I understand correctly, the only possible alternative is to have
per-request URIs (right?), as coalescing multiple user's requests into a
single request object URI seems to pose several difficulties.  We could
perhaps make the recommended alternative more clear.

[Ballot comment]
Hi,

Only one minor comment:

I liked the reference to max URL size for older versions of Internet Explorer, but wonder if that is still really relevant in 2020?  Or perhaps it could now be removed?

Regards,
Rob

[Ballot comment]
The directorate reviews are from 15 or more versions ago.  I wonder if returning documents like this should be sent through the directorates again as matter of course.

Abstract: "... the communication through the user agents are not ..." -- s/are/is/

Section 1 expressly cites two IANA URLs.  I suggest simply naming the registry or sub-registry; the URLs might not be permanent.  Or if you like the URL, do it as a reference, as you did with [IANA.MediaType].

The two bullets at the end of Section 1 toggle between "crypto" and "cryptography".  I suggest picking one, preferably the latter (as did the rest of the document).

In Section 3, should URI and URL include references to their defining RFCs?  I realize a reader familiar with this space probably knows those terms, but they seem to be the only acronyms without a reference here.

When would an implementer legitimately disregard the SHOULD in Section 4?

As Benjamin Kaduk also expressed, I'm a little puzzled by this text in Section 5.2: "The "request_uri" value MUST be reachable by the Authorization Server."  Is this part of the protocol?

All of the subsections of Section 9 say: "This specification adds the following values to the "OAuth Parameters" registry established ..." but they all are actually modifying different sub-registries.  I suggest naming the sub-registries explicitly.  I realize the subsection titles have it right, but this line of repeated prose had me squinting a bit.

[Ballot comment]
The directorate reviews are from 15 or more versions ago.  I wonder if returning documents like this should be sent through the directorates again as matter of course.

[Ballot comment]
[updated to note that, per https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0eaE/
and the JWT BCP (RFC 8725), some discussion of why explicit typing is not used would be in order]

Thanks for the many updates as we worked through the issues.

Let's also add a note about "whose JWT Claims Set holds the JSON encoded
OAuth 2.0 authorization request parameters" to the definition of Request
Object in Section 2.1 (in addition to the note in the Introduction); my
apologies for not including that when I suggested the change to the
Introduction.

Please update the Content-Length in the example in Section 5.2.3.


Section 4

  The client determines the algorithms used to sign and encrypt request
  objects.  This decision can be based on metadata the client
  registered via dynamic client registration [RFC7591] using the
  parameters "request_object_signing_alg",
  "request_object_encryption_alg", "request_object_encryption_enc" as
  defined in the the IANA "OAuth Dynamic Client Registration Metadata"
  registry [IANA.OAuth.Parameters] established by [RFC7591].

I had to read this ("this decision can be based on [...]") a few times
to understand it.  If I understand correctly, the idea is that the
client will register with the AS the keys it will use for constructing
the JAR, and in that way the AS has a binding from JAR-signing key to
the specific client and request.  So it's true that the decision of what
key to use "can be based on" the metadata that the client registered, in
that deciding to use a different key than the registered one(s) is
likely to cause the AS to reject the request, but that's perhaps not the
main point.  Would it work to instead just say that "The keys used to
sign and encrypt request objects (and thus, the algorithms that can be
used with those keys) can be registered via dynamic client registration
[...]"?

Section 5.2

  The contents of the resource referenced by the URI MUST be a Request
  Object, unless the URI was provided to the client by the
  Authorization Server.  The "request_uri" value MUST be either URN as
  defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of
  RFC7230 [RFC7230] .  The "request_uri" value MUST be reachable by the
  Authorization Server.

I defer to my ART-area colleagues, but I'm not sure what it means for a
URN URI to be "reachable"; is this requirement intended to only apply to
the "https:" case?

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

Is there a good reference for what the lifetime of such a request might
be?  Perhaps I've been reading too much of GNAP, but my intuition is
that much of the time these requests will be single-use, and I don't
have as clear of a picture for when they might persist longer.  There
are also potential security considerations for long-lived request
objects, in terms of making sure that there is a binding between the
client's intent to use a given request object for a given request, the
user's authorization, etc.

Section 5.2.3

(side note) I'd consider updating the timestamps in the example response
(and perhaps moving to Apache 2.4+ as well?).

Section 6.x

(nit) I suggest consistency in subsection headings, so, e.g., "JWE
Encrypted Request Object" and "JWS Signed Request Object".

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.

This text suggests that pre-registration is mandatory, whereas up in
Section 4 the client's choice of algorithm was merely something that
"can be based on [metadata registered via dynamic registration]".  I
know that dynamic registration is not the only kind of registration
possible, but we may want to wordsmith one (or both) location to improve
the consistency.

Section 6.3

I'd suggest reiterating here the requirement to verify "client_id"
consistency between Request Object and request parameters.

Section 10

I'd consider reiterating the security importance (i.e., what breaks if
you don't apply the check) of a few key compliance requirements and
which entity is responsible for enforcing them:

- the "request" and "request_uri" parameters MUST NOT be included in
  request objects, from Section 4

- The request object has the mime-type
  "application/oauth.authz.req+jwt", also from Section 4

- The client_id in the request object has to match the client_id from
  the request query parameters, from Section 5

- The AS must only use parameters from the request object, even if the
  client has duplicated them in the query parameters, also from Section 5

Section 10.2

  (e)  When a third party, such as a Trust Framework Provider(TFP),
        provides an endpoint that provides a Request Object URI in
        exchange for a Request Object.  The same requirements as (b) and
        (c) above apply.  In addition, the Authorization Server MUST

The (b) case is "the symmetric key for JWE encryption"; do we mean "(c)
and (d)" here?

Section 10.3

I'm not sure whether the key point of this section is "the following
endpoints are RECOMMENDED [...] to use this practice" or "an extension
specification should be created as a measure to address the risk".  That
is, can a deployment unilaterally apply the message-position and
intended-interaction-endpoint protections now, or is there need for
additional specification work first?

Section 10.4

I'm not sure how much of this is distinct from the Request URI Rewrite
discussed in Section 10.4.2, but having the request object contents be
in a separately dereferenceable URI introduces risk of the dereferenced
Request Object being dissociated from the triggering request.  (This
could happen due to internal error on the client or service hosting the
requested URI or content skew over time, in addition to a request URI
rewrite.)  Having an externally provided single-use nonce in the reqest
object would provide a mitigation, but it also (if I understand
correctly) not compatible with all of the envisioned use cases for JAR.

Section 10.5

Should the rejection of "alg":"none" be limited to the
require_signed_request_object case, or universally applied?

Section 12.1

  (2)  (Translation Process) The client uses the client credential that
        it got to push the request object to the TFP to get the
        "request_uri".

If I understand correctly, the TFP also verifies that the request object
is consistent with the claims the client is eligible for based on the
certification step in (1).

Section 12.2.2

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

If I understand correctly, the only possible alternative is to have
per-request URIs (right?), as coalescing multiple user's requests into a
single request object URI seems to pose several difficulties.  We could
perhaps make the recommended alternative more clear.

[Ballot comment]
Thanks for the many updates as we worked through the issues.

Let's also add a note about "whose JWT Claims Set holds the JSON encoded
OAuth 2.0 authorization request parameters" to the definition of Request
Object in Section 2.1 (in addition to the note in the Introduction); my
apologies for not including that when I suggested the change to the
Introduction.

Please update the Content-Length in the example in Section 5.2.3.


Section 4

  The client determines the algorithms used to sign and encrypt request
  objects.  This decision can be based on metadata the client
  registered via dynamic client registration [RFC7591] using the
  parameters "request_object_signing_alg",
  "request_object_encryption_alg", "request_object_encryption_enc" as
  defined in the the IANA "OAuth Dynamic Client Registration Metadata"
  registry [IANA.OAuth.Parameters] established by [RFC7591].

I had to read this ("this decision can be based on [...]") a few times
to understand it.  If I understand correctly, the idea is that the
client will register with the AS the keys it will use for constructing
the JAR, and in that way the AS has a binding from JAR-signing key to
the specific client and request.  So it's true that the decision of what
key to use "can be based on" the metadata that the client registered, in
that deciding to use a different key than the registered one(s) is
likely to cause the AS to reject the request, but that's perhaps not the
main point.  Would it work to instead just say that "The keys used to
sign and encrypt request objects (and thus, the algorithms that can be
used with those keys) can be registered via dynamic client registration
[...]"?

Section 5.2

  The contents of the resource referenced by the URI MUST be a Request
  Object, unless the URI was provided to the client by the
  Authorization Server.  The "request_uri" value MUST be either URN as
  defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of
  RFC7230 [RFC7230] .  The "request_uri" value MUST be reachable by the
  Authorization Server.

I defer to my ART-area colleagues, but I'm not sure what it means for a
URN URI to be "reachable"; is this requirement intended to only apply to
the "https:" case?

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

Is there a good reference for what the lifetime of such a request might
be?  Perhaps I've been reading too much of GNAP, but my intuition is
that much of the time these requests will be single-use, and I don't
have as clear of a picture for when they might persist longer.  There
are also potential security considerations for long-lived request
objects, in terms of making sure that there is a binding between the
client's intent to use a given request object for a given request, the
user's authorization, etc.

Section 5.2.3

(side note) I'd consider updating the timestamps in the example response
(and perhaps moving to Apache 2.4+ as well?).

Section 6.x

(nit) I suggest consistency in subsection headings, so, e.g., "JWE
Encrypted Request Object" and "JWS Signed Request Object".

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.

This text suggests that pre-registration is mandatory, whereas up in
Section 4 the client's choice of algorithm was merely something that
"can be based on [metadata registered via dynamic registration]".  I
know that dynamic registration is not the only kind of registration
possible, but we may want to wordsmith one (or both) location to improve
the consistency.

Section 6.3

I'd suggest reiterating here the requirement to verify "client_id"
consistency between Request Object and request parameters.

Section 10

I'd consider reiterating the security importance (i.e., what breaks if
you don't apply the check) of a few key compliance requirements and
which entity is responsible for enforcing them:

- the "request" and "request_uri" parameters MUST NOT be included in
  request objects, from Section 4

- The request object has the mime-type
  "application/oauth.authz.req+jwt", also from Section 4

- The client_id in the request object has to match the client_id from
  the request query parameters, from Section 5

- The AS must only use parameters from the request object, even if the
  client has duplicated them in the query parameters, also from Section 5

Section 10.2

  (e)  When a third party, such as a Trust Framework Provider(TFP),
        provides an endpoint that provides a Request Object URI in
        exchange for a Request Object.  The same requirements as (b) and
        (c) above apply.  In addition, the Authorization Server MUST

The (b) case is "the symmetric key for JWE encryption"; do we mean "(c)
and (d)" here?

Section 10.3

I'm not sure whether the key point of this section is "the following
endpoints are RECOMMENDED [...] to use this practice" or "an extension
specification should be created as a measure to address the risk".  That
is, can a deployment unilaterally apply the message-position and
intended-interaction-endpoint protections now, or is there need for
additional specification work first?

Section 10.4

I'm not sure how much of this is distinct from the Request URI Rewrite
discussed in Section 10.4.2, but having the request object contents be
in a separately dereferenceable URI introduces risk of the dereferenced
Request Object being dissociated from the triggering request.  (This
could happen due to internal error on the client or service hosting the
requested URI or content skew over time, in addition to a request URI
rewrite.)  Having an externally provided single-use nonce in the reqest
object would provide a mitigation, but it also (if I understand
correctly) not compatible with all of the envisioned use cases for JAR.

Section 10.5

Should the rejection of "alg":"none" be limited to the
require_signed_request_object case, or universally applied?

Section 12.1

  (2)  (Translation Process) The client uses the client credential that
        it got to push the request object to the TFP to get the
        "request_uri".

If I understand correctly, the TFP also verifies that the request object
is consistent with the claims the client is eligible for based on the
certification step in (1).

Section 12.2.2

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

If I understand correctly, the only possible alternative is to have
per-request URIs (right?), as coalescing multiple user's requests into a
single request object URI seems to pose several difficulties.  We could
perhaps make the recommended alternative more clear.

[Ballot comment]
Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
Should the document shepherd's write-up be updated ? It is dated October 2016... about 4 years ago.

-- Section 5.2 --
Based on the long history of this document, is the following statement "Many phones in the market as of this writing still"  still valid ?

-- Section 5.2.1 --
Suggest to give a hint about the use of tfp.example.org (TFP is expanded only in section 10.2).

== NITS ==

Please check the ID-NITS at https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-26.txt

[Ballot discuss]
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?

[Ballot comment]
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
        [RFC7516]

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

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

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
Object!

  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": "https://server.example.com",
      "response_type": "code id_token",
      "client_id": "s6BhdRkqt3",
      "redirect_uri": "https://client.example.org/cb",
      "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):

    eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
    F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
    c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
    JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
    bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
    Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
    ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
    ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
    Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
    wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
    ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
    sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
    dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
    luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
    F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
    KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
    0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
    ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
    iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw

Decoding the base64 of the body, we see:
{
"iss": "s6BhdRkqt3",
"aud": "https://server.example.com",
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://client.example.org/cb",
"scope": "openid",
"state": "af0ifjsldkj",
"nonce": "n-0S6_WzA2Mj",
"max_age": 86400,
"claims":
  {
  "userinfo":
    {
    "given_name": {"essential": true},
    "nickname": null,
    "email": {"essential": true},
    "email_verified": {"essential": true},
    "picture": null
    },
  "id_token":
    {
    "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
well.)

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 5.1.4.2.2 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 https://www.w3.org/TR/capability-urls/ 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
    Host: tfp.example.org

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
  "request_uri".

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?

[Ballot discuss]
This 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.

Once this (and some of the more substantive items in the Comment
section) is resolved, I'd be happy to ballot Yes.

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?
Maybe just talking about what an expected use case could be would
help alleviate my unease.

[Ballot comment]
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
        [RFC7516]

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

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

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
Object!

  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": "https://server.example.com",
      "response_type": "code id_token",
      "client_id": "s6BhdRkqt3",
      "redirect_uri": "https://client.example.org/cb",
      "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):

    eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
    F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
    c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
    JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
    bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
    Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
    ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
    ogICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgIm5p
    Y2tuYW1lIjogbnVsbCwNCiAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfS
    wNCiAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAg
    ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
    sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
    dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
    luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
    F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
    KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
    0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
    ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
    iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw

Decoding the base64 of the body, we see:
{
"iss": "s6BhdRkqt3",
"aud": "https://server.example.com",
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://client.example.org/cb",
"scope": "openid",
"state": "af0ifjsldkj",
"nonce": "n-0S6_WzA2Mj",
"max_age": 86400,
"claims":
  {
  "userinfo":
    {
    "given_name": {"essential": true},
    "nickname": null,
    "email": {"essential": true},
    "email_verified": {"essential": true},
    "picture": null
    },
  "id_token":
    {
    "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
well.)

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 5.1.4.2.2 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 https://www.w3.org/TR/capability-urls/ 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
    Host: tfp.example.org

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 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
  "request_uri".

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?

[Ballot comment]
"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.

[Ballot discuss]
Thank you for addressing my DISCUSS about use of RFC 6125.

I have one  new small issue from your recent change in In 5.2.3 (that was addressing my comment to include a response example): the example doesn't include Content-Type and (possibly) Transfer-Encoding header fields. Without these it doesn't look syntactically correct.

[Ballot discuss]
When referencing RFC 6125 you need to provide more details. In particular, you need to pretty much answer every question in section 3 of RFC 6125:

One example of how this might look like is in Section 9.2 of . For your convenience the relevant text is pasted below:

  Routers MUST also verify the cache's TLS server certificate, using
  subjectAltName dNSName identities as described in [RFC6125], to avoid
  man-in-the-middle attacks.  The rules and guidelines defined in
  [RFC6125] apply here, with the following considerations:

      Support for DNS-ID identifier type (that is, the dNSName identity
      in the subjectAltName extension) is REQUIRED in rpki-rtr server
      and client implementations which use TLS.  Certification
      authorities which issue rpki-rtr server certificates MUST support
      the DNS-ID identifier type, and the DNS-ID identifier type MUST be
      present in rpki-rtr server certificates.

      DNS names in rpki-rtr server certificates SHOULD NOT contain the
      wildcard character "*".

      rpki-rtr implementations which use TLS MUST NOT use CN-ID
      identifiers; a CN field may be present in the server certificate's
      subject name, but MUST NOT be used for authentication within the
      rules described in [RFC6125].

The only thing missing from the above is explicit mentioning that SRV-ID and URI-ID are not used. (I think the same should apply to your document.)

[Ballot comment]
Two minor questions:
- Should this document maybe update rfc6749?
- Should this be like this?
OLD
""request" and "request_uri" parameters MUST NOT be included in Request Objects."
NEW
""request" and "request_uri" parameters MUST NOT be both included in  Request Objects."

[Ballot comment]
- 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.

[Ballot comment]

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

[Ballot comment]
In 5.2: a document defining HTTPS URI needs to be a normative reference.

In 5.2.3: can you show an example of response (with relevant HTTP Header Fields)? Or update example in 5.2 to include HTTP Header Fields.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-oauth-jwsreq-11.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: Kathleen.Moriarty.ietf@gmail.com, oauth@ietf.org, Hannes.Tschofenig@gmx.net, oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)) to Proposed Standard


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization
  Request (JAR)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-02-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The authorization request in OAuth 2.0 described in RFC 6749 utilizes
  query parameter serialization, which means that Authorization Request
  parameters are encoded in the URI of the request and sent through
  user agents such as web browsers.  While it is easy to implement, it
  means that (a) the communication through the user agents are not
  integrity protected and thus the parameters can be tainted, and (b)
  the source of the communication is not authenticated.  Because of
  these weaknesses, several attacks to the protocol have now been put
  forward.

  This document introduces the ability to send request parameters in a
  JSON Web Token (JWT) instead, which allows the request to be JWS
  signed and/or JWE encrypted so that the integrity, source
  authentication and confidentiality property of the Authorization
  Request is attained.  The request can be sent by value or by
  reference.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) (Informational - IETF stream)
    rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informational - IETF stream)
    rfc6973: Privacy Considerations for Internet Protocols (Informational - IAB stream)
Note that some of these references may already be listed in the acceptable Downref Registry.

Shepherd Write-Up for
"OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)"


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This specification is proposed as a 'Standards Track' document. The
type of RFC is indicated. It changes the encoding of the authorization
request message.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The authorization request in OAuth 2.0 [RFC6749] utilizes query
  parameter serialization, which means that Authorization Request
  parameters are encoded in the URI of the request and sent through
  user agents such as web browsers.  While it is easy to implement, it
  means that (a) the communication through the user agents are not
  integrity protected and thus the parameters can be tainted, and (b)
  the source of the communication is not authentciated.  Because of
  these weaknesses, several attacks to the protocol have now been put
  forward.

  This document introduces the ability to send request parameters in a
  JSON Web Token (JWT) instead, which allows the request to be JWS
  signed and/or JWE encrypted so that the integrity, source
  authentication and confidentiallity property of the Authorization
  Request is attained.  The request can be sent by value or by
  reference.

Working Group Summary

  The document changes the encoding of the parameters in the
  authorization request to a JSON-based encoding.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The request object and the request uri is an optional feature in
the OpenID Connect Core specification and two working groups
in the OpenID Foundation (namely the Modrna WG and the FAPI WG)
are considering using this extension.

As part of the OpenID Foundation certification program the following
implementations of OpenID Connect Core indicate support for this
functionality:
* CZ.NIC mojeID,
* Thierry Habart's SimpleIdentitySever v.2.0.0,
* Roland Hedberg's pyoidc 0.7.7,
* Peercraft ApS's Peercarft,
* MIT's MITREidConnect,
* Gluue Server 2.3,
* Filip Skokan's node-oidc pre supports.

Authlete (https://www.authlete.com/), a commerical, closed source
server implementation, has also implemented this specification and
is offering it.

There is an open source implementation from NRI in PHP and Scala.
NRI's Open Source PHP: https://bitbucket.org/PEOFIAMP/phpoidc

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Hannes Tschofenig is the document shepherd and the responsible area
director is Kathleen Moriarty.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd was involved in the working group review process
and verified the document for correctness.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

There are no concerns regarding the document reviews.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

There are no specific reviews needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The document shepherd has no concerns with the document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

The authors have confirmed full conformance with the provisions of BCP 78
and BCP 79:

Nat: https://www.ietf.org/mail-archive/web/oauth/current/msg16675.html
John: https://www.ietf.org/mail-archive/web/oauth/current/msg16701.html

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed for this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There is solid consensus in the working group for publishing this
document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Nobody threatened an appeal or expressed extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The shepherd checked the document.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review is needed.

(13) Have all references within this document been identified as
either normative or informative?

Yes. The references are split into normative and informative references.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are published RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are two downrefs, namely
* RFC 6234: US Secure Hash Algorithms
* RFC 6819: OAuth Threat Model

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document does not change the status of an existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document does not request any actions by IANA.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

The document contains JSON examples and those have been verified
by the shepherd.