doc: Add RFC documents

1 files changed, 1297 insertions, 0 deletions

diff --git a/doc/rfc/rfc9101.txt b/doc/rfc/rfc9101.txt
new file mode 100644
index 0000000..115b07f
--- /dev/null
+++ b/doc/rfc/rfc9101.txt
@@ -0,0 +1,1297 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       N. Sakimura
+Request for Comments: 9101                                NAT.Consulting
+Category: Standards Track                                     J. Bradley
+ISSN: 2070-1721                                                   Yubico
+                                                                M. Jones
+                                                               Microsoft
+                                                             August 2021
+
+
+The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request
+                                 (JAR)
+
+Abstract
+
+   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
+   query parameter serialization, which means that authorization request
+   parameters are encoded in the URI of the request and sent through
+   user agents such as web browsers.  While it is easy to implement, it
+   means that a) the communication through the user agents is not
+   integrity protected and thus, the parameters can be tainted, b) the
+   source of the communication is not authenticated, and c) the
+   communication through the user agents can be monitored.  Because of
+   these weaknesses, several attacks to the protocol have now been put
+   forward.
+
+   This document introduces the ability to send request parameters in a
+   JSON Web Token (JWT) instead, which allows the request to be signed
+   with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
+   (JWE) so that the integrity, source authentication, and
+   confidentiality properties of the authorization request are attained.
+   The request can be sent by value or by reference.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9101.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Requirements Language
+   2.  Terminology
+     2.1.  Request Object
+     2.2.  Request Object URI
+   3.  Symbols and Abbreviated Terms
+   4.  Request Object
+   5.  Authorization Request
+     5.1.  Passing a Request Object by Value
+     5.2.  Passing a Request Object by Reference
+       5.2.1.  URI Referencing the Request Object
+       5.2.2.  Request Using the "request_uri" Request Parameter
+       5.2.3.  Authorization Server Fetches Request Object
+   6.  Validating JWT-Based Requests
+     6.1.  JWE Encrypted Request Object
+     6.2.  JWS-Signed Request Object
+     6.3.  Request Parameter Assembly and Validation
+   7.  Authorization Server Response
+   8.  TLS Requirements
+   9.  IANA Considerations
+     9.1.  OAuth Parameters Registration
+     9.2.  OAuth Authorization Server Metadata Registry
+     9.3.  OAuth Dynamic Client Registration Metadata Registry
+     9.4.  Media Type Registration
+       9.4.1.  Registry Contents
+   10. Security Considerations
+     10.1.  Choice of Algorithms
+     10.2.  Request Source Authentication
+     10.3.  Explicit Endpoints
+     10.4.  Risks Associated with request_uri
+       10.4.1.  DDoS Attack on the Authorization Server
+       10.4.2.  Request URI Rewrite
+     10.5.  Downgrade Attack
+     10.6.  TLS Security Considerations
+     10.7.  Parameter Mismatches
+     10.8.  Cross-JWT Confusion
+   11. Privacy Considerations
+     11.1.  Collection Limitation
+     11.2.  Disclosure Limitation
+       11.2.1.  Request Disclosure
+       11.2.2.  Tracking Using Request Object URI
+   12. References
+     12.1.  Normative References
+     12.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   The authorization request in OAuth 2.0 [RFC6749] utilizes query
+   parameter serialization and is typically sent through user agents
+   such as web browsers.
+
+   For example, the parameters "response_type", "client_id", "state",
+   and "redirect_uri" are encoded in the URI of the request:
+
+       GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
+       &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
+       Host: server.example.com
+
+   While it is easy to implement, the encoding in the URI does not allow
+   application-layer security to be used to provide confidentiality and
+   integrity protection.  While TLS is used to offer communication
+   security between the client and the user agent as well as the user
+   agent and the authorization server, TLS sessions are terminated in
+   the user agent.  In addition, TLS sessions may be terminated
+   prematurely at some middlebox (such as a load balancer).
+
+   As a result, the authorization request of [RFC6749] has shortcomings
+   in that:
+
+   (a)  the communication through the user agents is not integrity
+        protected, and thus, the parameters can be tainted (integrity
+        protection failure);
+
+   (b)  the source of the communication is not authenticated (source
+        authentication failure);
+
+   (c)  the communication through the user agents can be monitored
+        (containment/confidentiality failure).
+
+   Due to these inherent weaknesses, several attacks against the
+   protocol, such as redirection URI rewriting, have been identified.
+
+   The use of application-layer security mitigates these issues.
+
+   The use of application-layer security allows requests to be prepared
+   by a trusted third party so that a client application cannot request
+   more permissions than previously agreed upon.
+
+   Furthermore, passing the request by reference allows the reduction of
+   over-the-wire overhead.
+
+   The JWT [RFC7519] encoding has been chosen because of:
+
+   (1)  its close relationship with JSON, which is used as OAuth's
+        response format
+
+   (2)  its developer friendliness due to its textual nature
+
+   (3)  its relative compactness compared to XML
+
+   (4)  its development status as a Proposed Standard, along with the
+        associated signing and encryption methods [RFC7515] [RFC7516]
+
+   (5)  the relative ease of JWS and JWE compared to XML Signature and
+        Encryption.
+
+   The parameters "request" and "request_uri" are introduced as
+   additional authorization request parameters for the OAuth 2.0
+   [RFC6749] flows.  The "request" parameter is a JSON Web Token (JWT)
+   [RFC7519] whose JWT Claims Set holds the JSON-encoded OAuth 2.0
+   authorization request parameters.  Note that, in contrast to RFC
+   7519, the elements of the Claims Set are encoded OAuth request
+   parameters [IANA.OAuth.Parameters], supplemented with only a few of
+   the IANA-managed JSON Web Token Claims [IANA.JWT.Claims], in
+   particular, "iss" and "aud".  The JWT in the "request" parameter is
+   integrity protected and source authenticated using JWS.
+
+   The JWT [RFC7519] can be passed to the authorization endpoint by
+   reference, in which case the parameter "request_uri" is used instead
+   of "request".
+
+   Using JWT [RFC7519] as the request encoding instead of query
+   parameters has several advantages:
+
+   (a)  Integrity protection.  The request can be signed so that the
+        integrity of the request can be checked.
+
+   (b)  Source authentication.  The request can be signed so that the
+        signer can be authenticated.
+
+   (c)  Confidentiality protection.  The request can be encrypted so
+        that end-to-end confidentiality can be provided even if the TLS
+        connection is terminated at one point or another (including at
+        and before user agents).
+
+   (d)  Collection minimization.  The request can be signed by a trusted
+        third party attesting that the authorization request is
+        compliant with a certain policy.  For example, a request can be
+        pre-examined by a trusted third party to confirm that all the
+        personal data requested is strictly necessary to perform the
+        process that the end user asked for; the request would then be
+        signed by that trusted third party.  The authorization server
+        then examines the signature and shows the conformance status to
+        the end user who would have some assurance as to the legitimacy
+        of the request when authorizing it.  In some cases, it may even
+        be desirable to skip the authorization dialogue under such
+        circumstances.
+
+   There are a few cases where request by reference is useful, such as:
+
+   1.  when it is desirable to reduce the size of a transmitted request.
+       The use of application-layer security increases the size of the
+       request particularly when public-key cryptography is used.
+
+   2.  when the client does not want to do the application-level
+       cryptography.  The authorization server may provide an endpoint
+       to accept the authorization request through direct communication
+       with the client, so that the client is authenticated and the
+       channel is TLS protected.
+
+   This capability is in use by OpenID Connect [OpenID.Core].
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  Terminology
+
+   For the purposes of this specification, the following terms and
+   definitions apply in addition to what is defined in OAuth 2.0
+   Framework [RFC6749], JSON Web Signature [RFC7515], and JSON Web
+   Encryption [RFC7516].
+
+2.1.  Request Object
+
+   A Request Object is a JSON Web Token (JWT) [RFC7519] whose JWT Claims
+   Set holds the JSON-encoded OAuth 2.0 authorization request
+   parameters.
+
+2.2.  Request Object URI
+
+   A Request Object URI is an absolute URI that references the set of
+   parameters comprising an OAuth 2.0 authorization request.  The
+   content of the resource referenced by the URI is a Request Object
+   (Section 2.1), unless the URI was provided to the client by the same
+   authorization server, in which case the content is an implementation
+   detail at the discretion of the authorization server.  The content
+   being a Request Object is to ensure interoperability in cases where
+   the provider of the "request_uri" is a separate entity from the
+   consumer, such as when a client provides a URI referencing a Request
+   Object stored on the client's backend service that is made accessible
+   via HTTPS.  In the latter case, where the authorization server is
+   both provider and consumer of the URI, such as when it offers an
+   endpoint that provides a URI in exchange for a Request Object, this
+   interoperability concern does not apply.
+
+3.  Symbols and Abbreviated Terms
+
+   The following abbreviations are common to this specification.
+
+   JSON:  JavaScript Object Notation
+
+   JWT:  JSON Web Token
+
+   JWS:  JSON Web Signature
+
+   JWE:  JSON Web Encryption
+
+   URI:  Uniform Resource Identifier
+
+   URL:  Uniform Resource Locator
+
+4.  Request Object
+
+   A Request Object (Section 2.1) is used to provide authorization
+   request parameters for an OAuth 2.0 authorization request.  It MUST
+   contain all the parameters (including extension parameters) used to
+   process the OAuth 2.0 [RFC6749] authorization request except the
+   "request" and "request_uri" parameters that are defined in this
+   document.  The parameters are represented as the JWT Claims of the
+   object.  Parameter names and string values MUST be included as JSON
+   strings.  Since Request Objects are handled across domains and
+   potentially outside of a closed ecosystem, per Section 8.1 of
+   [RFC8259], these JSON strings MUST be encoded using UTF-8 [RFC3629].
+   Numerical values MUST be included as JSON numbers.  The Request
+   Object MAY include any extension parameters.  This JSON [RFC8259]
+   object constitutes the JWT Claims Set defined in JWT [RFC7519].  The
+   JWT Claims Set is then signed or signed and encrypted.
+
+   To sign, JSON Web Signature (JWS) [RFC7515] is used.  The result is a
+   JWS-signed JWT [RFC7519].  If signed, the Authorization Request
+   Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience)
+   as members with their semantics being the same as defined in the JWT
+   [RFC7519] specification.  The value of "aud" should be the value of
+   the authorization server (AS) "issuer", as defined in RFC 8414
+   [RFC8414].
+
+   To encrypt, JWE [RFC7516] is used.  When both signature and
+   encryption are being applied, the JWT MUST be signed, then encrypted,
+   as described in Section 11.2 of [RFC7519].  The result is a Nested
+   JWT, as defined in [RFC7519].
+
+   The client determines the algorithms used to sign and encrypt Request
+   Objects.  The algorithms chosen need to be supported by both the
+   client and the authorization server.  The client can inform the
+   authorization server of the algorithms that it supports in its
+   dynamic client registration metadata [RFC7591], specifically, the
+   metadata values "request_object_signing_alg",
+   "request_object_encryption_alg", and "request_object_encryption_enc".
+   Likewise, the authorization server can inform the client of the
+   algorithms that it supports in its authorization server metadata
+   [RFC8414], specifically, the metadata values
+   "request_object_signing_alg_values_supported",
+   "request_object_encryption_alg_values_supported", and
+   "request_object_encryption_enc_values_supported".
+
+   The Request Object MAY be sent by value, as described in Section 5.1,
+   or by reference, as described in Section 5.2.  "request" and
+   "request_uri" parameters MUST NOT be included in Request Objects.
+
+   A Request Object (Section 2.1) has the media type [RFC2046]
+   "application/oauth-authz-req+jwt".  Note that some existing
+   deployments may alternatively be using the type "application/jwt".
+
+   The following is an example of the Claims in a Request Object before
+   base64url [RFC7515] encoding and signing.  Note that it includes the
+   extension parameters "nonce" and "max_age".
+
+     {
+      "iss": "s6BhdRkqt3",
+      "aud": "https://server.example.com",
+      "response_type": "code id_token",
+      "client_id": "s6BhdRkqt3",
+      "redirect_uri": "https://client.example.org/cb",
+      "scope": "openid",
+      "state": "af0ifjsldkj",
+      "nonce": "n-0S6_WzA2Mj",
+      "max_age": 86400
+     }
+
+   Signing it with the "RS256" algorithm [RFC7518] results in this
+   Request Object value (with line wraps within values for display
+   purposes only):
+
+     eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
+     JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
+     ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
+     lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
+     aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
+     JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
+     IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
+     b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
+     HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
+     JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
+     CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
+     pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
+
+   The following RSA public key, represented in JSON Web Key (JWK)
+   format, can be used to validate the Request Object signature in this
+   and subsequent Request Object examples (with line wraps within values
+   for display purposes only):
+
+     {
+      "kty":"RSA",
+      "kid":"k2bdc",
+      "n":"x5RbkAZkmpRxia65qRQ1wwSMSxQUnS7gcpVTV_cdHmfmG2ltd2yabEO9XadD8
+           pJNZubINPpmgHh3J1aD9WRwS05ucmFq3CfFsluLt13_7oX5yDRSKX7poXmT_5
+           ko8k4NJZPMAO8fPToDTH7kHYbONSE2FYa5GZ60CUsFhSonI-dcMDJ0Ary9lxI
+           w5k2z4TAdARVWcS7sD07VhlMMshrwsPHBQgTatlkxyIHXbYdtak8fqvNAwr7O
+           lVEvM_Ipf5OfmdB8Sd-wjzaBsyP4VhJKoi_qdgSzpC694XZeYPq45Sw-q51iF
+           UlcOlTCI7z6jltUtnR6ySn6XDGFnzH5Fe5ypw",
+      "e":"AQAB"
+     }
+
+5.  Authorization Request
+
+   The client constructs the authorization request URI by adding the
+   following parameters to the query component of the authorization
+   endpoint URI using the "application/x-www-form-urlencoded" format:
+
+   request
+      REQUIRED unless "request_uri" is specified.  The Request Object
+      (Section 2.1) that holds authorization request parameters stated
+      in Section 4 of [RFC6749] (OAuth 2.0).  If this parameter is
+      present in the authorization request, "request_uri" MUST NOT be
+      present.
+
+   request_uri
+      REQUIRED unless "request" is specified.  The absolute URI, as
+      defined by RFC 3986 [RFC3986], that is the Request Object URI
+      (Section 2.2) referencing the authorization request parameters
+      stated in Section 4 of [RFC6749] (OAuth 2.0).  If this parameter
+      is present in the authorization request, "request" MUST NOT be
+      present.
+
+   client_id
+      REQUIRED.  OAuth 2.0 [RFC6749] "client_id".  The value MUST match
+      the "request" or "request_uri" Request Object's (Section 2.1)
+      "client_id".
+
+   The client directs the resource owner to the constructed URI using an
+   HTTP redirection response or by other means available to it via the
+   user agent.
+
+   For example, the client directs the end user's user agent to make the
+   following HTTPS request:
+
+   GET /authz?client_id=s6BhdRkqt3&request=eyJhbG..AlMGzw HTTP/1.1
+   Host: server.example.com
+
+   The value for the request parameter is abbreviated for brevity.
+
+   The Authorization Request Object MUST be one of the following:
+
+   (a)  JWS signed
+
+   (b)  JWS signed and JWE encrypted
+
+   The client MAY send the parameters included in the Request Object
+   duplicated in the query parameters as well for backward
+   compatibility, etc.  However, the authorization server supporting
+   this specification MUST only use the parameters included in the
+   Request Object.
+
+5.1.  Passing a Request Object by Value
+
+   The client sends the authorization request as a Request Object to the
+   authorization endpoint as the "request" parameter value.
+
+   The following is an example of an authorization request using the
+   "request" parameter (with line wraps within values for display
+   purposes only):
+
+     https://server.example.com/authorize?client_id=s6BhdRkqt3&
+       request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6
+       ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs
+       ZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAg
+       ICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6
+       ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAi
+       b3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2Ui
+       OiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VU
+       ElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC
+       0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKz
+       uKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3E
+       YLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W
+       9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3
+       j1i7tLR_5Nz-g
+
+5.2.  Passing a Request Object by Reference
+
+   The "request_uri" authorization request parameter enables OAuth
+   authorization requests to be passed by reference rather than by
+   value.  This parameter is used identically to the "request"
+   parameter, except that the Request Object value is retrieved from the
+   resource identified by the specified URI rather than passed by value.
+
+   The entire Request URI SHOULD NOT exceed 512 ASCII characters.  There
+   are two reasons for this restriction:
+
+   1.  Many phones on the market as of this writing still do not accept
+       large payloads.  The restriction is typically either 512 or 1024
+       ASCII characters.
+
+   2.  On a slow connection such as a 2G mobile connection, a large URL
+       would cause a slow response; therefore, the use of such is not
+       advisable from the user-experience point of view.
+
+   The contents of the resource referenced by the "request_uri" MUST be
+   a Request Object and MUST be reachable by the authorization server
+   unless the URI was provided to the client by the authorization
+   server.  In the first case, the "request_uri" MUST be an "https" URI,
+   as specified in Section 2.7.2 of [RFC7230].  In the second case, it
+   MUST be a URN, as specified in [RFC8141].
+
+   The following is an example of the contents of a Request Object
+   resource that can be referenced by a "request_uri" (with line wraps
+   within values for display purposes only):
+
+     eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
+     JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
+     ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
+     lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
+     aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
+     JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
+     IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
+     b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
+     HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
+     JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
+     CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
+     pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
+
+5.2.1.  URI Referencing the Request Object
+
+   The client stores the Request Object resource either locally or
+   remotely at a URI the authorization server can access.  Such a
+   facility may be provided by the authorization server or a trusted
+   third party.  For example, the authorization server may provide a URL
+   to which the client POSTs the Request Object and obtains the Request
+   URI.  This URI is the Request Object URI, "request_uri".
+
+   It is possible for the Request Object to include values that are to
+   be revealed only to the authorization server.  As such, the
+   "request_uri" MUST have appropriate entropy for its lifetime so that
+   the URI is not guessable if publicly retrievable.  For the guidance,
+   refer to Section 5.1.4.2.2 of [RFC6819] and "Good Practices for
+   Capability URLs" [CapURLs].  It is RECOMMENDED that the "request_uri"
+   be removed after a reasonable timeout unless access control measures
+   are taken.
+
+   The following is an example of a Request Object URI value (with line
+   wraps within values for display purposes only).  In this example, a
+   trusted third-party service hosts the Request Object.
+
+     https://tfp.example.org/request.jwt/
+       GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
+
+5.2.2.  Request Using the "request_uri" Request Parameter
+
+   The client sends the authorization request to the authorization
+   endpoint.
+
+   The following is an example of an authorization request using the
+   "request_uri" parameter (with line wraps within values for display
+   purposes only):
+
+     https://server.example.com/authorize?
+       client_id=s6BhdRkqt3
+       &request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
+       %2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
+
+5.2.3.  Authorization Server Fetches Request Object
+
+   Upon receipt of the Request, the authorization server MUST send an
+   HTTP "GET" request to the "request_uri" to retrieve the referenced
+   Request Object unless the Request Object is stored in a way so that
+   the server can retrieve it through other mechanisms securely and
+   parse it to recreate the authorization request parameters.
+
+   The following is an example of this fetch process.  In this example,
+   a trusted third-party service hosts the Request Object.
+
+   GET /request.jwt/GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM HTTP/1.1
+   Host: tfp.example.org
+
+   The following is an example of the fetch response:
+
+     HTTP/1.1 200 OK
+     Date: Thu, 20 Aug 2020 23:52:39 GMT
+     Server: Apache/2.4.43 (tfp.example.org)
+     Content-type: application/oauth-authz-req+jwt
+     Content-Length: 797
+     Last-Modified: Wed, 19 Aug 2020 23:52:32 GMT
+
+     eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
+     JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
+     ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
+     lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
+     aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
+     JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
+     IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
+     b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
+     HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
+     JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
+     CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
+     pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g
+
+6.  Validating JWT-Based Requests
+
+6.1.  JWE Encrypted Request Object
+
+   If the Request Object is encrypted, the authorization server MUST
+   decrypt the JWT in accordance with the JSON Web Encryption [RFC7516]
+   specification.
+
+   The result is a signed Request Object.
+
+   If decryption fails, the authorization server MUST return an
+   "invalid_request_object" error to the client in response to the
+   authorization request.
+
+6.2.  JWS-Signed Request Object
+
+   The authorization server MUST validate the signature of the JWS-
+   signed [RFC7515] Request Object.  If a "kid" Header Parameter is
+   present, the key identified MUST be the key used and MUST be a key
+   associated with the client.  The signature MUST be validated using a
+   key associated with the client and the algorithm specified in the
+   "alg" Header Parameter.  Algorithm verification MUST be performed, as
+   specified in Sections 3.1 and 3.2 of [RFC8725].
+
+   If the key is not associated with the client or if signature
+   validation fails, the authorization server MUST return an
+   "invalid_request_object" error to the client in response to the
+   authorization request.
+
+6.3.  Request Parameter Assembly and Validation
+
+   The authorization server MUST extract the set of authorization
+   request parameters from the Request Object value.  The authorization
+   server MUST only use the parameters in the Request Object, even if
+   the same parameter is provided in the query parameter.  The client ID
+   values in the "client_id" request parameter and in the Request Object
+   "client_id" claim MUST be identical.  The authorization server then
+   validates the request, as specified in OAuth 2.0 [RFC6749].
+
+   If the Client ID check or the request validation fails, then the
+   authorization server MUST return an error to the client in response
+   to the authorization request, as specified in Section 5.2 of
+   [RFC6749] (OAuth 2.0).
+
+7.  Authorization Server Response
+
+   The authorization server response is created and sent to the client
+   as in Section 4 of [RFC6749] (OAuth 2.0).
+
+   In addition, this document uses these additional error values:
+
+   invalid_request_uri
+      The "request_uri" in the authorization request returns an error or
+      contains invalid data.
+
+   invalid_request_object
+      The request parameter contains an invalid Request Object.
+
+   request_not_supported
+      The authorization server does not support the use of the "request"
+      parameter.
+
+   request_uri_not_supported
+      The authorization server does not support the use of the
+      "request_uri" parameter.
+
+8.  TLS Requirements
+
+   Client implementations supporting the Request Object URI method MUST
+   support TLS, following "Recommendations for Secure Use of Transport
+   Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"
+   [RFC7525].
+
+   To protect against information disclosure and tampering,
+   confidentiality protection MUST be applied using TLS with a cipher
+   suite that provides confidentiality and integrity protection.
+
+   HTTP clients MUST also verify the TLS server certificate, using DNS-
+   ID [RFC6125], to avoid man-in-the-middle attacks.  The rules and
+   guidelines defined in [RFC6125] apply here, with the following
+   considerations:
+
+   *  Support for DNS-ID identifier type (that is, the dNSName identity
+      in the subjectAltName extension) is REQUIRED.  Certification
+      authorities that issue server certificates MUST support the DNS-ID
+      identifier type, and the DNS-ID identifier type MUST be present in
+      server certificates.
+
+   *  DNS names in server certificates MAY contain the wildcard
+      character "*".
+
+   *  Clients MUST NOT use CN-ID identifiers; a Common Name field (CN
+      field) may be present in the server certificate's subject name but
+      MUST NOT be used for authentication within the rules described in
+      [RFC7525].
+
+   *  SRV-ID and URI-ID as described in Section 6.5 of [RFC6125] MUST
+      NOT be used for comparison.
+
+9.  IANA Considerations
+
+9.1.  OAuth Parameters Registration
+
+   Since the Request Object is a JWT, the core JWT claims cannot be used
+   for any purpose in the Request Object other than for what JWT
+   dictates.  Thus, they have been registered as OAuth authorization
+   request parameters to avoid future OAuth extensions using them with
+   different meanings.
+
+   This specification adds the following values to the "OAuth
+   Parameters" registry [IANA.OAuth.Parameters] established by
+   [RFC6749].
+
+   Name:  "iss"
+   Parameter Usage Location:  authorization request
+   Change Controller:  IETF
+   Specification Document(s):  This document and Section 4.1.1 of
+      [RFC7519].
+
+   Name:  "sub"
+   Parameter Usage Location:  authorization request
+   Change Controller:  IETF
+   Specification Document(s):  This document and Section 4.1.2 of
+      [RFC7519].
+
+   Name:  "aud"
+   Parameter Usage Location:  authorization request
+   Change Controller:  IETF
+   Specification Document(s):  This document and Section 4.1.3 of
+      [RFC7519].
+
+   Name:  "exp"
+   Parameter Usage Location:  authorization request
+   Change Controller:  IETF
+   Specification Document(s):  This document and Section 4.1.4 of
+      [RFC7519].
+
+   Name:  "nbf"
+   Parameter Usage Location:  authorization request
+   Change Controller:  IETF
+   Specification Document(s):  This document and Section 4.1.5 of
+      [RFC7519].
+
+   Name:  "iat"
+   Parameter Usage Location:  authorization request
+   Change Controller:  IETF
+   Specification Document(s):  This document and Section 4.1.6 of
+      [RFC7519].
+
+   Name:  "jti"
+   Parameter Usage Location:  authorization request
+   Change Controller:  IETF
+   Specification Document(s):  This document and Section 4.1.7 of
+      [RFC7519].
+
+9.2.  OAuth Authorization Server Metadata Registry
+
+   This specification adds the following value to the "OAuth
+   Authorization Server Metadata" registry [IANA.OAuth.Parameters]
+   established by [RFC8414].
+
+   Metadata Name:  "require_signed_request_object"
+   Metadata Description:  Indicates where authorization request needs to
+      be protected as Request Object and provided through either
+      "request" or "request_uri parameter".
+   Change Controller:  IETF
+   Specification Document(s):  Section 10.5 of this document.
+
+9.3.  OAuth Dynamic Client Registration Metadata Registry
+
+   This specification adds the following value to the "OAuth Dynamic
+   Client Registration Metadata" registry [IANA.OAuth.Parameters]
+   established by [RFC7591].
+
+   Metadata Name:  "require_signed_request_object"
+   Metadata Description:  Indicates where authorization request needs to
+      be protected as Request Object and provided through either
+      "request" or "request_uri parameter".
+   Change Controller:  IETF
+   Specification Document(s):  Section 10.5 of this document.
+
+9.4.  Media Type Registration
+
+9.4.1.  Registry Contents
+
+   This section registers the "application/oauth-authz-req+jwt" media
+   type [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the
+   manner described in [RFC6838].  It can be used to indicate that the
+   content is a JWT containing Request Object claims.
+
+   Type name:  application
+   Subtype name:  oauth-authz-req+jwt
+   Required parameters:  N/A
+   Optional parameters:  N/A
+   Encoding considerations:  binary; a Request Object is a JWT; JWT
+      values are encoded as a series of base64url-encoded values (some
+      of which may be the empty string) separated by period (".")
+      characters.
+   Security considerations:  See Section 10 of RFC 9101
+   Interoperability considerations:  N/A
+   Published specification:  Section 4 of RFC 9101
+   Applications that use this media type:  Applications that use Request
+      Objects to make an OAuth 2.0 authorization request
+   Fragment identifier considerations:  N/A
+   Additional information:
+      Deprecated alias names for this type:  N/A
+      Magic number(s):  N/A
+      File extension(s):  N/A
+      Macintosh file type code(s):  N/A
+   Person & email address to contact for further information:
+      Nat Sakimura <nat@nat.consulting>
+   Intended usage:  COMMON
+   Restrictions on usage:  none
+   Author:  Nat Sakimura <nat@nat.consulting>
+   Change controller:  IETF
+   Provisional registration?  No
+
+10.  Security Considerations
+
+   In addition to all the security considerations discussed in OAuth 2.0
+   [RFC6819], the security considerations in [RFC7515], [RFC7516],
+   [RFC7518], and [RFC8725] need to be considered.  Also, there are
+   several academic papers such as [BASIN] that provide useful insight
+   into the security properties of protocols like OAuth.
+
+   In consideration of the above, this document advises taking the
+   following security considerations into account.
+
+10.1.  Choice of Algorithms
+
+   When sending the Authorization Request Object through the "request"
+   parameter, it MUST be either signed using JWS [RFC7515] or signed and
+   then encrypted using JWS [RFC7515] and JWE [RFC7516], respectively,
+   with algorithms considered appropriate at the time.
+
+10.2.  Request Source Authentication
+
+   The source of the authorization request MUST always be verified.
+   There are several ways to do it:
+
+   (a)  Verifying the JWS Signature of the Request Object.
+
+   (b)  Verifying that the symmetric key for the JWE encryption is the
+        correct one if the JWE is using symmetric encryption.  Note,
+        however, that if public key encryption is used, no source
+        authentication is enabled by the encryption, as any party can
+        encrypt to the public key.
+
+   (c)  Verifying the TLS Server Identity of the Request Object URI.  In
+        this case, the authorization server MUST know out-of-band that
+        the client uses the Request Object URI and only the client is
+        covered by the TLS certificate.  In general, this is not a
+        reliable method.
+
+   (d)  When an authorization server implements a service that returns a
+        Request Object URI in exchange for a Request Object, the
+        authorization server MUST perform client authentication to
+        accept the Request Object and bind the client identifier to the
+        Request Object URI it is providing.  It MUST validate the
+        signature, per (a).  Since the Request Object URI can be
+        replayed, the lifetime of the Request Object URI MUST be short
+        and preferably one-time use.  The entropy of the Request Object
+        URI MUST be sufficiently large.  The adequate shortness of the
+        validity and the entropy of the Request Object URI depends on
+        the risk calculation based on the value of the resource being
+        protected.  A general guidance for the validity time would be
+        less than a minute, and the Request Object URI is to include a
+        cryptographic random value of 128 bits or more at the time of
+        the writing of this specification.
+
+   (e)  When a trusted third-party service returns a Request Object URI
+        in exchange for a Request Object, it MUST validate the
+        signature, per (a).  In addition, the authorization server MUST
+        be trusted by the third-party service and MUST know out-of-band
+        that the client is also trusted by it.
+
+10.3.  Explicit Endpoints
+
+   Although this specification does not require them, research such as
+   [BASIN] points out that it is a good practice to explicitly state the
+   intended interaction endpoints and the message position in the
+   sequence in a tamper-evident manner so that the intent of the
+   initiator is unambiguous.  It is RECOMMENDED by this specification to
+   use this practice for the following endpoints defined in [RFC6749],
+   [RFC6750], and [RFC8414]:
+
+   (a)  Protected resources ("protected_resources")
+
+   (b)  Authorization endpoint ("authorization_endpoint")
+
+   (c)  Redirection URI ("redirect_uri")
+
+   (d)  Token endpoint ("token_endpoint")
+
+   Further, if dynamic discovery is used, then this practice also
+   applies to the discovery-related endpoints.
+
+   In [RFC6749], while the redirection URI is included in the
+   authorization request, others are not.  As a result, the same applies
+   to the Authorization Request Object.
+
+10.4.  Risks Associated with request_uri
+
+   The introduction of "request_uri" introduces several attack
+   possibilities.  Consult the security considerations in Section 7 of
+   [RFC3986] for more information regarding risks associated with URIs.
+
+10.4.1.  DDoS Attack on the Authorization Server
+
+   A set of malicious clients can launch a DoS attack to the
+   authorization server by pointing the "request_uri" to a URI that
+   returns extremely large content or is extremely slow to respond.
+   Under such an attack, the server may use up its resource and start
+   failing.
+
+   Similarly, a malicious client can specify a "request_uri" value that
+   itself points to an authorization request URI that uses "request_uri"
+   to cause the recursive lookup.
+
+   To prevent such an attack from succeeding, the server should a) check
+   that the value of the "request_uri" parameter does not point to an
+   unexpected location, b) check that the media type of the response is
+   "application/oauth-authz-req+jwt", c) implement a timeout for
+   obtaining the content of "request_uri", and d) not perform recursive
+   GET on the "request_uri".
+
+10.4.2.  Request URI Rewrite
+
+   The value of "request_uri" is not signed; thus, it can be tampered
+   with by a man-in-the-browser attacker.  Several attack possibilities
+   arise because of this.  For example, a) an attacker may create
+   another file that the rewritten URI points to, making it possible to
+   request extra scope, or b) an attacker may launch a DoS attack on a
+   victim site by setting the value of "request_uri" to be that of the
+   victim.
+
+   To prevent such an attack from succeeding, the server should a) check
+   that the value of the "request_uri" parameter does not point to an
+   unexpected location, b) check that the media type of the response is
+   "application/oauth-authz-req+jwt", and c) implement a timeout for
+   obtaining the content of "request_uri".
+
+10.5.  Downgrade Attack
+
+   Unless the protocol used by the client and the server is locked down
+   to use an OAuth JWT-Secured Authorization Request (JAR), it is
+   possible for an attacker to use RFC 6749 requests to bypass all the
+   protection provided by this specification.
+
+   To prevent this kind of attack, this specification defines new client
+   metadata and server metadata values, both named
+   "require_signed_request_object", whose values are both booleans.
+
+   When the value of it as client metadata is "true", then the server
+   MUST reject the authorization request from the client that does not
+   conform to this specification.  It MUST also reject the request if
+   the Request Object uses an "alg" value of "none" when this server
+   metadata value is "true".  If omitted, the default value is "false".
+
+   When the value of it as server metadata is "true", then the server
+   MUST reject the authorization request from any client that does not
+   conform to this specification.  It MUST also reject the request if
+   the Request Object uses an "alg" value of "none".  If omitted, the
+   default value is "false".
+
+   Note that even if "require_signed_request_object" metadata values are
+   not present, the client MAY use signed Request Objects, provided that
+   there are signing algorithms mutually supported by the client and the
+   server.  Use of signing algorithm metadata is described in Section 4.
+
+10.6.  TLS Security Considerations
+
+   Current security considerations can be found in "Recommendations for
+   Secure Use of Transport Layer Security (TLS) and Datagram Transport
+   Layer Security (DTLS)" [RFC7525].  This supersedes the TLS version
+   recommendations in OAuth 2.0 [RFC6749].
+
+10.7.  Parameter Mismatches
+
+   Given that OAuth parameter values are being sent in two different
+   places, as normal OAuth parameters and as Request Object claims,
+   implementations must guard against attacks that could use mismatching
+   parameter values to obtain unintended outcomes.  That is the reason
+   that the two client ID values MUST match, the reason that only the
+   parameter values from the Request Object are to be used, and the
+   reason that neither "request" nor "request_uri" can appear in a
+   Request Object.
+
+10.8.  Cross-JWT Confusion
+
+   As described in Section 2.8 of [RFC8725], attackers may attempt to
+   use a JWT issued for one purpose in a context that it was not
+   intended for.  The mitigations described for these attacks can be
+   applied to Request Objects.
+
+   One way that an attacker might attempt to repurpose a Request Object
+   is to try to use it as a client authentication JWT, as described in
+   Section 2.2 of [RFC7523].  A simple way to prevent this is to never
+   use the client ID as the "sub" value in a Request Object.
+
+   Another way to prevent cross-JWT confusion is to use explicit typing,
+   as described in Section 3.11 of [RFC8725].  One would explicitly type
+   a Request Object by including a "typ" Header Parameter with the value
+   "oauth-authz-req+jwt" (which is registered in Section 9.4.1).  Note,
+   however, that requiring explicitly typed Request Objects at existing
+   authorization servers will break most existing deployments, as
+   existing clients are already commonly using untyped Request Objects,
+   especially with OpenID Connect [OpenID.Core].  However, requiring
+   explicit typing would be a good idea for new OAuth deployment
+   profiles where compatibility with existing deployments is not a
+   consideration.
+
+   Finally, yet another way to prevent cross-JWT confusion is to use a
+   key management regime in which keys used to sign Request Objects are
+   identifiably distinct from those used for other purposes.  Then, if
+   an adversary attempts to repurpose the Request Object in another
+   context, a key mismatch will occur, thwarting the attack.
+
+11.  Privacy Considerations
+
+   When the client is being granted access to a protected resource
+   containing personal data, both the client and the authorization
+   server need to adhere to Privacy Principles.  "Privacy Considerations
+   for Internet Protocols" [RFC6973] gives excellent guidance on the
+   enhancement of protocol design and implementation.  The provisions
+   listed in it should be followed.
+
+   Most of the provisions would apply to "The OAuth 2.0 Authorization
+   Framework" [RFC6749] and "The OAuth 2.0 Authorization Framework:
+   Bearer Token Usage" [RFC6750] and are not specific to this
+   specification.  In what follows, only the provisions specific to this
+   specification are noted.
+
+11.1.  Collection Limitation
+
+   When the client is being granted access to a protected resource
+   containing personal data, the client SHOULD limit the collection of
+   personal data to that which is within the bounds of applicable law
+   and strictly necessary for the specified purpose(s).
+
+   It is often hard for the user to find out if the personal data asked
+   for is strictly necessary.  A trusted third-party service can help
+   the user by examining the client request, comparing it to the
+   proposed processing by the client, and certifying the request.  After
+   the certification, the client, when making an authorization request,
+   can submit an authorization request to the trusted third-party
+   service to obtain the Request Object URI.  This process has two
+   steps:
+
+   (1)  (Certification Process) The trusted third-party service examines
+        the business process of the client and determines what claims
+        they need; this is the certification process.  Once the client
+        is certified, they are issued a client credential to
+        authenticate against to push Request Objects to the trusted
+        third-party service to get the "request_uri".
+
+   (2)  (Translation Process) The client uses the client credential that
+        it got to push the Request Object to the trusted third-party
+        service to get the "request_uri".  The trusted third-party
+        service also verifies that the Request Object is consistent with
+        the claims that the client is eligible for, per the prior step.
+
+   Upon receiving such a Request Object URI in the authorization
+   request, the authorization server first verifies that the authority
+   portion of the Request Object URI is a legitimate one for the trusted
+   third-party service.  Then, the authorization server issues an HTTP
+   GET request to the Request Object URI.  Upon connecting, the
+   authorization server MUST verify that the server identity represented
+   in the TLS certificate is legitimate for the Request Object URI.
+   Then, the authorization server can obtain the Request Object, which
+   includes the "client_id" representing the client.
+
+   The Consent screen MUST indicate the client and SHOULD indicate that
+   the request has been vetted by the trusted third-party service for
+   the adherence to the collection limitation principle.
+
+11.2.  Disclosure Limitation
+
+11.2.1.  Request Disclosure
+
+   This specification allows extension parameters.  These may include
+   potentially sensitive information.  Since URI query parameters may
+   leak through various means but most notably through referrer and
+   browser history, if the authorization request contains a potentially
+   sensitive parameter, the client SHOULD encrypt the Request Object
+   using JWE [RFC7516].
+
+   Where the Request Object URI method is being used, if the Request
+   Object contains personally identifiable or sensitive information, the
+   "request_uri" SHOULD be used only once and have a short validity
+   period, and it MUST have sufficient entropy for the applicable
+   security policies unless the Request Object itself is encrypted using
+   JWE [RFC7516].  The adequate shortness of the validity and the
+   entropy of the Request Object URI depends on the risk calculation
+   based on the value of the resource being protected.  A general
+   guidance for the validity time would be less than a minute, and the
+   Request Object URI is to include a cryptographic random value of 128
+   bits or more at the time of the writing of this specification.
+
+11.2.2.  Tracking Using Request Object URI
+
+   Even if the protected resource does not include personally
+   identifiable information, it is sometimes possible to identify the
+   user through the Request Object URI if persistent static per-user
+   Request Object URIs are used.  A third party may observe it through
+   browser history, etc. and start correlating the user's activity using
+   it.  In a way, it is a data disclosure as well and should be avoided.
+
+   Therefore, per-user persistent Request Object URIs should be avoided.
+   Single-use Request Object URIs are one alternative.
+
+12.  References
+
+12.1.  Normative References
+
+   [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>.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
+              2003, <https://www.rfc-editor.org/info/rfc3629>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <https://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
+              2011, <https://www.rfc-editor.org/info/rfc6125>.
+
+   [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>.
+
+   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
+              Framework: Bearer Token Usage", RFC 6750,
+              DOI 10.17487/RFC6750, October 2012,
+              <https://www.rfc-editor.org/info/rfc6750>.
+
+   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Message Syntax and Routing",
+              RFC 7230, DOI 10.17487/RFC7230, June 2014,
+              <https://www.rfc-editor.org/info/rfc7230>.
+
+   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
+              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
+              2015, <https://www.rfc-editor.org/info/rfc7515>.
+
+   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
+              RFC 7516, DOI 10.17487/RFC7516, May 2015,
+              <https://www.rfc-editor.org/info/rfc7516>.
+
+   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
+              DOI 10.17487/RFC7518, May 2015,
+              <https://www.rfc-editor.org/info/rfc7518>.
+
+   [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>.
+
+   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
+              "Recommendations for Secure Use of Transport Layer
+              Security (TLS) and Datagram Transport Layer Security
+              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
+              2015, <https://www.rfc-editor.org/info/rfc7525>.
+
+   [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
+              (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
+              <https://www.rfc-editor.org/info/rfc8141>.
+
+   [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>.
+
+   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+              Interchange Format", STD 90, RFC 8259,
+              DOI 10.17487/RFC8259, December 2017,
+              <https://www.rfc-editor.org/info/rfc8259>.
+
+   [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
+              Authorization Server Metadata", RFC 8414,
+              DOI 10.17487/RFC8414, June 2018,
+              <https://www.rfc-editor.org/info/rfc8414>.
+
+12.2.  Informative References
+
+   [BASIN]    Basin, D., Cremers, C., and S. Meier, "Provably Repairing
+              the ISO/IEC 9798 Standard for Entity Authentication",
+              Journal of Computer Security - Security and Trust
+              Principles, Volume 21, Issue 6, pp. 817-846, November
+              2013,
+              <https://www.cs.ox.ac.uk/people/cas.cremers/downloads/
+              papers/BCM2012-iso9798.pdf>.
+
+   [CapURLs]  Tennison, J., Ed., "Good Practices for Capability URLs",
+              W3C First Public Working Draft, 18 February 2014,
+              <https://www.w3.org/TR/capability-urls/>.
+
+   [IANA.JWT.Claims]
+              IANA, "JSON Web Token (JWT)",
+              <https://www.iana.org/assignments/jwt>.
+
+   [IANA.MediaTypes]
+              IANA, "Media Types",
+              <https://www.iana.org/assignments/media-types>.
+
+   [IANA.OAuth.Parameters]
+              IANA, "OAuth Parameters",
+              <https://www.iana.org/assignments/oauth-parameters>.
+
+   [OpenID.Core]
+              Sakimura, N., Bradley, J., Jones, M.B., de Medeiros, B.,
+              and C. Mortimore, "OpenID Connect Core 1.0 incorporating
+              errata set 1", OpenID Foundation Standards, 8 November
+              2014,
+              <http://openid.net/specs/openid-connect-core-1_0.html>.
+
+   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part Two: Media Types", RFC 2046,
+              DOI 10.17487/RFC2046, November 1996,
+              <https://www.rfc-editor.org/info/rfc2046>.
+
+   [RFC6819]  Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
+              Threat Model and Security Considerations", RFC 6819,
+              DOI 10.17487/RFC6819, January 2013,
+              <https://www.rfc-editor.org/info/rfc6819>.
+
+   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
+              Specifications and Registration Procedures", BCP 13,
+              RFC 6838, DOI 10.17487/RFC6838, January 2013,
+              <https://www.rfc-editor.org/info/rfc6838>.
+
+   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
+              Morris, J., Hansen, M., and R. Smith, "Privacy
+              Considerations for Internet Protocols", RFC 6973,
+              DOI 10.17487/RFC6973, July 2013,
+              <https://www.rfc-editor.org/info/rfc6973>.
+
+   [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>.
+
+   [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>.
+
+   [RFC8725]  Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
+              Current Practices", BCP 225, RFC 8725,
+              DOI 10.17487/RFC8725, February 2020,
+              <https://www.rfc-editor.org/info/rfc8725>.
+
+Acknowledgements
+
+   The following people contributed to the creation of this document in
+   the OAuth Working Group and other IETF roles.  (Affiliations at the
+   time of the contribution are used.)
+
+   Annabelle Backman (Amazon), Dirk Balfanz (Google), Sergey Beryozkin,
+   Ben Campbell (as AD), Brian Campbell (Ping Identity), Roman Danyliw
+   (as AD), Martin Duke (as AD), Vladimir Dzhuvinov (Connect2id), Lars
+   Eggert (as AD), Joel Halpern (as GENART), Benjamin Kaduk (as AD),
+   Stephen Kent (as SECDIR), Murray Kucherawy (as AD), Warren Kumari (as
+   OPSDIR), Watson Ladd (as SECDIR), Torsten Lodderstedt (yes.com), Jim
+   Manico, James H. Manger (Telstra), Kathleen Moriarty (as AD), Axel
+   Nennker (Deutsche Telecom), John Panzer (Google), Francesca Palombini
+   (as AD), David Recordon (Facebook), Marius Scurtescu (Google), Luke
+   Shepard (Facebook), Filip Skokan (Auth0), Hannes Tschofenig (ARM),
+   Éric Vyncke (as AD), and Robert Wilton (as AD).
+
+   The following people contributed to creating this document through
+   the OpenID Connect Core 1.0 [OpenID.Core].
+
+   Brian Campbell (Ping Identity), George Fletcher (AOL), Ryo Itou
+   (Mixi), Edmund Jay (Illumila), Breno de Medeiros (Google), Hideki
+   Nara (TACT), and Justin Richer (MITRE).
+
+Authors' Addresses
+
+   Nat Sakimura
+   NAT.Consulting
+   2-22-17 Naka
+   Kunitachi, Tokyo 186-0004
+   Japan
+
+   Phone: +81-42-580-7401
+   Email: nat@nat.consulting
+   URI:   https://nat.sakimura.org/
+
+
+   John Bradley
+   Yubico
+   Sucursal Talagante
+   Casilla 177
+   Talagante
+   RM
+   Chile
+
+   Phone: +1.202.630.5272
+   Email: rfc9101@ve7jtb.com
+   URI:   http://www.thread-safe.com/
+
+
+   Michael B. Jones
+   Microsoft
+   One Microsoft Way
+   Redmond, Washington 98052
+   United States of America
+
+   Email: mbj@microsoft.com
+   URI:   https://self-issued.info/