doc: Add RFC documents

1 files changed, 1224 insertions, 0 deletions

diff --git a/doc/rfc/rfc8705.txt b/doc/rfc/rfc8705.txt
new file mode 100644
index 0000000..943eae1
--- /dev/null
+++ b/doc/rfc/rfc8705.txt
@@ -0,0 +1,1224 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       B. Campbell
+Request for Comments: 8705                                 Ping Identity
+Category: Standards Track                                     J. Bradley
+ISSN: 2070-1721                                                   Yubico
+                                                             N. Sakimura
+                                               Nomura Research Institute
+                                                          T. Lodderstedt
+                                                              YES.com AG
+                                                           February 2020
+
+
+    OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound
+                             Access Tokens
+
+Abstract
+
+   This document describes OAuth client authentication and certificate-
+   bound access and refresh tokens using mutual Transport Layer Security
+   (TLS) authentication with X.509 certificates.  OAuth clients are
+   provided a mechanism for authentication to the authorization server
+   using mutual TLS, based on either self-signed certificates or public
+   key infrastructure (PKI).  OAuth authorization servers are provided a
+   mechanism for binding access tokens to a client's mutual-TLS
+   certificate, and OAuth protected resources are provided a method for
+   ensuring that such an access token presented to it was issued to the
+   client presenting the token.
+
+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/rfc8705.
+
+Copyright Notice
+
+   Copyright (c) 2020 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 Notation and Conventions
+     1.2.  Terminology
+   2.  Mutual TLS for OAuth Client Authentication
+     2.1.  PKI Mutual-TLS Method
+       2.1.1.  PKI Method Metadata Value
+       2.1.2.  Client Registration Metadata
+     2.2.  Self-Signed Certificate Mutual-TLS Method
+       2.2.1.  Self-Signed Method Metadata Value
+       2.2.2.  Client Registration Metadata
+   3.  Mutual-TLS Client Certificate-Bound Access Tokens
+     3.1.  JWT Certificate Thumbprint Confirmation Method
+     3.2.  Confirmation Method for Token Introspection
+     3.3.  Authorization Server Metadata
+     3.4.  Client Registration Metadata
+   4.  Public Clients and Certificate-Bound Tokens
+   5.  Metadata for Mutual-TLS Endpoint Aliases
+   6.  Implementation Considerations
+     6.1.  Authorization Server
+     6.2.  Resource Server
+     6.3.  Certificate Expiration and Bound Access Tokens
+     6.4.  Implicit Grant Unsupported
+     6.5.  TLS Termination
+   7.  Security Considerations
+     7.1.  Certificate-Bound Refresh Tokens
+     7.2.  Certificate Thumbprint Binding
+     7.3.  TLS Versions and Best Practices
+     7.4.  X.509 Certificate Spoofing
+     7.5.  X.509 Certificate Parsing and Validation Complexity
+   8.  Privacy Considerations
+   9.  IANA Considerations
+     9.1.  JWT Confirmation Methods Registration
+     9.2.  Authorization Server Metadata Registration
+     9.3.  Token Endpoint Authentication Method Registration
+     9.4.  Token Introspection Response Registration
+     9.5.  Dynamic Client Registration Metadata Registration
+   10. References
+     10.1.  Normative References
+     10.2.  Informative References
+   Appendix A.  Example "cnf" Claim, Certificate, and JWK
+   Appendix B.  Relationship to Token Binding
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   The OAuth 2.0 Authorization Framework [RFC6749] enables third-party
+   client applications to obtain delegated access to protected
+   resources.  In the prototypical abstract OAuth flow, illustrated in
+   Figure 1, the client obtains an access token from an entity known as
+   an authorization server and then uses that token when accessing
+   protected resources, such as HTTPS APIs.
+
+     +--------+                                 +---------------+
+     |        |                                 |               |
+     |        |<--(A)-- Get an access token --->| Authorization |
+     |        |                                 |     Server    |
+     |        |                                 |               |
+     |        |                                 +---------------+
+     |        |                                         ^
+     |        |                                         |
+     |        |
+     |        |                               (C)       |
+     | Client |                           Validate the
+     |        |                           access token  |
+     |        |
+     |        |                                         |
+     |        |                                         v
+     |        |                                 +---------------+
+     |        |                                 |      (C)      |
+     |        |                                 |               |
+     |        |<--(B)-- Use the access token -->|   Protected   |
+     |        |                                 |    Resource   |
+     |        |                                 |               |
+     +--------+                                 +---------------+
+
+                 Figure 1: Abstract OAuth 2.0 Protocol Flow
+
+   The flow illustrated in Figure 1 includes the following steps:
+
+   (A)  The client makes an HTTPS "POST" request to the authorization
+        server and presents a credential representing the authorization
+        grant.  For certain types of clients (those that have been
+        issued or otherwise established a set of client credentials) the
+        request must be authenticated.  In the response, the
+        authorization server issues an access token to the client.
+
+   (B)  The client includes the access token when making a request to
+        access a protected resource.
+
+   (C)  The protected resource validates the access token in order to
+        authorize the request.  In some cases, such as when the token is
+        self-contained and cryptographically secured, the validation can
+        be done locally by the protected resource.  Other cases require
+        that the protected resource call out to the authorization server
+        to determine the state of the token and obtain metainformation
+        about it.
+
+   Layering on the abstract flow above, this document standardizes
+   enhanced security options for OAuth 2.0 utilizing client-certificate-
+   based mutual TLS.  Section 2 provides options for authenticating the
+   request in Step (A).  Step (C) is supported with semantics to express
+   the binding of the token to the client certificate for both local and
+   remote processing in Sections 3.1 and 3.2, respectively.  This
+   ensures that, as described in Section 3, protected resource access in
+   Step (B) is only possible by the legitimate client using a
+   certificate-bound token and holding the private key corresponding to
+   the certificate.
+
+   OAuth 2.0 defines a shared-secret method of client authentication but
+   also allows for defining and using additional client authentication
+   mechanisms when interacting directly with the authorization server.
+   This document describes an additional mechanism of client
+   authentication utilizing mutual-TLS certificate-based authentication
+   that provides better security characteristics than shared secrets.
+   While [RFC6749] documents client authentication for requests to the
+   token endpoint, extensions to OAuth 2.0 (such as Introspection
+   [RFC7662], Revocation [RFC7009], and the Backchannel Authentication
+   Endpoint in [OpenID.CIBA]) define endpoints that also utilize client
+   authentication, and the mutual-TLS methods defined herein are
+   applicable to those endpoints as well.
+
+   Mutual-TLS certificate-bound access tokens ensure that only the party
+   in possession of the private key corresponding to the certificate can
+   utilize the token to access the associated resources.  Such a
+   constraint is sometimes referred to as key confirmation, proof-of-
+   possession, or holder-of-key and is unlike the case of the bearer
+   token described in [RFC6750], where any party in possession of the
+   access token can use it to access the associated resources.  Binding
+   an access token to the client's certificate prevents the use of
+   stolen access tokens or replay of access tokens by unauthorized
+   parties.
+
+   Mutual-TLS certificate-bound access tokens and mutual-TLS client
+   authentication are distinct mechanisms that are complementary but
+   don't necessarily need to be deployed or used together.
+
+   Additional client metadata parameters are introduced by this document
+   in support of certificate-bound access tokens and mutual-TLS client
+   authentication.  The authorization server can obtain client metadata
+   via the Dynamic Client Registration Protocol [RFC7591], which defines
+   mechanisms for dynamically registering OAuth 2.0 client metadata with
+   authorization servers.  Also the metadata defined by [RFC7591], and
+   registered extensions to it, imply a general data model for clients
+   that is useful for authorization server implementations, even when
+   the Dynamic Client Registration Protocol isn't in play.  Such
+   implementations will typically have some sort of user interface
+   available for managing client configuration.
+
+1.1.  Requirements Notation and Conventions
+
+   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.
+
+1.2.  Terminology
+
+   Throughout this document the term "mutual TLS" refers to the process
+   whereby, in addition to the normal TLS server authentication with a
+   certificate, a client presents its X.509 certificate and proves
+   possession of the corresponding private key to a server when
+   negotiating a TLS session.  In contemporary versions of TLS [RFC5246]
+   [RFC8446], this requires that the client send the Certificate and
+   CertificateVerify messages during the handshake and for the server to
+   verify the CertificateVerify and Finished messages.
+
+2.  Mutual TLS for OAuth Client Authentication
+
+   This section defines, as an extension of Section 2.3 of OAuth 2.0
+   [RFC6749], two distinct methods of using mutual-TLS X.509 client
+   certificates as client credentials.  The requirement of mutual TLS
+   for client authentication is determined by the authorization server,
+   based on policy or configuration for the given client (regardless of
+   whether the client was dynamically registered, statically configured,
+   or otherwise established).
+
+   In order to utilize TLS for OAuth client authentication, the TLS
+   connection between the client and the authorization server MUST have
+   been established or re-established with mutual-TLS X.509 certificate
+   authentication (i.e., the client Certificate and CertificateVerify
+   messages are sent during the TLS handshake).
+
+   For all requests to the authorization server utilizing mutual-TLS
+   client authentication, the client MUST include the "client_id"
+   parameter described in Section 2.2 of OAuth 2.0 [RFC6749].  The
+   presence of the "client_id" parameter enables the authorization
+   server to easily identify the client independently from the content
+   of the certificate.  The authorization server can locate the client
+   configuration using the client identifier and check the certificate
+   presented in the TLS handshake against the expected credentials for
+   that client.  The authorization server MUST enforce the binding
+   between client and certificate, as described in either Section 2.1 or
+   2.2 below.  If no certificate is presented, or that which is
+   presented doesn't match that which is expected for the given
+   "client_id", the authorization server returns a normal OAuth 2.0
+   error response per Section 5.2 of [RFC6749] with the "invalid_client"
+   error code to indicate failed client authentication.
+
+2.1.  PKI Mutual-TLS Method
+
+   The PKI (public key infrastructure) method of mutual-TLS OAuth client
+   authentication adheres to the way in which X.509 certificates are
+   traditionally used for authentication.  It relies on a validated
+   certificate chain [RFC5280] and a single subject distinguished name
+   (DN) or a single subject alternative name (SAN) to authenticate the
+   client.  Only one subject name value of any type is used for each
+   client.  The TLS handshake is utilized to validate the client's
+   possession of the private key corresponding to the public key in the
+   certificate and to validate the corresponding certificate chain.  The
+   client is successfully authenticated if the subject information in
+   the certificate matches the single expected subject configured or
+   registered for that particular client (note that a predictable
+   treatment of DN values, such as the distinguishedNameMatch rule from
+   [RFC4517], is needed in comparing the certificate's subject DN to the
+   client's registered DN).  Revocation checking is possible with the
+   PKI method but if and how to check a certificate's revocation status
+   is a deployment decision at the discretion of the authorization
+   server.  Clients can rotate their X.509 certificates without the need
+   to modify the respective authentication data at the authorization
+   server by obtaining a new certificate with the same subject from a
+   trusted certificate authority (CA).
+
+2.1.1.  PKI Method Metadata Value
+
+   For the PKI method of mutual-TLS client authentication, this
+   specification defines and registers the following authentication
+   method metadata value into the "OAuth Token Endpoint Authentication
+   Methods" registry [IANA.OAuth.Parameters].
+
+   tls_client_auth
+      Indicates that client authentication to the authorization server
+      will occur with mutual TLS utilizing the PKI method of associating
+      a certificate to a client.
+
+2.1.2.  Client Registration Metadata
+
+   In order to convey the expected subject of the certificate, the
+   following metadata parameters are introduced for the OAuth 2.0
+   Dynamic Client Registration Protocol [RFC7591] in support of the PKI
+   method of mutual-TLS client authentication.  A client using the
+   "tls_client_auth" authentication method MUST use exactly one of the
+   below metadata parameters to indicate the certificate subject value
+   that the authorization server is to expect when authenticating the
+   respective client.
+
+   tls_client_auth_subject_dn
+      A string representation -- as defined in [RFC4514] -- of the
+      expected subject distinguished name of the certificate that the
+      OAuth client will use in mutual-TLS authentication.
+
+   tls_client_auth_san_dns
+      A string containing the value of an expected dNSName SAN entry in
+      the certificate that the OAuth client will use in mutual-TLS
+      authentication.
+
+   tls_client_auth_san_uri
+      A string containing the value of an expected
+      uniformResourceIdentifier SAN entry in the certificate that the
+      OAuth client will use in mutual-TLS authentication.
+
+   tls_client_auth_san_ip
+      A string representation of an IP address in either dotted decimal
+      notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as
+      defined in [RFC5952]) that is expected to be present as an
+      iPAddress SAN entry in the certificate that the OAuth client will
+      use in mutual-TLS authentication.  Per Section 8 of [RFC5952], the
+      IP address comparison of the value in this parameter and the SAN
+      entry in the certificate is to be done in binary format.
+
+   tls_client_auth_san_email
+      A string containing the value of an expected rfc822Name SAN entry
+      in the certificate that the OAuth client will use in mutual-TLS
+      authentication.
+
+2.2.  Self-Signed Certificate Mutual-TLS Method
+
+   This method of mutual-TLS OAuth client authentication is intended to
+   support client authentication using self-signed certificates.  As a
+   prerequisite, the client registers its X.509 certificates (using
+   "jwks" defined in [RFC7591]) or a reference to a trusted source for
+   its X.509 certificates (using "jwks_uri" from [RFC7591]) with the
+   authorization server.  During authentication, TLS is utilized to
+   validate the client's possession of the private key corresponding to
+   the public key presented within the certificate in the respective TLS
+   handshake.  In contrast to the PKI method, the client's certificate
+   chain is not validated by the server in this case.  The client is
+   successfully authenticated if the certificate that it presented
+   during the handshake matches one of the certificates configured or
+   registered for that particular client.  The Self-Signed Certificate
+   method allows the use of mutual TLS to authenticate clients without
+   the need to maintain a PKI.  When used in conjunction with a
+   "jwks_uri" for the client, it also allows the client to rotate its
+   X.509 certificates without the need to change its respective
+   authentication data directly with the authorization server.
+
+2.2.1.  Self-Signed Method Metadata Value
+
+   For the Self-Signed Certificate method of mutual-TLS client
+   authentication, this specification defines and registers the
+   following authentication method metadata value into the "OAuth Token
+   Endpoint Authentication Methods" registry [IANA.OAuth.Parameters].
+
+   self_signed_tls_client_auth
+      Indicates that client authentication to the authorization server
+      will occur using mutual TLS with the client utilizing a self-
+      signed certificate.
+
+2.2.2.  Client Registration Metadata
+
+   For the Self-Signed Certificate method of binding a certificate with
+   a client using mutual-TLS client authentication, the existing
+   "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to
+   convey the client's certificates via JSON Web Key (JWK) in a JWK Set
+   [RFC7517].  The "jwks" metadata parameter is a JWK Set containing the
+   client's public keys as an array of JWKs, while the "jwks_uri"
+   parameter is a URL that references a client's JWK Set. A certificate
+   is represented with the "x5c" parameter of an individual JWK within
+   the set.  Note that the members of the JWK representing the public
+   key (e.g., "n" and "e" for RSA, "x" and "y" for Elliptic Curve (EC))
+   are required parameters per [RFC7518] so will be present even though
+   they are not utilized in this context.  Also note that Section 4.7 of
+   [RFC7517] requires that the key in the first certificate of the "x5c"
+   parameter match the public key represented by those other members of
+   the JWK.
+
+3.  Mutual-TLS Client Certificate-Bound Access Tokens
+
+   When mutual TLS is used by the client on the connection to the token
+   endpoint, the authorization server is able to bind the issued access
+   token to the client certificate.  Such a binding is accomplished by
+   associating the certificate with the token in a way that can be
+   accessed by the protected resource, such as embedding the certificate
+   hash in the issued access token directly, using the syntax described
+   in Section 3.1, or through token introspection as described in
+   Section 3.2.  Binding the access token to the client certificate in
+   that fashion has the benefit of decoupling that binding from the
+   client's authentication with the authorization server, which enables
+   mutual TLS during protected resource access to serve purely as a
+   proof-of-possession mechanism.  Other methods of associating a
+   certificate with an access token are possible, per agreement by the
+   authorization server and the protected resource, but are beyond the
+   scope of this specification.
+
+   In order for a resource server to use certificate-bound access
+   tokens, it must have advance knowledge that mutual TLS is to be used
+   for some or all resource accesses.  In particular, the access token
+   itself cannot be used as input to the decision of whether or not to
+   request mutual TLS because (from the TLS perspective) it is
+   "Application Data", only exchanged after the TLS handshake has been
+   completed, and the initial CertificateRequest occurs during the
+   handshake, before the Application Data is available.  Although
+   subsequent opportunities for a TLS client to present a certificate
+   may be available, e.g., via TLS 1.2 renegotiation [RFC5246] or TLS
+   1.3 post-handshake authentication [RFC8446], this document makes no
+   provision for their usage.  It is expected to be common that a
+   mutual-TLS-using resource server will require mutual TLS for all
+   resources hosted thereupon or will serve mutual-TLS-protected and
+   regular resources on separate hostname and port combinations, though
+   other workflows are possible.  How resource server policy is
+   synchronized with the authorization server (AS) is out of scope for
+   this document.
+
+   Within the scope of a mutual-TLS-protected resource-access flow, the
+   client makes protected resource requests, as described in [RFC6750],
+   however, those requests MUST be made over a mutually authenticated
+   TLS connection using the same certificate that was used for mutual
+   TLS at the token endpoint.
+
+   The protected resource MUST obtain, from its TLS implementation
+   layer, the client certificate used for mutual TLS and MUST verify
+   that the certificate matches the certificate associated with the
+   access token.  If they do not match, the resource access attempt MUST
+   be rejected with an error, per [RFC6750], using an HTTP 401 status
+   code and the "invalid_token" error code.
+
+   Metadata to convey server and client capabilities for mutual-TLS
+   client certificate-bound access tokens is defined in Sections 3.3 and
+   3.4, respectively.
+
+3.1.  JWT Certificate Thumbprint Confirmation Method
+
+   When access tokens are represented as JSON Web Tokens (JWT)
+   [RFC7519], the certificate hash information SHOULD be represented
+   using the "x5t#S256" confirmation method member defined herein.
+
+   To represent the hash of a certificate in a JWT, this specification
+   defines the new JWT Confirmation Method [RFC7800] member "x5t#S256"
+   for the X.509 Certificate SHA-256 Thumbprint.  The value of the
+   "x5t#S256" member is a base64url-encoded [RFC4648] SHA-256 [SHS] hash
+   (a.k.a., thumbprint, fingerprint, or digest) of the DER encoding
+   [X690] of the X.509 certificate [RFC5280].  The base64url-encoded
+   value MUST omit all trailing pad '=' characters and MUST NOT include
+   any line breaks, whitespace, or other additional characters.
+
+   The following is an example of a JWT payload containing an "x5t#S256"
+   certificate thumbprint confirmation method.  The new JWT content
+   introduced by this specification is the "cnf" confirmation method
+   claim at the bottom of the example that has the "x5t#S256"
+   confirmation method member containing the value that is the hash of
+   the client certificate to which the access token is bound.
+
+     {
+       "iss": "https://server.example.com",
+       "sub": "ty.webb@example.com",
+       "exp": 1493726400,
+       "nbf": 1493722800,
+       "cnf":{
+         "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
+       }
+     }
+
+   Figure 2: Example JWT Claims Set with an X.509 Certificate Thumbprint
+                            Confirmation Method
+
+3.2.  Confirmation Method for Token Introspection
+
+   OAuth 2.0 Token Introspection [RFC7662] defines a method for a
+   protected resource to query an authorization server about the active
+   state of an access token as well as to determine metainformation
+   about the token.
+
+   For a mutual-TLS client certificate-bound access token, the hash of
+   the certificate to which the token is bound is conveyed to the
+   protected resource as metainformation in a token introspection
+   response.  The hash is conveyed using the same "cnf" with "x5t#S256"
+   member structure as the certificate SHA-256 thumbprint confirmation
+   method, described in Section 3.1, as a top-level member of the
+   introspection response JSON.  The protected resource compares that
+   certificate hash to a hash of the client certificate used for mutual-
+   TLS authentication and rejects the request if they do not match.
+
+   The following is an example of an introspection response for an
+   active token with an "x5t#S256" certificate thumbprint confirmation
+   method.  The new introspection response content introduced by this
+   specification is the "cnf" confirmation method at the bottom of the
+   example that has the "x5t#S256" confirmation method member containing
+   the value that is the hash of the client certificate to which the
+   access token is bound.
+
+     HTTP/1.1 200 OK
+     Content-Type: application/json
+
+     {
+       "active": true,
+       "iss": "https://server.example.com",
+       "sub": "ty.webb@example.com",
+       "exp": 1493726400,
+       "nbf": 1493722800,
+       "cnf":{
+         "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
+       }
+     }
+
+      Figure 3: Example Introspection Response for a Certificate-Bound
+                                Access Token
+
+3.3.  Authorization Server Metadata
+
+   This document introduces the following new authorization server
+   metadata [RFC8414] parameter to signal the server's capability to
+   issue certificate-bound access tokens:
+
+   tls_client_certificate_bound_access_tokens
+      OPTIONAL.  Boolean value indicating server support for mutual-TLS
+      client certificate-bound access tokens.  If omitted, the default
+      value is "false".
+
+3.4.  Client Registration Metadata
+
+   The following new client metadata parameter is introduced to convey
+   the client's intention to use certificate-bound access tokens:
+
+   tls_client_certificate_bound_access_tokens
+      OPTIONAL.  Boolean value used to indicate the client's intention
+      to use mutual-TLS client certificate-bound access tokens.  If
+      omitted, the default value is "false".
+
+   Note that if a client that has indicated the intention to use mutual-
+   TLS client certificate-bound tokens makes a request to the token
+   endpoint over a non-mutual-TLS connection, it is at the authorization
+   server's discretion as to whether to return an error or issue an
+   unbound token.
+
+4.  Public Clients and Certificate-Bound Tokens
+
+   Mutual-TLS OAuth client authentication and certificate-bound access
+   tokens can be used independently of each other.  Use of certificate-
+   bound access tokens without mutual-TLS OAuth client authentication,
+   for example, is possible in support of binding access tokens to a TLS
+   client certificate for public clients (those without authentication
+   credentials associated with the "client_id").  The authorization
+   server would configure the TLS stack in the same manner as for the
+   Self-Signed Certificate method such that it does not verify that the
+   certificate presented by the client during the handshake is signed by
+   a trusted CA.  Individual instances of a client would create a self-
+   signed certificate for mutual TLS with both the authorization server
+   and resource server.  The authorization server would not use the
+   mutual-TLS certificate to authenticate the client at the OAuth layer
+   but would bind the issued access token to the certificate for which
+   the client has proven possession of the corresponding private key.
+   The access token is then bound to the certificate and can only be
+   used by the client possessing the certificate and corresponding
+   private key and utilizing them to negotiate mutual TLS on connections
+   to the resource server.  When the authorization server issues a
+   refresh token to such a client, it SHOULD also bind the refresh token
+   to the respective certificate and check the binding when the refresh
+   token is presented to get new access tokens.  The implementation
+   details of the binding of the refresh token are at the discretion of
+   the authorization server.
+
+5.  Metadata for Mutual-TLS Endpoint Aliases
+
+   The process of negotiating client certificate-based mutual TLS
+   involves a TLS server requesting a certificate from the TLS client
+   (the client does not provide one unsolicited).  Although a server can
+   be configured such that client certificates are optional, meaning
+   that the connection is allowed to continue when the client does not
+   provide a certificate, the act of a server requesting a certificate
+   can result in undesirable behavior from some clients.  This is
+   particularly true of web browsers as TLS clients, which will
+   typically present the end user with an intrusive certificate
+   selection interface when the server requests a certificate.
+
+   Authorization servers supporting both clients using mutual TLS and
+   conventional clients MAY chose to isolate the server side mutual-TLS
+   behavior to only clients intending to do mutual TLS, thus avoiding
+   any undesirable effects it might have on conventional clients.  The
+   following authorization server metadata parameter is introduced to
+   facilitate such separation:
+
+   mtls_endpoint_aliases
+      OPTIONAL.  A JSON object containing alternative authorization
+      server endpoints that, when present, an OAuth client intending to
+      do mutual TLS uses in preference to the conventional endpoints.
+      The parameter value itself consists of one or more endpoint
+      parameters, such as "token_endpoint", "revocation_endpoint",
+      "introspection_endpoint", etc., conventionally defined for the top
+      level of authorization server metadata.  An OAuth client intending
+      to do mutual TLS (for OAuth client authentication and/or to
+      acquire or use certificate-bound tokens) when making a request
+      directly to the authorization server MUST use the alias URL of the
+      endpoint within the "mtls_endpoint_aliases", when present, in
+      preference to the endpoint URL of the same name at the top level
+      of metadata.  When an endpoint is not present in
+      "mtls_endpoint_aliases", then the client uses the conventional
+      endpoint URL defined at the top level of the authorization server
+      metadata.  Metadata parameters within "mtls_endpoint_aliases" that
+      do not define endpoints to which an OAuth client makes a direct
+      request have no meaning and SHOULD be ignored.
+
+   Below is an example of an authorization server metadata document with
+   the "mtls_endpoint_aliases" parameter, which indicates aliases for
+   the token, revocation, and introspection endpoints that an OAuth
+   client intending to do mutual TLS would use in preference to the
+   conventional token, revocation, and introspection endpoints.  Note
+   that the endpoints in "mtls_endpoint_aliases" use a different host
+   than their conventional counterparts, which allows the authorization
+   server (via TLS "server_name" extension [RFC6066] or actual distinct
+   hosts) to differentiate its TLS behavior as appropriate.
+
+   {
+     "issuer": "https://server.example.com",
+     "authorization_endpoint": "https://server.example.com/authz",
+     "token_endpoint": "https://server.example.com/token",
+     "introspection_endpoint": "https://server.example.com/introspect",
+     "revocation_endpoint": "https://server.example.com/revo",
+     "jwks_uri": "https://server.example.com/jwks",
+     "response_types_supported": ["code"],
+     "response_modes_supported": ["fragment","query","form_post"],
+     "grant_types_supported": ["authorization_code", "refresh_token"],
+     "token_endpoint_auth_methods_supported":
+                     ["tls_client_auth","client_secret_basic","none"],
+     "tls_client_certificate_bound_access_tokens": true,
+     "mtls_endpoint_aliases": {
+       "token_endpoint": "https://mtls.example.com/token",
+       "revocation_endpoint": "https://mtls.example.com/revo",
+       "introspection_endpoint": "https://mtls.example.com/introspect"
+     }
+   }
+
+      Figure 4: Example Authorization Server Metadata with Mutual-TLS
+                              Endpoint Aliases
+
+6.  Implementation Considerations
+
+6.1.  Authorization Server
+
+   The authorization server needs to set up its TLS configuration
+   appropriately for the OAuth client authentication methods it
+   supports.
+
+   An authorization server that supports mutual-TLS client
+   authentication and other client authentication methods or public
+   clients in parallel would make mutual TLS optional (i.e., allowing a
+   handshake to continue after the server requests a client certificate
+   but the client does not send one).
+
+   In order to support the Self-Signed Certificate method alone, the
+   authorization server would configure the TLS stack in such a way that
+   it does not verify whether the certificate presented by the client
+   during the handshake is signed by a trusted CA certificate.
+
+   As described in Section 3, the authorization server binds the issued
+   access token to the TLS client certificate, which means that it will
+   only issue certificate-bound tokens for a certificate that the client
+   has proven possession of the corresponding private key.
+
+   The authorization server may also consider hosting the token endpoint
+   and other endpoints requiring client authentication on a separate
+   host name or port in order to prevent unintended impact on the TLS
+   behavior of its other endpoints, e.g., the authorization endpoint.
+   As described in Section 5, it may further isolate any potential
+   impact of the server requesting client certificates by offering a
+   distinct set of endpoints on a separate host or port, which are
+   aliases for the originals that a client intending to do mutual TLS
+   will use in preference to the conventional endpoints.
+
+6.2.  Resource Server
+
+   OAuth divides the roles and responsibilities such that the resource
+   server relies on the authorization server to perform client
+   authentication and obtain resource-owner (end-user) authorization.
+   The resource server makes authorization decisions based on the access
+   token presented by the client but does not directly authenticate the
+   client per se.  The manner in which an access token is bound to the
+   client certificate and how a protected resource verifies the proof-
+   of-possession decouples that from the specific method that the client
+   used to authenticate with the authorization server.  Mutual TLS
+   during protected resource access can, therefore, serve purely as a
+   proof-of-possession mechanism.  As such, it is not necessary for the
+   resource server to validate the trust chain of the client's
+   certificate in any of the methods defined in this document.  The
+   resource server would, therefore, configure the TLS stack in a way
+   that it does not verify whether the certificate presented by the
+   client during the handshake is signed by a trusted CA certificate.
+
+6.3.  Certificate Expiration and Bound Access Tokens
+
+   As described in Section 3, an access token is bound to a specific
+   client certificate, which means that the same certificate must be
+   used for mutual TLS on protected resource access.  It also implies
+   that access tokens are invalidated when a client updates the
+   certificate, which can be handled similarly to expired access tokens
+   where the client requests a new access token (typically with a
+   refresh token) and retries the protected resource request.
+
+6.4.  Implicit Grant Unsupported
+
+   This document describes binding an access token to the client
+   certificate presented on the TLS connection from the client to the
+   authorization server's token endpoint, however, such binding of
+   access tokens issued directly from the authorization endpoint via the
+   implicit grant flow is explicitly out of scope.  End users interact
+   directly with the authorization endpoint using a web browser, and the
+   use of client certificates in user's browsers bring operational and
+   usability issues that make it undesirable to support certificate-
+   bound access tokens issued in the implicit grant flow.
+   Implementations wanting to employ certificate-bound access tokens
+   should utilize grant types that involve the client making an access
+   token request directly to the token endpoint (e.g., the authorization
+   code and refresh token grant types).
+
+6.5.  TLS Termination
+
+   An authorization server or resource server MAY choose to terminate
+   TLS connections at a load balancer, reverse proxy, or other network
+   intermediary.  How the client certificate metadata is securely
+   communicated between the intermediary and the application server, in
+   this case, is out of scope of this specification.
+
+7.  Security Considerations
+
+7.1.  Certificate-Bound Refresh Tokens
+
+   The OAuth 2.0 Authorization Framework [RFC6749] requires that an
+   authorization server (AS) bind refresh tokens to the client to which
+   they were issued and that confidential clients (those having
+   established authentication credentials with the AS) authenticate to
+   the AS when presenting a refresh token.  As a result, refresh tokens
+   are indirectly certificate-bound by way of the client ID and the
+   associated requirement for (certificate-based) authentication to the
+   AS when issued to clients utilizing the "tls_client_auth" or
+   "self_signed_tls_client_auth" methods of client authentication.
+   Section 4 describes certificate-bound refresh tokens issued to public
+   clients (those without authentication credentials associated with the
+   "client_id").
+
+7.2.  Certificate Thumbprint Binding
+
+   The binding between the certificate and access token specified in
+   Section 3.1 uses a cryptographic hash of the certificate.  It relies
+   on the hash function having sufficient second-preimage resistance so
+   as to make it computationally infeasible to find or create another
+   certificate that produces to the same hash output value.  The SHA-256
+   hash function was used because it meets the aforementioned
+   requirement while being widely available.  If, in the future,
+   certificate thumbprints need to be computed using hash function(s)
+   other than SHA-256, it is suggested that, for additional related JWT
+   confirmation methods, members be defined for that purpose and
+   registered in the IANA "JWT Confirmation Methods" registry
+   [IANA.JWT.Claims] for JWT "cnf" member values.
+
+   Community knowledge about the strength of various algorithms and
+   feasible attacks can change suddenly, and experience shows that a
+   document about security is a point-in-time statement.  Readers are
+   advised to seek out any errata or updates that apply to this
+   document.
+
+7.3.  TLS Versions and Best Practices
+
+   This document is applicable with any TLS version supporting
+   certificate-based client authentication.  Both TLS 1.3 [RFC8446] and
+   TLS 1.2 [RFC5246] are cited herein, because, at the time of writing,
+   1.3 is the newest version, while 1.2 is the most widely deployed.
+   General implementation and security considerations for TLS, including
+   version recommendations, can be found in [BCP195].
+
+   TLS certificate validation (for both client and server certificates)
+   requires a local database of trusted certificate authorities (CAs).
+   Decisions about what CAs to trust and how to make such a
+   determination of trust are out of scope for this document.
+
+7.4.  X.509 Certificate Spoofing
+
+   If the PKI method of client authentication is used, an attacker could
+   try to impersonate a client using a certificate with the same subject
+   (DN or SAN) but issued by a different CA that the authorization
+   server trusts.  To cope with that threat, the authorization server
+   SHOULD only accept, as trust anchors, a limited number of CAs whose
+   certificate issuance policy meets its security requirements.  There
+   is an assumption then that the client and server agree out of band on
+   the set of trust anchors that the server uses to create and validate
+   the certificate chain.  Without this assumption the use of a subject
+   to identify the client certificate would open the server up to
+   certificate spoofing attacks.
+
+7.5.  X.509 Certificate Parsing and Validation Complexity
+
+   Parsing and validation of X.509 certificates and certificate chains
+   is complex, and implementation mistakes have previously exposed
+   security vulnerabilities.  Complexities of validation include (but
+   are not limited to) [CX5P] [DCW] [RFC5280]:
+
+   *  checking of basic constraints, basic and extended key usage
+      constraints, validity periods, and critical extensions;
+
+   *  handling of embedded NUL bytes in ASN.1 counted-length strings and
+      non-canonical or non-normalized string representations in subject
+      names;
+
+   *  handling of wildcard patterns in subject names;
+
+   *  recursive verification of certificate chains and checking
+      certificate revocation.
+
+   For these reasons, implementors SHOULD use an established and well-
+   tested X.509 library (such as one used by an established TLS library)
+   for validation of X.509 certificate chains and SHOULD NOT attempt to
+   write their own X.509 certificate validation procedures.
+
+8.  Privacy Considerations
+
+   In TLS versions prior to 1.3, the client's certificate is sent
+   unencrypted in the initial handshake and can potentially be used by
+   third parties to monitor, track, and correlate client activity.  This
+   is likely of little concern for clients that act on behalf of a
+   significant number of end users because individual user activity will
+   not be discernible amidst the client activity as a whole.  However,
+   clients that act on behalf of a single end user, such as a native
+   application on a mobile device, should use TLS version 1.3 whenever
+   possible or consider the potential privacy implications of using
+   mutual TLS on earlier versions.
+
+9.  IANA Considerations
+
+9.1.  JWT Confirmation Methods Registration
+
+   Per this specification, the following value has been registered in
+   the IANA "JWT Confirmation Methods" registry [IANA.JWT.Claims] for
+   JWT "cnf" member values established by [RFC7800].
+
+   Confirmation Method Value:  "x5t#S256"
+   Confirmation Method Description:  X.509 Certificate SHA-256
+      Thumbprint
+   Change Controller:  IESG
+   Specification Document(s):  Section 3.1 of RFC 8705
+
+9.2.  Authorization Server Metadata Registration
+
+   Per this specification, the following values have been registered in
+   the IANA "OAuth Authorization Server Metadata" registry
+   [IANA.OAuth.Parameters] established by [RFC8414].
+
+   Metadata Name:  "tls_client_certificate_bound_access_tokens"
+   Metadata Description:  Indicates authorization server support for
+      mutual-TLS client certificate-bound access tokens.
+   Change Controller:  IESG
+   Specification Document(s):  Section 3.3 of RFC 8705
+
+   Metadata Name:  "mtls_endpoint_aliases"
+   Metadata Description:  JSON object containing alternative
+      authorization server endpoints, which a client intending to do
+      mutual TLS will use in preference to the conventional endpoints.
+   Change Controller:  IESG
+   Specification Document(s):  Section 5 of RFC 8705
+
+9.3.  Token Endpoint Authentication Method Registration
+
+   Per this specification, the following values have been registered in
+   the IANA "OAuth Token Endpoint Authentication Methods" registry
+   [IANA.OAuth.Parameters] established by [RFC7591].
+
+   Token Endpoint Authentication Method Name:  "tls_client_auth"
+   Change Controller:  IESG
+   Specification Document(s):  Section 2.1.1 of RFC 8705
+
+   Token Endpoint Authentication Method Name:  "self_signed_tls_client_
+      auth"
+   Change Controller:  IESG
+   Specification Document(s):  Section 2.2.1 of RFC 8705
+
+9.4.  Token Introspection Response Registration
+
+   "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)"
+   [RFC7800] defined the "cnf" (confirmation) claim that enables
+   confirmation key information to be carried in a JWT.  However, the
+   same proof-of-possession semantics are also useful for introspected
+   access tokens whereby the protected resource obtains the confirmation
+   key data as metainformation of a token introspection response and
+   uses that information in verifying proof-of-possession.  Therefore,
+   this specification defines and registers proof-of-possession
+   semantics for OAuth 2.0 Token Introspection [RFC7662] using the "cnf"
+   structure.  When included as a top-level member of an OAuth token
+   introspection response, "cnf" has the same semantics and format as
+   the claim of the same name defined in [RFC7800].  While this
+   specification only explicitly uses the "x5t#S256" confirmation method
+   member (see Section 3.2), it needs to define and register the higher-
+   level "cnf" structure as an introspection response member in order to
+   define and use the more specific certificate thumbprint confirmation
+   method.
+
+   As such, the following values have been registered in the IANA "OAuth
+   Token Introspection Response" registry [IANA.OAuth.Parameters]
+   established by [RFC7662].
+
+   Claim Name:  "cnf"
+   Claim Description:  Confirmation
+   Change Controller:  IESG
+   Specification Document(s):  [RFC7800] and RFC 8705
+
+9.5.  Dynamic Client Registration Metadata Registration
+
+   Per this specification, the following client metadata definitions
+   have been registered in the IANA "OAuth Dynamic Client Registration
+   Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]:
+
+   Client Metadata Name:  "tls_client_certificate_bound_access_tokens"
+   Client Metadata Description:  Indicates the client's intention to use
+      mutual-TLS client certificate-bound access tokens.
+   Change Controller:  IESG
+   Specification Document(s):  Section 3.4 of RFC 8705
+
+   Client Metadata Name:  "tls_client_auth_subject_dn"
+   Client Metadata Description:  String value specifying the expected
+      subject DN of the client certificate.
+   Change Controller:  IESG
+   Specification Document(s):  Section 2.1.2 of RFC 8705
+
+   Client Metadata Name:  "tls_client_auth_san_dns"
+   Client Metadata Description:  String value specifying the expected
+      dNSName SAN entry in the client certificate.
+   Change Controller:  IESG
+   Specification Document(s):  Section 2.1.2 of RFC 8705
+
+   Client Metadata Name:  "tls_client_auth_san_uri"
+   Client Metadata Description:  String value specifying the expected
+      uniformResourceIdentifier SAN entry in the client certificate.
+   Change Controller:  IESG
+   Specification Document(s):  Section 2.1.2 of RFC 8705
+
+   Client Metadata Name:  "tls_client_auth_san_ip"
+   Client Metadata Description:  String value specifying the expected
+      iPAddress SAN entry in the client certificate.
+   Change Controller:  IESG
+   Specification Document(s):  Section 2.1.2 of RFC 8705
+
+   Client Metadata Name:  "tls_client_auth_san_email"
+   Client Metadata Description:  String value specifying the expected
+      rfc822Name SAN entry in the client certificate.
+   Change Controller:  IESG
+   Specification Document(s):  Section 2.1.2 of RFC 8705
+
+10.  References
+
+10.1.  Normative References
+
+   [BCP195]   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, May 2015,
+              <https://www.rfc-editor.org/info/bcp195>.
+
+   [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>.
+
+   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+              (LDAP): String Representation of Distinguished Names",
+              RFC 4514, DOI 10.17487/RFC4514, June 2006,
+              <https://www.rfc-editor.org/info/rfc4514>.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+              <https://www.rfc-editor.org/info/rfc4648>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <https://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+   [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>.
+
+   [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>.
+
+   [RFC7662]  Richer, J., Ed., "OAuth 2.0 Token Introspection",
+              RFC 7662, DOI 10.17487/RFC7662, October 2015,
+              <https://www.rfc-editor.org/info/rfc7662>.
+
+   [RFC7800]  Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
+              Possession Key Semantics for JSON Web Tokens (JWTs)",
+              RFC 7800, DOI 10.17487/RFC7800, April 2016,
+              <https://www.rfc-editor.org/info/rfc7800>.
+
+   [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>.
+
+   [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>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [SHS]      National Institute of Standards and Technology (NIST),
+              "Secure Hash Standard (SHS)", FIPS PUB 180-4,
+              DOI 10.6028/NIST.FIPS.180-4, August 2015,
+              <https://nvlpubs.nist.gov/nistpubs/FIPS/
+              NIST.FIPS.180-4.pdf>.
+
+   [X690]     ITU-T, "Information Technology - ASN.1 encoding rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER)", ITU-T Recommendation X.690, August 2015.
+
+10.2.  Informative References
+
+   [CX5P]     Wong, D., "Common x509 certificate validation/creation
+              pitfalls", September 2016,
+              <https://www.cryptologie.net/article/374/common-x509-
+              certificate-validationcreation-pitfalls>.
+
+   [DCW]      Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
+              D., and V. Shmatikov, "The Most Dangerous Code in the
+              World: Validating SSL Certificates in Non-Browser
+              Software", DOI 10.1145/2382196.2382204, October 2012,
+              <http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf>.
+
+   [IANA.JWT.Claims]
+              IANA, "JSON Web Token Claims",
+              <https://www.iana.org/assignments/jwt>.
+
+   [IANA.OAuth.Parameters]
+              IANA, "OAuth Parameters",
+              <https://www.iana.org/assignments/oauth-parameters>.
+
+   [OpenID.CIBA]
+              Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B.
+              Campbell, "OpenID Connect Client Initiated Backchannel
+              Authentication Flow - Core 1.0", 16 January 2019,
+              <https://openid.net/specs/openid-client-initiated-
+              backchannel-authentication-core-1_0.html>.
+
+   [RFC4517]  Legg, S., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Syntaxes and Matching Rules", RFC 4517,
+              DOI 10.17487/RFC4517, June 2006,
+              <https://www.rfc-editor.org/info/rfc4517>.
+
+   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
+              Address Text Representation", RFC 5952,
+              DOI 10.17487/RFC5952, August 2010,
+              <https://www.rfc-editor.org/info/rfc5952>.
+
+   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
+              Extensions: Extension Definitions", RFC 6066,
+              DOI 10.17487/RFC6066, January 2011,
+              <https://www.rfc-editor.org/info/rfc6066>.
+
+   [RFC7009]  Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
+              2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
+              August 2013, <https://www.rfc-editor.org/info/rfc7009>.
+
+   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
+              DOI 10.17487/RFC7518, May 2015,
+              <https://www.rfc-editor.org/info/rfc7518>.
+
+   [TOKEN]    Jones, M., Campbell, B., Bradley, J., and W. Denniss,
+              "OAuth 2.0 Token Binding", Work in Progress, Internet-
+              Draft, draft-ietf-oauth-token-binding-08, 19 October 2018,
+              <https://tools.ietf.org/html/draft-ietf-oauth-token-
+              binding-08>.
+
+Appendix A.  Example "cnf" Claim, Certificate, and JWK
+
+   For reference, an "x5t#S256" value and the X.509 certificate from
+   which it was calculated are provided in the following examples,
+   Figures 5 and 6, respectively.  A JWK representation of the
+   certificate's public key along with the "x5c" member is also provided
+   in Figure 7.
+
+   "cnf":{"x5t#S256":"A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"}
+
+                   Figure 5: x5t#S256 Confirmation Claim
+
+   -----BEGIN CERTIFICATE-----
+   MIIBBjCBrAIBAjAKBggqhkjOPQQDAjAPMQ0wCwYDVQQDDARtdGxzMB4XDTE4MTAx
+   ODEyMzcwOVoXDTIyMDUwMjEyMzcwOVowDzENMAsGA1UEAwwEbXRsczBZMBMGByqG
+   SM49AgEGCCqGSM49AwEHA0IABNcnyxwqV6hY8QnhxxzFQ03C7HKW9OylMbnQZjjJ
+   /Au08/coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8wCgYIKoZIzj0EAwID
+   SQAwRgIhAP0RC1E+vwJD/D1AGHGzuri+hlV/PpQEKTWUVeORWz83AiEA5x2eXZOV
+   bUlJSGQgjwD5vaUaKlLR50Q2DmFfQj1L+SY=
+   -----END CERTIFICATE-----
+
+               Figure 6: PEM Encoded Self-Signed Certificate
+
+   {
+    "kty":"EC",
+    "x":"1yfLHCpXqFjxCeHHHMVDTcLscpb07KUxudBmOMn8C7Q",
+    "y":"8_coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8",
+    "crv":"P-256",
+    "x5c":[
+     "MIIBBjCBrAIBAjAKBggqhkjOPQQDAjAPMQ0wCwYDVQQDDARtdGxzMB4XDTE4MTA
+      xODEyMzcwOVoXDTIyMDUwMjEyMzcwOVowDzENMAsGA1UEAwwEbXRsczBZMBMGBy
+      qGSM49AgEGCCqGSM49AwEHA0IABNcnyxwqV6hY8QnhxxzFQ03C7HKW9OylMbnQZ
+      jjJ/Au08/coZwxS7LfA4vOLS9WuneIXhbGGWvsDSb0tH6IxLm8wCgYIKoZIzj0E
+      AwIDSQAwRgIhAP0RC1E+vwJD/D1AGHGzuri+hlV/PpQEKTWUVeORWz83AiEA5x2
+      eXZOVbUlJSGQgjwD5vaUaKlLR50Q2DmFfQj1L+SY="
+      ]
+    }
+
+                           Figure 7: JSON Web Key
+
+Appendix B.  Relationship to Token Binding
+
+   OAuth 2.0 Token Binding [TOKEN] enables the application of Token
+   Binding to the various artifacts and tokens employed throughout
+   OAuth.  That includes binding of an access token to a Token Binding
+   key, which bears some similarities in motivation and design to the
+   mutual-TLS client certificate-bound access tokens defined in this
+   document.  Both documents define what is often called a proof-of-
+   possession security mechanism for access tokens, whereby a client
+   must demonstrate possession of cryptographic keying material when
+   accessing a protected resource.  The details differ somewhat between
+   the two documents but both have the authorization server bind the
+   access token that it issues to an asymmetric key pair held by the
+   client.  The client then proves possession of the private key from
+   that pair with respect to the TLS connection over which the protected
+   resource is accessed.
+
+   Token Binding uses bare keys that are generated on the client, which
+   avoids many of the difficulties of creating, distributing, and
+   managing certificates used in this specification.  However, at the
+   time of writing, Token Binding is fairly new, and there is relatively
+   little support for it in available application development platforms
+   and tooling.  Until better support for the underlying core Token
+   Binding specifications exists, practical implementations of OAuth 2.0
+   Token Binding are infeasible.  Mutual TLS, on the other hand, has
+   been around for some time and enjoys widespread support in web
+   servers and development platforms.  As a consequence, OAuth 2.0
+   Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
+   can be built and deployed now using existing platforms and tools.  In
+   the future, the two specifications are likely to be deployed in
+   parallel for solving similar problems in different environments.
+   Authorization servers may even support both specifications
+   simultaneously using different proof-of-possession mechanisms for
+   tokens issued to different clients.
+
+Acknowledgements
+
+   Scott "not Tomlinson" Tomilson and Matt Peterson were involved in
+   design and development work on a mutual-TLS OAuth client
+   authentication implementation that predates this document.
+   Experience and learning from that work informed some of the content
+   of this document.
+
+   This specification was developed within the OAuth Working Group under
+   the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with
+   Eric Rescorla, Benjamin Kaduk, and Roman Danyliw serving as Security
+   Area Directors.  Additionally, the following individuals contributed
+   ideas, feedback, and wording that helped shape this specification:
+   Vittorio Bertocci, Sergey Beryozkin, Ralph Bragg, Sophie Bremer,
+   Roman Danyliw, Vladimir Dzhuvinov, Samuel Erdtman, Evan Gilman, Leif
+   Johansson, Michael Jones, Phil Hunt, Benjamin Kaduk, Takahiko
+   Kawasaki, Sean Leonard, Kepeng Li, Neil Madden, James Manger, Jim
+   Manico, Nov Matake, Sascha Preibisch, Eric Rescorla, Justin Richer,
+   Vincent Roca, Filip Skokan, Dave Tonge, and Hannes Tschofenig.
+
+Authors' Addresses
+
+   Brian Campbell
+   Ping Identity
+
+   Email: brian.d.campbell@gmail.com
+
+
+   John Bradley
+   Yubico
+
+   Email: ve7jtb@ve7jtb.com
+   URI:   http://www.thread-safe.com/
+
+
+   Nat Sakimura
+   Nomura Research Institute
+
+   Email: n-sakimura@nri.co.jp
+   URI:   https://nat.sakimura.org/
+
+
+   Torsten Lodderstedt
+   YES.com AG
+
+   Email: torsten@lodderstedt.net