< draft-ietf-kitten-sasl-oauth-20.txt		draft-ietf-kitten-sasl-oauth-21.txt >
	KITTEN W. Mills		KITTEN W. Mills
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track T. Showalter		Intended status: Standards Track T. Showalter
	Expires: October 18, 2015		Expires: October 19, 2015
	H. Tschofenig		H. Tschofenig
	ARM Ltd.		ARM Ltd.
	April 16, 2015		April 17, 2015
	A set of SASL Mechanisms for OAuth		A set of SASL Mechanisms for OAuth
	draft-ietf-kitten-sasl-oauth-20.txt		draft-ietf-kitten-sasl-oauth-21.txt
	Abstract		Abstract
	OAuth enables a third-party application to obtain limited access to a		OAuth enables a third-party application to obtain limited access to a
	protected resource, either on behalf of a resource owner by		protected resource, either on behalf of a resource owner by
	orchestrating an approval interaction, or by allowing the third-party		orchestrating an approval interaction, or by allowing the third-party
	application to obtain access on its own behalf.		application to obtain access on its own behalf.
	This document defines how an application client uses credentials		This document defines how an application client uses credentials
	obtained via OAuth over the Simple Authentication and Security Layer		obtained via OAuth over the Simple Authentication and Security Layer
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 October 18, 2015.		This Internet-Draft will expire on October 19, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 2, line 42 ¶		skipping to change at page 2, line 42 ¶
	3.3. OAuth Access Token Types using Keyed Message Digests . . 10		3.3. OAuth Access Token Types using Keyed Message Digests . . 10
	4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 12		4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 12
	4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 13		4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 13
	4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 13		4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 13
	4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 14		4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 14
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 15		5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	6. Internationalization Considerations . . . . . . . . . . . . . 16		6. Internationalization Considerations . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 17		7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 17
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. Normative References . . . . . . . . . . . . . . . . . . 17		8.1. Normative References . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 19		Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 19
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 19		Appendix B. Document History . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	OAuth 1.0a [RFC5849] and OAuth 2.0 [RFC6749] are protocol frameworks		OAuth 1.0a [RFC5849] and OAuth 2.0 [RFC6749] are protocol frameworks
	that enable a third-party application to obtain limited access to a		that enable a third-party application to obtain limited access to a
	protected resource, either on behalf of a resource owner by		protected resource, either on behalf of a resource owner by
	orchestrating an approval interaction, or by allowing the third-party		orchestrating an approval interaction, or by allowing the third-party
	application to obtain access on its own behalf.		application to obtain access on its own behalf.
	skipping to change at page 10, line 13 ¶		skipping to change at page 10, line 13 ¶
	of parameters necessary for the OAuth protocol exchange to		of parameters necessary for the OAuth protocol exchange to
	function. Another comparable discovery or client registration		function. Another comparable discovery or client registration
	mechanism MAY be used if available.		mechanism MAY be used if available.
	The use of the 'offline_access' scope, as defined in		The use of the 'offline_access' scope, as defined in
	[OpenID.Core] is RECOMMENDED to give clients the capability to		[OpenID.Core] is RECOMMENDED to give clients the capability to
	explicitly request a refresh token.		explicitly request a refresh token.
	If the resource server provides a scope then the client MUST always		If the resource server provides a scope then the client MUST always
	request scoped tokens from the token endpoint. If the resource		request scoped tokens from the token endpoint. If the resource
	server does not return a scope the client SHOULD presume an empty		server does not return a scope the client SHOULD presume an unscoped
	scope (unscoped token) is required to access the resource.		token is required to access the resource.
	Since clients may interact with a number of application servers, such		Since clients may interact with a number of application servers, such
	as email servers and XMPP [RFC6120] servers, they need to have a way		as email servers and XMPP [RFC6120] servers, they need to have a way
	to determine whether dynamic client registration has been performed		to determine whether dynamic client registration has been performed
	already and whether an already available refresh token can be re-used		already and whether an already available refresh token can be re-used
	to obtain an access token for the desired resource server. This		to obtain an access token for the desired resource server. This
	specification RECOMMENDs that a client uses the information in the		specification RECOMMENDs that a client uses the information in the
	'iss' element defined in OpenID Connect Core [OpenID.Core] to make		'iss' element defined in OpenID Connect Core [OpenID.Core] to make
	this determination.		this determination.
	skipping to change at page 17, line 17 ¶		skipping to change at page 17, line 17 ¶
	At the time of writing the standardization of the various claims in		At the time of writing the standardization of the various claims in
	the access token (in JSON format) is still ongoing, see		the access token (in JSON format) is still ongoing, see
	[I-D.ietf-oauth-json-web-token]. Once completed it will provide a		[I-D.ietf-oauth-json-web-token]. Once completed it will provide a
	standardized format for exchanging identity information between the		standardized format for exchanging identity information between the
	authorization server and the resource server.		authorization server and the resource server.
	7. IANA Considerations		7. IANA Considerations
	7.1. SASL Registration		7.1. SASL Registration
	The IANA is requested to register the following SASL profile:		The IANA is requested to register the following entry in the SASL
			Mechanisms registry:
	SASL mechanism profile: OAUTHBEARER		SASL mechanism name: OAUTHBEARER
	Security Considerations: See this document		Security Considerations: See this document
	Published Specification: See this document		Published Specification: See this document
	For further information: Contact the authors of this document.		For further information: Contact the authors of this document.
	Owner/Change controller: the IETF		Intended usage: common
			Owner/Change controller: the IESG
	Note: None		Note: None
	The IANA is requested to register the following SASL profile:		The IANA is requested to register the following entry in the SASL
			Mechanisms registry:
	SASL mechanism profile: OAUTH10A		SASL mechanism name: OAUTH10A
	Security Considerations: See this document		Security Considerations: See this document
	Published Specification: See this document		Published Specification: See this document
	For further information: Contact the authors of this document.		For further information: Contact the authors of this document.
	Owner/Change controller: the IETF		Intended usage: common
			Owner/Change controller: the IESG
	Note: None		Note: None
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[OpenID.Core]		[OpenID.Core]
	Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and		Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
	C. Mortimore, "OpenID Connect Core 1.0", February 2014.		C. Mortimore, "OpenID Connect Core 1.0", February 2014.
End of changes. 13 change blocks.
	16 lines changed or deleted		22 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/