OAuth 2.0 Pushed Authorization Requests
draft-ietf-oauth-par-10

[Ballot comment]
I concur with Ben and Zahed that RFC 6749 should be listed as a normative reference.

Section 1:

* "The impact of which can be ..." -- s/which/this/

* "personal identifiable information" -- s/personal/personally/

* In the final paragraph, since you quote "POST", you should quote "GET" as well.

Section 7.2:

* "An attacker could try register ..." -- s/try/try to/

In Section 7.3, I think that SHOULD ought to be a MUST.  Is there a good reason not to do what it says?

The field names in Section 10.2 don't match the field names in the registry.

[Ballot comment]
Thanks for the efforts on this document.

I think RFC6749 should be in the normative reference. To understand, implement and use this document one has to understand RFC6749 first.

[Ballot comment]
Hi,

Thanks for this document.  Outside my area of expertise, but I have a couple of questions/comments:

Section 2:
  Due to historical reasons there is potential ambiguity regarding the
  appropriate audience value to use when employing JWT client assertion
  based authentication (defined in Section 2.2 of [RFC7523] with
  "private_key_jwt" or "client_secret_jwt" authentication method names
  per Section 9 of [OIDC]).  To address that ambiguity the issuer
  identifier URL of the authorization server according to [RFC8414]
  SHOULD be used as the value of the audience.  In order to facilitate
  interoperability the authorization server MUST accept its issuer
  identifier, token endpoint URL, or pushed authorization request
  endpoint URL as values that identify it as an intended audience.

I may be misunderstanding this text, but I note that by giving flexibility to the client (i.e., the SHOULD) and
being strict on the receiver (MUST support x, y, z), this seems to encourage a proliferation.  Hence, I was wondering whether this might be better the other way round.  I.e., be strict with what is sent, and less strict with what is received: MUST send 'issuer identifier', MUST receive 'issuer identifier', SHOULD receive 'token endpoint URL' and 'pushed authorization request endpoint URL'?

2.
  *  "expires_in" : A JSON number that represents the lifetime of the
      request URI in seconds as a positive integer.  The request URI
      lifetime is at the discretion of the authorization server but will
      typically be relatively short (e.g., between 5 and 600 seconds).

JSON numbers are doubles, but the value is a positive integer.  Does it make sense to put in a hard limit of 2^53, or given that these are expected to be small numbers, 2^31 - 1?


3. The success and error examples both define:
    Content-Type: application/json
    Cache-Control: no-cache, no-store

The document states that the response should be JSON, but should it more specifically specify the content type as "application/json"?
Similarly, the cache control makes sense, but should the document mandate that the response must include "Cache-Control: no-cache, no-store"?

Regards,
Rob

[Ballot comment]
I made a github PR with some editorial suggestions, at
https://github.com/oauthstuff/draft-oauth-par/pull/70 .

Section 1

                                      Those apps typically invoke a
  custom tab with an URL that is translated into a GET request.  Using
  "POST" would require the app to first open a web page under its
  control in the custom tab that in turn would initiate the form "POST"
  towards the authorization server.  PAR is simpler to use and has
  additional security benefits as described above.

This description leaves me with a feeling that I only have an incomplete
picture of why POST is "prohibitively difficult" to use with mobile
apps.  It seems like the setup is describing a scenario where the
authorization logic is operating inside a framework or environment
provided by some other entity that is unwilling or unable to change the
framework to accomodate new OAuth behavior.  Is this other entity the
author of the mobile app, or an app framework, or somethint else?
Having a bit more description of the multiple entities involved and
which one is trying to control the specific mechanics of the
authorization request would make this depiction a more compelling
argument that POST is unusable.

Section 1.1

    POST /as/par HTTP/1.1
    Host: as.example.com
    Content-Type: application/x-www-form-urlencoded
    Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

My personal preference would be to have examples that just want a
generic HTTP authentication mechanism to use something stronger than
Basic, though I don't think this is something that I can insist on, at
present.  (Applies throughout.)

    HTTP/1.1 201 Created
    Cache-Control: no-cache, no-store
    Content-Type: application/json

    {
      "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2",
      "expires_in": 90
    }

The "request_uri" element's semantics feels like a very natural fit for
the native HTTP "Location" response header field (vs requiring a
specific element in the JSON body of the response).  I am less sure that
there's a native HTTP element for the expiration time, as the HTTP
timeouts tend to be associated with HTTP caching vs the actual lifetime
of the resource.

