draft-ietf-oauth-par-02.txt   draft-ietf-oauth-par-03.txt 
Web Authorization Protocol T. Lodderstedt Web Authorization Protocol T. Lodderstedt
Internet-Draft yes.com Internet-Draft yes.com
Intended status: Standards Track B. Campbell Intended status: Standards Track B. Campbell
Expires: 11 January 2021 Ping Identity Expires: 1 February 2021 Ping Identity
N. Sakimura N. Sakimura
NAT.Consulting NAT.Consulting
D. Tonge D. Tonge
Moneyhub Financial Technology Moneyhub Financial Technology
F. Skokan F. Skokan
Auth0 Auth0
10 July 2020 31 July 2020
OAuth 2.0 Pushed Authorization Requests OAuth 2.0 Pushed Authorization Requests
draft-ietf-oauth-par-02 draft-ietf-oauth-par-03
Abstract Abstract
This document defines the pushed authorization request endpoint, This document defines the pushed authorization request endpoint,
which allows clients to push the payload of an OAuth 2.0 which allows clients to push the payload of an OAuth 2.0
authorization request to the authorization server via a direct authorization request to the authorization server via a direct
request and provides them with a request URI that is used as request and provides them with a request URI that is used as
reference to the data in a subsequent authorization request. reference to the data in a subsequent authorization request.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 January 2021. This Internet-Draft will expire on 1 February 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 5
2. Pushed Authorization Request Endpoint . . . . . . . . . . . . 5 2. Pushed Authorization Request Endpoint . . . . . . . . . . . . 5
2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Successful Response . . . . . . . . . . . . . . . . . . . 7 2.2. Successful Response . . . . . . . . . . . . . . . . . . . 8
2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 8 2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 9
3. "request" Parameter . . . . . . . . . . . . . . . . . . . . . 9 3. "request" Parameter . . . . . . . . . . . . . . . . . . . . . 10
3.1. Error responses for Request Object . . . . . . . . . . . 11
3.1.1. Authentication Required . . . . . . . . . . . . . . . 11
4. Authorization Request . . . . . . . . . . . . . . . . . . . . 12 4. Authorization Request . . . . . . . . . . . . . . . . . . . . 12
5. Authorization Server Metadata . . . . . . . . . . . . . . . . 12 5. Authorization Server Metadata . . . . . . . . . . . . . . . . 13
6. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 13 6. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Request URI Guessing . . . . . . . . . . . . . . . . . . 13 7.1. Request URI Guessing . . . . . . . . . . . . . . . . . . 14
7.2. Open Redirection . . . . . . . . . . . . . . . . . . . . 13 7.2. Open Redirection . . . . . . . . . . . . . . . . . . . . 14
7.3. Request Object Replay . . . . . . . . . . . . . . . . . . 13 7.3. Request Object Replay . . . . . . . . . . . . . . . . . . 14
7.4. Client Policy Change . . . . . . . . . . . . . . . . . . 13 7.4. Client Policy Change . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. OAuth Authorization Server Metadata . . . . . . . . . . . 14 9.1. OAuth Authorization Server Metadata . . . . . . . . . . . 15
9.2. OAuth Dynamic Client Registration Metadata . . . . . . . 14 9.2. OAuth Dynamic Client Registration Metadata . . . . . . . 15
9.3. OAuth URI Registration . . . . . . . . . . . . . . . . . 15 9.3. OAuth URI Registration . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . 15 10. Normative References . . . . . . . . . . . . . . . . . . . . 15
11. Informative References . . . . . . . . . . . . . . . . . . . 15 11. Informative References . . . . . . . . . . . . . . . . . . . 16
Appendix A. Document History . . . . . . . . . . . . . . . . . . 16 Appendix A. Document History . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
In OAuth [RFC6749] authorization request parameters are typically In OAuth [RFC6749] authorization request parameters are typically
sent as URI query parameters via redirection in the user-agent. This sent as URI query parameters via redirection in the user-agent. This
is simple but also yields challenges: is simple but also yields challenges:
* There is no cryptographic integrity and authenticity protection, * There is no cryptographic integrity and authenticity protection.
i.e. the request can be modified on its way through the user-agent An attacker could, for example, modify the ACR value requested by
and attackers can impersonate legitimate clients. the client or swap the context of a payment transaction
authorization by changing scope values. Although clients should
detect such changes by inspecting the token response data,
preventing such modifications early in the process would be a
better solution.
* There is no mechanism to ensure confidentiality of the request * There is no mechanism to ensure confidentiality of the request
parameters. parameters. This obviously is an issue if personal identifiable
information is sent in the authorization request, which might be
the case in identity and open banking scenarios.
* Authorization request URLs can become quite large, especially in * Authorization request URLs can become quite large, especially in
scenarios requiring fine-grained authorization data. scenarios requiring fine-grained authorization data, which might
cause errors in request processing.
JWT Secured Authorization Request (JAR) [I-D.ietf-oauth-jwsreq] JWT Secured Authorization Request (JAR) [I-D.ietf-oauth-jwsreq]
provides solutions for those challenges by allowing OAuth clients to provides solutions for the security challenges by allowing OAuth
wrap authorization request parameters in a signed, and optionally clients to wrap authorization request parameters in a signed, and
encrypted, JSON Web Token (JWT), the so-called "Request Object". optionally encrypted, JSON Web Token (JWT), the so-called "Request
Object". In order to cope with the size restrictions, JAR introduces
In order to cope with the size restrictions, JAR introduces the the "request_uri" parameter that allows clients to send a reference
"request_uri" parameter that allows clients to send a reference to a to a request object instead of the request object itself.
request object instead of the request object itself.
This document complements JAR by providing an interoperable way to This document complements JAR by providing an interoperable way to
push the payload of a request object directly to the AS in exchange push the payload of a request object directly to the authorization
for a "request_uri". server in exchange for a "request_uri".
It also allows for clients to push the form encoded authorization It also allows for clients to push the form encoded authorization
request parameters to the AS in order to exchange them for a request request parameters to the authorization server in order to exchange
URI that the client can use in a subsequent authorization request. them for a request URI that the client can use in a subsequent
authorization request.
For example, the following authorization request, For example, a client typically initiates an authorization request by
directing the user-agent to make an HTTP request like the following:
GET /authorize?response_type=code GET /authorize?response_type=code
&client_id=s6BhdRkqt3&state=af0ifjsldkj &client_id=s6BhdRkqt3&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: as.example.com Host: as.example.com
could be pushed directly to the AS by the client as follows: Such a request could instead be pushed directly to the authorization
server by the client as follows:
POST /as/par HTTP/1.1 POST /as/par HTTP/1.1
Host: as.example.com Host: as.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
response_type=code response_type=code
&client_id=s6BhdRkqt3&state=af0ifjsldkj &client_id=s6BhdRkqt3&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
The AS responds with a request URI, The authorization server responds with a request URI:
HTTP/1.1 201 Created HTTP/1.1 201 Created
Cache-Control: no-cache, no-store Cache-Control: no-cache, no-store
Content-Type: application/json Content-Type: application/json
{ {
"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2", "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2",
"expires_in": 90 "expires_in": 90
} }
which is used by the client in the subsequent authorization request The client uses the request URI value to create the subsequent
as follows, authorization request and directing the user-agent to make an HTTP
request like the following:
GET /authorize?client_id=s6BhdRkqt3& GET /authorize?client_id=s6BhdRkqt3&
request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1 request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1
Host: as.example.com
The pushed authorization request endpoint fosters OAuth security by The pushed authorization request endpoint fosters OAuth security by
providing all clients a simple means for an integrity protected providing all clients a simple means for a confidential and integrity
authorization request, but it also allows clients requiring an even protected authorization request, but it also allows clients requiring
higher security level, especially cryptographically confirmed non- an even higher security level, especially cryptographically confirmed
repudiation, to explicitly adopt JWT-based request objects. non-repudiation, to explicitly adopt JWT-based request objects.
As a further benefit, the pushed authorization request allows the AS As a further benefit, the pushed authorization request allows the
to authenticate the clients before any user interaction happens, authorization server to authenticate the clients before any user
i.e., the AS may refuse unauthorized requests much earlier in the interaction happens, i.e., the authorization server may refuse
process and has much higher confidence in the client's identity in unauthorized requests much earlier in the process and has much higher
the authorization process than before. confidence in the client's identity in the authorization process than
before. This generally improves security since it prevents attempts
to spoof confidential clients early in the process.
This is directly utilized by this draft to allow confidential clients This is directly utilized by this draft to allow confidential clients
to set the redirect URI for every authorization request, which gives to set the redirect URI for every authorization request, which gives
them more flexibility in building redirect URI. And if the client them more flexibility in building redirect URI. And if the client
IDs and credentials are managed by some external authority (e.g. a IDs and credentials are managed by some external authority (e.g. a
certification authority), explicit client registration with the certification authority), explicit client registration with the
particular AS could practically be skipped. particular authorization server could practically be skipped.
Note: HTTP POST requests to the authorization endpoint as described
in Section 3.1 of [RFC6749] and Section 3.1.2.1 of [OIDC] could also
be used to cope with the request size limitations described above.
Although this is a viable option for traditional web applications,
it's difficult to use with mobile apps. 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.
1.1. Conventions and Terminology 1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification uses the terms "access token", "refresh token", This specification uses the terms "access token", "refresh token",
skipping to change at page 5, line 11 skipping to change at page 5, line 43
"authorization request", "authorization response", "token endpoint", "authorization request", "authorization response", "token endpoint",
"grant type", "access token request", "access token response", and "grant type", "access token request", "access token response", and
"client" defined by The OAuth 2.0 Authorization Framework [RFC6749]. "client" defined by The OAuth 2.0 Authorization Framework [RFC6749].
2. Pushed Authorization Request Endpoint 2. Pushed Authorization Request Endpoint
The pushed authorization request endpoint is an HTTP API at the The pushed authorization request endpoint is an HTTP API at the
authorization server that accepts POST requests with parameters in authorization server that accepts POST requests with parameters in
the HTTP request entity-body using the "application/x-www-form- the HTTP request entity-body using the "application/x-www-form-
urlencoded" format with a character encoding of UTF-8 as described in urlencoded" format with a character encoding of UTF-8 as described in
Appendix B of [RFC6749]. Appendix B of [RFC6749]. The pushed authorization request endpoint
URL MUST use the "https" scheme.
Authorization servers supporting pushed authorization requests SHOULD Authorization servers supporting pushed authorization requests SHOULD
include the URL of their pushed authorization request endpoint in include the URL of their pushed authorization request endpoint in
their authorization server metadata document [RFC8414] using the their authorization server metadata document [RFC8414] using the
"pushed_authorization_request_endpoint" parameter as defined in "pushed_authorization_request_endpoint" parameter as defined in
Section 5. Section 5.
The endpoint accepts the parameters defined in [RFC6749] for the The endpoint accepts the parameters defined in [RFC6749] for the
authorization endpoint as well as all applicable extensions defined authorization endpoint as well as all applicable extensions defined
for the authorization endpoint. Some examples of such extensions for the authorization endpoint. Some examples of such extensions
skipping to change at page 5, line 39 skipping to change at page 6, line 25
apply for the pushed authorization request endpoint as well. If apply for the pushed authorization request endpoint as well. If
applicable, the "token_endpoint_auth_method" client metadata applicable, the "token_endpoint_auth_method" client metadata
parameter indicates the registered authentication method for the parameter indicates the registered authentication method for the
client to use when making direct requests to the authorization client to use when making direct requests to the authorization
server, including requests to the pushed authorization request server, including requests to the pushed authorization request
endpoint. endpoint.
Note that there's some potential ambiguity around the appropriate Note that there's some potential ambiguity around the appropriate
audience value to use when JWT client assertion based authentication audience value to use when JWT client assertion based authentication
is employed. To address that ambiguity the issuer identifier URL of is employed. To address that ambiguity the issuer identifier URL of
the AS according to [RFC8414] SHOULD be used as the value of the the authorization server according to [RFC8414] SHOULD be used as the
audience. In order to facilitate interoperability the AS MUST accept value of the audience. In order to facilitate interoperability the
its issuer identifier, token endpoint URL, or pushed authorization authorization server MUST accept its issuer identifier, token
request endpoint URL as values that identify it as an intended endpoint URL, or pushed authorization request endpoint URL as values
audience. that identify it as an intended audience.
2.1. Request 2.1. Request
A client can send all the parameters that usually comprise an A client can send all the parameters that usually comprise an
authorization request to the pushed authorization request endpoint. authorization request to the pushed authorization request endpoint.
A basic parameter set will typically include: A basic parameter set will typically include:
* "client_id" * "client_id"
* "response_type" * "response_type"
* "redirect_uri" * "redirect_uri"
* "scope" * "scope"
* "state" * "state"
* "code_challenge" * "code_challenge"
skipping to change at page 6, line 43 skipping to change at page 7, line 31
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
response_type=code& response_type=code&
state=af0ifjsldkj& state=af0ifjsldkj&
client_id=s6BhdRkqt3& client_id=s6BhdRkqt3&
redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb& redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb&
code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U& code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U&
code_challenge_method=S256& code_challenge_method=S256&
scope=ais scope=ais
The AS MUST process the request as follows: The authorization server MUST process the request as follows:
1. The AS MUST authenticate the client in the same way as at the 1. Authenticate the client in the same way as at the token endpoint.
token endpoint.
2. The AS MUST reject the request if the "request_uri" authorization 2. Reject the request if the "request_uri" authorization request
request parameter is provided. parameter is provided.
3. The AS MUST validate the pushed request as it would an 3. Validate the pushed request as it would an authorization request
authorization request sent to the authorization endpoint. For sent to the authorization endpoint. For example, the
example, the authorization server checks whether the redirect URI authorization server checks whether the redirect URI matches one
matches one of the redirect URIs configured for the client and of the redirect URIs configured for the client and also checks
also checks whether the client is authorized for the scope for whether the client is authorized for the scope for which it is
which it is requesting access. This validation allows the requesting access. This validation allows the authorization
authorization server to refuse unauthorized or fraudulent server to refuse unauthorized or fraudulent requests early. The
requests early. The AS MAY omit validation steps that it is authorization server MAY omit validation steps that it is unable
unable to perform when processing the pushed request, however to perform when processing the pushed request, however such
such checks MUST then be performed at the authorization endpoint. checks MUST then be performed at the authorization endpoint.
The AS MAY allow confidential clients to establish per-authorization The authorization server MAY allow confidential clients to establish
request redirect URIs with every pushed authorization request. This per-authorization request redirect URIs with every pushed
is possible since, in contrast to [RFC6749], this specification gives authorization request. This is possible since, in contrast to
the AS the ability to authenticate and authorize clients before the
actual authorization request is performed. [RFC6749], this specification gives the authorization server the
ability to authenticate and authorize clients before the actual
authorization request is performed.
This feature gives clients more flexibility in building redirect URIs This feature gives clients more flexibility in building redirect URIs
and, if the client IDs and credentials are managed by some authority and, if the client IDs and credentials are managed by some authority
(CA or other type), the explicit client registration with the (CA or other type), the explicit client registration with the
particular AS (manually or via dynamic client registration [RFC7591]) particular authorization server (manually or via dynamic client
could practically be skipped. This makes this mechanism especially registration [RFC7591]) could practically be skipped. This makes
useful for clients interacting with a federation of ASs (or OpenID this mechanism especially useful for clients interacting with a
Connect OPs), for example in Open Banking, where the certificate is federation of authorization servers (or OpenID Connect Providers),
provided as part of a federated PKI. for example in Open Banking, where the certificate is provided as
part of a federated PKI.
2.2. Successful Response 2.2. Successful Response
If the verification is successful, the server MUST generate a request If the verification is successful, the server MUST generate a request
URI and return a JSON response that contains "request_uri" and URI and return a JSON response with the following members at the top
"expires_in" members at the top level with "201 Created" HTTP level with "201 Created" HTTP response code.
response code.
* "request_uri" : The request URI corresponding to the authorization * "request_uri" : The request URI corresponding to the authorization
request posted. This URI is used as reference to the respective request posted. This URI is used as reference to the respective
request data in the subsequent authorization request only. The request data in the subsequent authorization request only. The
way the authorization process obtains the authorization request way the authorization process obtains the authorization request
data is at the discretion of the authorization server and out of data is at the discretion of the authorization server and out of
scope of this specification. There is no need to make the scope of this specification. There is no need to make the
authorization request data available to other parties via this authorization request data available to other parties via this
URI. URI.
* "expires_in" : A JSON number that represents the lifetime of the * "expires_in" : A JSON number that represents the lifetime of the
request URI in seconds. The request URI lifetime is at the request URI in seconds. The request URI lifetime is at the
discretion of the AS. discretion of the authorization server and will typically be
relatively short.
The format of the "request_uri" value is at the discretion of the The format of the "request_uri" value is at the discretion of the
authorization server but it MUST contain some part generated using a authorization server but it MUST contain some part generated using a
cryptographically strong pseudorandom algorithm such that it is cryptographically strong pseudorandom algorithm such that it is
computationally infeasible to predict or guess a valid value. The computationally infeasible to predict or guess a valid value. The
authorization server MAY construct the "request_uri" value using the authorization server MAY construct the "request_uri" value using the
form "urn:ietf:params:oauth:request_uri:<reference-value>" with form "urn:ietf:params:oauth:request_uri:<reference-value>" with
"<reference-value>" as the random part of the URI that references the "<reference-value>" as the random part of the URI that references the
respective authorization request data. The string representation of respective authorization request data. The string representation of
a UUID as a URN per [RFC4122] is also an option for authorization a UUID as a URN per [RFC4122] is also an option for authorization
servers to construct "request_uri" values. servers to construct "request_uri" values.
The "request_uri" MUST be bound to the client that posted the The "request_uri" MUST be bound to the client that posted the
authorization request. authorization request.
Since the request URI can be replayed, its lifetime SHOULD be short Since parts of the request content, e.g. the "code_challenge"
and preferably limited to one-time use. parameter value, is unique to a certain authorization request, a
"request_uri" SHOULD be limited to one-time use.
The following is an example of such a response: The following is an example of such a response:
HTTP/1.1 201 Created HTTP/1.1 201 Created
Content-Type: application/json Content-Type: application/json
Cache-Control: no-cache, no-store Cache-Control: no-cache, no-store
{ {
"request_uri": "request_uri":
"urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2", "urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2",
skipping to change at page 8, line 46 skipping to change at page 9, line 33
For an error the authorization server sets an appropriate HTTP status For an error the authorization server sets an appropriate HTTP status
code and MAY include additional error parameters in the entity-body code and MAY include additional error parameters in the entity-body
of the HTTP response using the format specified for the token of the HTTP response using the format specified for the token
endpoint in Section 5.2 of [RFC6749]. endpoint in Section 5.2 of [RFC6749].
If the authorization server sets an error code, it SHOULD be one of If the authorization server sets an error code, it SHOULD be one of
the defined codes for the token endpoint in Section 5.2 or for the the defined codes for the token endpoint in Section 5.2 or for the
authorization endpoint in Sections 4.1.2.1 and 4.2.2.1 of [RFC6749], authorization endpoint in Sections 4.1.2.1 and 4.2.2.1 of [RFC6749],
or by an OAuth extension if one is involved in the initial processing or by an OAuth extension if one is involved in the initial processing
of authorization request that was pushed. Since initial processing of authorization request that was pushed. Since initial processing
of the pushed authorisation request doesn't involve resource owner of the pushed authorization request doesn't involve resource owner
interaction, error codes related to user interaction, such as interaction, error codes related to user interaction, such as
"consent_required" defined by [OIDC], are not returned. "consent_required" defined by [OIDC], are not returned.
If the client is required to use signed request objects, either by If the client is required to use signed request objects, either by
authorization server or client policy (see [I-D.ietf-oauth-jwsreq], authorization server or client policy (see [I-D.ietf-oauth-jwsreq],
section 10.5), the authorization server MUST only accept requests section 10.5), the authorization server MUST only accept requests
complying with the definition given in Section 3 and MUST refuse any complying with the definition given in Section 3 and MUST refuse any
other request with HTTP status code 400 and error code other request with HTTP status code 400 and error code
"invalid_request". "invalid_request".
In addition to the error codes above, the pushed authorization In addition to the error codes above, the pushed authorization
request endpoint specifies use of the following HTTP status codes: request endpoint can also make use of the following HTTP status
codes:
* 405: If the request did not use POST, the authorization server * 405: If the request did not use POST, the authorization server
responds with an HTTP 405 (Method Not Allowed) status code. responds with an HTTP 405 (Method Not Allowed) status code.
* 413: If the request size was beyond the upper bound that the * 413: If the request size was beyond the upper bound that the
authorization server allows, the authorization server responds authorization server allows, the authorization server responds
with an HTTP 413 (Payload Too Large) status code. with an HTTP 413 (Payload Too Large) status code.
* 429: If the request from the client for a time period goes beyond * 429: If the request from the client for a time period goes beyond
the number the authorization server allows, the authorization the number the authorization server allows, the authorization
skipping to change at page 9, line 38 skipping to change at page 10, line 29
{ {
"error": "invalid_request", "error": "invalid_request",
"error_description": "error_description":
"The redirect_uri is not valid for the given client" "The redirect_uri is not valid for the given client"
} }
3. "request" Parameter 3. "request" Parameter
Clients MAY use the "request" parameter as defined in JAR Clients MAY use the "request" parameter as defined in JAR
[I-D.ietf-oauth-jwsreq] to push a request object JWT to the AS. The [I-D.ietf-oauth-jwsreq] to push a request object JWT to the
rules for processing, signing, and encryption of the request object authorization server. The rules for processing, signing, and
as defined in JAR [I-D.ietf-oauth-jwsreq] apply. When the encryption of the request object as defined in JAR
"application/x-www-form-urlencoded" HTTP entity-body "request" [I-D.ietf-oauth-jwsreq] apply. When the "application/x-www-form-
parameter is used, the request object MUST contain all the urlencoded" HTTP entity-body "request" parameter is used, the request
authorization request parameters as claims of the JWT. Additional object MUST contain all the authorization request parameters as
request parameters as required by the given client authentication claims of the JWT. Additional request parameters as required by the
method are to be included as 'application/x-www-form-urlencoded' given client authentication method are to be included as
parameters in the HTTP request entity-body (e.g. Mutual TLS client 'application/x-www-form-urlencoded' parameters in the HTTP request
authentication [I-D.ietf-oauth-mtls] uses the "client_id" HTTP entity-body (e.g. Mutual TLS client authentication
request parameter while JWT assertion based client authentication [I-D.ietf-oauth-mtls] uses the "client_id" HTTP request parameter
[RFC7523] uses "client_assertion" and "client_assertion_type"). while JWT assertion based client authentication [RFC7523] uses
"client_assertion" and "client_assertion_type").
The following is an example of a pushed authorization request using a The following is an example of a pushed authorization request using a
signed request object. The client is authenticated by its client signed request object. The client is authenticated by its client
secret using the HTTP Basic Authentication scheme specified in secret using the HTTP Basic Authentication scheme specified in
Section 2.3.1 of [RFC6749]: Section 2.3.1 of [RFC6749]:
POST /as/par HTTP/1.1 POST /as/par HTTP/1.1
Host: as.example.com Host: as.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
skipping to change at page 10, line 28 skipping to change at page 11, line 23
jdF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsInNjb3BlIjoi jdF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsInNjb3BlIjoi
YWlzIiwic3RhdGUiOiJhZjBpZmpzbGRraiIsImNvZGVfY2hhbGxlbmdlIjoiSzItb YWlzIiwic3RhdGUiOiJhZjBpZmpzbGRraiIsImNvZGVfY2hhbGxlbmdlIjoiSzItb
HRjODNhY2M0aDBjOXc2RVNDX3JFTVRKM2J3dy11Q0hhb2VLMXQ4VSIsImNvZGVfY2 HRjODNhY2M0aDBjOXc2RVNDX3JFTVRKM2J3dy11Q0hhb2VLMXQ4VSIsImNvZGVfY2
hhbGxlbmdlX21ldGhvZCI6IlMyNTYifQ.O49ffUxRPdNkN3TRYDvbEYVr1CeAL64u hhbGxlbmdlX21ldGhvZCI6IlMyNTYifQ.O49ffUxRPdNkN3TRYDvbEYVr1CeAL64u
W4FenV3n9WlaFIRHeFblzv-wlEtMm8-tusGxeE9z3ek6FxkhvvLEqEpjthXnyXqqy W4FenV3n9WlaFIRHeFblzv-wlEtMm8-tusGxeE9z3ek6FxkhvvLEqEpjthXnyXqqy
Jfq3k9GSf5ay74ml_0D6lHE1hy-kVWg7SgoPQ-GB1xQ9NRhF3EKS7UZIrUHbFUCF0 Jfq3k9GSf5ay74ml_0D6lHE1hy-kVWg7SgoPQ-GB1xQ9NRhF3EKS7UZIrUHbFUCF0
MsRLbmtIvaLYbQH_Ef3UkDLOGiU7exhVFTPeyQUTM9FF-u3K-zX-FO05_brYxNGLh MsRLbmtIvaLYbQH_Ef3UkDLOGiU7exhVFTPeyQUTM9FF-u3K-zX-FO05_brYxNGLh
VkO1G8MjqQnn2HpAzlBd5179WTzTYhKmhTiwzH-qlBBI_9GLJmE3KOipko9TfSpa2 VkO1G8MjqQnn2HpAzlBd5179WTzTYhKmhTiwzH-qlBBI_9GLJmE3KOipko9TfSpa2
6H4JOlMyfZFl0PCJwkByS0xZFJ2sTo3Gkk488RQohhgt1I0onw 6H4JOlMyfZFl0PCJwkByS0xZFJ2sTo3Gkk488RQohhgt1I0onw
The AS needs to take the following steps beyond the processing rules The authorization server needs to take the following steps beyond the
defined in Section 2.1: processing rules defined in Section 2.1:
1. If applicable, the AS decrypts the request object as specified in 1. If applicable, decrypt the request object as specified in JAR
JAR [I-D.ietf-oauth-jwsreq], section 6.1. [I-D.ietf-oauth-jwsreq], section 6.1.
2. The AS validates the request object signature as specified in JAR 2. Validates the request object signature as specified in JAR
[I-D.ietf-oauth-jwsreq], section 6.2. [I-D.ietf-oauth-jwsreq], section 6.2.
3. If the client is a confidential client, the authorization server 3. If the client is a confidential client, the authorization server
MUST check whether the authenticated "client_id" matches the MUST check whether the authenticated "client_id" matches the
"client_id" claim in the request object. If they do not match, "client_id" claim in the request object. If they do not match,
the authorization server MUST refuse to process the request. It the authorization server MUST refuse to process the request. It
is at the authorization server's discretion to require the "iss" is at the authorization server's discretion to require the "iss"
claim to match the "client_id" as well. claim to match the "client_id" as well.
The following RSA key pair, represented in JWK [RFC7517] format, can The following RSA key pair, represented in JWK [RFC7517] format, can
skipping to change at page 11, line 39 skipping to change at page 12, line 39
5WCW6BNgB3HDWhq8aYPirwQnqm0K9mX1E-4xM10WWZ-rP3XjYpQeS0Snru5 5WCW6BNgB3HDWhq8aYPirwQnqm0K9mX1E-4xM10WWZ-rP3XjYpQeS0Snru5
LFVWsAzi-FX7BOqBibSAXLdEGXcXa44l08iec_bPD3xduq5V_1YoE", LFVWsAzi-FX7BOqBibSAXLdEGXcXa44l08iec_bPD3xduq5V_1YoE",
"dq": "Nz2PF3XM6bEc4XsluKZO70ErdYdKgdtIJReUR7Rno_tOZpejwlPGBYVW19 "dq": "Nz2PF3XM6bEc4XsluKZO70ErdYdKgdtIJReUR7Rno_tOZpejwlPGBYVW19
zpAeYtCT82jxroB2XqhLxGeMxEPQpsz2qTKLSe4BgHY2ml2uxSDGdjcsrbb zpAeYtCT82jxroB2XqhLxGeMxEPQpsz2qTKLSe4BgHY2ml2uxSDGdjcsrbb
NoKUKaN1CuyZszhWl1n0AT_bENl4bJgQj_Fh0UEsQj5YBBUJt5gr_k", NoKUKaN1CuyZszhWl1n0AT_bENl4bJgQj_Fh0UEsQj5YBBUJt5gr_k",
"dp": "Zc877jirkkLOtyTs2vxyNe9KnMNAmOidlUc2tE_-0gAL4Lpo1hSwKCtKwe "dp": "Zc877jirkkLOtyTs2vxyNe9KnMNAmOidlUc2tE_-0gAL4Lpo1hSwKCtKwe
ZJ-gkqt1hT-dwNx_0Xtg_-NXsadMRMwJnzBMYwYAfjApUkfqABc0yUCJJl3 ZJ-gkqt1hT-dwNx_0Xtg_-NXsadMRMwJnzBMYwYAfjApUkfqABc0yUCJJl3
KozRCugf1WXkU9GZAH2_x8PUopdNUEa70ISowPRh04HANKX4fkjWAE" KozRCugf1WXkU9GZAH2_x8PUopdNUEa70ISowPRh04HANKX4fkjWAE"
} }
3.1. Error responses for Request Object
This section gives the error responses that go beyond the basic
Section 2.3.
3.1.1. Authentication Required
If the signature validation fails, the authorization server returns a
"401 Unauthorized" HTTP error response. The same applies if the
"client_id" or, if applicable, the "iss" claim in the request object
do not match the authenticated "client_id".
4. Authorization Request 4. Authorization Request
The client uses the "request_uri" value returned by the authorization The client uses the "request_uri" value returned by the authorization
server to build an authorization request as defined in server to build an authorization request as defined in
[I-D.ietf-oauth-jwsreq]. This is shown in the following example. [I-D.ietf-oauth-jwsreq]. This is shown in the following example
where the client directs the user-agent to make the following HTTP
request:
GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams
%3Aoauth%3Arequest_uri%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1 %3Aoauth%3Arequest_uri%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1
Host: as.example.com
The authorization server MUST validate authorization requests arising The authorization server MUST validate authorization requests arising
from a pushed request as it would any other authorization request. from a pushed request as it would any other authorization request.
The authorization server MAY omit validation steps that it performed The authorization server MAY omit validation steps that it performed
when the request was pushed, provided that it can validate that the when the request was pushed, provided that it can validate that the
request was a pushed request, and that the request or the request was a pushed request, and that the request or the
authorization server's policy has not been modified in a way that authorization server's policy has not been modified in a way that
would affect the outcome of the omitted steps. would affect the outcome of the omitted steps.
Authorization server policy MAY dictate, either globally or on a per- Authorization server policy MAY dictate, either globally or on a per-
skipping to change at page 13, line 27 skipping to change at page 14, line 12
"require_pushed_authorization_requests" Boolean parameter indicating "require_pushed_authorization_requests" Boolean parameter indicating
whether the only means of initiating an authorization request the whether the only means of initiating an authorization request the
client is allowed to use is a pushed authorization request. client is allowed to use is a pushed authorization request.
7. Security Considerations 7. Security Considerations
7.1. Request URI Guessing 7.1. Request URI Guessing
An attacker could attempt to guess and replay a valid request URI An attacker could attempt to guess and replay a valid request URI
value and try to impersonate the respective client. The AS MUST value and try to impersonate the respective client. The
consider the considerations given in JAR [I-D.ietf-oauth-jwsreq], authorization server MUST consider the considerations given in JAR
section 10.2, clause d on request URI entropy. [I-D.ietf-oauth-jwsreq], section 10.2, clause (d) on request URI
entropy.
7.2. Open Redirection 7.2. Open Redirection
An attacker could try register a redirect URI pointing to a site An attacker could try register a redirect URI pointing to a site
under his control in order to obtain authorization codes or lauch under his control in order to obtain authorization codes or lauch
other attacks towards the user. The AS MUST only accept new redirect other attacks towards the user. The authorization server MUST only
URIs in the PAR request from confidential clients after sucessful accept new redirect URIs in the PAR request from confidential clients
authentication and authorization. after successful authentication and authorization.
7.3. Request Object Replay 7.3. Request Object Replay
An attacker could replay a request URI captured from a legitimate An attacker could replay a request URI captured from a legitimate
authorization request. In order to cope with such attacks, the AS authorization request. In order to cope with such attacks, the
SHOULD make the request URIs one-time use. authorization server SHOULD make the request URIs one-time use.
7.4. Client Policy Change 7.4. Client Policy Change
The client policy might change between the lodging of the request The client policy might change between the lodging of the request
object and the authorization request using a particular request object and the authorization request using a particular request
object. It is therefore recommended that the AS check the request object. It is therefore recommended that the authorization server
parameter against the client policy when processing the authorization check the request parameter against the client policy when processing
request. the authorization request.
8. Acknowledgements 8. Acknowledgements
This specification is based on the work towards Pushed Request Object This specification is based on the work towards Pushed Request Object
(https://bitbucket.org/openid/fapi/src/master/ (https://bitbucket.org/openid/fapi/src/master/
Financial_API_Pushed_Request_Object.md) conducted at the Financial- Financial_API_Pushed_Request_Object.md) conducted at the Financial-
grade API working group at the OpenID Foundation. We would like to grade API working group at the OpenID Foundation. We would like to
thank the members of the WG for their valuable contributions. thank the members of the WG for their valuable contributions.
We would like to thank Vladimir Dzhuvinov, Aaron Parecki, Justin We would like to thank Vladimir Dzhuvinov, Aaron Parecki, Justin
Richer, Sascha Preibisch, Daniel Fett, Michael B. Jones, Annabelle Richer, Sascha Preibisch, Daniel Fett, Michael B. Jones, Annabelle
Backman, Joseph Heenan, and Takahiko Kawasaki for their valuable Backman, Joseph Heenan, Sean Glencross, Maggie Hung, Neil Madden, and
feedback on this draft. Takahiko Kawasaki for their valuable feedback on this draft.
9. IANA Considerations 9. IANA Considerations
9.1. OAuth Authorization Server Metadata 9.1. OAuth Authorization Server Metadata
This specification requests registration of the following values in This specification requests registration of the following values in
the IANA "OAuth Authorization Server Metadata" registry of the IANA "OAuth Authorization Server Metadata" registry of
[IANA.OAuth.Parameters] established by [RFC8414]. [IANA.OAuth.Parameters] established by [RFC8414].
Metadata Name: "pushed_authorization_request_endpoint" Metadata Name: "pushed_authorization_request_endpoint"
skipping to change at page 15, line 18 skipping to change at page 16, line 5
the "OAuth URI" registry of [IANA.OAuth.Parameters] established by the "OAuth URI" registry of [IANA.OAuth.Parameters] established by
[RFC6755]. [RFC6755].
URN: "urn:ietf:params:oauth:request_uri:" URN: "urn:ietf:params:oauth:request_uri:"
Common Name: A URN Sub-Namespace for OAuth Request URIs. Common Name: A URN Sub-Namespace for OAuth Request URIs.
Change Controller: IESG Change Controller: IESG
Specification Document(s): Section 2.2 of [[ this document ]] Specification Document(s): Section 2.2 of [[ this document ]]
10. Normative References 10. Normative References
[I-D.ietf-oauth-jwsreq]
Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization
Framework: JWT Secured Authorization Request (JAR)", Work
in Progress, Internet-Draft, draft-ietf-oauth-jwsreq-26,
27 July 2020,
<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-26>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
C. Mortimore, "OpenID Connect Core 1.0 incorporating 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
errata set 1", 8 November 2014, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
<http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, C. Mortimore, "OpenID Connect Core 1.0 incorporating
May 2017, <https://www.rfc-editor.org/info/rfc8174>. errata set 1", 8 November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414, Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018, DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>. <https://www.rfc-editor.org/info/rfc8414>.
[I-D.ietf-oauth-jwsreq]
Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization
Framework: JWT Secured Authorization Request (JAR)", Work
in Progress, Internet-Draft, draft-ietf-oauth-jwsreq-25, 1
July 2020,
<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-25>.
11. Informative References 11. Informative References
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/info/rfc7591>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012,
<https://www.rfc-editor.org/info/rfc6755>.
[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
February 2020, <https://www.rfc-editor.org/info/rfc8707>.
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
for Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015,
<https://www.rfc-editor.org/info/rfc7636>.
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and (JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
2015, <https://www.rfc-editor.org/info/rfc7523>. 2015, <https://www.rfc-editor.org/info/rfc7523>.
[IANA.OAuth.Parameters] [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
IANA, "OAuth Parameters", Unique IDentifier (UUID) URN Namespace", RFC 4122,
<http://www.iana.org/assignments/oauth-parameters>. DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>.
[I-D.ietf-oauth-mtls] [I-D.ietf-oauth-mtls]
Campbell, B., Bradley, J., Sakimura, N., and T. Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", Work in Progress, and Certificate-Bound Access Tokens", Work in Progress,
Internet-Draft, draft-ietf-oauth-mtls-17, 23 August 2019, Internet-Draft, draft-ietf-oauth-mtls-17, 23 August 2019,
<https://tools.ietf.org/html/draft-ietf-oauth-mtls-17>. <https://tools.ietf.org/html/draft-ietf-oauth-mtls-17>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015, DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>. <https://www.rfc-editor.org/info/rfc7517>.
[IANA.OAuth.Parameters]
IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012,
<https://www.rfc-editor.org/info/rfc6755>.
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
for Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015,
<https://www.rfc-editor.org/info/rfc7636>.
[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
February 2020, <https://www.rfc-editor.org/info/rfc8707>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/info/rfc7591>.
Appendix A. Document History Appendix A. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-03
* Editorial updates
* Mention that https is required for the PAR endpoint
* Add some discussion of browser form posting an authz request vs.
the benefits of PAR for any application
* Added text about motivations behind PAR - integrity,
confidentiality and early client auth
* Better explain one-time use recommendation of the request_uri
* Drop the section on special error responses for request objects
* Clarify authorization request examples to say that the client
directs the user-agent to make the HTTP GET request (vs. making
the request itself)
-02 -02
* Update Resource Indicators reference to the somewhat recently * Update Resource Indicators reference to the somewhat recently
published RFC 8707 published RFC 8707
* Added metadata in support of pushed authorization requests only * Added metadata in support of pushed authorization requests only
feature feature
* Update to comply with draft-ietf-oauth-jwsreq-21, which requires * Update to comply with draft-ietf-oauth-jwsreq-21, which requires
"client_id" in the authorization request in addition to the "client_id" in the authorization request in addition to the
"request_uri" "request_uri"
 End of changes. 59 change blocks. 
176 lines changed or deleted 218 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/