draft-ietf-oauth-mtls-07.txt		draft-ietf-oauth-mtls-08.txt
	OAuth Working Group B. Campbell		OAuth Working Group B. Campbell
	Internet-Draft Ping Identity		Internet-Draft Ping Identity
	Intended status: Standards Track J. Bradley		Intended status: Standards Track J. Bradley
	Expires: August 2, 2018 Yubico		Expires: November 7, 2018 Yubico
	N. Sakimura		N. Sakimura
	Nomura Research Institute		Nomura Research Institute
	T. Lodderstedt		T. Lodderstedt
	YES Europe AG		YES Europe AG
	January 29, 2018		May 6, 2018
	OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access		OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access
	Tokens		Tokens
	draft-ietf-oauth-mtls-07		draft-ietf-oauth-mtls-08
	Abstract		Abstract
	This document describes Transport Layer Security (TLS) mutual		This document describes OAuth client authentication and certificate
	authentication using X.509 certificates as a mechanism for OAuth		bound access tokens using mutual Transport Layer Security (TLS)
	client authentication to the authorization sever as well as for		authentication with X.509 certificates. OAuth clients are provided a
	certificate bound sender constrained access tokens as a method for a		mechanism for authentication to the authorization sever using mutual
	protected resource to ensure that an access token presented to it by		TLS, based on either single certificates or public key infrastructure
	a given client was issued to that client by the authorization server.		(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		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 2, 2018.		This Internet-Draft will expire on November 7, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Notation and Conventions . . . . . . . . . . 3		1.1. Requirements Notation and Conventions . . . . . . . . . . 4
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Mutual TLS for OAuth Client Authentication . . . . . . . . . 4		2. Mutual TLS for OAuth Client Authentication . . . . . . . . . 4
	2.1. PKI Mutual TLS OAuth Client Authentication Method . . . . 5		2.1. PKI Mutual TLS OAuth Client Authentication Method . . . . 5
	2.1.1. PKI Authentication Method Metadata Value . . . . . . 5		2.1.1. PKI Authentication Method Metadata Value . . . . . . 5
	2.1.2. Client Registration Metadata . . . . . . . . . . . . 5		2.1.2. Client Registration Metadata . . . . . . . . . . . . 5
	2.2. Self-Signed Certificate Mutual TLS OAuth Client		2.2. Self-Signed Certificate Mutual TLS OAuth Client
	Authentication Method . . . . . . . . . . . . . . . . . . 6		Authentication Method . . . . . . . . . . . . . . . . . . 6
	2.2.1. Self-Signed Certificate Authentication Method		2.2.1. Self-Signed Certificate Authentication Method
	Metadata Value . . . . . . . . . . . . . . . . . . . 6		Metadata Value . . . . . . . . . . . . . . . . . . . 6
	2.2.2. Client Registration Metadata . . . . . . . . . . . . 6		2.2.2. Client Registration Metadata . . . . . . . . . . . . 6
	3. Mutual TLS Sender Constrained Resources Access . . . . . . . 7		3. Mutual TLS Client Certificate Bound Access Tokens . . . . . . 7
	3.1. X.509 Certificate Thumbprint Confirmation Method for JWT 7		3.1. X.509 Certificate Thumbprint Confirmation Method for JWT 7
	3.2. Confirmation Method for Token Introspection . . . . . . . 8		3.2. Confirmation Method for Token Introspection . . . . . . . 8
	3.3. Authorization Server Metadata . . . . . . . . . . . . . . 9		3.3. Authorization Server Metadata . . . . . . . . . . . . . . 9
	3.4. Client Registration Metadata . . . . . . . . . . . . . . 9		3.4. Client Registration Metadata . . . . . . . . . . . . . . 10
	4. Implementation Considerations . . . . . . . . . . . . . . . . 10		4. Implementation Considerations . . . . . . . . . . . . . . . . 10
	4.1. Authorization Server . . . . . . . . . . . . . . . . . . 10		4.1. Authorization Server . . . . . . . . . . . . . . . . . . 10
	4.2. Resource Server . . . . . . . . . . . . . . . . . . . . . 10		4.2. Resource Server . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Sender Constrained Access Tokens Without Client		4.3. Certificate Bound Access Tokens Without Client
	Authentication . . . . . . . . . . . . . . . . . . . . . 10		Authentication . . . . . . . . . . . . . . . . . . . . . 10
	4.4. Certificate Bound Access Tokens . . . . . . . . . . . . . 11		4.4. Certificate Bound Access Tokens . . . . . . . . . . . . . 11
	4.5. Implicit Grant Unsupported . . . . . . . . . . . . . . . 11		4.5. Implicit Grant Unsupported . . . . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		4.6. TLS Termination . . . . . . . . . . . . . . . . . . . . . 12
	5.1. TLS Versions and Best Practices . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
			5.1. TLS Versions and Best Practices . . . . . . . . . . . . . 12
	5.2. X.509 Certificate Spoofing . . . . . . . . . . . . . . . 12		5.2. X.509 Certificate Spoofing . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		5.3. X.509 Certificate Parsing and Validation Complexity . . . 12
	6.1. JWT Confirmation Methods Registration . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	6.2. OAuth Authorization Server Metadata Registration . . . . 12		6.1. JWT Confirmation Methods Registration . . . . . . . . . . 13
	6.3. Token Endpoint Authentication Method Registration . . . . 12		6.2. OAuth Authorization Server Metadata Registration . . . . 13
	6.4. OAuth Token Introspection Response Registration . . . . . 13		6.3. Token Endpoint Authentication Method Registration . . . . 13
	6.5. OAuth Dynamic Client Registration Metadata Registration . 13		6.4. OAuth Token Introspection Response Registration . . . . . 14
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		6.5. OAuth Dynamic Client Registration Metadata Registration . 14
	7.1. Normative References . . . . . . . . . . . . . . . . . . 13		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
			7.1. Normative References . . . . . . . . . . . . . . . . . . 14
	7.2. Informative References . . . . . . . . . . . . . . . . . 15		7.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. Relationship to Token Binding . . . . . . . . . . . 16		Appendix A. Relationship to Token Binding . . . . . . . . . . . 17
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17
	Appendix C. Document(s) History . . . . . . . . . . . . . . . . 17		Appendix C. Document(s) History . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	This document describes Transport Layer Security (TLS) mutual		This document describes OAuth client authentication and certificate
	authentication using X.509 certificates as a mechanism for OAuth		bound access tokens using mutual TLS [RFC5246] authentication with
	client authentication to the authorization sever as well as for		X.509 certificates. OAuth clients are provided mechanisms for
	sender constrained access to OAuth protected resources.		authentication to the authorization sever using mutual TLS. 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.
	The OAuth 2.0 Authorization Framework [RFC6749] defines a shared		The OAuth 2.0 Authorization Framework [RFC6749] defines a shared
	secret method of client authentication but also allows for the		secret method of client authentication but also allows for the
	definition and use of additional client authentication mechanisms		definition and use of additional client authentication mechanisms
	when interacting directly with the authorization server. This		when interacting directly with the authorization server. This
	document describes an additional mechanism of client authentication		document describes an additional mechanism of client authentication
	utilizing mutual TLS [RFC5246] certificate-based authentication,		utilizing mutual TLS certificate-based authentication, which provides
	which provides better security characteristics than shared secrets.		better security characteristics than shared secrets. While [RFC6749]
	While [RFC6749] documents client authentication for requests to the		documents client authentication for requests to the token endpoint,
	token endpoint, extensions to OAuth 2.0 (such as Introspection		extensions to OAuth 2.0 (such as Introspection [RFC7662] and
	[RFC7662] and Revocation [RFC7009]) define endpoints that also		Revocation [RFC7009]) define endpoints that also utilize client
	utilize client authentication and the mutual TLS methods defined		authentication and the mutual TLS methods defined herein are
	herein are applicable to those endpoints as well.		applicable to those endpoints as well.
	Mutual TLS sender constrained access to protected resources ensures		Mutual TLS certificate bound access tokens ensure that only the party
	that only the party in possession of the private key corresponding to		in possession of the private key corresponding to the certificate can
	the certificate can utilize the access token to get access to the		utilize the token to access the associated resources. Such a
	associated resources. Such a constraint is unlike the case of the		constraint is sometimes referred to as key confirmation, proof-of-
	basic bearer token described in [RFC6750], where any party in		possession, or holder-of-key and is unlike the case of the bearer
	possession of the access token can use it to access the associated		token described in [RFC6750], where any party in possession of the
	resources. Mutual TLS sender constrained access binds the access		access token can use it to access the associated resources. Binding
	token to the client's certificate thus preventing the use of stolen		an access token to the client's certificate prevents the use of
	access tokens or replay of access tokens by unauthorized parties.		stolen access tokens or replay of access tokens by unauthorized
			parties.
	Mutual TLS sender constrained access tokens and mutual TLS client		Mutual TLS certificate bound access tokens and mutual TLS client
	authentication are distinct mechanisms, which are complementary but		authentication are distinct mechanisms, which are complementary but
	don't necessarily need to be deployed together.		don't necessarily need to be deployed or used together.
	1.1. Requirements Notation and Conventions		1.1. Requirements Notation and Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	1.2. Terminology		1.2. Terminology
	This specification uses the following phrases interchangeably:		Mutual TLS refers to the process whereby a client presents its X.509
			certificate and proves possession of the corresponding private key to
	Transport Layer Security (TLS) Mutual Authentication		a server when negotiating a TLS session. In TLS 1.2 [RFC5246] this
			requires the client to send Client Certificate and Certificate Verify
	Mutual TLS		messages during the TLS handshake and for the server to verify these
			messages.
	These phrases all refer to the process whereby a client presents its
	X.509 certificate and proves possession of the corresponding private
	key to a server when negotiating a TLS session. In TLS 1.2 [RFC5246]
	this requires the client to send Client Certificate and Certificate
	Verify messages during the TLS handshake and for the server to verify
	these messages.
	2. Mutual TLS for OAuth Client Authentication		2. Mutual TLS for OAuth Client Authentication
	This section defines, as an extension of OAuth 2.0, Section 2.3		This section defines, as an extension of OAuth 2.0, Section 2.3
	[RFC6749], two distinct methods of using mutual TLS X.509 client		[RFC6749], two distinct methods of using mutual TLS X.509 client
	certificates as client credentials. The requirement of mutual TLS		certificates as client credentials. The requirement of mutual TLS
	for client authentication is determined by the authorization server		for client authentication is determined by the authorization server
	based on policy or configuration for the given client (regardless of		based on policy or configuration for the given client (regardless of
	whether the client was dynamically registered or statically		whether the client was dynamically registered, statically configured,
	configured or otherwise established).		or otherwise established).
	In order to utilize TLS for OAuth client authentication, the TLS		In order to utilize TLS for OAuth client authentication, the TLS
	connection between the client and the authorization server MUST have		connection between the client and the authorization server MUST have
	been established or reestablished with mutual X.509 certificate		been established or reestablished with mutual TLS X.509 certificate
	authentication (i.e. the Client Certificate and Certificate Verify		authentication (i.e. the Client Certificate and Certificate Verify
	messages are sent during the TLS Handshake [RFC5246]).		messages are sent during the TLS Handshake [RFC5246]).
	For all requests to the authorization server utilizing mutual TLS		For all requests to the authorization server utilizing mutual TLS
	client authentication, the client MUST include the "client_id"		client authentication, the client MUST include the "client_id"
	parameter, described in OAuth 2.0, Section 2.2 [RFC6749]. The		parameter, described in OAuth 2.0, Section 2.2 [RFC6749]. The
	presence of the "client_id" parameter enables the authorization		presence of the "client_id" parameter enables the authorization
	server to easily identify the client independently from the content		server to easily identify the client independently from the content
	of the certificate. The authorization server can locate the client		of the certificate. The authorization server can locate the client
	configuration using the client identifier and check the certificate		configuration using the client identifier and check the certificate
	presented in the TLS Handshake against the expected credentials for		presented in the TLS Handshake against the expected credentials for
	that client. The authorization server MUST enforce some method of		that client. The authorization server MUST enforce the binding of a
	binding a certificate to a client. Sections Section 2.1 and		certificate to a specific client as described in either Section 2.1
	Section 2.2 below define two ways of binding a certificate to a		or Section 2.2 below.
	client as two distinct client authentication methods.
	2.1. PKI Mutual TLS OAuth Client Authentication Method		2.1. PKI Mutual TLS OAuth Client Authentication Method
	The PKI (public key infrastructure) method of mutual TLS OAuth client		The PKI (public key infrastructure) method of mutual TLS OAuth client
	authentication uses a subject distinguished name (DN) and validated		authentication uses a subject distinguished name (DN) and validated
	certificate chain to identify the client. The TLS handshake is		certificate chain to identify the client. The TLS handshake is
	utilized to validate the client's possession of the private key		utilized to validate the client's possession of the private key
	corresponding to the public key in the certificate and to validate		corresponding to the public key in the certificate and to validate
	the corresponding certificate chain. The client is successfully		the corresponding certificate chain. The client is successfully
	authenticated if the subject information in the certificate matches		authenticated if the subject information in the certificate matches
	the expected DN configured or registered for that particular client.		the expected DN configured or registered for that particular client
	The PKI method facilitates the way X.509 certificates are		(note that a predictable treatment of DN values, such as the
	traditionally being used for authentication. It also allows the		distinguishedNameMatch rule from [RFC4517], is needed in comparing
	client to rotate its X.509 certificates without the need to modify		the certificate's subject DN to the client's registered DN). If and
	its respective authentication data at the authorization server by		how to check a certificate's revocation status is a deployment
	obtaining a new certificate with the same subject DN from a trusted		decision at the discretion of the authorization server. The PKI
	certificate authority (CA).		method facilitates the way X.509 certificates are traditionally being
			used for authentication. It also allows the client to rotate its
			X.509 certificates without the need to modify its respective
			authentication data at the authorization server by obtaining a new
			certificate with the same subject DN from a trusted certificate
			authority (CA).
	2.1.1. PKI Authentication Method Metadata Value		2.1.1. PKI Authentication Method Metadata Value
	The "OAuth Token Endpoint Authentication Methods" registry		For the PKI method of mutual TLS client authentication, this
	[IANA.OAuth.Parameters] contains values, each of which specify a		specification defines and registers the following authentication
	method of authenticating a client to the authorization server. The		method metadata value into the "OAuth Token Endpoint Authentication
	values are used to indicate supported and utilized client		Methods" registry [IANA.OAuth.Parameters].
	authentication methods in authorization server metadata, such as
	OpenID Connect Discovery [OpenID.Discovery] and OAuth 2.0
	Authorization Server Metadata [I-D.ietf-oauth-discovery], and in the
	OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. For the
	PKI method of mutual TLS client authentication, this specification
	defines and registers the following authentication method metadata
	value.
	tls_client_auth		tls_client_auth
	Indicates that client authentication to the authorization server		Indicates that client authentication to the authorization server
	will occur with mutual TLS utilizing the PKI method of associating		will occur with mutual TLS utilizing the PKI method of associating
	a certificate to a client.		a certificate to a client.
	2.1.2. Client Registration Metadata		2.1.2. Client Registration Metadata
	The following metadata parameter is introduced for the OAuth 2.0		The following metadata parameter is introduced for the OAuth 2.0
	Dynamic Client Registration Protocol [RFC7591] in support of the PKI		Dynamic Client Registration Protocol [RFC7591] in support of the PKI
	skipping to change at page 6, line 11 ¶		skipping to change at page 6, line 11 ¶
	An [RFC4514] string representation of the expected subject		An [RFC4514] string representation of the expected subject
	distinguished name of the certificate the OAuth client will use in		distinguished name of the certificate the OAuth client will use in
	mutual TLS authentication.		mutual TLS authentication.
	2.2. Self-Signed Certificate Mutual TLS OAuth Client Authentication		2.2. Self-Signed Certificate Mutual TLS OAuth Client Authentication
	Method		Method
	This method of mutual TLS OAuth client authentication is intended to		This method of mutual TLS OAuth client authentication is intended to
	support client authentication using self-signed certificates. As		support client authentication using self-signed certificates. As
	pre-requisite, the client registers an X.509 certificate or a trusted		pre-requisite, the client registers an X.509 certificate or a trusted
	source for its X.509 certificates (such as the "jwks_uri" as defined		source for its X.509 certificates (such as the "jwks_uri" defined in
	in [RFC7591]) with the authorization server. During authentication,		[RFC7591] that references a JSON Web Key [RFC7517] Set containing the
	TLS is utilized to validate the client's possession of the private		client's certificates and public keys) with the authorization server.
	key corresponding to the public key presented within the certificate		During authentication, TLS is utilized to validate the client's
	in the respective TLS handshake. In contrast to the PKI method, the		possession of the private key corresponding to the public key
	certificate chain is not validated in this case. The client is		presented within the certificate in the respective TLS handshake. In
	successfully authenticated, if the subject public key info of the		contrast to the PKI method, the client's certificate chain is not
	certificate matches the subject public key info of one of the		validated by the server in this case. The client is successfully
	certificates configured or registered for that particular client.		authenticated if the subject public key info of the certificate
	The Self-Signed Certificate method allows to use mutual TLS to		matches the subject public key info of one of the certificates
	authenticate clients without the need to maintain a PKI. When used		configured or registered for that particular client. The Self-Signed
	in conjunction with a "jwks_uri" for the client, it also allows the		Certificate method allows to use mutual TLS to authenticate clients
	client to rotate its X.509 certificates without the need to change		without the need to maintain a PKI. When used in conjunction with a
	its respective authentication data directly with the authorization		"jwks_uri" for the client, it also allows the client to rotate its
	server.		X.509 certificates without the need to change its respective
			authentication data directly with the authorization server.
	2.2.1. Self-Signed Certificate Authentication Method Metadata Value		2.2.1. Self-Signed Certificate Authentication Method Metadata Value
	The "OAuth Token Endpoint Authentication Methods" registry		For the Self-Signed Certificate method of mutual TLS client
	[IANA.OAuth.Parameters] contains values, each of which specify a		authentication, this specification defines and registers the
	method of authenticating a client to the authorization server. The		following authentication method metadata value into the "OAuth Token
	values are used to indicate supported and utilized client		Endpoint Authentication Methods" registry [IANA.OAuth.Parameters].
	authentication methods in authorization server metadata, such as
	OpenID Connect Discovery [OpenID.Discovery] and OAuth 2.0
	Authorization Server Metadata [I-D.ietf-oauth-discovery], and in the
	OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. For the
	Self-Signed Certificate method of binding a certificate to a client
	using mutual TLS client authentication, this specification defines
	and registers the following authentication method metadata value.
	self_signed_tls_client_auth		self_signed_tls_client_auth
	Indicates that client authentication to the authorization server		Indicates that client authentication to the authorization server
	will occur using mutual TLS with the client utilizing a self-		will occur using mutual TLS with the client utilizing a self-
	signed certificate.		signed certificate.
	2.2.2. Client Registration Metadata		2.2.2. Client Registration Metadata
	For the Self-Signed Certificate method of binding a certificate to a		For the Self-Signed Certificate method of binding a certificate to a
	client using mutual TLS client authentication, the existing		client using mutual TLS client authentication, the existing
	"jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to		"jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to
	convey the client's certificates and public keys, where the X.509		convey the client's certificates and public keys, where the X.509
	certificates are represented using the JSON Web Key (JWK) [RFC7517]		certificates are represented using the JSON Web Key (JWK) [RFC7517]
	"x5c" parameter (note that Sec 4.7 of RFC 7517 requires that the key		"x5c" parameter (note that Sec 4.7 of RFC 7517 requires that the key
	in the first certificate of the "x5c" parameter must match the public		in the first certificate of the "x5c" parameter must match the public
	key represented by other members of the JWK).		key represented by other members of the JWK).
	3. Mutual TLS Sender Constrained Resources Access		3. Mutual TLS Client Certificate Bound Access Tokens
	When mutual TLS is used by the client on the connection to the token		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		endpoint, the authorization server is able to bind the issued access
	token to the client certificate. Such a binding is accomplished by		token to the client certificate. Such a binding is accomplished by
	associating the certificate with the token in a way that can be		associating the certificate with the token in a way that can be
	accessed by the protected resource, such as embedding the certificate		accessed by the protected resource, such as embedding the certificate
	hash in the issued access token directly, using the syntax described		hash in the issued access token directly, using the syntax described
	in Section 3.1, or through token introspection as described in		in Section 3.1, or through token introspection as described in
	Section 3.2. Other methods of associating a certificate with an		Section 3.2. Binding the access token to the client certificate in
	access token are possible, per agreement by the authorization server		that fashion has the benefit of decoupling that binding from the
	and the protected resource, but are beyond the scope of this		client's authentication with the authorization server, which enables
	specification.		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.
	The client makes protected resource requests as described in		The client makes protected resource requests as described in
	[RFC6750], however, those requests MUST be made over a mutually		[RFC6750], however, those requests MUST be made over a mutually
	authenticated TLS connection using the same certificate that was used		authenticated TLS connection using the same certificate that was used
	for mutual TLS at the token endpoint.		for mutual TLS at the token endpoint.
	The protected resource MUST obtain the client certificate used for		The protected resource MUST obtain the client certificate used for
	mutual TLS authentication and MUST verify that the certificate		mutual TLS authentication and MUST verify that the certificate
	matches the certificate associated with the access token. If they do		matches the certificate associated with the access token. If they do
	not match, the resource access attempt MUST be rejected with an error		not match, the resource access attempt MUST be rejected with an error
	per [RFC6750] using an HTTP 401 status code and the "invalid_token"		per [RFC6750] using an HTTP 401 status code and the "invalid_token"
	error code.		error code.
	Metadata to convey server and client capabilities for mutual TLS		Metadata to convey server and client capabilities for mutual TLS
	sender constrained access tokens is defined in Section 3.3 and		client certificate bound access tokens is defined in Section 3.3 and
	Section 3.4 respectively.		Section 3.4 respectively.
	3.1. X.509 Certificate Thumbprint Confirmation Method for JWT		3.1. X.509 Certificate Thumbprint Confirmation Method for JWT
	When access tokens are represented as JSON Web Tokens (JWT)[RFC7519],		When access tokens are represented as JSON Web Tokens (JWT)[RFC7519],
	the certificate hash information SHOULD be represented using the		the certificate hash information SHOULD be represented using the
	"x5t#S256" confirmation method member defined herein.		"x5t#S256" confirmation method member defined herein.
	To represent the hash of a certificate in a JWT, this specification		To represent the hash of a certificate in a JWT, this specification
	defines the new JWT Confirmation Method RFC 7800 [RFC7800] member		defines the new JWT Confirmation Method [RFC7800] member "x5t#S256"
	"x5t#S256" for the X.509 Certificate SHA-256 Thumbprint. The value		for the X.509 Certificate SHA-256 Thumbprint. The value of the
	of the "x5t#S256" member is a base64url-encoded SHA-256[SHS] hash		"x5t#S256" member is the SHA-256[SHS] hash (a.k.a. thumbprint,
	(a.k.a. thumbprint or digest) of the DER encoding of the X.509		fingerprint or digest) of the DER encoding of the X.509 certificate
	certificate[RFC5280] (note that certificate thumbprints are also		[RFC5280] base64url-encoded [RFC4648] with with all trailing pad '='
	sometimes known as certificate fingerprints).		characters omitted and without the inclusion of any line breaks,
			whitespace, or other additional characters.
	The following is an example of a JWT payload containing an "x5t#S256"		The following is an example of a JWT payload containing an "x5t#S256"
	certificate thumbprint confirmation method.		certificate thumbprint confirmation method.
	{		{
	"iss": "https://server.example.com",		"iss": "https://server.example.com",
	"sub": "ty.webb@example.com",		"sub": "ty.webb@example.com",
	"exp": 1493726400,		"exp": 1493726400,
	"nbf": 1493722800,		"nbf": 1493722800,
	"cnf":{		"cnf":{
	"x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"		"x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
	}		}
	}		}
	Figure 1: Example claims of a Certificate Thumbprint Constrained JWT		Figure 1: Example JWT Claims Set with an X.509 Certificate Thumbprint
			Confirmation Method
	If, in the future, certificate thumbprints need to be computed using		If, in the future, certificate thumbprints need to be computed using
	hash functions other than SHA-256, it is suggested that additional		hash functions other than SHA-256, it is suggested that additional
	related JWT confirmation methods members be defined for that purpose.		related JWT confirmation methods members be defined for that purpose.
	For example, a new "x5t#S512" (X.509 Certificate Thumbprint using		For example, a new "x5t#S512" (X.509 Certificate Thumbprint using
	SHA-512) confirmation method member could be defined by registering		SHA-512) confirmation method member could be defined by registering
	it in the the IANA "JWT Confirmation Methods" registry		it in the the IANA "JWT Confirmation Methods" registry
	[IANA.JWT.Claims] for JWT "cnf" member values established by		[IANA.JWT.Claims] for JWT "cnf" member values established by
	[RFC7800].		[RFC7800].
	3.2. Confirmation Method for Token Introspection		3.2. Confirmation Method for Token Introspection
	OAuth 2.0 Token Introspection [RFC7662] defines a method for a		OAuth 2.0 Token Introspection [RFC7662] defines a method for a
	protected resource to query an authorization server about the active		protected resource to query an authorization server about the active
	state of an access token as well as to determine meta-information		state of an access token as well as to determine meta-information
	about the token.		about the token.
	For a mutual TLS sender constrained access token, the hash of the		For a mutual TLS client certificate bound access token, the hash of
	certificate to which the token is bound is conveyed to the protected		the certificate to which the token is bound is conveyed to the
	resource as meta-information in a token introspection response. The		protected resource as meta-information in a token introspection
	hash is conveyed using the same structure as the certificate SHA-256		response. The hash is conveyed using the same structure as the
	thumbprint confirmation method, described in Section 3.1, as a top-		certificate SHA-256 thumbprint confirmation method, described in
	level member of the introspection response JSON. The protected		Section 3.1, as a top-level member of the introspection response
	resource compares that certificate hash to a hash of the client		JSON. The protected resource compares that certificate hash to a
	certificate used for mutual TLS authentication and rejects the		hash of the client certificate used for mutual TLS authentication and
	request, if they do not match.		rejects the request, if they do not match.
	Proof-of-Possession Key Semantics for JSON Web Tokens [RFC7800]		Proof-of-Possession Key Semantics for JSON Web Tokens [RFC7800]
	defined the "cnf" (confirmation) claim, which enables confirmation		defined the "cnf" (confirmation) claim, which enables confirmation
	key information to be carried in a JWT. However, the same proof-of-		key information to be carried in a JWT. However, the same proof-of-
	possession semantics are also useful for introspected access tokens		possession semantics are also useful for introspected access tokens
	whereby the protected resource obtains the confirmation key data as		whereby the protected resource obtains the confirmation key data as
	meta-information of a token introspection response and uses that		meta-information of a token introspection response and uses that
	information in verifying proof-of-possession. Therefore this		information in verifying proof-of-possession. Therefore this
	specification defines and registers proof-of-possession semantics for		specification defines and registers proof-of-possession semantics for
	OAuth 2.0 Token Introspection [RFC7662] using the "cnf" structure.		OAuth 2.0 Token Introspection [RFC7662] using the "cnf" structure.
	When included as a top-level member of an OAuth token introspection		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		response, "cnf" has the same semantics and format as the claim of the
	same name defined in [RFC7800]. While this specification only		same name defined in [RFC7800]. While this specification only
	explicitly uses the "x5t#S256" confirmation method member, it needed		explicitly uses the "x5t#S256" confirmation method member, it needed
	to define and register the higher level "cnf" structure as an		to define and register the higher level "cnf" structure as an
	introspection response member in order to define and use its more		introspection response member in order to define and use the more
	specific "x5t#S256" confirmation method.		specific certificate thumbprint confirmation method.
	The following is an example of an introspection response for an		The following is an example of an introspection response for an
	active token with an "x5t#S256" certificate thumbprint confirmation		active token with an "x5t#S256" certificate thumbprint confirmation
	method.		method.
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	{		{
	"active": true,		"active": true,
	"iss": "https://server.example.com",		"iss": "https://server.example.com",
	"sub": "ty.webb@example.com",		"sub": "ty.webb@example.com",
	"exp": 1493726400,		"exp": 1493726400,
	"nbf": 1493722800,		"nbf": 1493722800,
	"cnf":{		"cnf":{
	"x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"		"x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
	}		}
	}		}
	Figure 2: Example Introspection Response for a Certificate		Figure 2: Example Introspection Response for a Certificate Bound
	Constrained Access Token		Access Token
	3.3. Authorization Server Metadata		3.3. Authorization Server Metadata
	This document introduces the following new authorization server		This document introduces the following new authorization server
	metadata parameter to signal the server's capability to issue		metadata parameter to signal the server's capability to issue
	certificate bound access tokens:		certificate bound access tokens:
	mutual_tls_sender_constrained_access_tokens		tls_client_certificate_bound_access_tokens
	OPTIONAL. Boolean value indicating server support for mutual TLS		OPTIONAL. Boolean value indicating server support for mutual TLS
	sender constrained access tokens. If omitted, the default value		client certificate bound access tokens. If omitted, the default
	is "false".		value is "false".
	3.4. Client Registration Metadata		3.4. Client Registration Metadata
	The following new client metadata parameter is introduced to convey		The following new client metadata parameter is introduced to convey
	the client's intention to use certificate bound access tokens:		the client's intention to use certificate bound access tokens:
	mutual_tls_sender_constrained_access_tokens		tls_client_certificate_bound_access_tokens
	OPTIONAL. Boolean value used to indicate the client's intention		OPTIONAL. Boolean value used to indicate the client's intention
	to use mutual TLS sender constrained access tokens. If omitted,		to use mutual TLS client certificate bound access tokens. If
	the default value is "false".		omitted, the default value is "false".
	4. Implementation Considerations		4. Implementation Considerations
	4.1. Authorization Server		4.1. Authorization Server
	The authorization server needs to setup its TLS configuration		The authorization server needs to set up its TLS configuration
	appropriately for the binding methods it supports.		appropriately for the binding methods it supports.
	If the authorization server wants to support mutual TLS client		If the authorization server wants to support mutual TLS client
	authentication and other client authentication methods in parallel,		authentication and other client authentication methods in parallel,
	it should make mutual TLS optional.		it should make mutual TLS optional.
	If the authorization server supports the Self-Signed Certificate		If the authorization server supports the Self-Signed Certificate
	method, it should configure the TLS stack in a way that it does not		method, it should configure the TLS stack in a way that it does not
	verify whether the certificate presented by the client during the		verify whether the certificate presented by the client during the
	handshake is signed by a trusted CA certificate.		handshake is signed by a trusted CA certificate.
	The authorization server may also consider hosting the token		The authorization server may also consider hosting the token
	endpoint, and other endpoints requiring client authentication, on a		endpoint, and other endpoints requiring client authentication, on a
	separate host name in order to prevent unintended impact on the TLS		separate host name or port in order to prevent unintended impact on
	behavior of its other endpoints, e.g. authorization or registration.		the TLS behavior of its other endpoints, e.g. the authorization
			endpoint.
	4.2. Resource Server		4.2. Resource Server
	From the perspective of the resource server, TLS client		Since the resource server relies on the authorization server to
	authentication is used as a proof of possession method only. For the		perform client authentication, there is no need for the resource
	purpose of client authentication, the resource server may completely		server to validate the trust chain of the client's certificate in any
	rely on the authorization server. So there is no need to validate		of the methods defined in this document. Mutual TLS is used only as
	the trust chain of the client's certificate in any of the methods		a proof-of-possession mechanism during protected resource access.
	defined in this document. The resource server should therefore		The resource server should therefore configure the TLS stack in a way
	configure the TLS stack in a way that it does not verify whether the		that it does not verify whether the certificate presented by the
	certificate presented by the client during the handshake is signed by		client during the handshake is signed by a trusted CA certificate.
	a trusted CA certificate.
	4.3. Sender Constrained Access Tokens Without Client Authentication		4.3. Certificate Bound Access Tokens Without Client Authentication
	This document allows use of client authentication only or client		Mutual TLS OAuth client authentication and mutual TLS client
	authentication in combination with sender constraint access tokens.		certificate bound access tokens can be used independently of each
	Use of mutual TLS sender constrained access tokens without client		other. Use of certificate bound access tokens without mutual TLS
	authentication (e.g. to support binding access tokens to a TLS client		OAuth client authentication, for example, is possible in support of
	certificate for public clients) is also possible. The authorization		binding access tokens to a TLS client certificate for public clients
	server would configure the TLS stack in the same manner as for the		or clients utilizing other methods of authentication to the
	Self-Signed Certificate method such that it does not verify that the		authorization server. The authorization server would configure the
	certificate presented by the client during the handshake is signed by		TLS stack in the same manner as for the Self-Signed Certificate
	a trusted CA. Individual instances of a public client would then		method such that it does not verify that the certificate presented by
	create a self-signed certificate for mutual TLS with the		the client during the handshake is signed by a trusted CA.
	authorization server and resource server. The authorization server		Individual instances of a client would create a self-signed
	would not authenticate the client at the OAuth layer but would bind		certificate for mutual TLS with both the authorization server and
	issued access tokens to the certificate, which the client has proven		resource server. The authorization server would not use the mutual
	possession of the corresponding private key. The access token is		TLS certificate to authenticate the client at the OAuth layer but
	then mutual TLS sender constrained and can only be used by the client		would bind the issued access token to that certificate, which the
	possessing the certificate and private key and utilizing them to		client has proven possession of the corresponding private key. The
	negotiate mutual TLS on connections to the resource server.		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.
	4.4. Certificate Bound Access Tokens		4.4. Certificate Bound Access Tokens
	As described in Section 3, an access token is bound to a specific		As described in Section 3, an access token is bound to a specific
	client certificate, which means that the same certificate must be		client certificate, which means that the same certificate must be
	used for mutual TLS on protected resource access. It also implies		used for mutual TLS on protected resource access. It also implies
	that access tokens are invalidated when a client updates the		that access tokens are invalidated when a client updates the
	certificate, which can be handled similar to expired access tokens		certificate, which can be handled similar to expired access tokens
	where the client requests a new access token (typically with a		where the client requests a new access token (typically with a
	refresh token) and retries the protected resource request.		refresh token) and retries the protected resource request.
	4.5. Implicit Grant Unsupported		4.5. Implicit Grant Unsupported
	This document describes binding an access token to the client		This document describes binding an access token to the client
	certificate presented on the TLS connection from the client to the		certificate presented on the TLS connection from the client to the
	authorization server's token endpoint, however, certificate binding		authorization server's token endpoint, however, such binding of
	of access tokens issued directly from the authorization endpoint via		access tokens issued directly from the authorization endpoint via the
	the implicit grant flow is explicitly out of scope. End users		implicit grant flow is explicitly out of scope. End users interact
	interact directly with the authorization endpoint using a web browser		directly with the authorization endpoint using a web browser and the
	and the use of client certificates in user's browsers bring		use of client certificates in user's browsers bring operational and
	operational and usability issues, which make it undesirable to		usability issues, which make it undesirable to support certificate
	support certificate bound access tokens issued in the implicit grant		bound access tokens issued in the implicit grant flow.
	flow. Implementations wanting to employ certificate bound sender		Implementations wanting to employ certificate bound access tokens
	constrained access tokens should utilize grant types that involve the		should utilize grant types that involve the client making an access
	client making an access token request directly to the token endpoint		token request directly to the token endpoint (e.g. the authorization
	(e.g. the authorization code and refresh token grant types).		code and refresh token grant types).
			4.6. 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.
	5. Security Considerations		5. Security Considerations
	5.1. TLS Versions and Best Practices		5.1. TLS Versions and Best Practices
	TLS 1.2 [RFC5246] is cited in this document because, at the time of		TLS 1.2 [RFC5246] is cited in this document because, at the time of
	writing, it is the latest version that is widely deployed. However,		writing, it is the latest version that is widely deployed. However,
	this document is applicable with other TLS versions supporting		this document is applicable with other TLS versions supporting
	certificate-based client authentication. Implementation security		certificate-based client authentication. Implementation security
	considerations for TLS, including version recommendations, can be		considerations for TLS, including version recommendations, can be
	skipping to change at page 12, line 19 ¶		skipping to change at page 12, line 39 ¶
	DN but issued by a different CA, which the authorization server		DN but issued by a different CA, which the authorization server
	trusts. To cope with that threat, the authorization server should		trusts. To cope with that threat, the authorization server should
	only accept as trust anchors a limited number of CAs whose		only accept as trust anchors a limited number of CAs whose
	certificate issuance policy meets its security requirements. There		certificate issuance policy meets its security requirements. There
	is an assumption then that the client and server agree on the set of		is an assumption then that the client and server agree on the set of
	trust anchors that the server uses to create and validate the		trust anchors that the server uses to create and validate the
	certificate chain. Without this assumption the use of a Subject DN		certificate chain. Without this assumption the use of a Subject DN
	to identify the client certificate would open the server up to		to identify the client certificate would open the server up to
	certificate spoofing attacks.		certificate spoofing attacks.
			5.3. 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) [X509Pitfalls] [DangerousCode] [RFC5280]:
			o checking of Basic Constraints, basic and extended Key Usage
			constraints, validity periods, and critical extensions;
			o handling of null-terminator bytes and non-canonical string
			representations in subject names;
			o handling of wildcard patterns in subject names;
			o 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.
	6. IANA Considerations		6. IANA Considerations
	6.1. JWT Confirmation Methods Registration		6.1. JWT Confirmation Methods Registration
	This specification requests registration of the following value in		This specification requests registration of the following value in
	the IANA "JWT Confirmation Methods" registry [IANA.JWT.Claims] for		the IANA "JWT Confirmation Methods" registry [IANA.JWT.Claims] for
	JWT "cnf" member values established by [RFC7800].		JWT "cnf" member values established by [RFC7800].
	o Confirmation Method Value: "x5t#S256"		o Confirmation Method Value: "x5t#S256"
	o Confirmation Method Description: X.509 Certificate SHA-256		o Confirmation Method Description: X.509 Certificate SHA-256
	Thumbprint		Thumbprint
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3.1 of [[ this specification ]]		o Specification Document(s): Section 3.1 of [[ this specification ]]
	6.2. OAuth Authorization Server Metadata Registration		6.2. OAuth Authorization Server Metadata Registration
	This specification requests registration of the following value in		This specification requests registration of the following value in
	the IANA "OAuth Authorization Server Metadata" registry		the IANA "OAuth Authorization Server Metadata" registry
	[IANA.OAuth.Parameters] established by [I-D.ietf-oauth-discovery].		[IANA.OAuth.Parameters] established by [I-D.ietf-oauth-discovery].
	o Metadata Name: "mutual_tls_sender_constrained_access_tokens"		o Metadata Name: "tls_client_certificate_bound_access_tokens"
	o Metadata Description: Indicates authorization server support for		o Metadata Description: Indicates authorization server support for
	mutual TLS sender constrained access tokens.		mutual TLS client certificate bound access tokens.
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3.3 of [[ this specification ]]		o Specification Document(s): Section 3.3 of [[ this specification ]]
	6.3. Token Endpoint Authentication Method Registration		6.3. Token Endpoint Authentication Method Registration
	This specification requests registration of the following value in		This specification requests registration of the following value in
	the IANA "OAuth Token Endpoint Authentication Methods" registry		the IANA "OAuth Token Endpoint Authentication Methods" registry
	[IANA.OAuth.Parameters] established by [RFC7591].		[IANA.OAuth.Parameters] established by [RFC7591].
	o Token Endpoint Authentication Method Name: "tls_client_auth"		o Token Endpoint Authentication Method Name: "tls_client_auth"
	skipping to change at page 13, line 30 ¶		skipping to change at page 14, line 24 ¶
	o Claim Description: Confirmation		o Claim Description: Confirmation
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3.2 of [[ this specification ]]		o Specification Document(s): Section 3.2 of [[ this specification ]]
	6.5. OAuth Dynamic Client Registration Metadata Registration		6.5. OAuth Dynamic Client Registration Metadata Registration
	This specification requests registration of the following client		This specification requests registration of the following client
	metadata definitions in the IANA "OAuth Dynamic Client Registration		metadata definitions in the IANA "OAuth Dynamic Client Registration
	Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]:		Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]:
	o Client Metadata Name:		o Client Metadata Name: "tls_client_certificate_bound_access_tokens"
	"mutual_tls_sender_constrained_access_tokens"
	o Client Metadata Description: Indicates the client's intention to		o Client Metadata Description: Indicates the client's intention to
	use mutual TLS sender constrained access tokens.		use mutual TLS client certificate bound access tokens.
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3.4 of [[ this specification ]]		o Specification Document(s): Section 3.4 of [[ this specification ]]
	o Client Metadata Name: "tls_client_auth_subject_dn"		o Client Metadata Name: "tls_client_auth_subject_dn"
	o Client Metadata Description: String value specifying the expected		o Client Metadata Description: String value specifying the expected
	subject distinguished name of the client certificate.		subject distinguished name of the client certificate.
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 2.1.2 of [[ this specification		o Specification Document(s): Section 2.1.2 of [[ this specification
	]]		]]
	skipping to change at page 14, line 21 ¶		skipping to change at page 15, line 10 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol		[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
	(LDAP): String Representation of Distinguished Names",		(LDAP): String Representation of Distinguished Names",
	RFC 4514, DOI 10.17487/RFC4514, June 2006,		RFC 4514, DOI 10.17487/RFC4514, June 2006,
	<https://www.rfc-editor.org/info/rfc4514>.		<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		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<https://www.rfc-editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	skipping to change at page 15, line 7 ¶		skipping to change at page 15, line 46 ¶
	RFC 7800, DOI 10.17487/RFC7800, April 2016,		RFC 7800, DOI 10.17487/RFC7800, April 2016,
	<https://www.rfc-editor.org/info/rfc7800>.		<https://www.rfc-editor.org/info/rfc7800>.
	[SHS] National Institute of Standards and Technology, "Secure		[SHS] National Institute of Standards and Technology, "Secure
	Hash Standard (SHS)", FIPS PUB 180-4, March 2012,		Hash Standard (SHS)", FIPS PUB 180-4, March 2012,
	<http://csrc.nist.gov/publications/fips/fips180-4/		<http://csrc.nist.gov/publications/fips/fips180-4/
	fips-180-4.pdf>.		fips-180-4.pdf>.
	7.2. Informative References		7.2. Informative References
			[DangerousCode]
			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",
			<http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf>.
	[I-D.ietf-oauth-discovery]		[I-D.ietf-oauth-discovery]
	Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0		Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
	Authorization Server Metadata", draft-ietf-oauth-		Authorization Server Metadata", draft-ietf-oauth-
	discovery-08 (work in progress), November 2017.		discovery-10 (work in progress), March 2018.
	[I-D.ietf-oauth-token-binding]		[I-D.ietf-oauth-token-binding]
	Jones, M., Campbell, B., Bradley, J., and W. Denniss,		Jones, M., Campbell, B., Bradley, J., and W. Denniss,
	"OAuth 2.0 Token Binding", draft-ietf-oauth-token-		"OAuth 2.0 Token Binding", draft-ietf-oauth-token-
	binding-05 (work in progress), October 2017.		binding-06 (work in progress), March 2018.
	[IANA.JWT.Claims]		[IANA.JWT.Claims]
	IANA, "JSON Web Token Claims",		IANA, "JSON Web Token Claims",
	<http://www.iana.org/assignments/jwt>.		<http://www.iana.org/assignments/jwt>.
	[IANA.OAuth.Parameters]		[IANA.OAuth.Parameters]
	IANA, "OAuth Parameters",		IANA, "OAuth Parameters",
	<http://www.iana.org/assignments/oauth-parameters>.		<http://www.iana.org/assignments/oauth-parameters>.
	[OpenID.Discovery]		[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
	Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID		(LDAP): Syntaxes and Matching Rules", RFC 4517,
	Connect Discovery 1.0", August 2015,		DOI 10.17487/RFC4517, June 2006,
	<http://openid.net/specs/		<https://www.rfc-editor.org/info/rfc4517>.
	openid-connect-discovery-1_0.html>.
	[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth		[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
	2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,		2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
	August 2013, <https://www.rfc-editor.org/info/rfc7009>.		August 2013, <https://www.rfc-editor.org/info/rfc7009>.
	[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,		[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
	DOI 10.17487/RFC7517, May 2015,		DOI 10.17487/RFC7517, May 2015,
	<https://www.rfc-editor.org/info/rfc7517>.		<https://www.rfc-editor.org/info/rfc7517>.
	[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	skipping to change at page 16, line 9 ¶		skipping to change at page 17, line 5 ¶
	<https://www.rfc-editor.org/info/rfc7591>.		<https://www.rfc-editor.org/info/rfc7591>.
	[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",		[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
	RFC 7662, DOI 10.17487/RFC7662, October 2015,		RFC 7662, DOI 10.17487/RFC7662, October 2015,
	<https://www.rfc-editor.org/info/rfc7662>.		<https://www.rfc-editor.org/info/rfc7662>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[X509Pitfalls]
			Wong, D., "Common x509 certificate validation/creation
			pitfalls", September 2016,
			<https://www.cryptologie.net/article/374/
			common-x509-certificate-validationcreation-pitfalls>.
	Appendix A. Relationship to Token Binding		Appendix A. Relationship to Token Binding
	OAuth 2.0 Token Binding [I-D.ietf-oauth-token-binding] enables the		OAuth 2.0 Token Binding [I-D.ietf-oauth-token-binding] enables the
	application of Token Binding to the various artifacts and tokens		application of Token Binding to the various artifacts and tokens
	employed throughout OAuth. That includes binding of an access token		employed throughout OAuth. That includes binding of an access token
	to a Token Binding key, which bears some similarities in motivation		to a Token Binding key, which bears some similarities in motivation
	and design to the mutual TLS sender constrained resources access		and design to the mutual TLS client certificate bound access tokens
	defined in this document. Both documents define what is often called		defined in this document. Both documents define what is often called
	a proof-of-possession security mechanism for access tokens, whereby a		a proof-of-possession security mechanism for access tokens, whereby a
	client must demonstrate possession of cryptographic keying material		client must demonstrate possession of cryptographic keying material
	when accessing a protected resource. The details differ somewhat		when accessing a protected resource. The details differ somewhat
	between the two documents but both have the authorization server bind		between the two documents but both have the authorization server bind
	the access token it issues to an asymmetric key pair on the client.		the access token that it issues to an asymmetric key pair held by the
	The client then proves possession of the private key from that pair		client. The client then proves possession of the private key from
	on the TLS connection over which the protected resource is accessed.		that pair with respect to the TLS connection over which the protected
			resource is accessed.
	The two documents then are effectively competing specifications, at		Token Binding uses bare keys that are generated on the client, which
	least with respect to the binding of access tokens. Token Binding		avoids many of the difficulties of creating, distributing, and
	uses bare keys that are generated on the client, which avoids many of		managing certificates used in this specification. However, at the
	the difficulties of creating, distributing, and managing certificates		time of writing, Token Binding is fairly new and there is relatively
	and has the potential to see wider scale adoption and deployment.		little support for it in available application development platforms
	However, at the time of writing, Token Binding is fairly new and		and tooling. Until better support for the underlying core Token
	there is relatively little support for it in available application		Binding specifications exists, practical implementations of OAuth 2.0
	development platforms and tooling. Until better support for the		Token Binding are infeasible. Mutual TLS, on the other hand, has
	underlying core Token Binding specifications exists, practical		been around for some time and enjoys widespread support in web
	implementations of OAuth 2.0 Token Binding are infeasible. Despite		servers and development platforms. As a consequence, OAuth 2.0
	its name, Token Binding doesn't have a monopoly on the binding of		Mutual TLS Client Authentication and Certificate Bound Access Tokens
	tokens. Mutual TLS, on the other hand, has been around for some time		can be built and deployed now using existing platforms and tools. In
	and enjoys widespread support in web servers and development		the future, the two specifications are likely to be deployed in
	platforms. Mutual TLS for OAuth 2.0 can be built and deployed now		parallel for solving similar problems in different environments.
	using existing platforms and tools. There are emerging and immediate		Authorization servers may even support both specifications
	scenarios, such as OAuth enabled financial transactions motivated by		simultaneously using different proof-of-possession mechanisms for
	regulatory requirements in some cases, which demand the additional		tokens issued to different clients.
	security protections of proof-of-possession access tokens. This
	document aspires to provide standardized and expeditious solution for
	those scenarios.
	Appendix B. Acknowledgements		Appendix B. Acknowledgements
	Scott "not Tomlinson" Tomilson and Matt Peterson were involved in		Scott "not Tomlinson" Tomilson and Matt Peterson were involved in
	design and development work on a mutual TLS OAuth client		design and development work on a mutual TLS OAuth client
	authentication implementation that informed some of the content of		authentication implementation, which predates this document.
	this document.		Experience and learning from that work informed some of the content
			of this document.
	Additionally, the authors would like to thank the following people		Additionally, the authors would like to thank the following people
	for their input and contributions to the specification: Sergey		for their input and contributions to the specification: Sergey
	Beryozkin, Vladimir Dzhuvinov, Samuel Erdtman, Leif Johansson, Phil		Beryozkin, Vladimir Dzhuvinov, Samuel Erdtman, Leif Johansson,
	Hunt, Takahiko Kawasaki, Sean Leonard, Kepeng Li, James Manger, Jim		Michael Jones, Phil Hunt, Benjamin Kaduk, Takahiko Kawasaki, Sean
	Manico, Nov Matake, Sascha Preibisch, Justin Richer, Dave Tonge, and		Leonard, Kepeng Li, Neil Madden, James Manger, Jim Manico, Nov
	Hannes Tschofenig.		Matake, Sascha Preibisch, Justin Richer, Dave Tonge, and Hannes
			Tschofenig.
	Appendix C. Document(s) History		Appendix C. Document(s) History
	[[ to be removed by the RFC Editor before publication as an RFC ]]		[[ to be removed by the RFC Editor before publication as an RFC ]]
			draft-ietf-oauth-mtls-08
			o Incorporate clarifications and editorial improvements from Justin
			Richer's WGLC review
			o Drop the use of the "sender constrained" terminology per WGLC
			feedback from Neil Madden (including changing the metadata
			parameters from mutual_tls_sender_constrained_access_tokens to
			tls_client_certificate_bound_access_tokens)
			o Add a new security considerations section on X.509 parsing and
			validation per WGLC feedback from Neil Madden and Benjamin Kaduk
			o Note that a server can terminate TLS at a load balancer, reverse
			proxy, etc. but how the client certificate metadata is securely
			communicated to the backend is out of scope per WGLC feedback
			o Note that revocation checking is at the discretion of the AS per
			WGLC feedback
			o Editorial updates and clarifications
			o Update draft-ietf-oauth-discovery reference to -10 and draft-ietf-
			oauth-token-binding to -06
			o Add folks involved in WGLC feedback to the acknowledgements list
	draft-ietf-oauth-mtls-07		draft-ietf-oauth-mtls-07
	o Update to use the boilerplate from RFC 8174		o Update to use the boilerplate from RFC 8174
	draft-ietf-oauth-mtls-06		draft-ietf-oauth-mtls-06
	o Add an appendix section describing the relationship of this		o Add an appendix section describing the relationship of this
	document to OAuth Token Binding as requested during the the		document to OAuth Token Binding as requested during the the
	Singapore meeting https://datatracker.ietf.org/doc/minutes-		Singapore meeting https://datatracker.ietf.org/doc/minutes-
	100-oauth/		100-oauth/
End of changes. 60 change blocks.
	228 lines changed or deleted		298 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/