< draft-ietf-kitten-sasl-oauth-00.txt		draft-ietf-kitten-sasl-oauth-01.txt >
	KITTEN W. Mills		KITTEN W. Mills
	Internet-Draft T. Showalter		Internet-Draft Yahoo! Inc.
	Intended status: Standards Track Yahoo! Inc.		Intended status: Standards Track T. Showalter
	Expires: May 17, 2012 H. Tschofenig		Expires: December 1, 2012
			H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	November 14, 2011		May 30, 2012
	A SASL and GSS-API Mechanism for OAuth		A SASL and GSS-API Mechanism for OAuth
	draft-ietf-kitten-sasl-oauth-00.txt		draft-ietf-kitten-sasl-oauth-01
	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 OAuth over the		This document defines how an application client uses OAuth over the
	Simple Authentication and Security Layer (SASL) or the Generic		Simple Authentication and Security Layer (SASL) or the Generic
	Security Service Application Program Interface (GSS-API) to access a		Security Service Application Program Interface (GSS-API) to access a
	protected resource at a resource serve, and additionally defines		protected resource at a resource serve. Thereby, it enables schemes
	authorization and token issuing endpoint discovery. Thereby, it		defined within the OAuth framework for non-HTTP-based application
	enables schemes defined within the OAuth framework for non-HTTP-based		protocols.
	application protocols.
	Clients typically store the user's long term credential. This does,		Clients typically store the user's long term credential. This does,
	however, lead to significant security vulnerabilities, for example,		however, lead to significant security vulnerabilities, for example,
	when such a credential leaks. A significant benefit of OAuth for		when such a credential leaks. A significant benefit of OAuth for
	usage in those clients is that the password is replaced by a token.		usage in those clients is that the password is replaced by a token.
	Tokens typically provided limited access rights and can be managed		Tokens typically provided limited access rights and can be managed
	and revoked separately from the user's long-term credential		and revoked separately from the user's long-term credential
	(password).		(password).
	Status of this Memo		Status of this Memo
	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 17, 2012.		This Internet-Draft will expire on December 1, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. OAuth SASL Mechanism Specification . . . . . . . . . . . . . . 8		3. OAuth SASL Mechanism Specification . . . . . . . . . . . . . . 8
	3.1. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8		3.1. Initial Client Response . . . . . . . . . . . . . . . . . 8
	3.2. Initial Client Response . . . . . . . . . . . . . . . . . 8		3.1.1. Reserved Key/Values in OAUTH . . . . . . . . . . . . . 8
	3.2.1. Query String in OAUTH-PLUS . . . . . . . . . . . . . . 9		3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 9
	3.3. Server's Response . . . . . . . . . . . . . . . . . . . . 9		3.2.1. Mapping to SASL Identities . . . . . . . . . . . . . . 9
	3.4. Mapping to SASL Identities . . . . . . . . . . . . . . . . 10		3.2.2. Server response to failed authentication. . . . . . . 10
	3.5. Discovery Information . . . . . . . . . . . . . . . . . . 10		3.3. Use of Signature Type Authorization . . . . . . . . . . . 10
	3.6. Use of Signature Type Authorization . . . . . . . . . . . 12		3.4. Channel Binding . . . . . . . . . . . . . . . . . . . . . 11
	4. GSS-API OAuth Mechanism Specification . . . . . . . . . . . . 14		4. GSS-API OAuth Mechanism Specification . . . . . . . . . . . . 12
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.1. Successful Bearer Token Exchange . . . . . . . . . . . . . 15		5.1. Successful Bearer Token Exchange . . . . . . . . . . . . . 13
	5.2. MAC Authentication with Channel Binding . . . . . . . . . 15		5.2. MAC Authentication with Channel Binding . . . . . . . . . 13
	5.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 16		5.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 14
	5.4. Failed Channel Binding . . . . . . . . . . . . . . . . . . 17		5.4. Failed Channel Binding . . . . . . . . . . . . . . . . . . 15
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 18		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 19		7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 17
	7.2. GSS-API Registration . . . . . . . . . . . . . . . . . . . 19		7.2. GSS-API Registration . . . . . . . . . . . . . . . . . . . 17
	7.3. Link Type Registration . . . . . . . . . . . . . . . . . . 19		8. Appendix A -- Document History . . . . . . . . . . . . . . . . 18
	7.3.1. OAuth 2 Authentication Endpoint . . . . . . . . . . . 19		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	7.3.2. OAuth 2 Token Endpoint . . . . . . . . . . . . . . . . 20		9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	7.3.3. OAuth 1.0a Request Initiation Endpoint . . . . . . . . 20		9.2. Informative References . . . . . . . . . . . . . . . . . . 20
	7.3.4. OAuth 1.0a Authorization Endpoint . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	7.3.5. OAuth 1.0a Token Endpoint . . . . . . . . . . . . . . 21
	8. Appendix A -- Document History . . . . . . . . . . . . . . . . 22
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
	9.2. Informative References . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	OAuth [I-D.ietf-oauth-v2] enables a third-party application to obtain		OAuth [I-D.ietf-oauth-v2] enables a third-party application to obtain
	limited access to a protected resource, either on behalf of a		limited access to a protected resource, either on behalf of a
	resource owner by orchestrating an approval interaction, or by		resource owner by orchestrating an approval interaction, or by
	allowing the third-party application to obtain access on its own		allowing the third-party application to obtain access on its own
	behalf. The core OAuth specification [I-D.ietf-oauth-v2] does not		behalf. The core OAuth specification [I-D.ietf-oauth-v2] does not
	define the interaction between the client and the resource server		define the interaction between the client and the resource server
	with the access to a protected resource using an Access Token. This		with the access to a protected resource using an Access Token. This
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 4 ¶
	validates the authorization grant, and if valid issues an access		validates the authorization grant, and if valid issues an access
	token.		token.
	(E) The client requests the protected resource from the resource		(E) The client requests the protected resource from the resource
	server and authenticates by presenting the access token.		server and authenticates by presenting the access token.
	(F) The resource server validates the access token, and if valid,		(F) The resource server validates the access token, and if valid,
	serves the request.		serves the request.
	Steps (E) and (F) are not defined in [I-D.ietf-oauth-v2] and are the		Steps (E) and (F) are not defined in [I-D.ietf-oauth-v2] and are the
	main functionality specified within this document. Additionally, an		main functionality specified within this document. Consequently, the
	optional discovery exchange is defined. Consequently, the message		message exchange shown in Figure 2 is the result of this
	exchange shown in Figure 2 is the result of this specification. (1)		specification. The client will genrally need to determine the
	and (2) denote the optional discovery exchange steps that may happen		authentication endpoints (and perhaps the service endpoints) before
	before the OAuth 2.0 protocol exchange messages in steps (A)-(D) are		the OAuth 2.0 protocol exchange messages in steps (A)-(D) are
	executed. Steps (E) and (F) also defined in this specification.		executed. The discovery of the resource owner and authorization
			server endpoints is outside the scope of this specification. The
			client must discover those endpoints using a discovery mechanisms
			such as Webfinger using host-meta [I-D.jones-appsawg-webfinger]. In
			band discovery is not tenable if clients support the OAuth 2.0
			password grant. Once credentials are obtained the client proceeds to
			steps (E) and (F) defined in this specification.
	----+		----+
	+--------+ +---------------+ |		+--------+ +---------------+ |
	| |--(A)-- Authorization Request --->| Resource | |		| |--(A)-- Authorization Request --->| Resource | |
	| | | Owner | |Plain		| | | Owner | |Plain
	| |<-(B)------ Access Grant ---------| | |OAuth		| |<-(B)------ Access Grant ---------| | |OAuth
	| | +---------------+ |2.0		| | +---------------+ |2.0
	| | |		| | |
	| | Client Credentials & +---------------+ |		| | Client Credentials & +---------------+ |
	| |--(C)------ Access Grant -------->| Authorization | |		| |--(C)------ Access Grant -------->| Authorization | |
	| Client | | Server | |		| Client | | Server | |
	| |<-(D)------ Access Token ---------| | |		| |<-(D)------ Access Token ---------| | |
	| | (w/ Optional Refresh Token) +---------------+ |		| | (w/ Optional Refresh Token) +---------------+ |
	| | ----+		| | ----+
	| |
	| | ----+		| | ----+
	| | (Optional discovery) +---------------+ |		| | +---------------+ |
	| |--(1)------- User Name --------->| | |		| | | | |OAuth
	| Client | | | |		| |--(E)------ Access Token -------->| Resource | |over
	| |<-(2)------ Authentication -------| | |		| | | Server | |SASL/
	| | endpoint information | Resource | |OAuth		| |<-(F)---- Protected Resource -----| | |GSS-
	| | | Server | |over		| | | | |API
	| |--(E)------ Access Token -------->| | |SASL/
	| | | | |GSS-
	| |<-(F)---- Protected Resource -----| | |API
	+--------+ +---------------+ |		+--------+ +---------------+ |
	----+		----+
	Figure 2: OAuth SASL Architecture		Figure 2: OAuth SASL Architecture
	Note: The discovery procedure in OAuth is still work in progress.
	Hence, the discovery components described in this document should
	be considered incomplete and a tentative proposal. In general,
	there is a trade off between a generic, externally available
	defined discovery mechanisms (such as Webfinger using host-meta
	[I-D.hammer-hostmeta], or [I-D.jones-simple-web-discovery]) and
	configuration information exchanged in-band between the SASL
	communication endpoints.
	It is worthwhile to note that this specification is also compatible		It is worthwhile to note that this specification is also compatible
	with OAuth 1.0a [RFC5849].		with OAuth 1.0a [RFC5849].
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	The reader is assumed to be familiar with the terms used in the OAuth		The reader is assumed to be familiar with the terms used in the OAuth
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 10 ¶
	server respectively. Line breaks have been inserted for readability.		server respectively. Line breaks have been inserted for readability.
	Note that the IMAP SASL specification requires base64 encoding		Note that the IMAP SASL specification requires base64 encoding
	message, not this memo.		message, not this memo.
	3. OAuth SASL Mechanism Specification		3. OAuth SASL Mechanism Specification
	SASL is used as a generalized authentication method in a variety of		SASL is used as a generalized authentication method in a variety of
	application layer protocols. This document defines two SASL		application layer protocols. This document defines two SASL
	mechanisms for usage with OAuth: "OAUTH" and "OAUTH-PLUS". The		mechanisms for usage with OAuth: "OAUTH" and "OAUTH-PLUS". The
	"OAUTH" SASL mechanism provides bearer token alike semantic for SASL		"OAUTH" SASL mechanism enables OAuth authorizattion schemes for SASL,
	while "OAUTH-PLUS" provides a semantic similar to OAuth MAC		"OAUTH-PLUS" adds channel binding [RFC5056] capability for additional
	authentication by utilizing a channel binding mechanism [RFC5056].		security guarantees.
	3.1. Channel Binding
	If the specification for the underlying authorization scheme requires
	a security layer, such as TLS [RFC5246], the server SHOULD only offer
	a mechanism where channel binding can be enabled.
	The channel binding data is computed by the client based on it's		3.1. Initial Client Response
	choice of preferred channel binding type. As specified in [RFC5056],
	the channel binding information MUST start with the channel binding
	unique prefix, followed by a colon (ASCII 0x3A), followed by a base64
	encoded channel binding payload. The channel binding payload is the
	raw data from the channel binding type if the raw channel binding
	data is less than 500 bytes. If the raw channel binding data is 500
	bytes or larger then a SHA-1 [RFC3174] hash of the raw channel
	binding data is computed.
	If the client is using tls-unique for a channel binding then the raw		Client responses are a key/value pair sequence. These key/value
	channel binding data equals the first TLS finished message. This is		pairs carry the equivalent values form an HTTP context in order to be
	under the 500 byte limit, so the channel binding payload sent to the		able to complete an OAuth style HTTP authorization. The ABNF
	server would be the base64 encoded first TLS finished message.		[RFC2234] syntax is:
	In the case where the client has chosen tls-endpoint, the raw channel		kvsep = %x01
	binding data is the certificate of the server the client connected		key = 1*ALPHA
	to, which will frequently be 500 bytes or more. If it is then the		value = *(VCHAR | SP | HTAB | CR | LF )
	channel binding payload is the base64 encoded SHA-1 hash of the		kvpair = key "=" value kvsep
	server certificate.		client_resp = 1*kvpair kvsep
	3.2. Initial Client Response		The following key/value pairs are defined in the client response:
	The SASL client response is formatted as an HTTP [RFC2616] request.		auth (REQUIRED): The payload of the HTTP Authorization header for
	The HTTP request is limited in that the path MUST be "/". In the		an equivalent HTTP OAuth authroization.
	OAUTH mechanism no query string is allowed. The following header
	lines are defined in the client response:
	User (OPTIONAL): Contains the user identifier being		host: Contains the host name to which the client connected.
	authenticated, and is provided to allow correct discovery
	information to be returned.
	Host (REQUIRED): Contains the host name to which the client		port: Contains the port number represented as a decimal positive
			integer string without leading zeros to which the client
	connected.		connected.
	Authorization (REQUIRED): An HTTP Authorization header.		In authorization schemes that use signatures, the client MUST send
			host and port number key/values, and the server MUST fail
			authorization request requiring signatures that do not have host and
			port values.
	The user name is provided by the client to allow the discovery		3.1.1. Reserved Key/Values in OAUTH
	information to be customized for the user, a given server could allow
	multiple authenticators and it needs to return the correct one. For
	instance, a large ISP could provide mail service for several domains
	who manage their own user information. For instance, users at foo-
	example.com could be authenticated by an OAuth service at
	https://oauth.foo-example.com/, and users at bar-example.com could be
	authenticated by https://oauth.bar-example.com, but both could be
	served by a hypothetical IMAP server running at a third domain,
	imap.example.net.
	3.2.1. Query String in OAUTH-PLUS		In the OAUTH mechanism values for path, query string and post body
			are assigned default values. OAuth authorization schemes MAY define
			usage of these in the SASL context and extend this specification.
			For OAuth schemes that use request signatures the default values MUST
			be used unless explict values are provided in the client response.
			The following key values are reserved for future use:
	In the OAUTH-PLUS mechanism the channel binding information is		path (RESERVED): HTTP path data, the default value is "/".
	carried in the query string. OAUTH-PLUS defines following query
	parameter(s):
	cbdata (REQUIRED): Contains the base64 encoded channel binding		qs (RESERVED): HTTP query string, the default value is "".
	data, properly escaped as an HTML query parameter value.
	3.3. Server's Response		post (RESERVED): HTTP post data, the default value is "".
			3.2. Server's Response
	The server validates the response per the specification for the		The server validates the response per the specification for the
	authorization scheme used. If the authorization scheme used includes		authorization scheme used. If the authorization scheme used includes
	signing of the request parameters the client must provide a complete		signing of the request parameters the client must provide a client
	HTTP style request that satisfies the data requirements for the		response that satisfies the data requirements for the scheme in use.
	scheme in use.
	In the OAUTH-PLUS mechanism the server examines the channel binding		In the OAUTH-PLUS mechanism the server examines the channel binding
	data, extracts the channel binding unique prefix, and extracts the		data, extracts the channel binding unique prefix, and extracts the
	raw channel biding data based on the channel binding type used. It		raw channel biding data based on the channel binding type used. It
	then computes it's own copy of the channel binding payload and		then computes it's own copy of the channel binding payload and
	compares that to the payload sent by the client in the query		compares that to the payload sent by the client in the cbdata key/
	parameters of the tunneled HTTP request. Those two must be equal for		value. Those two must be equal for channel binding to succeed.
	channel binding to succeed.
	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 authentication scheme MUST		completing the SASL negotiation. The authentication scheme MUST
	carry the user ID to be used as the authorization identity (identity		carry the user ID to be used as the authorization identity (identity
	to act as). The server MUST use that ID as the user being		to act as). The server MUST use the ID obtained from the credential
	authorized, that is the user assertion we accept and not other		as the user being authorized.
	information such as from the URL or "User:" header.
	The server responds to failed authentication by sending discovery
	information in an HTTP style response with the HTTP status code set
	to 401, and then failing the authentication.
	If channel binding is in use and the channel binding fails the server
	responds with a minimal HTTP response without discovery information
	and the HTTP status code set to 412 to indicate that the channel
	binding precondition failed. If the authentication scheme in use
	does not include signing the server SHOULD revoke the presented
	credential and the client SHOULD discard that credential.
	3.4. Mapping to SASL Identities		3.2.1. Mapping to SASL Identities
	Some OAuth mechanisms can provide both an authorization identity and		Some OAuth mechanisms can provide both an authorization identity and
	an authentication identity. An example of this is OAuth 1.0a		an authentication identity. An example of this is OAuth 1.0a
	[RFC5849] where the consumer key (oauth_consumer_key) identifies the		[RFC5849] where the consumer key (oauth_consumer_key) identifies the
	entity using to token which equates to the SASL authentication		entity using to token which equates to the SASL authentication
	identity, and is authenticated using the shared secret. The		identity, and is authenticated using the shared secret. The
	authorization identity in the OAuth 1.0a case is carried in the token		authorization identity in the OAuth 1.0a case is carried in the token
	(per the requirement above), which SHOULD validated independently.		(per the requirement above), which SHOULD validated independently.
	The server MAY use a consumer key or other comparable identity in the		The server MAY use a consumer key, a value derived from it, or other
	OAuth authorization scheme as the SASL authentication identity. If		comparable identity in the OAuth authorization scheme as the SASL
	an appropriate authentication identity is not available the server		authentication identity. If an appropriate authentication identity
	MUST use the identity asserted in the token.		is not available the server MUST use the authorization identity as
			the wuthentication identity.
	3.5. Discovery Information
	The server MUST send discovery information in response to a failed
	authentication exchange or a request with an empty Authorization
	header. If discovery information is returned it MUST include an
	authentication endpoint appropriate for the user. If the "User"
	header is present the discovery information MUST be for that user.
	Discovery information is provided by the server to the client to
	allow a client to discover the appropriate OAuth authentication and
	token endpoints. The client then uses that information to obtain the
	access token needed for OAuth authentication. The client SHOULD
	cache and re-use the user specific discovery information for service
	endpoints.
	Discovery information makes use of both the WWW-Authenticate header
	as defined in HTTP Authentication: Basic and Digest Access
	Authentication [RFC2617] and Link headers as defined in [RFC5988].
	The following elements are defined for discovery information:
	WWW-Authenticate A WWW-Authenticate header for each authentication
	scheme supported by the server. Authentication scheme names are
	case insensitive. The following [RFC2617] authentication
	parameters are defined:
	realm REQUIRED -- (as defined by RFC2617)
	scope OPTIONAL -- A quoted string. This provides the client an
	OAuth 2 scope known to be valid for the resource.
	oauth2-authenticator An [RFC5988] Link header specifying the
	[I-D.ietf-oauth-v2] authentication endpoint. This link has an
	OPTIONAL link-extension "scheme", if included this link applies
	ONLY to the specified scheme.
	oauth2-token An [RFC5988] Link header specifying the
	[I-D.ietf-oauth-v2] token endpoint. This link has an OPTIONAL
	link-extension "scheme", if included this link applies ONLY to the
	specified scheme.
	oauth-initiate (Optional) An [RFC5988] Link header specifying the		3.2.2. Server response to failed authentication.
	OAuth1.0a [RFC5849] initiation endpoint. The server MUST send
	this if "OAuth" is included in the supported list of HTTP
	authentication schemes for the server.
	oauth-authorize (Optional) An [RFC5988] Link header specifying the		For a failed authentication the server returns a JSON [RFC4627]
	OAuth1.0a [RFC5849] authentication endpoint. The server MUST send		formatted error result, and fails the authentication. The error
	this if "OAuth" is included in the supported list of HTTP		result consists of the following values:
	authentication schemes for the server.
	oauth-token (Optional) An [RFC5988] Link header specifying the		status (REQUIRED): The authorization error code. Valid error
	OAuth1.0a [RFC5849] token endpoint. The server MUST send this if		codes are defined in the IANA [[need registry name]] registry
	"OAuth" is included in the supported list of HTTP authentication		specified in the OAuth 2 core specification.
	schemes for the server. This link type has one link-extension
	"grant-types" which is a space separated list of the OAuth 2.0
	grant types that can be used at the token endpoint to obtain a
	token.
	Usage of the URLs provided in the discovery information is defined in		scope (OPTIONAL): The OAuth scope required to access the service.
	the relevant specifications. If the server supports multiple
	authenticators the discovery information returned for unknown users
	MUST be consistent with the discovery information for known users to
	prevent user enumeration. The OAuth 2.0 specification
	[I-D.ietf-oauth-v2] supports multiple types of authentication schemes
	and the server MUST specify at least one supported authentication
	scheme in the discovery information. The server MAY support multiple
	schemes and MAY support schemes not listed in the discovery
	information.
	If the resource server provides a scope the client SHOULD always		If the resource server provides a scope the client SHOULD always
	request scoped tokens from the token endpoint. The client MAY use a		request scoped tokens from the token endpoint. The client MAY use a
	scope other than the one provided by the resource server. Scopes		scope other than the one provided by the resource server. Scopes
	other than those advertised by the resource server must be defined by		other than those advertised by the resource server are be defined by
	the resource owner and provided in service documentation (which is		the resource owner and provided in service documentation or discovery
	beyond the scope of this memo).		information (which is beyond the scope of this memo). If not present
			then the client SHOULD presume an empty scope (unscoped token) is
			needed.
	3.6. Use of Signature Type Authorization		If channel binding is in use and the channel binding fails the server
			responds with a status code set to 412 to indicate that the channel
			binding precondition failed. If the authentication scheme in use
			does not include signing the server SHOULD revoke the presented
			credential and the client SHOULD discard that credential.
			3.3. Use of Signature Type Authorization
	This mechanism supports authorization using signatures, which		This mechanism supports authorization using signatures, which
	requires that both client and server construct the string to be		requires that both client and server construct the string to be
	signed. OAuth 2 is designed for authentication/authorization to		signed. OAuth 2 is designed for authentication/authorization to
	access specific URIs. SASL is designed for user authentication, and		access specific URIs. SASL is designed for user authentication, and
	has no facility for being more specific. In this mechanism we		has no facility for being more specific. In this mechanism we
	require an HTTP style format specifically to support signature type		require or define default values for the data elements from an HTTP
	authentication, but this is extremely limited. The HTTP style		request which allow the signature base string to be constructed
	request is limited to a path of "/". This mechanism is in the SASL		properly. The default HTTP path is "/" and the default post body is
	model, but is designed so that no changes are needed if there is a		empty. These atoms are defined as extension points so that no
	revision of SASL which supports more specific resource authorization,		changes are needed if there is a revision of SASL which supports more
	e.g. IMAP access to a specific folder or FTP access limited to a		specific resource authorization, e.g. IMAP access to a specific
	specific directory.		folder or FTP access limited to a specific directory.
	Using the example in the MAC specification		Using the example in the MAC specification
	[I-D.ietf-oauth-v2-http-mac] as a starting point, on an IMAP server		[I-D.ietf-oauth-v2-http-mac] as a starting point, on an IMAP server
	running on port 143 and given the MAC style authorization request		running on port 143 and given the MAC style authorization request
	(with long lines wrapped for readability) below:		(with %x01 shown as ^A and long lines wrapped for readability) below:
	GET / HTTP/1.1		host=server.example.com^A
	Host: server.example.com		port=143^A
	User: user@example.com		auth=MAC token="h480djs93hd8",timestamp="137131200",nonce="dj83hs9s",
	Authorization: MAC token="h480djs93hd8",timestamp="137131200",		signature="YTVjyNSujYs1WsDurFnvFi4JK6o="^A^A
	nonce="dj83hs9s",signature="YTVjyNSujYs1WsDurFnvFi4JK6o="
	The normalized request string would be constructed per the MAC		The normalized request string would be constructed per the MAC
	specification [I-D.ietf-oauth-v2-http-mac]. In this example the		specification [I-D.ietf-oauth-v2-http-mac]. In this example the
	normalized request string with the new line separator character is		normalized request string with the new line separator character is
	represented by "\n" for display purposes only would be:		represented by "\n" for display purposes only would be:
	h480djs93hi8\n		h480djs93hi8\n
	137131200\n		137131200\n
	dj83hs9s\n		dj83hs9s\n
	\n		\n
	GET\n		GET\n
	server.example.com\n		server.example.com\n
	143\n		143\n
	/\n		/\n
	\n		\n
			3.4. Channel Binding
			If the specification for the underlying authorization scheme requires
			a security layer, such as TLS [RFC5246], the server SHOULD only offer
			a mechanism where channel binding can be enabled.
			The channel binding data is computed by the client based on it's
			choice of preferred channel binding type. As specified in [RFC5056],
			the channel binding information MUST start with the channel binding
			unique prefix, followed by a colon (ASCII 0x3A), followed by a base64
			encoded channel binding payload. The channel binding payload is the
			raw data from the channel binding type if the raw channel binding
			data is less than 500 bytes. If the raw channel binding data is 500
			bytes or larger then a SHA-1 [RFC3174] hash of the raw channel
			binding data is computed.
			If the client is using tls-unique for a channel binding then the raw
			channel binding data equals the first TLS finished message. This is
			under the 500 byte limit, so the channel binding payload sent to the
			server would be the base64 encoded first TLS finished message.
			In the case where the client has chosen tls-endpoint, the raw channel
			binding data is the certificate of the server the client connected
			to, which will frequently be 500 bytes or more. If it is then the
			channel binding payload is the base64 encoded SHA-1 hash of the
			server certificate.
	4. GSS-API OAuth Mechanism Specification		4. GSS-API OAuth Mechanism Specification
	Note: The normative references in this section are informational for		Note: The normative references in this section are informational for
	SASL implementers, but they are normative for GSS-API implementers.		SASL implementers, but they are normative for GSS-API implementers.
	The SASL OAuth mechanism is also a GSS-API mechanism and the messages		The SASL OAuth mechanism is also a GSS-API mechanism and the messages
	described in Section 3 are the same, but		described in Section 3 are the same, but
	1. the GS2 header on the client's first message is excluded when		1. the GS2 header on the client's first message is excluded when
	OAUTH is used as a GSS-API mechanism, and		OAUTH is used as a GSS-API mechanism, and
	skipping to change at page 15, line 20 ¶		skipping to change at page 13, line 20 ¶
	5.1. Successful Bearer Token Exchange		5.1. Successful Bearer Token Exchange
	This example shows a successful OAuth 2.0 bearer token exchange with		This example shows a successful OAuth 2.0 bearer token exchange with
	an initial client response. Note that line breaks are inserted for		an initial client response. Note that line breaks are inserted for
	readability.		readability.
	S: * IMAP4rev1 Server Ready		S: * IMAP4rev1 Server Ready
	C: t0 CAPABILITY		C: t0 CAPABILITY
	S: * CAPABILITY IMAP4rev1 AUTH=OAUTH		S: * CAPABILITY IMAP4rev1 AUTH=OAUTH
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE OAUTH R0VUIC8gSFRUUC8xLjENCkhvc3Q6IGltYXAuZXhhbXBs		C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMB
	ZS5jb20NCkF1dGhvcml6YXRpb246IEJFQVJFUiAidkY5ZGZ0NHFtVGMyTnZiM1J		YXV0aD1CRUFSRVIgdkY5ZGZ0NHFtVGMyTnZiM1JsY2tCaGJIUmhkbWx6ZEdFdVk
	sY2tCaGJIUmhkbWx6ZEdFdVkyOXRDZz09Ig0KDQo=		yOXRDZz09AQE=
	S: +		S: +
	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 is:		decoded initial client response (with %x01 represented as ^A and long
			lines wrapped for readability) is:
	GET / HTTP/1.1		host=server.example.com^Aport=143^A
	Host: imap.example.com		auth=BEARER "vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=="^A^A
	Authorization: BEARER "vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=="
	The line containing just a "+" and a space is an empty response from		The line containing just a "+" and a space is an empty response from
	the server. This response contains discovery information, and in the		the server. This response contains error information, and in the
	success case no discovery information is necessary so the response is		success case the error response is empty. Like other messages, and
	empty. Like other messages, and in accordance with the IMAP SASL		in accordance with the IMAP SASL binding, the empty response is
	binding, the empty response is base64-encoded.		base64-encoded.
	5.2. MAC Authentication with Channel Binding		5.2. MAC Authentication with Channel Binding
	This example shows a channel binding failure. The example sends the		This example shows a channel binding failure. The example sends the
	same request as above, but in the context of an OAUTH-PLUS exchange		same request as above, but in the context of an OAUTH-PLUS exchange
	the channel binding information is missing. Note that line breaks		the channel binding information is missing. Note that line breaks
	are inserted for readability.		are inserted for readability.
	S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready		S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE MAC R0VUIC8/Y2JkYXRhPSJTRzkzSUdKcFp5QnBjeUJoSUZSTVV5Q		C: t1 AUTHENTICATE MAC aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMBYXV0a
	m1hVzVoYkNCdFpYTnpZV2RsUHdvPSIgSFRUUC8xLjENCkhvc3Q6IHNlcnZlci5leGFtcG		D1NQUMgdG9rZW49Img0ODBkanM5M2hkOCIsdGltZXN0YW1wPSIxMzcxMzEyMDAiLG5vbm
	xlLmNvbQ0KVXNlcjogdXNlckBleGFtcGxlLmNvbQ0KQXV0aG9yaXphdGlvbjogTUFDIHR		NlPSJkajgzaHM5cyIsc2lnbmF0dXJlPSJZVFZqeU5TdWpZczFXc0R1ckZudkZpNEpLNm8
	va2VuPSJoNDgwZGpzOTNoZDgiLHRpbWVzdGFtcD0iMTM3MTMxMjAwIixub25jZT0iZGo4		9IgFjYmRhdGE9U0c5M0lHSnBaeUJwY3lCaElGUk1VeUJtYVc1aGJDQnRaWE56WVdkbFB3
	M2hzOXMiLHNpZ25hdHVyZT0iV1c5MUlHMTFjM1FnWW1VZ1ltOXlaV1F1SUFvPSINCg0K		bz0BAQ==
	S: +		S: +
	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 is:		decoded initial client response (with %x01 represented as ^A and long
			lines wrapped for readability) is:
	GET /?cbdata="SG93IGJpZyBpcyBhIFRMUyBmaW5hbCBtZXNzYWdlPwo=" HTTP/1.1		-
	Host: server.example.com		host=server.example.com^A
	User: user@example.com		port=143^A
	Authorization: MAC token="h480djs93hd8",timestamp="137131200",		auth=MAC token="h480djs93hd8",timestamp="137131200",nonce="dj83hs9s",
	nonce="dj83hs9s",signature="WW91IG11c3QgYmUgYm9yZWQuIAo="		signature="YTVjyNSujYs1WsDurFnvFi4JK6o="^A
			cbdata=SG93IGJpZyBpcyBhIFRMUyBmaW5hbCBtZXNzYWdlPwo=^A^A
	The line containing just a "+" and a space is an empty response from		The line containing just a "+" and a space is an empty response from
	the server. This response contains discovery information, and in the		the server. This response contains discovery information, and in the
	success case no discovery information is necessary so the response is		success case no discovery information is necessary so the response is
	empty. Like other messages, and in accordance with the IMAP SASL		empty. Like other messages, and in accordance with the IMAP SASL
	binding, the empty response is base64-encoded.		binding, the empty response is base64-encoded.
	5.3. Failed Exchange		5.3. Failed Exchange
	This example shows a failed exchange because of the empty		This example shows a failed exchange because of the empty
	Authorization header, which is how a client can query for discovery		Authorization header, which is how a client can query for the needed
	information. Note that line breaks are inserted for readability.		scope. Note that line breaks are inserted for readability.
	S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready		S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE OAUTH R0VUIC8gSFRUUC8xLjENClVzZXI6IHNjb290ZXJAYW		C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xND
	x0YXZpc3RhLmNvbQ0KSG9zdDogaW1hcC55YWhvby5jb20NCkF1dGhlbnRpY2F0ZT		MBYXV0aD0BAQ==
	ogDQoNCg==		S: + ewoic3RhdHVzIjoiNDAxIiwKInNjb3BlIjoiZXhhbXBsZV9zY29wZSIKfQo=
	S: + SFRUUC8xLjEgNDAxIFVuYXV0aG9yaXplZA0KV1dXLUF1dGhlbnRpY2F0ZTogQk
	VBUkVSIHJlYWxtPSJleGFtcGxlLmNvbSINCkxpbms6IDxodHRwczovL2xvZ2luLn
	lhaG9vLmNvbS9vYXV0aD4gcmVsPSJvYXV0aDItYXV0aGVudGljYXRvciIgIA0KTG
	luazogPGh0dHBzOi8vbG9naW4ueWFob28uY29tL29hdXRoPiByZWw9Im91YXRoMi
	10b2tlbiINCg0K
	S: t1 NO SASL authentication failed		S: t1 NO SASL authentication failed
	The decoded initial client response is:		The decoded initial client response is:
	GET / HTTP/1.1		host=server.example.com^Aport=143^Aauth=^A^A
	User: alice@example.com
	Host: imap.example.com
	Authorization:
	The decoded server discovery response is:		The decoded server error response is:
	HTTP/1.1 401 Unauthorized		{
	WWW-Authenticate: BEARER realm="example.com"		"status":"401",
	Link: <https://login.example.com/oauth> rel="oauth2-authenticator"		"scope":"example_scope"
	Link: <https://login.example.com/oauth> rel="oauth2-token"		}
	5.4. Failed Channel Binding		5.4. Failed Channel Binding
	This example shows a channel binding failure in a discovery request.		This example shows a channel binding failure in an empty request.
	The channel binding information is empty. Note that line breaks are		The channel binding information is empty. Note that line breaks are
	inserted for readability.		inserted for readability.
	S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready		S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE OAUTH R0VUIC8/Y2JkYXRhPSIiIEhUVFAvMS4xDQpVc2VyOi		C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xND
	BhbGljZUBleGFtcGxlLmNvbQ0KSG9zdDogaW1hcC5leGFtcGxlLmNvbQ0KQXV0aG		MBYXV0aD0BY2JkYXRhPQEB
	9yaXphdGlvbjoNCg0K		S: + ewoic3RhdHVzIjoiNDEyIiwKInNjb3BlIjoiZXhhbXBsZV9zY29wZSIKfQ==
	S: + SFRUUC8xLjEgNDEyIFByZWNvbmRpdGlvbiBGYWlsZWQNCg0KDQo=
	S: t1 NO SASL authentication failed		S: t1 NO SASL authentication failed
	The decoded initial client response is:		The decoded initial client response is:
	GET /?cbdata="" HTTP/1.1		host=server.example.com^Aport=143^Aauth=^Acbdata=^A^A
	User: alice@example.com
	Host: imap.example.com
	Authorization:
	The decoded server response is:		The decoded server response is:
	HTTP/1.1 412 Precondition Failed		{
			"status":"412",
			"scope":"example_scope"
			}
	6. Security Considerations		6. Security Considerations
	This mechanism does not provide a security layer, but does provide a		This mechanism does not provide a security layer, but does provide a
	provision for channel binding. The OAuth 2 specification		provision for channel binding. The OAuth 2 specification
	[I-D.ietf-oauth-v2] allows for a variety of usages, and the security		[I-D.ietf-oauth-v2] allows for a variety of usages, and the security
	properties of these profiles vary. The usage of bearer tokens, for		properties of these profiles vary. The usage of bearer tokens, for
	example, provide security features similar to cookies. Applications		example, provide security features similar to cookies. Applications
	using this mechanism SHOULD exercise the same level of care using		using this mechanism SHOULD exercise the same level of care using
	this mechanism as they would in using the SASL PLAIN mechanism. In		this mechanism as they would in using the SASL PLAIN mechanism. In
	particular, TLS 1.2 or an equivalent secure channel MUST be		particular, TLS 1.2 or an equivalent secure channel MUST be
	implemented and its usage is RECOMMENDED.		implemented and its usage is RECOMMENDED.
	Channel binding in this mechanism has different properties based on		Channel binding in this mechanism has different properties based on
	the authentication scheme used. Channel binding to TLS with a bearer		the authentication scheme used. Channel binding to TLS with a bearer
	token provides only a binding to the TLS layer. Authentication		token provides only a binding to the TLS layer. Authentication
	schemes like MAC tokens have a signature over the channel binding		schemes like MAC tokens can implement a signature over the channel
	information. These provide additional protection against a man in		binding information. These provide additional protection against a
	the middle attacks, and the MAC authorization header is bound to the		man in the middle attacks, and the MAC authorization header is bound
	channel and only valid in that context.		to the channel and only valid in that context.
	It is possible that SASL will be authenticating a connection and the		It is possible that SASL will be authenticating a connection and the
	life of that connection may outlast the life of the token used to		life of that connection may outlast the life of the token used to
	authenticate it. This is a common problem in application protocols		authenticate it. This is a common problem in application protocols
	where connections are long-lived, and not a problem with this		where connections are long-lived, and not a problem with this
	mechanism per se. Servers MAY unilaterally disconnect clients in		mechanism per se. Servers MAY unilaterally disconnect clients in
	accordance with the application protocol.		accordance with the application protocol.
	An OAuth credential is not equivalent to the password or primary		An OAuth credential is not equivalent to the password or primary
	account credential. There are protocols like XMPP that allow actions		account credential. There are protocols like XMPP that allow actions
	like change password. The server SHOULD ensure that actions taken in		like change password. The server SHOULD ensure that actions taken in
	the authenticated channel are appropriate to the strength of the		the authenticated channel are appropriate to the strength of the
	presented credential.		presented credential.
	It is possible for an application server running on Evil.example.com		Tokens have a lifetime associated with them. Reducing the lifetime
	to tell a client to request a token from Good.example.org. A client		of a token provides security benefits in case that tokens leak. In
	following these instructions will pass a token from Good to Evil.		addition a previously obtained token MAY be revoked or rendered
	This is by design, since it is possible that Good and Evil are merely		invalid at any time. The client MAY request a new access token for
	names, not descriptive, and that this is an innocuous activity		each connection to a resource server, but it SHOULD cache and re-use
	between cooperating two servers in different domains. For instance,		access credentials that appear to be valid.
	a site might operate their authentication service in-house, but
	outsource their mail systems to an external entity.
	Tokens have a lifetime associated with them. Reducing both the
	lifetime of a token provides security benefits in case that tokens
	leak. In addition a previously obtained token MAY be revoked or
	rendered invalid at any time. The client MAY request a new access
	token for each connection to a resource server, but it SHOULD cache
	and re-use access credentials that appear to be valid.
	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 SASL profile:
	SASL mechanism profile: OAUTH		SASL mechanism profile: OAUTH
	Security Considerations: See this document		Security Considerations: See this document
	skipping to change at page 19, line 44 ¶		skipping to change at page 18, line 5 ¶
	Note: None		Note: None
	7.2. GSS-API Registration		7.2. GSS-API Registration
	IANA is further requested to assign an OID for this GSS mechanism in		IANA is further requested to assign an OID for this GSS mechanism in
	the SMI numbers registry, with the prefix of		the SMI numbers registry, with the prefix of
	iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to		iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to
	reference this specification in the registry.		reference this specification in the registry.
	7.3. Link Type Registration
	Pursuant to [RFC5988] The following link type registrations [[will
	be]] registered by mail to link-relations@ietf.org.
	7.3.1. OAuth 2 Authentication Endpoint
	o Relation Name: oauth2-authenticator
	o Description: An OAuth 2.0 authentication endpoint.
	o Reference:
	o Notes: This link type indicates an OAuth 2.0 authentication
	endpoint that can be used for user authentication/authorization
	for the endpoint providing the link.
	o Application Data: [optional]
	7.3.2. OAuth 2 Token Endpoint
	o Relation Name: oauth2-token
	o Description: The OAuth token endpoint used to get tokens for
	access.
	o Reference:
	o Notes: The OAuth 2.0 token endpoint to be used for obtaining
	tokens to access the endpoint providing the link.
	o Application Data: This link type has one link-extension "grant-
	types", which is the OAuth 2.0 grant types that can be used at the
	token endpoint to obtain a token. This is not an exclusive list,
	it provides a hint to the application of what SHOULD be valid. A
	token endpoint MAY support additional grant types not advertised
	by a resource endpoint.
	7.3.3. OAuth 1.0a Request Initiation Endpoint
	o Relation Name: oauth-initiate
	o Description: The OAuth 1.0a request initiation endpoint used to
	get tokens for access.
	o Reference:
	o Notes: The OAuth 1.0a endpoint used to initiate the sequence, this
	temporary request is what the user approves to grant access to the
	resource.
	o Application Data:
	7.3.4. OAuth 1.0a Authorization Endpoint
	o Relation Name: oauth-authorize
	o Description: The OAuth 1.0a authorization endpoint used to approve
	an access request.
	o Reference:
	o Notes:
	o Application Data:
	7.3.5. OAuth 1.0a Token Endpoint
	o Relation Name: oauth-token
	o Description: The OAuth 1.0a token endpoint used to get tokens for
	access.
	o Reference:
	o Notes:
	o Application Data:
	8. Appendix A -- Document History		8. Appendix A -- Document History
	[[ to be removed by RFC editor before publication as an RFC ]]		[[ to be removed by RFC editor before publication as an RFC ]]
	-04		-01
	o Editorial clean-up and text in introduction improved.
	o Added GSS-API support
	-03
	o Fixing channel binding, not tls-unique specific. Also defining
	how the CB data is properly generated.
	o Various small editorial changes and embarassing spelling fixes.
	-02
	o Filling out Channel Binding
	o Added text clarifying how to bind to the 2 kinds of SASL		o Ripping out discovery. Changed to refer to I-D.jones-appsawg-
	identities.		webfinger instead of WF and SWD older drafts.
	-01		o Replacing HTTP as the message format and adjusted all examples.
	o Bringing this into line with draft 12 of the core spec, the bearer		-00
	token spec, and references the MAC token spec
	o Changing discovery over to using the Link header construct from		o Renamed draft into proper IETF naming format now that it's
	RFC5988.		adopted.
	o Added the seeds of channel binding.		o Minor fixes.
	-00		-00
	o Initial revision		o Initial revision
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-oauth-v2]		[I-D.ietf-oauth-v2]
	Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth		Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
	2.0 Authorization Protocol", draft-ietf-oauth-v2-22 (work		2.0 Authorization Framework", draft-ietf-oauth-v2-26 (work
	in progress), September 2011.		in progress), May 2012.
	[I-D.ietf-oauth-v2-bearer]		[I-D.ietf-oauth-v2-bearer]
	Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0		Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0
	Authorization Protocol: Bearer Tokens",		Authorization Protocol: Bearer Tokens",
	draft-ietf-oauth-v2-bearer-14 (work in progress),		draft-ietf-oauth-v2-bearer-19 (work in progress),
	November 2011.		April 2012.
	[I-D.ietf-oauth-v2-http-mac]		[I-D.ietf-oauth-v2-http-mac]
	Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP		Hammer-Lahav, E., "HTTP Authentication: MAC Access
	Authentication: MAC Access Authentication",		Authentication", draft-ietf-oauth-v2-http-mac-01 (work in
	draft-ietf-oauth-v2-http-mac-00 (work in progress),		progress), February 2012.
	May 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.
			[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
			Specifications: ABNF", RFC 2234, November 1997.
	[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.
	[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,		[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
	Leach, P., Luotonen, A., and L. Stewart, "HTTP		Leach, P., Luotonen, A., and L. Stewart, "HTTP
	Authentication: Basic and Digest Access Authentication",		Authentication: Basic and Digest Access Authentication",
	RFC 2617, June 1999.		RFC 2617, June 1999.
	[RFC2743] Linn, J., "Generic Security Service Application Program		[RFC2743] Linn, J., "Generic Security Service Application Program
	Interface Version 2, Update 1", RFC 2743, January 2000.		Interface Version 2, Update 1", RFC 2743, January 2000.
	[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.
	[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure		[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
	Channels", RFC 5056, November 2007.		Channels", RFC 5056, November 2007.
	[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
	Service Application Program Interface (GSS-API) Mechanisms		Service Application Program Interface (GSS-API) Mechanisms
	in Simple Authentication and Security Layer (SASL): The		in Simple Authentication and Security Layer (SASL): The
	GS2 Mechanism Family", RFC 5801, July 2010.		GS2 Mechanism Family", RFC 5801, July 2010.
	skipping to change at page 24, line 26 ¶		skipping to change at page 20, line 30 ¶
	[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.		[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
	[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and		[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
	Verification of Domain-Based Application Service Identity		Verification of Domain-Based Application Service Identity
	within Internet Public Key Infrastructure Using X.509		within Internet Public Key Infrastructure Using X.509
	(PKIX) Certificates in the Context of Transport Layer		(PKIX) Certificates in the Context of Transport Layer
	Security (TLS)", RFC 6125, March 2011.		Security (TLS)", RFC 6125, March 2011.
	9.2. Informative References		9.2. Informative References
	[I-D.hammer-hostmeta]		[I-D.jones-appsawg-webfinger]
	Hammer-Lahav, E. and B. Cook, "Web Host Metadata",		Jones, P., Salgueiro, G., and J. Smarr, "WebFinger",
	draft-hammer-hostmeta-17 (work in progress),		draft-jones-appsawg-webfinger-05 (work in progress),
	September 2011.		May 2012.
	[I-D.jones-simple-web-discovery]
	Jones, M. and Y. Goland, "Simple Web Discovery (SWD)",
	draft-jones-simple-web-discovery-01 (work in progress),
	July 2011.
	[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.
	Authors' Addresses		Authors' Addresses
	William Mills		William Mills
	Yahoo! Inc.		Yahoo! Inc.
	Phone:		Phone:
	Email: wmills@yahoo-inc.com		Email: wmills@yahoo-inc.com
	Tim Showalter		Tim Showalter
	Yahoo! Inc.
	Phone:		Phone:
	Email: timshow@yahoo-inc.com		Email: tjs@psaux.com
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Phone: +358 (50) 4871445		Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
End of changes. 73 change blocks.
	416 lines changed or deleted		237 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/