Section 2

It feels a little unfortunate that we have to reuse the metadata
parameters relating to the token_endpoint_auth_method for PAR, but
creating new metadata parameters that are basically always going to hold
the same values is probably worse...

Section 2.1

                    Any token endpoint parameters that are not related
  to client authentication have no defined meaning for a pushed
  authorization request.  [...]

I suppose that in most cases, whether or not a token endpoint parameter
is related to client authentication should be fairly unambiguous ... but
the registry at
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters
has a dedicated column for "parameter usage location".  It seems like it
would be fairly straightforward to add "pushed authorization request" as
an additional possible value there and remove the ambiguity.  We could
enumerate the existing parameters that are applicable and update the
references for the registry to include this document.

Section 2.1

  The authorization server MUST process the request as follows:

We often see descriptions along the lines of "this is not intended to
constrain implementation techniques; any procedure that results in an
equivalent outcome is permissible".  This procedure is simple enough
that we may not need to have concerns of that nature, though.

Section 2.2

  *  "request_uri" : The request URI corresponding to the authorization
      request posted.  This URI is used as reference to the respective
      request data in the subsequent authorization request only.  [...]

Would it be appropriate to use the phrase "single-use" in this
description?

Section 2.4

  It is at the discretion of the authorization server to apply
  restrictions on supplied "redirect_uri" values, e.g. the
  authorization server MAY require a certain URI prefix or allow only a
  query parameter to vary at runtime.

Is this expected to be discoverable by the client?  Would there be a
particular error code used, for example?

Section 3

                                  When the "application/x-www-form-
  urlencoded" HTTP entity-body "request" parameter is used, the request
  object MUST contain all the authorization request parameters as
  claims of the JWT.  Additional request parameters as required by the
  given client authentication method are to be included as
  'application/x-www-form-urlencoded' parameters in the HTTP request
  entity-body [...]

I might flip this around and start off with "authentication request
parameters required by a given client authentication method are included
in the application/x-www-form-urlencoded request directly, and are the
only parameters other than 'request' in the form body.  All other
request parameters, i.e., those pertaining to the authorization request
itself, MUST appear as claims of the JWT representing the authorization
request".  The current formulation kind of hides the specifics of how to
determine which parameter goes where -- the spec for the client
authentication method in use is the authoritative one, IIUC.

  1.  If applicable, decrypt the request object as specified in JAR
      [I-D.ietf-oauth-jwsreq], section 6.1.

  2.  Validate the request object signature as specified in JAR
      [I-D.ietf-oauth-jwsreq], section 6.2.

Do we want to say anything more about error handling if decryption or
signature validation fails?

Section 4

I think we should explicitly state that expired "request_uri"s are
rejected as invalid.

Section 5

  Note that the presence of "pushed_authorization_request_endpoint" is
  sufficient for a client to determine that it may use the pushed
  authorization request flow.  A "request_uri" value obtained from the
  PAR endpoint is usable at the authorization endpoint regardless of
  other authorization server metadata such as
  "request_uri_parameter_supported" or
  "require_request_uri_registration".

Since this is the only mention of it in this document, and it's an OIDC
parameter, maybe we should provide a reference for
"require_request_uri_registration"?

Section 7.1

  An attacker could attempt to guess and replay a valid request URI
  value and try to impersonate the respective client.  [...]

Just to confirm my analysis here: an attacker that does guess a valid
request URI value would probably also need to guess the corresponding
"client_id", and if the request used PKCE, would also need to guess the
PKCE value in order to successfully obtain a token response?  I'm not
sure whether any of that is worth mentioning or not here, though.

Section 10.3

Section 12

Why is RFC 6749 not a normative reference?

NITS

Section 2

  The pushed authorization request endpoint is an HTTP API at the
  authorization server that accepts HTTP "POST" requests with
  parameters in the HTTP request entity-body using the "application/x-
  www-form-urlencoded" format with a character encoding of UTF-8 as

I'm not sure where "entity-body" is defined as the name for the request
body in this case; draft-ietf-httpbis-semantics would seem to just have
us refer to this as the "message body".

Section 2.1

  The client adds the parameters in "x-www-form-urlencoded" format with

I'd suggest a different word than "adds"; these paratmers are the entire
body, not appended to some earlier structure.


Some parameters of the example request (e.g., "state") are duplicated
across the multiple examples in the document.  For those which are
typically single-use in practice, we might consider using different
values in the different examples (including in the JWT payload of the
example request in Section 3).

