idnits 2.17.1 draft-ietf-oauth-par-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (18 February 2020) is 1519 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-34) exists of draft-ietf-oauth-jwsreq-20 -- Possible downref: Non-RFC (?) normative reference: ref. 'OIDC' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Web Authorization Protocol T. Lodderstedt 3 Internet-Draft yes.com 4 Intended status: Standards Track B. Campbell 5 Expires: 21 August 2020 Ping Identity 6 N. Sakimura 7 Nomura Research Institute 8 D. Tonge 9 Moneyhub Financial Technology 10 F. Skokan 11 Auth0 12 18 February 2020 14 OAuth 2.0 Pushed Authorization Requests 15 draft-ietf-oauth-par-01 17 Abstract 19 This document defines the pushed authorization request endpoint, 20 which allows clients to push the payload of an OAuth 2.0 21 authorization request to the authorization server via a direct 22 request and provides them with a request URI that is used as 23 reference to the data in a subsequent authorization request. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 21 August 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 60 2. Pushed Authorization Request Endpoint . . . . . . . . . . . . 4 61 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.2. Successful Response . . . . . . . . . . . . . . . . . . . 7 63 2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 8 64 3. "request" Parameter . . . . . . . . . . . . . . . . . . . . . 9 65 3.1. Error responses for Request Object . . . . . . . . . . . 10 66 3.1.1. Authentication Required . . . . . . . . . . . . . . . 10 67 4. Authorization Request . . . . . . . . . . . . . . . . . . . . 10 68 5. Authorization Server Metadata . . . . . . . . . . . . . . . . 10 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 6.1. Request URI Guessing . . . . . . . . . . . . . . . . . . 11 71 6.2. Open Redirection . . . . . . . . . . . . . . . . . . . . 11 72 6.3. Request Object Replay . . . . . . . . . . . . . . . . . . 11 73 6.4. Client Policy Change . . . . . . . . . . . . . . . . . . 11 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 9. Normative References . . . . . . . . . . . . . . . . . . . . 12 77 10. Informative References . . . . . . . . . . . . . . . . . . . 12 78 Appendix A. Document History . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 In OAuth [RFC6749] authorization request parameters are typically 84 sent as URI query parameters via redirection in the user-agent. This 85 is simple but also yields challenges: 87 * There is no cryptographic integrity and authenticity protection, 88 i.e. the request can be modified on its way through the user-agent 89 and attackers can impersonate legitimate clients. 91 * There is no mechanism to ensure confidentiality of the request 92 parameters. 94 * Authorization request URLs can become quite large, especially in 95 scenarios requiring fine-grained authorization data. 97 JWT Secured Authorization Request (JAR) [I-D.ietf-oauth-jwsreq] 98 provides solutions for those challenges by allowing OAuth clients to 99 wrap authorization request parameters in a signed, and optionally 100 encrypted, JSON Web Token (JWT), the so-called "Request Object". 102 In order to cope with the size restrictions, JAR introduces the 103 "request_uri" parameter that allows clients to send a reference to a 104 request object instead of the request object itself. 106 This document complements JAR by providing an interoperable way to 107 push the payload of a request object directly to the AS in exchange 108 for a "request_uri". 110 It also allows for clients to push the form encoded authorization 111 request parameters to the AS in order to exchange them for a request 112 URI that the client can use in a subsequent authorization request. 114 For example, the following authorization request, 116 GET /authorize?response_type=code 117 &client_id=s6BhdRkqt3&state=af0ifjsldkj 118 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1 119 Host: as.example.com 121 could be pushed directly to the AS by the client as follows: 123 POST /as/par HTTP/1.1 124 Host: as.example.com 125 Content-Type: application/x-www-form-urlencoded 126 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 128 response_type=code 129 &client_id=s6BhdRkqt3&state=af0ifjsldkj 130 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb 132 The AS responds with a request URI, 134 HTTP/1.1 201 Created 135 Cache-Control: no-cache, no-store 136 Content-Type: application/json 138 { 140 "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2", 141 "expires_in": 90 142 } 144 which is used by the client in the subsequent authorization request 145 as follows, 147 GET /authorize?request_uri= 148 urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1 150 The pushed authorization request endpoint fosters OAuth security by 151 providing all clients a simple means for an integrity protected 152 authorization request, but it also allows clients requiring an even 153 higher security level, especially cryptographically confirmed non- 154 repudiation, to explicitly adopt JWT-based request objects. 156 As a further benefit, the pushed authorization request allows the AS 157 to authenticate the clients before any user interaction happens, 158 i.e., the AS may refuse unauthorized requests much earlier in the 159 process and has much higher confidence in the client's identity in 160 the authorization process than before. 162 This is directly utilized by this draft to allow confidential clients 163 to set the redirect URI for every authorization request, which gives 164 them more flexibility in building redirect URI. And if the client 165 IDs and credentials are managed by some external authority (e.g. a 166 certification authority), explicit client registration with the 167 particular AS could practically be skipped. 169 1.1. Conventions and Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 This specification uses the terms "access token", "refresh token", 178 "authorization server", "resource server", "authorization endpoint", 179 "authorization request", "authorization response", "token endpoint", 180 "grant type", "access token request", "access token response", and 181 "client" defined by The OAuth 2.0 Authorization Framework [RFC6749]. 183 2. Pushed Authorization Request Endpoint 185 The pushed authorization request endpoint is an HTTP API at the 186 authorization server that accepts POST requests with parameters in 187 the HTTP request entity-body using the "application/x-www-form- 188 urlencoded" format with a character encoding of UTF-8 as described in 189 Appendix B of [RFC6749]. 191 The endpoint accepts the parameters defined in [RFC6749] for the 192 authorization endpoint as well as all applicable extensions defined 193 for the authorization endpoint. Some examples of such extensions 194 include PKCE [RFC7636], Resource Indicators 195 [I-D.ietf-oauth-resource-indicators], and OpenID Connect [OIDC]. 197 The rules for client authentication as defined in [RFC6749] for token 198 endpoint requests, including the applicable authentication methods, 199 apply for the pushed authorization request endpoint as well. If 200 applicable, the "token_endpoint_auth_method" client metadata 201 parameter indicates the registered authentication method for the 202 client to use when making direct requests to the authorization 203 server, including requests to the pushed authorization request 204 endpoint. 206 Note that there's some potential ambiguity around the appropriate 207 audience value to use when JWT client assertion based authentication 208 is employed. To address that ambiguity the issuer identifier URL of 209 the AS according to [RFC8414] SHOULD be used as the value of the 210 audience. In order to facilitate interoperability the AS MUST accept 211 its issuer identifier, token endpoint URL, or pushed authorization 212 request endpoint URL as values that identify it as an intended 213 audience. 215 2.1. Request 217 A client can send all the parameters that usually comprise an 218 authorization request to the pushed authorization request endpoint. 219 A basic parameter set will typically include: 221 * "client_id" 223 * "response_type" 225 * "redirect_uri" 227 * "scope" 229 * "state" 231 * "code_challenge" 233 * "code_challenge_method" 235 Depending on client type and authentication method, the request might 236 also include other parameters for client authentication such as the 237 "client_secret" parameter, the "client_assertion" parameter and the 238 "client_assertion_type" parameter. The "request_uri" authorization 239 request parameter MUST NOT be provided in this case (see Section 3). 241 The client adds the parameters in "x-www-form-urlencoded" format with 242 a character encoding of UTF-8 as described in Appendix B of [RFC6749] 243 to the body of an HTTP POST request. If applicable, the client also 244 adds client credentials to the request header or the request body 245 using the same rules as for token endpoint requests. 247 This is illustrated by the following example: 249 POST /as/par HTTP/1.1 250 Host: as.example.com 251 Content-Type: application/x-www-form-urlencoded 252 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 254 response_type=code& 255 state=af0ifjsldkj& 256 client_id=s6BhdRkqt3& 257 redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb& 258 code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U& 259 code_challenge_method=S256& 260 scope=ais 262 The AS MUST process the request as follows: 264 1. The AS MUST authenticate the client in the same way as at the 265 token endpoint. 267 2. The AS MUST reject the request if the "request_uri" authorization 268 request parameter is provided. 270 3. The AS MUST validate the request in the same way as at the 271 authorization endpoint. For example, the authorization server 272 checks whether the redirect URI matches one of the redirect URIs 273 configured for the client. It MUST also check whether the client 274 is authorized for the "scope" for which it is requesting access. 275 This validation allows the authorization server to refuse 276 unauthorized or fraudulent requests early. 278 The AS MAY allow confidential clients to establish per-authorization 279 request redirect URIs with every pushed authorization request. This 280 is possible since, in contrast to [RFC6749], this specification gives 281 the AS the ability to authenticate and authorize clients before the 282 actual authorization request is performed. 284 This feature gives clients more flexibility in building redirect URIs 285 and, if the client IDs and credentials are managed by some authority 286 (CA or other type), the explicit client registration with the 287 particular AS (manually or via dynamic client registration [RFC7591]) 288 could practically be skipped. This makes this mechanism especially 289 useful for clients interacting with a federation of ASs (or OpenID 290 Connect OPs), for example in Open Banking, where the certificate is 291 provided as part of a federated PKI. 293 2.2. Successful Response 295 If the verification is successful, the server MUST generate a request 296 URI and return a JSON response that contains "request_uri" and 297 "expires_in" members at the top level with "201 Created" HTTP 298 response code. 300 * "request_uri" : The request URI corresponding to the authorization 301 request posted. This URI is used as reference to the respective 302 request data in the subsequent authorization request only. The 303 way the authorization process obtains the authorization request 304 data is at the discretion of the authorization server and out of 305 scope of this specification. There is no need to make the 306 authorization request data available to other parties via this 307 URI. 309 * "expires_in" : A JSON number that represents the lifetime of the 310 request URI in seconds. The request URI lifetime is at the 311 discretion of the AS. 313 The "request_uri" value MUST be generated using a cryptographically 314 strong pseudorandom algorithm such that it is computationally 315 infeasible to predict or guess a valid value. 317 The "request_uri" MUST be bound to the client that posted the 318 authorization request. 320 Since the request URI can be replayed, its lifetime SHOULD be short 321 and preferably limited to one-time use. 323 The following is an example of such a response: 325 HTTP/1.1 201 Created 326 Content-Type: application/json 327 Cache-Control: no-cache, no-store 329 { 330 "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2", 331 "expires_in": 3600 332 } 334 2.3. Error Response 336 For an error the authorization server sets an appropriate HTTP status 337 code and MAY include additional error parameters in the entity-body 338 of the HTTP response using the format specified for the token 339 endpoint in Section 5.2 of [RFC6749]. 341 If the authorization server sets an error code, it SHOULD be one of 342 the defined codes for the token endpoint in Section 5.2 or for the 343 authorization endpoint in Sections 4.1.2.1 and 4.2.2.1 of [RFC6749], 344 or by an OAuth extension if one is involved in the initial processing 345 of authorization request that was pushed. Since initial processing 346 of the pushed authorisation request doesn't involve resource owner 347 interaction, error codes related to user interaction, such as 348 "consent_required" defined by [OIDC], are not returned. 350 In addition to the error codes above, the pushed authorization 351 request endpoint specifies use of the following HTTP status codes: 353 * 405: If the request did not use POST, the authorization server 354 responds with an HTTP 405 (Method Not Allowed) status code. 356 * 413: If the request size was beyond the upper bound that the 357 authorization server allows, the authorization server responds 358 with an HTTP 413 (Payload Too Large) status code. 360 * 429: If the request from the client for a time period goes beyond 361 the number the authorization server allows, the authorization 362 server responds with an HTTP 429 (Too Many Requests) status code. 364 The following is an example of an error response from the pushed 365 authorization request endpoint: 367 HTTP/1.1 400 Bad Request 368 Content-Type: application/json 369 Cache-Control: no-cache, no-store 371 { 372 "error": "invalid_request", 373 "error_description": 374 "The redirect_uri is not valid for the given client" 375 } 377 3. "request" Parameter 379 Clients MAY use the "request" parameter as defined in JAR 380 [I-D.ietf-oauth-jwsreq] to push a request object JWT to the AS. The 381 rules for processing, signing, and encryption of the request object 382 as defined in JAR [I-D.ietf-oauth-jwsreq] apply. When the 383 "application/x-www-form-urlencoded" HTTP entity-body "request" 384 parameter is used, the request object MUST contain all the 385 authorization request parameters as claims of the JWT. Additional 386 request parameters as required by the given client authentication 387 method are to be included as 'application/x-www-form-urlencoded' 388 parameters in the HTTP request entity-body (e.g. Mutual TLS client 389 authentication [I-D.ietf-oauth-mtls] uses the "client_id" HTTP 390 request parameter while JWT assertion based client authentication 391 [RFC7523] uses "client_assertion" and "client_assertion_type"). 393 The following is an example of a pushed authorization request using a 394 signed request object. The client is authenticated by its client 395 secret using the HTTP Basic Authentication scheme specified in 396 Section 2.3.1 of [RFC6749]: 398 POST /as/par HTTP/1.1 399 Host: as.example.com 400 Content-Type: application/x-www-form-urlencoded 401 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 403 request=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3MiOiJzNkJoZ 404 FJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJyZXNwb2 405 5zZV90eXBlIjoiY29kZSIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmV 406 jdF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsInNjb3BlIjoi 407 YWlzIiwic3RhdGUiOiJhZjBpZmpzbGRraiIsImNvZGVfY2hhbGxlbmdlIjoiSzItb 408 HRjODNhY2M0aDBjOXc2RVNDX3JFTVRKM2J3dy11Q0hhb2VLMXQ4VSIsImNvZGVfY2 409 hhbGxlbmdlX21ldGhvZCI6IlMyNTYifQ.O49ffUxRPdNkN3TRYDvbEYVr1CeAL64u 410 W4FenV3n9WlaFIRHeFblzv-wlEtMm8-tusGxeE9z3ek6FxkhvvLEqEpjthXnyXqqy 411 Jfq3k9GSf5ay74ml_0D6lHE1hy-kVWg7SgoPQ-GB1xQ9NRhF3EKS7UZIrUHbFUCF0 412 MsRLbmtIvaLYbQH_Ef3UkDLOGiU7exhVFTPeyQUTM9FF-u3K-zX-FO05_brYxNGLh 413 VkO1G8MjqQnn2HpAzlBd5179WTzTYhKmhTiwzH-qlBBI_9GLJmE3KOipko9TfSpa2 414 6H4JOlMyfZFl0PCJwkByS0xZFJ2sTo3Gkk488RQohhgt1I0onw 416 The AS needs to take the following steps beyond the processing rules 417 defined in Section 2.1: 419 1. If applicable, the AS decrypts the request object as specified in 420 JAR [I-D.ietf-oauth-jwsreq], section 6.1. 422 2. The AS validates the request object signature as specified in JAR 423 [I-D.ietf-oauth-jwsreq], section 6.2. 425 3. If the client is a confidential client, the authorization server 426 MUST check whether the authenticated "client_id" matches the 427 "client_id" claim in the request object. If they do not match, 428 the authorization server MUST refuse to process the request. It 429 is at the authorization server's discretion to require the "iss" 430 claim to match the "client_id" as well. 432 3.1. Error responses for Request Object 434 This section gives the error responses that go beyond the basic 435 Section 2.3. 437 3.1.1. Authentication Required 439 If the signature validation fails, the authorization server returns a 440 "401 Unauthorized" HTTP error response. The same applies if the 441 "client_id" or, if applicable, the "iss" claim in the request object 442 do not match the authenticated "client_id". 444 4. Authorization Request 446 The client uses the "request_uri" value returned by the authorization 447 server as the authorization request parameter "request_uri" as 448 defined in JAR. 450 GET /authorize?request_uri= 451 urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1 453 Clients are encouraged to use the request URI as the only parameter 454 in order to use the integrity and authenticity provided by the pushed 455 authorization request. 457 5. Authorization Server Metadata 459 If the authorization server has a pushed authorization request 460 endpoint, it SHOULD include the following OAuth/OpenID Provider 461 Metadata parameter in discovery responses: 463 "pushed_authorization_request_endpoint" : The URL of the pushed 464 authorization request endpoint at which the client can post an 465 authorization request and get a request URI in exchange. 467 6. Security Considerations 468 6.1. Request URI Guessing 470 An attacker could attempt to guess and replay a valid request URI 471 value and try to impersonate the respective client. The AS MUST 472 consider the considerations given in JAR [I-D.ietf-oauth-jwsreq], 473 section 10.2, clause d on request URI entropy. 475 6.2. Open Redirection 477 An attacker could try register a redirect URI pointing to a site 478 under his control in order to obtain authorization codes or lauch 479 other attacks towards the user. The AS MUST only accept new redirect 480 URIs in the PAR request from confidential clients after sucessful 481 authentication and authorization. 483 6.3. Request Object Replay 485 An attacker could replay a request URI captured from a legitimate 486 authorization request. In order to cope with such attacks, the AS 487 SHOULD make the request URIs one-time use. 489 6.4. Client Policy Change 491 The client policy might change between the lodging of the request 492 object and the authorization request using a particular request 493 object. It is therefore recommended that the AS check the request 494 parameter against the client policy when processing the authorization 495 request. 497 7. Acknowledgements 499 This specification is based on the work towards Pushed Request Object 500 (https://bitbucket.org/openid/fapi/src/master/ 501 Financial_API_Pushed_Request_Object.md) conducted at the Financial- 502 grade API working group at the OpenID Foundation. We would like to 503 thank the members of the WG for their valuable contributions. 505 We would like to thank Vladimir Dzhuvinov, Aaron Parecki, Joseph 506 Heenan, and Takahiko Kawasaki for their valuable feedback on this 507 draft. 509 8. IANA Considerations 511 This specification requests registration of the following value in 512 the IANA "OAuth Authorization Server Metadata" registry of 513 [IANA.OAuth.Parameters] established by [RFC8414]. 515 Metadata Name: "pushed_authorization_request_endpoint" 516 Metadata Description: URL of the authorization server's pushed 517 authorization request endpoint 518 Change Controller: IESG 519 Specification Document(s): [[ this document ]] 521 9. Normative References 523 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 524 Authorization Server Metadata", RFC 8414, 525 DOI 10.17487/RFC8414, June 2018, 526 . 528 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 529 RFC 6749, DOI 10.17487/RFC6749, October 2012, 530 . 532 [I-D.ietf-oauth-jwsreq] 533 Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization 534 Framework: JWT Secured Authorization Request (JAR)", Work 535 in Progress, Internet-Draft, draft-ietf-oauth-jwsreq-20, 536 21 October 2019, 537 . 539 [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 540 C. Mortimore, "OpenID Connect Core 1.0 incorporating 541 errata set 1", 8 November 2014, 542 . 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, 546 DOI 10.17487/RFC2119, March 1997, 547 . 549 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 550 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 551 May 2017, . 553 10. Informative References 555 [I-D.ietf-oauth-resource-indicators] 556 Campbell, B., Bradley, J., and H. Tschofenig, "Resource 557 Indicators for OAuth 2.0", Work in Progress, Internet- 558 Draft, draft-ietf-oauth-resource-indicators-08, 11 559 September 2019, . 562 [I-D.ietf-oauth-mtls] 563 Campbell, B., Bradley, J., Sakimura, N., and T. 565 Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication 566 and Certificate-Bound Access Tokens", Work in Progress, 567 Internet-Draft, draft-ietf-oauth-mtls-17, 23 August 2019, 568 . 570 [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token 571 (JWT) Profile for OAuth 2.0 Client Authentication and 572 Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 573 2015, . 575 [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 576 for Code Exchange by OAuth Public Clients", RFC 7636, 577 DOI 10.17487/RFC7636, September 2015, 578 . 580 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 581 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 582 RFC 7591, DOI 10.17487/RFC7591, July 2015, 583 . 585 [IANA.OAuth.Parameters] 586 IANA, "OAuth Parameters", 587 . 589 Appendix A. Document History 591 [[ To be removed from the final specification ]] 593 -01 595 * Use the newish RFC v3 XML and HTML format 596 * Added IANA registration request for 597 "pushed_authorization_request_endpoint" 598 * Changed abbrev to "OAuth PAR" 600 -00 (WG draft) 602 * Reference RFC6749 sec 2.3.1 for client secret basic rather than 603 RFC7617 604 * further clarify that a request object JWT contains all the 605 authorization request parameters while client authentication 606 params, if applicable, are outside that JWT as regular form 607 encoded params in HTTP body 609 -01 611 * List "client_id" as one of the basic parameters 612 * Explicitly forbid "request_uri" in the processing rules 613 * Clarification regarding client authentication and that public 614 clients are allowed 615 * Added option to let clients register per-authorization request 616 redirect URIs 617 * General clean up and wording improvements 619 -00 621 * first draft 623 Authors' Addresses 625 Torsten Lodderstedt 626 yes.com 628 Email: torsten@lodderstedt.net 630 Brian Campbell 631 Ping Identity 633 Email: bcampbell@pingidentity.com 635 Nat Sakimura 636 Nomura Research Institute 638 Email: nat@sakimura.org 640 Dave Tonge 641 Moneyhub Financial Technology 643 Email: dave@tonge.org 645 Filip Skokan 646 Auth0 648 Email: panva.ip@gmail.com