draft-ietf-kitten-sasl-oauth-17.txt		draft-ietf-kitten-sasl-oauth-18.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: May 16, 2015		Expires: May 29, 2015
	H. Tschofenig		H. Tschofenig
	ARM Ltd.		ARM Ltd.
	November 12, 2014		November 25, 2014
	A set of SASL Mechanisms for OAuth		A set of SASL Mechanisms for OAuth
	draft-ietf-kitten-sasl-oauth-17.txt		draft-ietf-kitten-sasl-oauth-18.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 May 16, 2015.		This Internet-Draft will expire on May 29, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 3, line 19		skipping to change at page 3, line 19
	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.
	The core OAuth 2.0 specification [RFC6749] specifies the interaction		The core OAuth 2.0 specification [RFC6749] specifies the interaction
	between the OAuth client and the authorization server; it does not		between the OAuth client and the authorization server; it does not
	define the interaction between the OAuth client and the resource		define the interaction between the OAuth client and the resource
	server for the access to a protected resource using an Access Token.		server for the access to a protected resource using an Access Token.
	Instead, the OAuth client to resource server interaction is described		Instead, the OAuth client to resource server interaction is described
	in separate specifications, such as the bearer token specification		in separate specifications, such as the bearer token specification
	[RFC6750] and the MAC Token specification		[RFC6750]. OAuth 1.0a included the protocol specification for the
	[I-D.ietf-oauth-v2-http-mac]. OAuth 1.0a included the protocol		communication between the OAuth client and the resource server in
	specification for the communication between the OAuth client and the		[RFC5849].
	resource server in [RFC5849].
	The main use cases for OAuth 2.0 and OAuth 1.0a have so far focused		The main use cases for OAuth 2.0 and OAuth 1.0a have so far focused
	on an HTTP-based [RFC2616] environment only. This document		on an HTTP-based [RFC2616] environment only. This document
	integrates OAuth 1.0a and OAuth 2.0 into non-HTTP-based applications		integrates OAuth 1.0a and OAuth 2.0 into non-HTTP-based applications
	using the integration into SASL. Hence, this document takes		using the integration into SASL. Hence, this document takes
	advantage of the OAuth protocol and its deployment base to provide a		advantage of the OAuth protocol and its deployment base to provide a
	way to use the Simple Authentication and Security Layer (SASL)		way to use the Simple Authentication and Security Layer (SASL)
	[RFC4422] to gain access to resources when using non-HTTP-based		[RFC4422] to gain access to resources when using non-HTTP-based
	protocols, such as the Internet Message Access Protocol (IMAP)		protocols, such as the Internet Message Access Protocol (IMAP)
	[RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5321],		[RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5321],
	skipping to change at page 9, line 11		skipping to change at page 9, line 11
	about the authentication of the resource owner and about the client		about the authentication of the resource owner and about the client
	and may therefore make this information accessible to the resource		and may therefore make this information accessible to the resource
	server.		server.
	If both identifiers are needed by an application the developer will		If both identifiers are needed by an application the developer will
	need to provide a way to communicate that from the SASL mechanism		need to provide a way to communicate that from the SASL mechanism
	back to the application.		back to the application.
	3.2.2. Server Response to Failed Authentication		3.2.2. Server Response to Failed Authentication
	For a failed authentication the server returns a JSON [RFC4627]		For a failed authentication the server returns a JSON [RFC7159]
	formatted error result, and fails the authentication. The error		formatted error result, and fails the authentication. The error
	result consists of the following values:		result consists of the following values:
	status (REQUIRED): The authorization error code. Valid error		status (REQUIRED): The authorization error code. Valid error
	codes are defined in the IANA "OAuth Extensions Error Registry"		codes are defined in the IANA "OAuth Extensions Error Registry"
	specified in the OAuth 2 core specification.		specified in the OAuth 2 core specification.
	scope (OPTIONAL): An OAuth scope which is valid to access the		scope (OPTIONAL): An OAuth scope which is valid to access the
	service. This may be empty which implies that unscoped tokens		service. This may be empty which implies that unscoped tokens
	are required, or a scope value. If a scope is specified then a		are required, or a scope value. If a scope is specified then a
	skipping to change at page 10, line 11		skipping to change at page 10, line 11
	request scoped tokens from the token endpoint. If the resource		request scoped tokens from the token endpoint. If the resource
	server provides no scope to the client then the client SHOULD presume		server provides no scope to the client then the client SHOULD presume
	an empty scope (unscoped token) is required to access the resource.		an empty scope (unscoped 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 servers, they need to have a way to		as email servers and XMPP servers, they need to have a way to
	determine whether dynamic client registration has been performed		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
	'issue' element to make this determination.		'iss' element defined in OpenID Connect Core [OpenID.Core] to make
			this determination.
	3.2.3. Completing an Error Message Sequence		3.2.3. Completing an Error Message Sequence
	Section 3.6 of [RFC4422] explicitly prohibits additional information		Section 3.6 of [RFC4422] explicitly prohibits additional information
	in an unsuccessful authentication outcome. Therefore, the error		in an unsuccessful authentication outcome. Therefore, the error
	message is sent in a normal message. The client MUST then send an		message is sent in a normal message. The client MUST then send an
	additional client response consisting of a single %x01 (control A)		additional client response consisting of a single %x01 (control A)
	character to the server in order to allow the server to finish the		character to the server in order to allow the server to finish the
	exchange.		exchange.
	skipping to change at page 17, line 41		skipping to change at page 17, line 41
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1		[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
	(SHA1)", RFC 3174, September 2001.		(SHA1)", RFC 3174, September 2001.
	[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and		[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
	Security Layer (SASL)", RFC 4422, June 2006.		Security Layer (SASL)", RFC 4422, June 2006.
	[RFC4627] Crockford, D., "The application/json Media Type for
	JavaScript Object Notation (JSON)", RFC 4627, July 2006.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, October 2006.		Encodings", RFC 4648, October 2006.
	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	[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, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security		[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
	skipping to change at page 18, line 19		skipping to change at page 18, line 19
	[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,		[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
	April 2010.		April 2010.
	[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC		[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
	6749, October 2012.		6749, October 2012.
	[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization		[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
	Framework: Bearer Token Usage", RFC 6750, October 2012.		Framework: Bearer Token Usage", RFC 6750, October 2012.
			[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
			Interchange Format", RFC 7159, March 2014.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-oauth-dyn-reg]		[I-D.ietf-oauth-dyn-reg]
	Richer, J., Jones, M., Bradley, J., Machulak, M., and P.		Richer, J., Jones, M., Bradley, J., Machulak, M., and P.
	Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",		Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
	draft-ietf-oauth-dyn-reg-20 (work in progress), August		draft-ietf-oauth-dyn-reg-20 (work in progress), August
	2014.		2014.
	[I-D.ietf-oauth-json-web-token]		[I-D.ietf-oauth-json-web-token]
	Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", draft-ietf-oauth-json-web-token-30 (work in		(JWT)", draft-ietf-oauth-json-web-token-31 (work in
	progress), October 2014.		progress), November 2014.
	[I-D.ietf-oauth-v2-http-mac]
	Richer, J., Mills, W., Tschofenig, H., and P. Hunt, "OAuth
	2.0 Message Authentication Code (MAC) Tokens", draft-ietf-
	oauth-v2-http-mac-05 (work in progress), January 2014.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION		[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
	4rev1", RFC 3501, March 2003.		4rev1", RFC 3501, March 2003.
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	October 2008.		October 2008.
	skipping to change at page 19, line 23		skipping to change at page 19, line 23
	Williams, Matt Miller, and Benjamin Kaduk.		Williams, Matt Miller, and Benjamin Kaduk.
	This document was produced under the chairmanship of Alexey Melnikov,		This document was produced under the chairmanship of Alexey Melnikov,
	Tom Yu, Shawn Emery, Josh Howlett, Sam Hartman. The supervising area		Tom Yu, Shawn Emery, Josh Howlett, Sam Hartman. The supervising area
	director was Stephen Farrell.		director was Stephen Farrell.
	Appendix B. Document History		Appendix B. Document History
	[[ to be removed by RFC editor before publication as an RFC ]]		[[ to be removed by RFC editor before publication as an RFC ]]
			-18
			o Last call feedback round #5. Fixed -17 change log.
			o Corrected "issue" to "iss", other minor changes.
	-17		-17
	o Last call feedback again. eradicated comma splicing. Removed		o Last call feedback again (WGLC #4). eradicated comma splicing.
	extra server message in example 4.3.		Removed extra server message in example 4.3.
			o Added recommendations for discovery and dynamic client
			registration support.
	-16		-16
	o Last call feedback again. Primarily editorial changes. Corrected		o Last call feedback again. Primarily editorial changes. Corrected
	examples.		examples.
	-15		-15
	o Last call feedack on the GS2 stuff being ripped out completely.		o Last call feedack on the GS2 stuff being ripped out completely.
End of changes. 12 change blocks.
	22 lines changed or deleted		26 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/