Section 7.4

The section heading is "Client Policy Change", which to me indicates a
change in the policy of the client, that is, what the client requires.
The text of the section indicates that this is discussing the AS's
per-client policy, though, so I wonder if there is a better phrasing
that could be used.

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

I can only regret that the document shepherd write-up does not include anything about the WG consensus.

Please find below one non-blocking COMMENT points (no need to reply), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
"traditional web applications but is prohibitively difficult to use with mobile apps", I find the adverb "prohibitively" possibly slightly exagerated ;-)

== NITS ==

Is this "user-agent" or "user agent" ? As it is not about the HTTP header.

The PAR acronym for "pushed authorization requests" is defined but nearly never used in the text.

-- Section 1 --
The first § is a single very long sentence. Consider splitting this long sentence in shorter ones ? Same applies in other places in the document (e.g., 1st sentence in section 2.4)

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

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

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the OAuth Authorization Server Metadata registry on the OAuth Parameters registry page located at:

https://www.iana.org/assignments/oauth-parameters/

two new registrations are to be made as follows:

Metadata Name: pushed_authorization_request_endpoint
Metadata Description: URL of the authorization server's pushed authorization request endpoint
Change Controller: IESG
Reference: [ RFC-to-be; section 5 ]

Metadata Name: require_pushed_authorization_requests
Metadata Description: Indicates whether the authorization server accepts authorization request only via the pushed authorization request method.
Change Controller: IESG
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the OAuth Dynamic Client Registration Metadata registry also on the OAuth Parameters registry page located at:

https://www.iana.org/assignments/oauth-parameters/

a new registration is to be made as follows:

Client Metadata Name: require_pushed_authorization_requests
Client Metadata Description: Indicates whether the client is required to use the pushed authorization request method to initiate authorization requests.
Change Controller: IESG
Reference: [ RFC-to-be; section 6 ]

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the OAuth URI registry also on the OAuth Parameters registry page located at:

https://www.iana.org/assignments/oauth-parameters/

a new registration is to be made as follows:

URN: urn:ietf:params:oauth:request_uri:
Common Name: A URN Sub-Namespace for OAuth Request URIs.
Change Controller: IESG
Reference: [ RFC-to-be; section 2.2 ]

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-06-08):

From: The IESG
To: IETF-Announce
CC: draft-ietf-oauth-par@ietf.org, hannes.tschofenig@arm.com, oauth-chairs@ietf.org, oauth@ietf.org, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (OAuth 2.0 Pushed Authorization Requests) to Proposed Standard


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Pushed Authorization
Requests'
  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
last-call@ietf.org mailing lists by 2021-06-08. 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


  This document defines the pushed authorization request endpoint,
  which allows clients to push the payload of an OAuth 2.0
  authorization request to the authorization server via a direct
  request and provides them with a request URI that is used as
  reference to the data in a subsequent call to the authorization
  endpoint.




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



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

Shepherd Write-Up for "OAuth 2.0 Pushed Authorization Requests" 

