draft-ietf-oauth-mtls-06.txt		draft-ietf-oauth-mtls-07.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: July 19, 2018 Yubico		Expires: August 2, 2018 Yubico
	N. Sakimura		N. Sakimura
	Nomura Research Institute		Nomura Research Institute
	T. Lodderstedt		T. Lodderstedt
	YES Europe AG		YES Europe AG
	January 15, 2018		January 29, 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-06		draft-ietf-oauth-mtls-07
	Abstract		Abstract
	This document describes Transport Layer Security (TLS) mutual		This document describes Transport Layer Security (TLS) mutual
	authentication using X.509 certificates as a mechanism for OAuth		authentication using X.509 certificates as a mechanism for OAuth
	client authentication to the authorization sever as well as for		client authentication to the authorization sever as well as for
	certificate bound sender constrained access tokens as a method for a		certificate bound sender constrained access tokens as a method for a
	protected resource to ensure that an access token presented to it by		protected resource to ensure that an access token presented to it by
	a given client was issued to that client by the authorization server.		a given client was issued to that client by the authorization server.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 July 19, 2018.		This Internet-Draft will expire on August 2, 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
	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 45 ¶
	access tokens or replay of access tokens by unauthorized parties.		access tokens or replay of access tokens by unauthorized parties.
	Mutual TLS sender constrained access tokens and mutual TLS client		Mutual TLS sender constrained 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 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 RFC		"OPTIONAL" in this document are to be interpreted as described in BCP
	2119 [RFC2119].		14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	1.2. Terminology		1.2. Terminology
	This specification uses the following phrases interchangeably:		This specification uses the following phrases interchangeably:
	Transport Layer Security (TLS) Mutual Authentication		Transport Layer Security (TLS) Mutual Authentication
	Mutual TLS		Mutual TLS
	These phrases all refer to the process whereby a client presents its		These phrases all refer to the process whereby a client presents its
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 5 ¶
	[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and		[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
	P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",		P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
	RFC 7591, DOI 10.17487/RFC7591, July 2015,		RFC 7591, DOI 10.17487/RFC7591, July 2015,
	<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
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	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 sender constrained resources access
	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
	skipping to change at page 17, line 11 ¶		skipping to change at page 17, line 16 ¶
	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, Phil
	Hunt, Takahiko Kawasaki, Sean Leonard, Kepeng Li, James Manger, Jim		Hunt, Takahiko Kawasaki, Sean Leonard, Kepeng Li, James Manger, Jim
	Manico, Nov Matake, Sascha Preibisch, Justin Richer, Dave Tonge, and		Manico, Nov Matake, Sascha Preibisch, Justin Richer, Dave Tonge, and
	Hannes Tschofenig.		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-07
			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/
	o Add an explicit note that the implicit flow is not supported for		o Add an explicit note that the implicit flow is not supported for
	obtaining certificate bound access tokens as discussed at the		obtaining certificate bound access tokens as discussed at the
	Singapore meeting https://datatracker.ietf.org/doc/minutes-		Singapore meeting https://datatracker.ietf.org/doc/minutes-
	100-oauth/		100-oauth/
	skipping to change at page 18, line 44 ¶		skipping to change at page 19, line 4 ¶
	U46UMEh8XIOQnvXY9pHFq1MKPns		U46UMEh8XIOQnvXY9pHFq1MKPns
	o Changed the title (hopefully "Mutual TLS Profile for OAuth 2.0" is		o Changed the title (hopefully "Mutual TLS Profile for OAuth 2.0" is
	better than "Mutual TLS Profiles for OAuth Clients").		better than "Mutual TLS Profiles for OAuth Clients").
	draft-ietf-oauth-mtls-01		draft-ietf-oauth-mtls-01
	o Added more explicit details of using RFC 7662 token introspection		o Added more explicit details of using RFC 7662 token introspection
	with mutual TLS sender constrained access tokens.		with mutual TLS sender constrained access tokens.
	o Added an IANA OAuth Token Introspection Response Registration		o Added an IANA OAuth Token Introspection Response Registration
	request for "cnf".		request for "cnf".
	o Specify that tls_client_auth_subject_dn and		o Specify that tls_client_auth_subject_dn and
	tls_client_auth_root_dn are RFC 4514 String Representation of		tls_client_auth_root_dn are RFC 4514 String Representation of
	Distinguished Names.		Distinguished Names.
	o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn.		o Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn.
	o Changed the text in the Section 3 to not be specific about using a		o Changed the text in the Section 3 to not be specific about using a
	hash of the cert.		hash of the cert.
	o Changed the abbreviated title to 'OAuth Mutual TLS' (previously		o Changed the abbreviated title to 'OAuth Mutual TLS' (previously
	was the acronym MTLSPOC).		was the acronym MTLSPOC).
			draft-ietf-oauth-mtls-00
	o Created the initial working group version from draft-campbell-		o Created the initial working group version from draft-campbell-
	oauth-mtls		oauth-mtls
	draft-campbell-oauth-mtls-01		draft-campbell-oauth-mtls-01
	o Fix some typos.		o Fix some typos.
	o Add to the acknowledgements list.		o Add to the acknowledgements list.
	draft-campbell-oauth-mtls-00		draft-campbell-oauth-mtls-00
End of changes. 9 change blocks.
	6 lines changed or deleted		18 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/