draft-ietf-oauth-par-04.txt   draft-ietf-oauth-par-05.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: 22 March 2021 Ping Identity Expires: 17 June 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
18 September 2020 14 December 2020
OAuth 2.0 Pushed Authorization Requests OAuth 2.0 Pushed Authorization Requests
draft-ietf-oauth-par-04 draft-ietf-oauth-par-05
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 call to the authorization reference to the data in a subsequent call to the authorization
endpoint. endpoint.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 22 March 2021. This Internet-Draft will expire on 17 June 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Introductory Example . . . . . . . . . . . . . . . . . . 4 1.1. Introductory Example . . . . . . . . . . . . . . . . . . 4
1.2. Conventions and Terminology . . . . . . . . . . . . . . . 5 1.2. Conventions and Terminology . . . . . . . . . . . . . . . 5
2. Pushed Authorization Request Endpoint . . . . . . . . . . . . 5 2. Pushed Authorization Request Endpoint . . . . . . . . . . . . 5
2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Successful Response . . . . . . . . . . . . . . . . . . . 8 2.2. Successful Response . . . . . . . . . . . . . . . . . . . 8
2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 9 2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 9
2.4. Management of Client Redirect URIs . . . . . . . . . . . 10 2.4. Management of Client Redirect URIs . . . . . . . . . . . 10
3. The "request" Request Parameter . . . . . . . . . . . . . . . 11 3. The "request" Request Parameter . . . . . . . . . . . . . . . 11
4. Authorization Request . . . . . . . . . . . . . . . . . . . . 13 4. Authorization Request . . . . . . . . . . . . . . . . . . . . 13
5. Authorization Server Metadata . . . . . . . . . . . . . . . . 13 5. Authorization Server Metadata . . . . . . . . . . . . . . . . 14
6. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 14 6. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7.1. Request URI Guessing . . . . . . . . . . . . . . . . . . 14 7.1. Request URI Guessing . . . . . . . . . . . . . . . . . . 15
7.2. Open Redirection . . . . . . . . . . . . . . . . . . . . 14 7.2. Open Redirection . . . . . . . . . . . . . . . . . . . . 15
7.3. Request Object Replay . . . . . . . . . . . . . . . . . . 15 7.3. Request Object Replay . . . . . . . . . . . . . . . . . . 15
7.4. Client Policy Change . . . . . . . . . . . . . . . . . . 15 7.4. Client Policy Change . . . . . . . . . . . . . . . . . . 16
7.5. Request URI Swapping . . . . . . . . . . . . . . . . . . 15 7.5. Request URI Swapping . . . . . . . . . . . . . . . . . . 16
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. OAuth Authorization Server Metadata . . . . . . . . . . 16 10.1. OAuth Authorization Server Metadata . . . . . . . . . . 17
10.2. OAuth Dynamic Client Registration Metadata . . . . . . . 16 10.2. OAuth Dynamic Client Registration Metadata . . . . . . . 17
10.3. OAuth URI Registration . . . . . . . . . . . . . . . . . 16 10.3. OAuth URI Registration . . . . . . . . . . . . . . . . . 17
11. Normative References . . . . . . . . . . . . . . . . . . . . 17 11. Normative References . . . . . . . . . . . . . . . . . . . . 17
12. Informative References . . . . . . . . . . . . . . . . . . . 17 12. Informative References . . . . . . . . . . . . . . . . . . . 18
Appendix A. Document History . . . . . . . . . . . . . . . . . . 19 Appendix A. Document History . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Pushed authorization requests (PAR), defined by this document, enable Pushed authorization requests (PAR), defined by this document, enable
OAuth [RFC6749] clients to push the payload of an authorization OAuth [RFC6749] clients to push the payload of an authorization
request directly to the authorization server in exchange for a request directly to the authorization server in exchange for a
request URI value, which is used as reference to the authorization request URI value, which is used as reference to the authorization
request payload data in a subsequent call to the authorization request payload data in a subsequent call to the authorization
endpoint via the user-agent. endpoint via the user-agent.
skipping to change at page 9, line 20 skipping to change at page 9, line 20
"request_uri": "request_uri":
"urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2", "urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2",
"expires_in": 60 "expires_in": 60
} }
2.3. Error Response 2.3. Error Response
The authorization server returns an error response with the same The authorization server returns an error response with the same
format as is specified for error responses from the token endpoint in format as is specified for error responses from the token endpoint in
Section 5.2 of [RFC6749] using the appropriate error code from Section 5.2 of [RFC6749] using the appropriate error code from
therein or from Section 4.1.2.1 of [RFC6749]. Error codes defined by therein or from Section 4.1.2.1 of [RFC6749]. In those cases where
OAuth extension can also be used when such an extension is involved Section 4.1.2.1 of [RFC6749] prohibits automatic redirection with an
in the initial processing of authorization request that was pushed. error back to the requesting client and hence doesn't define an error
Since initial processing of the pushed authorization request does not code, for example when the request fails due to a missing, invalid,
or mismatching redirection URI, the "invalid_request" error code can
be used as the default error code. Error codes defined by OAuth
extension can also be used when such an extension is involved in the
initial processing of authorization request that was pushed. Since
initial processing of the pushed authorization request does not
involve resource owner interaction, error codes related to user involve resource owner interaction, error codes related to user
interaction, such as "consent_required" defined by [OIDC], are never interaction, such as "consent_required" defined by [OIDC], are never
returned. 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".
skipping to change at page 17, line 4 skipping to change at page 17, line 47
Specification Document(s): Section 6 of [[ this document ]] Specification Document(s): Section 6 of [[ this document ]]
10.3. OAuth URI Registration 10.3. OAuth URI Registration
This specification requests registration of the following value in This specification requests registration of the following value in
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 ]]
11. Normative References 11. Normative References
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-oauth-jwsreq] [I-D.ietf-oauth-jwsreq]
Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0
Authorization Framework: JWT Secured Authorization Request Authorization Framework: JWT Secured Authorization Request
(JAR)", Work in Progress, Internet-Draft, draft-ietf- (JAR)", Work in Progress, Internet-Draft, draft-ietf-
oauth-jwsreq-30, 10 September 2020, oauth-jwsreq-30, 10 September 2020,
<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30>. <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30>.
[OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 1", 8 November 2014, errata set 1", 8 November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 12. Informative References
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. February 2020, <https://www.rfc-editor.org/info/rfc8707>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
RFC 6749, DOI 10.17487/RFC6749, October 2012, P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
<https://www.rfc-editor.org/info/rfc6749>. RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/info/rfc7591>.
12. Informative References [IANA.OAuth.Parameters]
IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>.
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
2015, <https://www.rfc-editor.org/info/rfc7523>.
[I-D.ietf-oauth-v2-1] [I-D.ietf-oauth-v2-1]
Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1 Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
Authorization Framework", Work in Progress, Internet- Authorization Framework", Work in Progress, Internet-
Draft, draft-ietf-oauth-v2-1-00, 30 July 2020, Draft, draft-ietf-oauth-v2-1-00, 30 July 2020,
<https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00>. <https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00>.
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication DOI 10.17487/RFC7517, May 2015,
and Certificate-Bound Access Tokens", RFC 8705, <https://www.rfc-editor.org/info/rfc7517>.
DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/info/rfc8705>. [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[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 [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
for Code Exchange by OAuth Public Clients", RFC 7636, for Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015, DOI 10.17487/RFC7636, September 2015,
<https://www.rfc-editor.org/info/rfc7636>. <https://www.rfc-editor.org/info/rfc7636>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[IANA.OAuth.Parameters]
IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>.
[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>.
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
2015, <https://www.rfc-editor.org/info/rfc7523>.
[I-D.ietf-oauth-security-topics] [I-D.ietf-oauth-security-topics]
Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"OAuth 2.0 Security Best Current Practice", Work in "OAuth 2.0 Security Best Current Practice", Work in
Progress, Internet-Draft, draft-ietf-oauth-security- Progress, Internet-Draft, draft-ietf-oauth-security-
topics-15, 5 April 2020, <https://tools.ietf.org/html/ topics-16, 5 October 2020, <https://tools.ietf.org/html/
draft-ietf-oauth-security-topics-15>. draft-ietf-oauth-security-topics-16>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[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>.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
<https://www.rfc-editor.org/info/rfc6755>. and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/info/rfc8705>.
Appendix A. Document History Appendix A. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-05
* Mention use of "invalid_request" error code for cases, like a bad
"redirect_uri", that don't have a more specific one
-04 -04
* Edits to address WGLC comments * Edits to address WGLC comments
* Replace I-D.ietf-oauth-mtls reference with now published RFC8705 * Replace I-D.ietf-oauth-mtls reference with now published RFC8705
* Moved text about redirect URI management from introduction into * Moved text about redirect URI management from introduction into
separate section separate section
-03 -03
 End of changes. 19 change blocks. 
72 lines changed or deleted 81 lines changed or added

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