(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. The spec defines extensions to OAuth 2.0.


(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

  This document defines the pushed authorization request endpoint,
  which allows clients to push the payload of an OAuth 2.0
  authorization request to the authorization server via a direct
  request and provides them with a request URI that is used as
  reference to the data in a subsequent call to the authorization
  endpoint.

Working Group Summary

  The document changes the way to interact with the authorization
  request endpoint. The use of this work is envisioned within the
  finance sector. 

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?

Based on feedback provided by participants of the OAuth working group
the following implementations of PAR are available:

Open source framework implementing PAR (with optional JWSREQ) in Golang:
https://github.com/zntrio/solid

Authlete supports PAR and has passed the PAR test cases in the OpenID
conformance suite. Documents mentioning Authlete's PAR support are here:
https://www.authlete.com/news/20210204_authlete_2_2/
https://www.authlete.com/developers/relnotes/2.2/

The Node.js open source openid-client project:
https://github.com/panva/node-openid-client

Glewlwyd 2.5.2 supports PAR:
https://github.com/babelouest/glewlwyd

PAR is supported by the Connect2id server and the the open source OAuth 2.0 / OIDC SDK,
which has also been picked up by some downstream security frameworks and projects:
https://connect2id.com/blog/pushed-authorisation-request-in-oauth-sdk

The Yes Signing Flow is based on PAR and therefore implemented by our banks (> 1000).
A python client for the yes signing flow is publicly available that uses PAR:
https://github.com/yescom/pyyes

Authress supports PAR.

The Node.js open source oidc-provider project implements PAR behind a feature flag:
https://github.com/panva/node-oidc-provider

The open source project "Loginbuddy" implements PAR and the functionality is
documented here:
https://github.com/SaschaZeGerman/loginbuddy/wiki/Protocols-and-APIs

PingFederate has officially released PAR, see
https://docs.pingidentity.com/bundle/pingfederate-102/page/qem1584122852896.html

Finally, ForgeRock plans to implement PAR.

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.

(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:

Torsten: https://mailarchive.ietf.org/arch/msg/oauth/UThbquRJSBn8lKLOju847-4T5NI/
Brian: https://mailarchive.ietf.org/arch/msg/oauth/7_WI9fKVsYyZjeZx5f-Y7DGD1y0/
Nat: https://mailarchive.ietf.org/arch/msg/oauth/D1WVNkFyuNHY-hji1-sOCVQFWdI/
Dave: https://mailarchive.ietf.org/arch/msg/oauth/Wizp_8oSIaJCFCbMVvA3oZITCBc/
Filip: https://mailarchive.ietf.org/arch/msg/oauth/edmRupNwGj-5C6OgJQ5ak4HNEeQ/

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

No, there have been no IPR disclosures filed on the documennt.

(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?

Among the normative references is a draft (draft-ietf-oauth-jwsreq) and
a non-IETF document. draft-ietf-oauth-jwsreq is pending publication as
an RFC.

The non-IETF document has been published by the OpenID Foundation,
an organization that defined extensions to OAuth. Here is the reference:

  [OIDC]    Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0 incorporating
              errata set 1", 8 November 2014,
              .

(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 values to previously created registries, namely

* the OAuth Authorization Server Metadata registry,
* the OAuth Dynamic Client Registration Metadata registry, and
* the OAuth URI 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 basic JSON examples and those have been verified
by the shepherd.

Shepherd Write-Up for "OAuth 2.0 Pushed Authorization Requests" 

(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. The spec defines extensions to OAuth 2.0.


(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

  This document defines the pushed authorization request endpoint,
  which allows clients to push the payload of an OAuth 2.0
  authorization request to the authorization server via a direct
  request and provides them with a request URI that is used as
  reference to the data in a subsequent call to the authorization
  endpoint.

Working Group Summary

  The document changes the way to interact with the authorization
  request endpoint. The use of this work is envisioned within the
  finance sector. 

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?

Based on feedback provided by participants of the OAuth working group
the following implementations of PAR are available:

Open source framework implementing PAR (with optional JWSREQ) in Golang:
https://github.com/zntrio/solid

Authlete supports PAR and has passed the PAR test cases in the OpenID
conformance suite. Documents mentioning Authlete's PAR support are here:
https://www.authlete.com/news/20210204_authlete_2_2/
https://www.authlete.com/developers/relnotes/2.2/

The Node.js open source openid-client project:
https://github.com/panva/node-openid-client

Glewlwyd 2.5.2 supports PAR:
https://github.com/babelouest/glewlwyd

PAR is supported by the Connect2id server and the the open source OAuth 2.0 / OIDC SDK,
which has also been picked up by some downstream security frameworks and projects:
https://connect2id.com/blog/pushed-authorisation-request-in-oauth-sdk

The Yes Signing Flow is based on PAR and therefore implemented by our banks (> 1000).
A python client for the yes signing flow is publicly available that uses PAR:
https://github.com/yescom/pyyes

Authress supports PAR.

The Node.js open source oidc-provider project implements PAR behind a feature flag:
https://github.com/panva/node-oidc-provider

The open source project "Loginbuddy" implements PAR and the functionality is
documented here:
https://github.com/SaschaZeGerman/loginbuddy/wiki/Protocols-and-APIs

PingFederate has officially released PAR, see
https://docs.pingidentity.com/bundle/pingfederate-102/page/qem1584122852896.html

Finally, ForgeRock plans to implement PAR.

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.

(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:

Torsten: https://mailarchive.ietf.org/arch/msg/oauth/UThbquRJSBn8lKLOju847-4T5NI/
Brian: https://mailarchive.ietf.org/arch/msg/oauth/7_WI9fKVsYyZjeZx5f-Y7DGD1y0/
Nat: https://mailarchive.ietf.org/arch/msg/oauth/D1WVNkFyuNHY-hji1-sOCVQFWdI/
Dave: https://mailarchive.ietf.org/arch/msg/oauth/Wizp_8oSIaJCFCbMVvA3oZITCBc/
Filip: https://mailarchive.ietf.org/arch/msg/oauth/edmRupNwGj-5C6OgJQ5ak4HNEeQ/

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

No, there have been no IPR disclosures filed on the documennt.

(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?

Among the normative references is a draft (draft-ietf-oauth-jwsreq) and
a non-IETF document. draft-ietf-oauth-jwsreq is pending publication as
an RFC.

The non-IETF document has been published by the OpenID Foundation,
an organization that defined extensions to OAuth. Here is the reference:

  [OIDC]    Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0 incorporating
              errata set 1", 8 November 2014,
              .

(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 values to previously created registries, namely

* the OAuth Authorization Server Metadata registry,
* the OAuth Dynamic Client Registration Metadata registry, and
* the OAuth URI 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 basic JSON examples and those have been verified
by the shepherd.

Shepherd Write-Up for "OAuth 2.0 Pushed Authorization Requests" 

(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. The spec defines extensions to OAuth 2.0.


(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

  This document defines the pushed authorization request endpoint,
  which allows clients to push the payload of an OAuth 2.0
  authorization request to the authorization server via a direct
  request and provides them with a request URI that is used as
  reference to the data in a subsequent call to the authorization
  endpoint.

Working Group Summary

  The document changes the way to interact with the authorization
  request endpoint. The use of this work is envisioned within the
  finance sector. 

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?

Based on feedback provided by participants of the OAuth working group
the following implementations of PAR are available:

Open source framework implementing PAR (with optional JWSREQ) in Golang:
https://github.com/zntrio/solid

Authlete supports PAR and has passed the PAR test cases in the OpenID
conformance suite. Documents mentioning Authlete's PAR support are here:
https://www.authlete.com/news/20210204_authlete_2_2/
https://www.authlete.com/developers/relnotes/2.2/

The Node.js open source openid-client project:
https://github.com/panva/node-openid-client

Glewlwyd 2.5.2 supports PAR:
https://github.com/babelouest/glewlwyd

PAR is supported by the Connect2id server and the the open source OAuth 2.0 / OIDC SDK,
which has also been picked up by some downstream security frameworks and projects:
https://connect2id.com/blog/pushed-authorisation-request-in-oauth-sdk

The Yes Signing Flow is based on PAR and therefore implemented by our banks (> 1000).
A python client for the yes signing flow is publicly available that uses PAR:
https://github.com/yescom/pyyes

Authress supports PAR.

The Node.js open source oidc-provider project implements PAR behind a feature flag:
https://github.com/panva/node-oidc-provider

The open source project "Loginbuddy" implements PAR and the functionality is
documented here:
https://github.com/SaschaZeGerman/loginbuddy/wiki/Protocols-and-APIs

PingFederate has officially released PAR, see
https://docs.pingidentity.com/bundle/pingfederate-102/page/qem1584122852896.html

Finally, ForgeRock plans to implement PAR.

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.

(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:

Torsten: https://mailarchive.ietf.org/arch/msg/oauth/UThbquRJSBn8lKLOju847-4T5NI/
Brian: https://mailarchive.ietf.org/arch/msg/oauth/7_WI9fKVsYyZjeZx5f-Y7DGD1y0/
Nat: https://mailarchive.ietf.org/arch/msg/oauth/D1WVNkFyuNHY-hji1-sOCVQFWdI/
Dave: https://mailarchive.ietf.org/arch/msg/oauth/Wizp_8oSIaJCFCbMVvA3oZITCBc/
Filip: https://mailarchive.ietf.org/arch/msg/oauth/edmRupNwGj-5C6OgJQ5ak4HNEeQ/

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

No, there have been no IPR disclosures filed on the documennt.

(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?

Among the normative references is a draft (draft-ietf-oauth-jwsreq) and
a non-IETF document. draft-ietf-oauth-jwsreq is pending publication as
an RFC.

The non-IETF document has been published by the OpenID Foundation,
an organization that defined extensions to OAuth. Here is the reference:

  [OIDC]    Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0 incorporating
              errata set 1", 8 November 2014,
              .

(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 values to previously created registries, namely

* the OAuth Authorization Server Metadata registry,
* the OAuth Dynamic Client Registration Metadata registry, and
* the OAuth URI 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 basic JSON examples and those have been verified
by the shepherd.