< draft-ietf-kitten-sasl-oauth-18.txt		draft-ietf-kitten-sasl-oauth-19.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 29, 2015		Expires: July 24, 2015
	H. Tschofenig		H. Tschofenig
	ARM Ltd.		ARM Ltd.
	November 25, 2014		January 20, 2015
	A set of SASL Mechanisms for OAuth		A set of SASL Mechanisms for OAuth
	draft-ietf-kitten-sasl-oauth-18.txt		draft-ietf-kitten-sasl-oauth-19.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 29, 2015.		This Internet-Draft will expire on July 24, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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
	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
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 6		3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 6
	3.1. Initial Client Response . . . . . . . . . . . . . . . . . 7		3.1. Initial Client Response . . . . . . . . . . . . . . . . . 7
	3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 8		3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 8
	3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 8		3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 8
	3.2.1. OAuth Identifiers in the SASL Context . . . . . . . . 8		3.2.1. OAuth Identifiers in the SASL Context . . . . . . . . 9
	3.2.2. Server Response to Failed Authentication . . . . . . 9		3.2.2. Server Response to Failed Authentication . . . . . . 9
	3.2.3. Completing an Error Message Sequence . . . . . . . . 10		3.2.3. Completing an Error Message Sequence . . . . . . . . 10
	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 . . . . . . . . . . . . 11		4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 12
	4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 12		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 . . . . . . . . . . 15
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 15		5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	6. Internationalization Considerations . . . . . . . . . . . . . 16		6. Internationalization Considerations . . . . . . . . . . . . . 17
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 16		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 . . . . . . . . . . . . . . . . . . . . . . . 22		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.
	The core OAuth 2.0 specification [RFC6749] specifies the interaction		The core OAuth 2.0 specification [RFC6749] specifies the interaction
	skipping to change at page 6, line 38 ¶		skipping to change at page 6, line 38 ¶
	further definition.		further definition.
	These mechanisms are client initiated and lock-step, the server		These mechanisms are client initiated and lock-step, the server
	always replying to a client message. In the case where the client		always replying to a client message. In the case where the client
	has and correctly uses a valid token the flow is:		has and correctly uses a valid token the flow is:
	1. Client sends a valid and correct initial client response.		1. Client sends a valid and correct initial client response.
	2. Server responds with a successful authentication.		2. Server responds with a successful authentication.
	In the case where authorization fails the server sends an error		In the case where authentication fails the server sends an error
	result, then client MUST then send an additional message to the		result, then client MUST then send an additional message to the
	server in order to allow the server to finish the exchange. Some		server in order to allow the server to finish the exchange. Some
	protocols and common SASL implementations do not support both sending		protocols and common SASL implementations do not support both sending
	a SASL message and finalizing a SASL negotiation, the additional		a SASL message and finalizing a SASL negotiation. The additional
	client message in the error case deals with this problem. This		client message in the error case deals with this problem. This
	exchange is:		exchange is:
	1. Client sends an invalid initial client response.		1. Client sends an invalid initial client response.
	2. Server responds with an error message.		2. Server responds with an error message.
	3. Client sends a dummy client response.		3. Client sends a dummy client response.
	4. Server fails the authentication.		4. Server fails the authentication.
	skipping to change at page 7, line 19 ¶		skipping to change at page 7, line 19 ¶
	Client responses are a GS2 [RFC5801] header followed by zero or more		Client responses are a GS2 [RFC5801] header followed by zero or more
	key/value pairs, or may be empty. The gs2-header is defined here for		key/value pairs, or may be empty. The gs2-header is defined here for
	compatibility with GS2 if a GS2 mechanism is formally defined, but		compatibility with GS2 if a GS2 mechanism is formally defined, but
	this document does not define one. These key/value pairs take the		this document does not define one. These key/value pairs take the
	place of the corresponding HTTP headers and values to convey the		place of the corresponding HTTP headers and values to convey the
	information necessary to complete an OAuth style HTTP authorization.		information necessary to complete an OAuth style HTTP authorization.
	Unknown key/value pairs MUST be ignored by the server. The ABNF		Unknown key/value pairs MUST be ignored by the server. The ABNF
	[RFC5234] syntax is:		[RFC5234] syntax is:
	kvsep = %x01		kvsep = %x01
	key = 1*(ALPHA / ",")		key = 1*(ALPHA)
	value = *(VCHAR / SP / HTAB / CR / LF )		value = *(VCHAR / SP / HTAB / CR / LF )
	kvpair = key "=" value kvsep		kvpair = key "=" value kvsep
	;;gs2-header = See RFC 5801		;;gs2-header = See RFC 5801
	client_resp = (gs2-header kvsep 0*kvpair kvsep) / kvsep		client_resp = (gs2-header kvsep 0*kvpair kvsep) / kvsep
	The GS2 header MAY include the user name associated with the resource		The GS2 header MAY include the user name associated with the resource
	being accessed, the "authzid". It is worth noting that application		being accessed, the "authzid". It is worth noting that application
	protocols are allowed to require an authzid, as are specific server		protocols are allowed to require an authzid, as are specific server
	implementations.		implementations.
			The client response consisting of only a single kvsep is used only
			when authentication fails, and is only valid in that context. If
			sent as the first message from the client the server MAY simply fail
			the authentication without returning discovery information since
			there is no user or server name indication.
	The following keys and corresponding values are defined in the client		The following keys and corresponding values are defined in the client
	response:		response:
	auth (REQUIRED): The payload that would be in the HTTP		auth (REQUIRED): The payload that would be in the HTTP
	Authorization header if this OAuth exchange was being carried		Authorization header if this OAuth exchange was being carried
	out over HTTP.		out over HTTP.
	host: Contains the host name to which the client connected. In		host: Contains the host name to which the client connected. In
	an HTTP context this is the value of the HTTP Host header.		an HTTP context this is the value of the HTTP Host header.
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 17 ¶
	server MUST fail an authorization request requiring keyed message		server MUST fail an authorization request requiring keyed message
	digests that are not accompanied by host and port values. In OAuth		digests that are not accompanied by host and port values. In OAuth
	1.0a for example, the so-called "signature base string calculation"		1.0a for example, the so-called "signature base string calculation"
	includes the reconstructed HTTP URL.		includes the reconstructed HTTP URL.
	3.1.1. Reserved Key/Values		3.1.1. Reserved Key/Values
	In these mechanisms values for path, query string and post body are		In these mechanisms values for path, query string and post body are
	assigned default values. OAuth authorization schemes MAY define		assigned default values. OAuth authorization schemes MAY define
	usage of these in the SASL context and extend this specification.		usage of these in the SASL context and extend this specification.
	For OAuth Access Token Types that use request keyed message digest		For OAuth Access Token Types that include a keyed message digest of
	the default values MUST be used unless explicit values are provided		the request the default values MUST be used unless explicit values
	in the client response. The following key values are reserved for		are provided in the client response. The following key values are
	future use:		reserved for future use:
	mthd (RESERVED): HTTP method, the default value is "POST".		mthd (RESERVED): HTTP method, the default value is "POST".
	path (RESERVED): HTTP path data, the default value is "/".		path (RESERVED): HTTP path data, the default value is "/".
	post (RESERVED): HTTP post data, the default value is "".		post (RESERVED): HTTP post data, the default value is "".
	qs (RESERVED): The HTTP query string, the default value is "".		qs (RESERVED): The HTTP query string, the default value is "".
	3.2. Server's Response		3.2. Server's Response
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 44 ¶
	utilizes a keyed message digest of the request parameters then the		utilizes a keyed message digest of the request parameters then the
	client must provide a client response that satisfies the data		client must provide a client response that satisfies the data
	requirements for the scheme in use.		requirements for the scheme in use.
	The server responds to a successfully verified client message by		The server responds to a successfully verified client message by
	completing the SASL negotiation. The authenticated identity reported		completing the SASL negotiation. The authenticated identity reported
	by the SASL mechanism is the identity securely established for the		by the SASL mechanism is the identity securely established for the
	client with the OAuth credential. The application, not the SASL		client with the OAuth credential. The application, not the SASL
	mechanism, based on local access policy determines whether the		mechanism, based on local access policy determines whether the
	identity reported by the mechanism is allowed access to the requested		identity reported by the mechanism is allowed access to the requested
	resource. Note that the semantics of the authz-id is specified by		resource. Note that the semantics of the authorization identity is
	the SASL framework [RFC4422].		specified by the SASL framework [RFC4422].
	3.2.1. OAuth Identifiers in the SASL Context		3.2.1. OAuth Identifiers in the SASL Context
	In the OAuth framework the client may be authenticated by the		In the OAuth framework the client may be authenticated by the
	authorization server and the resource owner is authenticated to the		authorization server and the resource owner is authenticated to the
	authorization server. OAuth access tokens may contain information		authorization server. OAuth access tokens may contain information
	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.
	skipping to change at page 9, line 25 ¶		skipping to change at page 9, line 34 ¶
	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
	single scope is preferred, use of a space separated list of		single scope is preferred, use of a space separated list of
	scopes is NOT RECOMMENDED.		scopes is NOT RECOMMENDED.
	oauth-configuration (OPTIONAL): The URL for for a document		openid-configuration (OPTIONAL): The URL for a document following
	following the OpenID Provider Configuration Information schema		the OpenID Provider Configuration Information schema as
	as described in OpenID Connect Discovery [OpenID.Discovery]		described in OpenID Connect Discovery (OIDCD)
	section 3 that is appropriate for the user. This document MUST		[OpenID.Discovery] section 3 that is appropriate for the user.
	have all OAuth related data elements populated. The server MAY		As specified in OIDCD this will have the "https" URL scheme.
	return different URLs for users in different domains and the		This document MUST have all OAuth related data elements
	client SHOULD NOT cache a single returned value and assume it		populated. The server MAY return different URLs for users in
	applies for all users/domains that the server suports. The		different domains and the client SHOULD NOT cache a single
	returned discovery document SHOULD have all data elements		returned value and assume it applies for all users/domains that
	required by the OpenID Connect Discovery specification		the server suports. The returned discovery document SHOULD
	populated. In addition, the discovery document SHOULD contain		have all data elements required by the OpenID Connect Discovery
	the 'registration_endpoint' element to learn about the endpoint		specification populated. In addition, the discovery document
	to be used with the Dynamic Client Registration protocol		SHOULD contain the 'registration_endpoint' element to learn
	[I-D.ietf-oauth-dyn-reg] to obtain the minimum number of		about the endpoint to be used with the Dynamic Client
	parameters necessary for the OAuth protocol exchange to		Registration protocol [I-D.ietf-oauth-dyn-reg] to obtain the
	function. Another comparable discovery or client registration		minimum number of parameters necessary for the OAuth protocol
	mechanism MAY be used if available.		exchange to function. Another comparable discovery or client
			registration 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 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.
	skipping to change at page 10, line 16 ¶		skipping to change at page 10, line 27 ¶
	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
	'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.
	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 SASL [RFC4422] explicitly prohibits additional
	in an unsuccessful authentication outcome. Therefore, the error		information in an unsuccessful authentication outcome. Therefore,
	message is sent in a normal message. The client MUST then send an		the error message is sent in a normal message. The client MUST then
	additional client response consisting of a single %x01 (control A)		send either an additional client response consisting of a single %x01
	character to the server in order to allow the server to finish the		(control A) character to the server in order to allow the server to
	exchange.		finish the exchange or send a SASL cancellation token as generally
			defined in section 3.5 of SASL [RFC4422]. A specific example of a
			cancellation token can be found in IMAP [RFC3501] section 6.2.2.
	3.3. OAuth Access Token Types using Keyed Message Digests		3.3. OAuth Access Token Types using Keyed Message Digests
	OAuth Access Token Types may use keyed message digests and the client		OAuth Access Token Types may use keyed message digests and the client
	and the resource server may need to perform a cryptographic		and the resource server may need to perform a cryptographic
	computation for integrity protection and data origin authentication.		computation for integrity protection and data origin authentication.
	OAuth is designed for access to resources identified by URIs. SASL		OAuth is designed for access to resources identified by URIs. SASL
	is designed for user authentication, and has no facility for more		is designed for user authentication, and has no facility for more
	fine-grained access control. In this specification we require or		fine-grained access control. In this specification we require or
	skipping to change at page 11, line 38 ¶		skipping to change at page 11, line 43 ¶
	In this example the signature base string with line breaks added for		In this example the signature base string with line breaks added for
	readability would be:		readability would be:
	POST&http%3A%2F%2Fexample.com:143%2F&oauth_consumer_key%3D9djdj82h4		POST&http%3A%2F%2Fexample.com:143%2F&oauth_consumer_key%3D9djdj82h4
	8djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_signature_method%3DHMAC-SH		8djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_signature_method%3DHMAC-SH
	A1%26oauth_timestamp%3D137131201%26oauth_token%3Dkkk9d7dh3k39sjv7		A1%26oauth_timestamp%3D137131201%26oauth_token%3Dkkk9d7dh3k39sjv7
	4. Examples		4. Examples
	These examples illustrate exchanges between IMAP and SMTP clients and		These examples illustrate exchanges between IMAP and SMTP clients and
	servers.		servers. All IMAP examples use SASL-IR [RFC4959] and send payload in
			the initial client response. The Bearer Token examples assume
			encrypted transport, if the underlying connection is not already TLS
			then STARTTLS MUST be used as TLS is required in the Bearer Token
			specification.
	Note to implementers: The SASL OAuth method names are case		Note to implementers: The SASL OAuth method names are case
	insensitive. One example uses "Bearer" but that could as easily be		insensitive. One example uses "Bearer" but that could as easily be
	"bearer", "BEARER", or "BeArEr".		"bearer", "BEARER", or "BeArEr".
	4.1. Successful Bearer Token Exchange		4.1. Successful Bearer Token Exchange
	This example shows a successful OAuth 2.0 bearer token exchange in		This example shows a successful OAuth 2.0 bearer token exchange in
	IMAP. Note that line breaks are inserted for readability and the		IMAP. Note that line breaks are inserted for readability. The
	underlying TLS establishment is not shown either.		underlying TLS establishment is not shown but is required for using
			Bearer Tokens per that specification.
	S: * OK IMAP4rev1 Server Ready		S: * OK IMAP4rev1 Server Ready
	C: t0 CAPABILITY		C: t0 CAPABILITY
	S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR		S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c2		C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c2
	VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDRxb		VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDRxb
	VRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB		VRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB
	S: t1 OK SASL authentication succeeded		S: t1 OK SASL authentication succeeded
	As required by IMAP [RFC3501], the payloads are base64-encoded. The		As required by IMAP [RFC3501], the payloads are base64-encoded. The
	decoded initial client response (with %x01 represented as ^A and long		decoded initial client response (with %x01 represented as ^A and long
	lines wrapped for readability) is:		lines wrapped for readability) is:
	n,a=user@example.com,^Ahost=server.example.com^Aport=143^A		n,a=user@example.com,^Ahost=server.example.com^Aport=143^A
	auth=Bearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==^A^A		auth=Bearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==^A^A
	The same credential used in an SMTP exchange is shown below. Note		The same credential used in an SMTP exchange is shown below. Note
	that line breaks are inserted for readability, and that the SMTP		that line breaks are inserted for readability, and that the SMTP
	protocol terminates lines with CR and LF characters (ASCII values		protocol terminates lines with CR and LF characters (ASCII values
	0x0D and 0x0A), these are not displayed explicitly in the example.		0x0D and 0x0A), these are not displayed explicitly in the example.
			Again this example assumes that TLS is already established per the
			Bearer Token specification requirements.
	[connection begins]		[connection begins]
	S: 220 mx.example.com ESMTP 12sm2095603fks.9		S: 220 mx.example.com ESMTP 12sm2095603fks.9
	C: EHLO sender.example.com		C: EHLO sender.example.com
	S: 250-mx.example.com at your service,[172.31.135.47]		S: 250-mx.example.com at your service,[172.31.135.47]
	S: 250-SIZE 35651584		S: 250-SIZE 35651584
	S: 250-8BITMIME		S: 250-8BITMIME
	S: 250-AUTH LOGIN PLAIN OAUTHBEARER		S: 250-AUTH LOGIN PLAIN OAUTHBEARER
	S: 250-ENHANCEDSTATUSCODES		S: 250-ENHANCEDSTATUSCODES
			S: 250-STARTTLS
	S: 250 PIPELINING		S: 250 PIPELINING
	C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c		[Negotiate TLS...]
			C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c
	2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDR		2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDR
	xbVRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB		xbVRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB
	S: 235 Authentication successful.		S: 235 Authentication successful.
	[connection continues...]		[connection continues...]
	4.2. Successful OAuth 1.0a Token Exchange		4.2. Successful OAuth 1.0a Token Exchange
	This IMAP example shows a successful OAuth 1.0a token exchange. Note		This IMAP example shows a successful OAuth 1.0a token exchange. Note
	that line breaks are inserted for readability and the underlying TLS		that line breaks are inserted for readability. This example assumes
	establishment is not shown. Signature computation is discussed in		that TLS is already established. Signature computation is discussed
	Section 3.3.		in Section 3.3.
	S: * OK IMAP4rev1 Server Ready		S: * OK IMAP4rev1 Server Ready
	C: t0 CAPABILITY		C: t0 CAPABILITY
	S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER OAUTH10A SASL-IR		S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER OAUTH10A SASL-IR
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE OAUTH10A bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9ZXhhb		C: t1 AUTH OAUTH10A bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9ZXhhb
	XBsZS5jb20BcG9ydD0xNDMBYXV0aD1PQXV0aCByZWFsbT0iRXhhbXBsZSIsb2F1		XBsZS5jb20BcG9ydD0xNDMBYXV0aD1PQXV0aCByZWFsbT0iRXhhbXBsZSIsb2F1
	dGhfY29uc3VtZXJfa2V5PSI5ZGpkajgyaDQ4ZGpzOWQyIixvYXV0aF90b2tlbj0		dGhfY29uc3VtZXJfa2V5PSI5ZGpkajgyaDQ4ZGpzOWQyIixvYXV0aF90b2tlbj0
	ia2trOWQ3ZGgzazM5c2p2NyIsb2F1dGhfc2lnbmF0dXJlX21ldGhvZD0iSE1BQy		ia2trOWQ3ZGgzazM5c2p2NyIsb2F1dGhfc2lnbmF0dXJlX21ldGhvZD0iSE1BQy
	1TSEExIixvYXV0aF90aW1lc3RhbXA9IjEzNzEzMTIwMSIsb2F1dGhfbm9uY2U9I		1TSEExIixvYXV0aF90aW1lc3RhbXA9IjEzNzEzMTIwMSIsb2F1dGhfbm9uY2U9I
	jdkOGYzZTRhIixvYXV0aF9zaWduYXR1cmU9IlRtOTBJR0VnY21WaGJDQnphV2R1		jdkOGYzZTRhIixvYXV0aF9zaWduYXR1cmU9IlRtOTBJR0VnY21WaGJDQnphV2R1
	WVhSMWNtVSUzRCIBAQ==		WVhSMWNtVSUzRCIBAQ==
	S: t1 OK SASL authentication succeeded		S: t1 OK SASL authentication succeeded
	As required by IMAP [RFC3501], the payloads are base64-encoded. The		As required by IMAP [RFC3501], the payloads are base64-encoded. The
	decoded initial client response (with %x01 represented as ^A and		decoded initial client response (with %x01 represented as ^A and
	skipping to change at page 13, line 41 ¶		skipping to change at page 14, line 7 ¶
	oauth_signature="SSdtIGEgbGl0dGxlIHRlYSBwb3Qu"^A^A		oauth_signature="SSdtIGEgbGl0dGxlIHRlYSBwb3Qu"^A^A
	4.3. Failed Exchange		4.3. Failed Exchange
	This IMAP example shows a failed exchange because of the empty		This IMAP example shows a failed exchange because of the empty
	Authorization header, which is how a client can query for the needed		Authorization header, which is how a client can query for the needed
	scope. Note that line breaks are inserted for readability.		scope. Note that line breaks are inserted for readability.
	S: * OK IMAP4rev1 Server Ready		S: * OK IMAP4rev1 Server Ready
	C: t0 CAPABILITY		C: t0 CAPABILITY
	S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR IMAP4rev1 Server		S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR
	Ready
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW		C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW
	hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=		hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=
	S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl		S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl
	X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4		X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4
	YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u		YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
	In0=		In0=
	C: + AQ==		C: AQ==
	S: t1 NO SASL authentication failed		S: t1 NO SASL authentication failed
	The decoded initial client response is:		The decoded initial client response is:
	n,a=user@example.com,^Ahost=server.example.com^A		n,a=user@example.com,^Ahost=server.example.com^A
	port=143^Aauth=^A^A		port=143^Aauth=^A^A
	The decoded server error response is:		The decoded server error response is:
	{		{
	"status":"invalid_token",		"status":"invalid_token",
	"scope":"example_scope",		"scope":"example_scope",
	"openid-configuration":"https://example.com/.well-known/openid-configuration"		"openid-configuration":"https://example.com/.well-known/openid-configuration"
	}		}
	The client responds with the required dummy response, "AQ==" is the		The client responds with the required dummy response, "AQ==" is the
	base64 encoding of the ASCII value 0x01.		base64 encoding of the ASCII value 0x01. The same exchange using the
			IMAP specific method of cancelling an AUTHENTICATE command sends "*"
			and is shown below.
			S: * OK IMAP4rev1 Server Ready
			C: t0 CAPABILITY
			S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR IMAP4rev1
			S: t0 OK Completed
			C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW
			hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=
			S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl
			X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4
			YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
			In0=
			C: *
			S: t1 NO SASL authentication failed
	4.4. SMTP Example of a Failed Negotiation		4.4. SMTP Example of a Failed Negotiation
	This example shows an authorization failure in an SMTP exchange.		This example shows an authorization failure in an SMTP exchange.
	Note that line breaks are inserted for readability, and that the SMTP		Note that line breaks are inserted for readability, and that the SMTP
	protocol terminates lines with CR and LF characters (ASCII values		protocol terminates lines with CR and LF characters (ASCII values
	0x0D and 0x0A), these are not displayed explicitly in the example.		0x0D and 0x0A), these are not displayed explicitly in the example.
			TLS negotiation is not shown but as noted above it is required for
			the use of Bearer Tokens.
	[connection begins]		[connection begins]
	S: 220 mx.example.com ESMTP 12sm2095603fks.9		S: 220 mx.example.com ESMTP 12sm2095603fks.9
	C: EHLO sender.example.com		C: EHLO sender.example.com
	S: 250-mx.example.com at your service,[172.31.135.47]		S: 250-mx.example.com at your service,[172.31.135.47]
	S: 250-SIZE 35651584		S: 250-SIZE 35651584
	S: 250-8BITMIME		S: 250-8BITMIME
	S: 250-AUTH LOGIN PLAIN OAUTHBEARER		S: 250-AUTH LOGIN PLAIN OAUTHBEARER
	S: 250-ENHANCEDSTATUSCODES		S: 250-ENHANCEDSTATUSCODES
	S: 250 PIPELINING		S: 250 PIPELINING
	skipping to change at page 17, line 17 ¶		skipping to change at page 18, line 4 ¶
	SASL mechanism profile: OAUTH10A		SASL mechanism profile: 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		Owner/Change controller: the IETF
	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.
	[OpenID.Discovery]		[OpenID.Discovery]
	Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID		Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
	Connect Discovery 1.0", July 2011.		Connect Discovery 1.0", July 2011.
	[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.
			[RFC2244] Newman, C. and J. Myers, "ACAP -- Application
			Configuration Access Protocol", RFC 2244, November 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.
	[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
	skipping to change at page 18, line 27 ¶		skipping to change at page 19, line 13 ¶
	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		[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, March 2014.		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-22 (work in progress), January
	2014.		2015.
	[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-31 (work in		(JWT)", draft-ietf-oauth-json-web-token-32 (work in
	progress), November 2014.		progress), December 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.
			[RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
			Simple Authentication and Security Layer (SASL) Initial
			Client Response", RFC 4959, September 2007.
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	October 2008.		October 2008.
	[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence		[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
	Protocol (XMPP): Core", RFC 6120, March 2011.		Protocol (XMPP): Core", RFC 6120, March 2011.
	[RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0		[RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
	Threat Model and Security Considerations", RFC 6819,		Threat Model and Security Considerations", RFC 6819,
	January 2013.		January 2013.
	skipping to change at page 19, line 23 ¶		skipping to change at page 20, line 13 ¶
	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 ]]
			-19
			o Last call feedback agaiun.
			o Clarified usage of TLS in examples and fixed them some more.
			Adding reference to RFC4422 and cancellation token and an example
			for that.
	-18		-18
	o Last call feedback round #5. Fixed -17 change log.		o Last call feedback round #5. Fixed -17 change log.
	o Corrected "issue" to "iss", other minor changes.		o Corrected "issue" to "iss", other minor changes.
	-17		-17
	o Last call feedback again (WGLC #4). eradicated comma splicing.		o Last call feedback again (WGLC #4). eradicated comma splicing.
	Removed extra server message in example 4.3.		Removed extra server message in example 4.3.
End of changes. 38 change blocks.
	68 lines changed or deleted		117 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/