< draft-ietf-oauth-v2-18.txt		draft-ietf-oauth-v2-19.txt >
	Network Working Group E. Hammer-Lahav, Ed.		Network Working Group E. Hammer-Lahav, Ed.
	Internet-Draft Yahoo!		Internet-Draft Yahoo!
	Obsoletes: 5849 (if approved) D. Recordon		Obsoletes: 5849 (if approved) D. Recordon
	Intended status: Standards Track Facebook		Intended status: Standards Track Facebook
	Expires: January 9, 2012 D. Hardt		Expires: January 26, 2012 D. Hardt
	Microsoft		Microsoft
	July 8, 2011		July 25, 2011
	The OAuth 2.0 Authorization Protocol		The OAuth 2.0 Authorization Protocol
	draft-ietf-oauth-v2-18		draft-ietf-oauth-v2-19
	Abstract		Abstract
	The OAuth 2.0 authorization protocol enables a third-party		The OAuth 2.0 authorization protocol enables a third-party
	application to obtain limited access to an HTTP service, either on		application to obtain limited access to an HTTP service, either on
	behalf of a resource owner by orchestrating an approval interaction		behalf of a resource owner by orchestrating an approval interaction
	between the resource owner and the HTTP service, or by allowing the		between the resource owner and the HTTP service, or by allowing the
	third-party application to obtain access on its own behalf.		third-party application to obtain access on its own behalf.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 January 9, 2012.		This Internet-Draft will expire on January 26, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 6
	1.3. Access Token . . . . . . . . . . . . . . . . . . . . . . 6		1.3. Access Token . . . . . . . . . . . . . . . . . . . . . . 7
	1.4. Authorization Grant . . . . . . . . . . . . . . . . . . . 7		1.4. Authorization Grant . . . . . . . . . . . . . . . . . . . 8
	1.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 7		1.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 8
	1.4.2. Implicit . . . . . . . . . . . . . . . . . . . . . . . 7		1.4.2. Implicit . . . . . . . . . . . . . . . . . . . . . . . 8
	1.4.3. Resource Owner Password Credentials . . . . . . . . . 8		1.4.3. Resource Owner Password Credentials . . . . . . . . . 9
	1.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 8		1.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 9
	1.4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . 8		1.4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . 9
	1.5. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 8		1.5. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 9
	1.6. Notational Conventions . . . . . . . . . . . . . . . . . 10		1.6. Notational Conventions . . . . . . . . . . . . . . . . . 11
	2. Client Registration . . . . . . . . . . . . . . . . . . . . . 10		2. Client Registration . . . . . . . . . . . . . . . . . . . . . 11
	2.1. Client Types . . . . . . . . . . . . . . . . . . . . . . 11		2.1. Client Types . . . . . . . . . . . . . . . . . . . . . . 12
	2.2. Registration Requirements . . . . . . . . . . . . . . . . 11		2.2. Registration Requirements . . . . . . . . . . . . . . . . 13
	2.3. Client Identifier . . . . . . . . . . . . . . . . . . . . 11		2.3. Client Identifier . . . . . . . . . . . . . . . . . . . . 13
	2.4. Client Authentication . . . . . . . . . . . . . . . . . . 11		2.4. Client Authentication . . . . . . . . . . . . . . . . . . 13
	2.4.1. Client Password . . . . . . . . . . . . . . . . . . . 12		2.4.1. Client Password . . . . . . . . . . . . . . . . . . . 14
	2.4.2. Other Authentication Methods . . . . . . . . . . . . . 13		2.4.2. Other Authentication Methods . . . . . . . . . . . . . 15
	2.5. Unregistered Clients . . . . . . . . . . . . . . . . . . 13		2.5. Unregistered Clients . . . . . . . . . . . . . . . . . . 15
	3. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . . 13		3. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . . 15
	3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 13		3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 15
	3.1.1. Response Type . . . . . . . . . . . . . . . . . . . . 14		3.1.1. Response Type . . . . . . . . . . . . . . . . . . . . 16
	3.1.2. Redirection URI . . . . . . . . . . . . . . . . . . . 15		3.1.2. Redirection Endpoint . . . . . . . . . . . . . . . . . 16
	3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 17		3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 18
	3.2.1. Client Authentication . . . . . . . . . . . . . . . . 17		3.2.1. Client Authentication . . . . . . . . . . . . . . . . 19
	4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 18		4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 19
	4.1. Authorization Code . . . . . . . . . . . . . . . . . . . 18		4.1. Authorization Code . . . . . . . . . . . . . . . . . . . 20
	4.1.1. Authorization Request . . . . . . . . . . . . . . . . 20		4.1.1. Authorization Request . . . . . . . . . . . . . . . . 21
	4.1.2. Authorization Response . . . . . . . . . . . . . . . . 21		4.1.2. Authorization Response . . . . . . . . . . . . . . . . 22
	4.1.3. Access Token Request . . . . . . . . . . . . . . . . . 23		4.1.3. Access Token Request . . . . . . . . . . . . . . . . . 24
	4.1.4. Access Token Response . . . . . . . . . . . . . . . . 24		4.1.4. Access Token Response . . . . . . . . . . . . . . . . 25
	4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . 24		4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . 26
	4.2.1. Authorization Request . . . . . . . . . . . . . . . . 27		4.2.1. Authorization Request . . . . . . . . . . . . . . . . 28
	4.2.2. Access Token Response . . . . . . . . . . . . . . . . 28		4.2.2. Access Token Response . . . . . . . . . . . . . . . . 29
	4.3. Resource Owner Password Credentials . . . . . . . . . . . 30		4.3. Resource Owner Password Credentials . . . . . . . . . . . 31
	4.3.1. Authorization Request and Response . . . . . . . . . . 31		4.3.1. Authorization Request and Response . . . . . . . . . . 32
	4.3.2. Access Token Request . . . . . . . . . . . . . . . . . 32		4.3.2. Access Token Request . . . . . . . . . . . . . . . . . 33
	4.3.3. Access Token Response . . . . . . . . . . . . . . . . 33		4.3.3. Access Token Response . . . . . . . . . . . . . . . . 34
	4.4. Client Credentials . . . . . . . . . . . . . . . . . . . 33		4.4. Client Credentials . . . . . . . . . . . . . . . . . . . 34
	4.4.1. Authorization Request and Response . . . . . . . . . . 34		4.4.1. Authorization Request and Response . . . . . . . . . . 35
	4.4.2. Access Token Request . . . . . . . . . . . . . . . . . 34		4.4.2. Access Token Request . . . . . . . . . . . . . . . . . 35
	4.4.3. Access Token Response . . . . . . . . . . . . . . . . 35		4.4.3. Access Token Response . . . . . . . . . . . . . . . . 36
	4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . 35		4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . 36
	5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 36		5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 37
	5.1. Successful Response . . . . . . . . . . . . . . . . . . . 36		5.1. Successful Response . . . . . . . . . . . . . . . . . . . 37
	5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 38		5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 39
	6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 39		6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 40
	7. Accessing Protected Resources . . . . . . . . . . . . . . . . 40		7. Accessing Protected Resources . . . . . . . . . . . . . . . . 41
	7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 41		7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 42
	8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 42		8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 43
	8.1. Defining Access Token Types . . . . . . . . . . . . . . . 42		8.1. Defining Access Token Types . . . . . . . . . . . . . . . 43
	8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 42		8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 43
	8.3. Defining New Authorization Grant Types . . . . . . . . . 43		8.3. Defining New Authorization Grant Types . . . . . . . . . 44
	8.4. Defining New Authorization Endpoint Response Types . . . 43		8.4. Defining New Authorization Endpoint Response Types . . . 44
	8.5. Defining Additional Error Codes . . . . . . . . . . . . . 43		8.5. Defining Additional Error Codes . . . . . . . . . . . . . 44
	9. Native Applications . . . . . . . . . . . . . . . . . . . . . 44		9. Native Applications . . . . . . . . . . . . . . . . . . . . . 45
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 45		10. Security Considerations . . . . . . . . . . . . . . . . . . . 46
	10.1. Client Authentication . . . . . . . . . . . . . . . . . . 46		10.1. Client Authentication . . . . . . . . . . . . . . . . . . 46
	10.2. Client Impersonation . . . . . . . . . . . . . . . . . . 46		10.2. Client Impersonation . . . . . . . . . . . . . . . . . . 47
	10.3. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 47		10.3. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 47
	10.4. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 47		10.4. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 48
	10.5. Authorization Codes . . . . . . . . . . . . . . . . . . . 48		10.5. Authorization Codes . . . . . . . . . . . . . . . . . . . 48
	10.6. Authorization Code Leakage . . . . . . . . . . . . . . . 48		10.6. Authorization Code Leakage . . . . . . . . . . . . . . . 49
	10.7. Resource Owner Password Credentials . . . . . . . . . . . 49		10.7. Resource Owner Password Credentials . . . . . . . . . . . 49
	10.8. Request Confidentiality . . . . . . . . . . . . . . . . . 49		10.8. Request Confidentiality . . . . . . . . . . . . . . . . . 50
	10.9. Endpoints Authenticity . . . . . . . . . . . . . . . . . 49		10.9. Endpoints Authenticity . . . . . . . . . . . . . . . . . 50
	10.10. Credentials Guessing Attacks . . . . . . . . . . . . . . 49		10.10. Credentials Guessing Attacks . . . . . . . . . . . . . . 50
	10.11. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 50		10.11. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 50
	10.12. Cross-Site Request Forgery . . . . . . . . . . . . . . . 50		10.12. Cross-Site Request Forgery . . . . . . . . . . . . . . . 51
	10.13. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 51		10.13. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 51
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51		10.14. Code Injection and Input Validation . . . . . . . . . . . 52
	11.1. The OAuth Access Token Type Registry . . . . . . . . . . 51		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
	11.1.1. Registration Template . . . . . . . . . . . . . . . . 52		11.1. The OAuth Access Token Type Registry . . . . . . . . . . 52
	11.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 52		11.1.1. Registration Template . . . . . . . . . . . . . . . . 53
	11.2.1. Registration Template . . . . . . . . . . . . . . . . 53		11.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 53
	11.2.2. Initial Registry Contents . . . . . . . . . . . . . . 53		11.2.1. Registration Template . . . . . . . . . . . . . . . . 54
			11.2.2. Initial Registry Contents . . . . . . . . . . . . . . 54
	11.3. The OAuth Authorization Endpoint Response Type		11.3. The OAuth Authorization Endpoint Response Type
	Registry . . . . . . . . . . . . . . . . . . . . . . . . 55		Registry . . . . . . . . . . . . . . . . . . . . . . . . 56
	11.3.1. Registration Template . . . . . . . . . . . . . . . . 56		11.3.1. Registration Template . . . . . . . . . . . . . . . . 57
	11.3.2. Initial Registry Contents . . . . . . . . . . . . . . 56		11.3.2. Initial Registry Contents . . . . . . . . . . . . . . 57
	11.4. The OAuth Extensions Error Registry . . . . . . . . . . . 57		11.4. The OAuth Extensions Error Registry . . . . . . . . . . . 58
	11.4.1. Registration Template . . . . . . . . . . . . . . . . 57		11.4.1. Registration Template . . . . . . . . . . . . . . . . 58
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59
	Appendix A. Editor's Notes . . . . . . . . . . . . . . . . . . . 59		Appendix A. Editor's Notes . . . . . . . . . . . . . . . . . . . 60
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
	13.1. Normative References . . . . . . . . . . . . . . . . . . 59		13.1. Normative References . . . . . . . . . . . . . . . . . . 60
	13.2. Informative References . . . . . . . . . . . . . . . . . 60		13.2. Informative References . . . . . . . . . . . . . . . . . 61
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
	1. Introduction		1. Introduction
	In the traditional client-server authentication model, the client		In the traditional client-server authentication model, the client
	accesses a protected resource on the server by authenticating with		accesses a protected resource on the server by authenticating with
	the server using the resource owner's credentials. In order to		the server using the resource owner's credentials. In order to
	provide third-party applications access to protected resources, the		provide third-party applications access to protected resources, the
	resource owner shares its credentials with the third-party. This		resource owner shares its credentials with the third-party. This
	creates several problems and limitations:		creates several problems and limitations:
	skipping to change at page 10, line 36 ¶		skipping to change at page 11, line 36 ¶
	defined in [RFC4949]. These terms include, but are not limited to,		defined in [RFC4949]. These terms include, but are not limited to,
	'attack', 'authentication', 'authorization', 'certificate',		'attack', 'authentication', 'authorization', 'certificate',
	'confidentiality', 'credential', 'encryption', 'identity', 'sign',		'confidentiality', 'credential', 'encryption', 'identity', 'sign',
	'signature', 'trust', 'validate', and 'verify'.		'signature', 'trust', 'validate', and 'verify'.
	Unless otherwise noted, all the protocol parameter names and values		Unless otherwise noted, all the protocol parameter names and values
	are case sensitive.		are case sensitive.
	2. Client Registration		2. Client Registration
	[[ Pending Consensus ]]
	Before initiating the protocol, the client registers with the		Before initiating the protocol, the client registers with the
	authorization server. The means through which the client registers		authorization server. The means through which the client registers
	with the authorization server are beyond the scope of this		with the authorization server are beyond the scope of this
	specification, but typically involve end-user interaction with an		specification, but typically involve end-user interaction with an
	HTML registration form.		HTML registration form.
	Client registration does not require a direct interaction between the		Client registration does not require a direct interaction between the
	client and the authorization server. When supported by the		client and the authorization server. When supported by the
	authorization server, registration can rely on other means for		authorization server, registration can rely on other means for
	establishing trust and obtaining the required client properties (e.g.		establishing trust and obtaining the required client properties (e.g.
	skipping to change at page 11, line 27 ¶		skipping to change at page 12, line 27 ¶
	Clients incapable of maintaining the confidentiality of their		Clients incapable of maintaining the confidentiality of their
	credentials (e.g. clients executing on the resource owner's device		credentials (e.g. clients executing on the resource owner's device
	such as an installed native application or a user-agent-based		such as an installed native application or a user-agent-based
	application), and incapable of secure client authentication via		application), and incapable of secure client authentication via
	any other mean.		any other mean.
	The client type designation is based on the authorization server's		The client type designation is based on the authorization server's
	definition of secure authentication and its acceptable exposure		definition of secure authentication and its acceptable exposure
	levels of client credentials.		levels of client credentials.
			This specification has been designed around the following client
			profiles:
			web application
			A web application is a private client running on a web server.
			Resource owners access the client via an HTML user interface
			rendered in a user-agent on the resource owner's device. The
			client credentials as well as any access token issued to the
			client are stored on the web server and are not exposed to or
			accessible by the resource owner.
			user-agent-based application
			A user-agent-based application is a public client in which the
			client code is downloaded from a web server and executes within a
			user-agent on the resource owner's device. Protocol data and
			credentials are easily accessible (and often visible) to the
			resource owner. Since such applications reside within the user-
			agent, they can make seamless use of the user-agent capabilities
			when requesting authorization.
			native application
			A native application is a public client installed and executed on
			the resource owner's device. Protocol data and credentials are
			accessible to the resource owner. It is assumed that any client
			authentication credentials included in the application can be
			extracted. On the other hand, dynamically issued credentials such
			access tokens or refresh tokens, can receive an acceptable level
			of protection. At a minimum, these credentials are protected from
			hostile servers which the application may interact with. On some
			platform these credentials might be protected from other
			applications residing on the same device.
	2.2. Registration Requirements		2.2. Registration Requirements
	When registering a client, the client developer MUST specify:		When registering a client, the client developer:
	o the client type as described in Section 2.1,		o specifies the client type as described in Section 2.1,
	o the client redirection URIs as described in Section 3.1.2, and		o provides its client redirection URIs as described in
	o any other information required by the authorization server (e.g.		Section 3.1.2, and
	application name, website, description, logo image, the acceptance		o includes any other information required by the authorization
	of legal terms).		server (e.g. application name, website, description, logo image,
			the acceptance of legal terms).
	2.3. Client Identifier		2.3. Client Identifier
	The authorization server issues the registered client a client		The authorization server issues the registered client a client
	identifier - a unique string representing the registration		identifier - a unique string representing the registration
	information provided by the client. The client identifier is not a		information provided by the client. The client identifier is not a
	secret, it is exposed to the resource owner, and cannot not be used		secret, it is exposed to the resource owner, and cannot be used alone
	alone for client authentication.		for client authentication.
	2.4. Client Authentication		2.4. Client Authentication
	In addition, the client and authorization server establish a client		If the client type is private, the client and authorization server
	authentication method suitable for the client type and security		establish a client authentication method suitable for the security
	requirements of the authorization server. The authorization server		requirements of the authorization server. The authorization server
	MAY accept any form of client authentication meeting its security		MAY accept any form of client authentication meeting its security
	requirements.		requirements.
	Private clients are typically issued (or establish) a set of client		Private clients are typically issued (or establish) a set of client
	credentials used for authenticating with the authorization server		credentials used for authenticating with the authorization server
	(e.g. password, public/private key pair).		(e.g. password, public/private key pair).
	The authorization server SHOULD NOT make assumptions about the client		The authorization server SHOULD NOT make assumptions about the client
	type or accept the type information provided without establishing		type or accept the type information provided without establishing
	trust with the client or its developer. The authorization server		trust with the client or its developer. The authorization server MAY
	MUST NOT rely on client authentication performed by public clients.		establish a client authentication method with public clients.
			However, the authorization server MUST NOT rely on public client
			authentication for the purpose of identifying the client.
	The client MUST NOT use more than one authentication method in each		The client MUST NOT use more than one authentication method in each
	request.		request.
	2.4.1. Client Password		2.4.1. Client Password
	Clients in possession of a client password MAY use the HTTP Basic		Clients in possession of a client password MAY use the HTTP Basic
	authentication scheme as defined in [RFC2617] to authenticate with		authentication scheme as defined in [RFC2617] to authenticate with
	the authorization server. The client identifier is used as the		the authorization server. The client identifier is used as the
	username, and the client password is used as the password.		username, and the client password is used as the password.
	skipping to change at page 14, line 46 ¶		skipping to change at page 16, line 32 ¶
	The authorization endpoint is used by the authorization code grant		The authorization endpoint is used by the authorization code grant
	type and implicit grant type flows. The client informs the		type and implicit grant type flows. The client informs the
	authorization server of the desired grant type using the following		authorization server of the desired grant type using the following
	parameter:		parameter:
	response_type		response_type
	REQUIRED. The value MUST be one of "code" for requesting an		REQUIRED. The value MUST be one of "code" for requesting an
	authorization code as described by Section 4.1.1, "token" for		authorization code as described by Section 4.1.1, "token" for
	requesting an access token (implicit grant) as described by		requesting an access token (implicit grant) as described by
	Section 4.2.1, or a registered extension value as described by		Section 4.2.1, or a registered extension value as described by
	Section 8.4.		Section 8.4. If the response type contains one or more space
			characters (%x20), it is interpreted as a space-delimited list
			of values, where the order of values does not matter (e.g. "a
			b" is the same as "b a").
	If an authorization request is missing the "response_type" parameter,		If an authorization request is missing the "response_type" parameter,
	the authorization server SHOULD return an error response as described		the authorization server SHOULD return an error response as described
	in Section 4.1.2.1.		in Section 4.1.2.1.
	3.1.2. Redirection URI		3.1.2. Redirection Endpoint
	[[ Pending Consensus ]]
	After completing its interaction with the resource owner, the		After completing its interaction with the resource owner, the
	authorization server directs the resource owner's user-agent back to		authorization server directs the resource owner's user-agent back to
	the client. The authorization server redirects the user-agent to the		the client. The authorization server redirects the user-agent to the
	client's redirection URI previously established with the		client's redirection endpoint previously established with the
	authorization server during the client registration process.		authorization server during the client registration process or when
			initiating the authorization request.
	The redirection URI MUST be an absolute URI as defined by [RFC3986]		The redirection endpoint URI MUST be an absolute URI as defined by
	section 4.3, MAY include a query component which MUST be retained by		[RFC3986] section 4.3, MAY include a query component which MUST be
	the authorization server when adding additional query parameters, and		retained by the authorization server when adding additional query
	MUST NOT include a fragment component.		parameters, and MUST NOT include a fragment component.
	3.1.2.1. Endpoint Confidentiality		3.1.2.1. Endpoint Confidentiality
	If a redirection request will result in the transmission of an		If a redirection request will result in the transmission of an
	authorization code or access token over an open network (between the		authorization code or access token over an open network (between the
	resource owner's user-agent and the client), the client SHOULD		resource owner's user-agent and the client), the client SHOULD
	require the use of a transport-layer security mechanism.		require the use of a transport-layer security mechanism.
	Lack of transport-layer security can have a severe impact on the		Lack of transport-layer security can have a severe impact on the
	security of the client and the protected resources it is authorized		security of the client and the protected resources it is authorized
	skipping to change at page 17, line 36 ¶		skipping to change at page 19, line 20 ¶
	The client MUST use the HTTP "POST" method when making access token		The client MUST use the HTTP "POST" method when making access token
	requests.		requests.
	Parameters sent without a value MUST be treated as if they were		Parameters sent without a value MUST be treated as if they were
	omitted from the request. The authorization server SHOULD ignore		omitted from the request. The authorization server SHOULD ignore
	unrecognized request parameters. Request and response parameters		unrecognized request parameters. Request and response parameters
	MUST NOT be included more than once.		MUST NOT be included more than once.
	3.2.1. Client Authentication		3.2.1. Client Authentication
	[[ Pending Consensus ]]
	Private clients, clients issued client credentials, or clients		Private clients, clients issued client credentials, or clients
	assigned other authentication requirements, MUST authenticate with		assigned other authentication requirements, MUST authenticate with
	the authorization server as described in Section 2.4 when making		the authorization server as described in Section 2.4 when making
	requests to the token endpoint. Client authentication is used for:		requests to the token endpoint. Client authentication is used for:
	o Enforcing the binding of refresh tokens and authorization codes to		o Enforcing the binding of refresh tokens and authorization codes to
	the client they are issued. Client authentication is critical		the client they are issued. Client authentication is critical
	when an authorization code is transmitted to the redirection URI		when an authorization code is transmitted to the redirection
	endpoint over an insecure channel, or when the redirection URI has		endpoint over an insecure channel, or when the redirection URI has
	not been registered in full.		not been registered in full.
	o Recovery from a compromised client by disabling the client or		o Recovery from a compromised client by disabling the client or
	changing its credentials, by preventing an attacker from abusing		changing its credentials, by preventing an attacker from abusing
	stolen refresh tokens. Changing a single set of client		stolen refresh tokens. Changing a single set of client
	credentials is significantly faster than revoking an entire set of		credentials is significantly faster than revoking an entire set of
	refresh tokens.		refresh tokens.
	o Implementing authentication management best practices which		o Implementing authentication management best practices which
	require periodic credentials rotation. Rotation of an entire set		require periodic credentials rotation. Rotation of an entire set
	of refresh tokens can be challenging, while rotation of a single		of refresh tokens can be challenging, while rotation of a single
	set of client credentials is significantly easier. In addition,		set of client credentials is significantly easier.
	this specification does not provide a mechanism for refresh token
	rotation.
	The security ramifications of allowing unauthenticated access by		The security ramifications of allowing unauthenticated access by
	public clients to the token endpoint MUST be considered, as well as		public clients to the token endpoint MUST be considered, as well as
	the issuance of refresh tokens to public clients, their scope, and		the issuance of refresh tokens to public clients, their scope, and
	lifetime.		lifetime.
	4. Obtaining Authorization		4. Obtaining Authorization
	To request an access token, the client obtains authorization from the		To request an access token, the client obtains authorization from the
	resource owner. The authorization is expressed in the form of an		resource owner. The authorization is expressed in the form of an
	skipping to change at page 40, line 31 ¶		skipping to change at page 41, line 31 ¶
	grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA		grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
	The authorization server MUST:		The authorization server MUST:
	o require client authentication for private clients or for any		o require client authentication for private clients or for any
	client issued client credentials (or with other authentication		client issued client credentials (or with other authentication
	requirements),		requirements),
	o authenticate the client if client authentication is included and		o authenticate the client if client authentication is included and
	ensure the refresh token was issued to the authenticated client,		ensure the refresh token was issued to the authenticated client,
	o validate the refresh token, and		o validate the refresh token, and
	o verify that the resource owner's authorization is still valid.
	If valid and authorized, the authorization server issues an access		If valid and authorized, the authorization server issues an access
	token as described in Section 5.1. If the request failed		token as described in Section 5.1. If the request failed
	verification or is invalid, the authorization server returns an error		verification or is invalid, the authorization server returns an error
	response as described in Section 5.2.		response as described in Section 5.2.
	The authorization server MAY issue a new refresh token, in which case		The authorization server MAY issue a new refresh token, in which case
	the client MUST discard the old refresh token and replace it with the		the client MUST discard the old refresh token and replace it with the
	new refresh token. The authorization server MAY revoke the old		new refresh token. The authorization server MAY revoke the old
	refresh token after issuing a new refresh token to the client. If a		refresh token after issuing a new refresh token to the client. If a
	skipping to change at page 43, line 15 ¶		skipping to change at page 44, line 15 ¶
	8.3. Defining New Authorization Grant Types		8.3. Defining New Authorization Grant Types
	New authorization grant types can be defined by assigning them a		New authorization grant types can be defined by assigning them a
	unique absolute URI for use with the "grant_type" parameter. If the		unique absolute URI for use with the "grant_type" parameter. If the
	extension grant type requires additional token endpoint parameters,		extension grant type requires additional token endpoint parameters,
	they MUST be registered in the OAuth parameters registry as described		they MUST be registered in the OAuth parameters registry as described
	by Section 11.2.		by Section 11.2.
	8.4. Defining New Authorization Endpoint Response Types		8.4. Defining New Authorization Endpoint Response Types
	[[ Pending consensus ]]
	New response types for use with the authorization endpoint are		New response types for use with the authorization endpoint are
	defined and registered in the authorization endpoint response type		defined and registered in the authorization endpoint response type
	registry following the procedure in Section 11.3. Response type		registry following the procedure in Section 11.3. Response type
	names MUST conform to the response-type ABNF.		names MUST conform to the response-type ABNF.
	response-type = response-name *( "+" response-name )		response-type = response-name *( SP response-name )
	response-name = 1*response-char		response-name = 1*response-char
	response-char = "_" / DIGIT / ALPHA		response-char = "_" / DIGIT / ALPHA
	The "+" character is reserved for defining composite response types		If a response type contains one of more space characters (%x20), it
	made up of two or more existing registered response types. Only one		is compared as a space-delimited list of values in which the order of
	response type of each combination may be registered and used for		values does not matter. Only one order of values can be registered,
	making requests. Composite response types are treated and compared		which covers all other arrangements of the same set of values.
	in the same as manner as non-composite response types. The "+"
	notation is meant only to improve human readability and is not used
	for machine parsing.
	For example, an extension can define and register the "token+code"		For example, the response type "token code" is left undefined by this
	response type. However, once registered, the same combination cannot		specification. However, an extension can define and register the
	be registered as "code+token", or used to make an authorization		"token code" response type. Once registered, the same combination
	request.		cannot be registered as "code token", but both values can be used to
			denote the same response type.
	8.5. Defining Additional Error Codes		8.5. Defining Additional Error Codes
	In cases where protocol extensions (i.e. access token types,		In cases where protocol extensions (i.e. access token types,
	extension parameters, or extension grant types) require additional		extension parameters, or extension grant types) require additional
	error codes to be used with the authorization code grant error		error codes to be used with the authorization code grant error
	response (Section 4.1.2.1), the implicit grant error response		response (Section 4.1.2.1), the implicit grant error response
	(Section 4.2.2.1), or the token error response (Section 5.2), such		(Section 4.2.2.1), or the token error response (Section 5.2), such
	error codes MAY be defined.		error codes MAY be defined.
	skipping to change at page 45, line 28 ¶		skipping to change at page 46, line 27 ¶
	o Native applications that use the authorization code grant type		o Native applications that use the authorization code grant type
	SHOULD do so without using client credentials, due to the native		SHOULD do so without using client credentials, due to the native
	application's inability to keep credentials confidential.		application's inability to keep credentials confidential.
	o When using the implicit grant type flow a refresh token is not		o When using the implicit grant type flow a refresh token is not
	returned.		returned.
	10. Security Considerations		10. Security Considerations
	As a flexible and extensible framework, OAuth's security		As a flexible and extensible framework, OAuth's security
	considerations depend on many factors. The following sections		considerations depend on many factors. The following sections
	provide implementers with security guidelines focused on three common		provide implementers with security guidelines focused on the three
	client types:		client profiles described in Section 2.1: web application, user-
			agent-based application, and native application.
	Web Application
	A web application is a client running on a web server. Resource
	owners access the client via an HTML user interface rendered in a
	user-agent on the resource-owner's device. The client credentials
	as well as any access token issued to the client are stored on the
	web server and are not exposed to or accessible by the resource
	owner.
	User-Agent-based Application
	A user-agent-based application is a client in which the client
	code is downloaded from a web server and executes within a user-
	agent on the resource owner's device. Protocol data and
	credentials are easily accessible (and often visible) to the
	resource owner. Since such applications reside within the user-
	agent, they can make seamless use of the user-agent capabilities
	when requesting authorization.
	Native Application
	A native application is a client installed and executed on the
	resource owner's device. Protocol data and credentials are
	accessible to the resource owner. It is assumed that any client
	authentication credentials included in the application can be
	extracted, and furthermore that rotation of the client
	authentication credentials is impractical. On the other hand,
	dynamically issued credentials such access tokens or refresh
	tokens, can receive an acceptable level of protection. At a
	minimum, these credentials are protected from hostile servers
	which the application may interact with. On some platform these
	credentials might be protected from other applications residing on
	the same device.
	A comprehensive OAuth security model and analysis, as well as		A comprehensive OAuth security model and analysis, as well as
	background for the protocol design is provided by		background for the protocol design is provided by
	[I-D.lodderstedt-oauth-security].		[I-D.ietf-oauth-v2-threatmodel].
	10.1. Client Authentication		10.1. Client Authentication
	The authorization server establishes client credentials with web		The authorization server establishes client credentials with web
	application clients for the purpose of client authentication. The		application clients for the purpose of client authentication. The
	authorization server is encouraged to consider stronger client		authorization server is encouraged to consider stronger client
	authentication means than a client password. Web application clients		authentication means than a client password. Web application clients
	MUST ensure confidentiality of client passwords and other client		MUST ensure confidentiality of client passwords and other client
	credentials.		credentials.
	The authorization server MUST NOT issue client passwords or other		The authorization server MUST NOT issue client passwords or other
	client credentials to native application or user-agent-based		client credentials to native application or user-agent-based
	application clients for the purpose of client authentication. The		application clients for the purpose of client authentication. The
	authorization server MAY issue a client password or other credentials		authorization server MAY issue a client password or other credentials
	for a specific installation of a native application client on a		for a specific installation of a native application client on a
	specific device.		specific device.
			When client authentication is not possible, the authorization server
			SHOULD employ other means to validate the client's identity. For
			example, by requiring the registration of the client redirection URI
			or enlisting the resource owner to confirm identity. The
			authorization server must consider the security implications of
			interacting with unauthenticated clients and take measures to limit
			the potential exposure of other credentials (e.g. refresh tokens)
			issued to such clients.
	10.2. Client Impersonation		10.2. Client Impersonation
	A malicious client can impersonate another client and obtain access		A malicious client can impersonate another client and obtain access
	to protected resources, if the impersonated client fails to, or is		to protected resources, if the impersonated client fails to, or is
	unable to, keep is client credentials confidential.		unable to, keep is client credentials confidential.
	The authorization server MUST authenticate the client whenever		The authorization server MUST authenticate the client whenever
	possible. If the authorization server cannot authenticate the client		possible. If the authorization server cannot authenticate the client
	due to the client nature, the authorization server MUST require the		due to the client nature, the authorization server MUST require the
	registration of any redirection URI used for receiving authorization,		registration of any redirection URI used for receiving authorization,
	skipping to change at page 47, line 8 ¶		skipping to change at page 47, line 35 ¶
	The authorization server SHOULD enforce explicit resource owner		The authorization server SHOULD enforce explicit resource owner
	authentication and provide the resource owner with information about		authentication and provide the resource owner with information about
	the client and the requested authorization scope and lifetime. It is		the client and the requested authorization scope and lifetime. It is
	up to the resource owner to review the information in the context of		up to the resource owner to review the information in the context of
	the current client, and authorize the request.		the current client, and authorize the request.
	The authorization server SHOULD NOT process repeated authorization		The authorization server SHOULD NOT process repeated authorization
	requests automatically (without active resource owner interaction)		requests automatically (without active resource owner interaction)
	without authenticating the client or relying on other measures to		without authenticating the client or relying on other measures to
	ensure the repeated request comes from an authentic client and not an		ensure the repeated request comes from the original client and not an
	impersonator.		impersonator.
	10.3. Access Tokens		10.3. Access Tokens
	Access token (as well as any type-specific attributes) MUST be kept		Access token (as well as any access token type-specific attributes)
	confidential in transit and storage, and only shared among the		MUST be kept confidential in transit and storage, and only shared
	authorization server, the resource servers the access token is valid		among the authorization server, the resource servers the access token
	for, and the client to whom the access token is issued.		is valid for, and the client to whom the access token is issued.
	When using the implicit grant type, the access token is transmitted		When using the implicit grant type, the access token is transmitted
	in the URI fragment, which can expose it to unauthorized parties.		in the URI fragment, which can expose it to unauthorized parties.
	The authorization server MUST ensure that access tokens cannot be		The authorization server MUST ensure that access tokens cannot be
	generated, modified, or guessed to produce valid access tokens.		generated, modified, or guessed to produce valid access tokens.
	The client SHOULD request access tokens with the minimal scope and		The client SHOULD request access tokens with the minimal scope and
	lifetime necessary. The authorization server SHOULD take the client		lifetime necessary. The authorization server SHOULD take the client
	identity into account when choosing how to honor the requested scope		identity into account when choosing how to honor the requested scope
	skipping to change at page 47, line 45 ¶		skipping to change at page 48, line 24 ¶
	Refresh tokens MUST be kept confidential in transit and storage, and		Refresh tokens MUST be kept confidential in transit and storage, and
	shared only among the authorization server and the client to whom the		shared only among the authorization server and the client to whom the
	refresh tokens were issued. The authorization server MUST maintain		refresh tokens were issued. The authorization server MUST maintain
	the binding between a refresh token and the client to whom it was		the binding between a refresh token and the client to whom it was
	issued.		issued.
	The authorization server MUST verify the binding between the refresh		The authorization server MUST verify the binding between the refresh
	token and client identity whenever the client identity can be		token and client identity whenever the client identity can be
	authenticated. When client authentication is not possible, the		authenticated. When client authentication is not possible, the
	authorization server SHOULD deploy other means to detect refresh		authorization server SHOULD deploy other means to detect refresh
	token abuse [[ add example ]].		token abuse.
			For example, the authorization server could employ refresh tokens
			rotation in which a new refresh token is issued with every access
			token refresh response. The previous refresh token is invalidated
			but retained by the authorization server. If a refresh token is
			compromised and subsequently used by both the attacker and the
			legitimate client, one of them will present an invalidated refresh
			token which will inform the authorization server of the breach.
	The authorization server MUST ensure that refresh tokens cannot be		The authorization server MUST ensure that refresh tokens cannot be
	generated, modified, or guessed to produce valid refresh tokens.		generated, modified, or guessed to produce valid refresh tokens.
	10.5. Authorization Codes		10.5. Authorization Codes
	The transmission of authorization codes SHOULD be made over a secure		The transmission of authorization codes SHOULD be made over a secure
	channel, and the client SHOULD implement TLS for use with its		channel, and the client SHOULD implement TLS for use with its
	redirection URI if the URI identifies a network resource. Effort		redirection URI if the URI identifies a network resource. Effort
	should be made to keep authorization codes confidential. Since		should be made to keep authorization codes confidential. Since
	skipping to change at page 48, line 34 ¶		skipping to change at page 49, line 18 ¶
	authorization code for an access token, the authorization server		authorization code for an access token, the authorization server
	SHOULD attempt to revoke all access tokens already granted based on		SHOULD attempt to revoke all access tokens already granted based on
	the compromised authorization code.		the compromised authorization code.
	If the client can be authenticated, the authorization servers MUST		If the client can be authenticated, the authorization servers MUST
	authenticate the client and ensure that the authorization code was		authenticate the client and ensure that the authorization code was
	issued to the same client.		issued to the same client.
	10.6. Authorization Code Leakage		10.6. Authorization Code Leakage
	Session fixation attacks leverage the authorization code grant type,		An attacker can leverage the authorization code grant type by
	by tricking a resource owner to authorize access to a legitimate		tricking a resource owner to authorize access to a legitimate client,
	client, but using a client account under the control of the attacker.		but using a client account under the control of the attacker. The
	The only difference between a valid request and the attack request is		only difference between a valid request and the attack request is in
	in how the victim reached the authorization server to grant access.		how the victim reached the authorization server to grant access.
	Once at the authorization server, the victim is prompted with a		Once at the authorization server, the victim is prompted with a
	normal, valid request on behalf of a legitimate and familiar client.		normal, valid request on behalf of a legitimate and familiar client.
	The attacker then uses the victim's authorization to gain access to		The attacker then uses the victim's authorization to gain access to
	the information authorized by the victim (via the client).		the information authorized by the victim (via the client).
	In order to prevent such an attack, authorization servers MUST ensure		In order to prevent such an attack, authorization servers MUST ensure
	that the redirection URI used to obtain the authorization code, is		that the redirection URI used to obtain the authorization code, is
	the same as the redirection URI provided when exchanging the		the same as the redirection URI provided when exchanging the
	authorization code for an access token. The authorization server		authorization code for an access token. The authorization server
	skipping to change at page 51, line 30 ¶		skipping to change at page 52, line 15 ¶
	To prevent clickjacking (and phishing attacks), native applications		To prevent clickjacking (and phishing attacks), native applications
	SHOULD use external browsers instead of embedding browsers in an		SHOULD use external browsers instead of embedding browsers in an
	iframe when requesting end-user authorization. For newer browsers,		iframe when requesting end-user authorization. For newer browsers,
	avoidance of iframes can be enforced by the authorization server		avoidance of iframes can be enforced by the authorization server
	using the "x-frame-options" header [[ Add reference ]]. This header		using the "x-frame-options" header [[ Add reference ]]. This header
	can have two values, "deny" and "sameorigin", which will block any		can have two values, "deny" and "sameorigin", which will block any
	framing or framing by sites with a different origin, respectively.		framing or framing by sites with a different origin, respectively.
	For older browsers, javascript framebusting techniques can be used		For older browsers, javascript framebusting techniques can be used
	but may not be effective in all browsers.		but may not be effective in all browsers.
			10.14. Code Injection and Input Validation
			A code injection attack occurs when an input or otherwise external
			variable is used by an application in which that input can cause
			modification of the application logic when used unsanitized. This
			may allow an attacker to gain access to the application device or its
			data, cause denial of service, or a wide range of malicious side-
			effects.
			The Authorization server and client MUST validate and sanitize any
			value received, and in particular, the value of the "state" and
			"redirect_uri" parameters.
	11. IANA Considerations		11. IANA Considerations
	11.1. The OAuth Access Token Type Registry		11.1. The OAuth Access Token Type Registry
	This specification establishes the OAuth access token type registry.		This specification establishes the OAuth access token type registry.
	Access token types are registered on the advice of one or more		Access token types are registered on the advice of one or more
	Designated Experts (appointed by the IESG or their delegate), with a		Designated Experts (appointed by the IESG or their delegate), with a
	Specification Required (using terminology from [RFC5226]). However,		Specification Required (using terminology from [RFC5226]). However,
	to allow for the allocation of values prior to publication, the		to allow for the allocation of values prior to publication, the
	skipping to change at page 58, line 48 ¶		skipping to change at page 59, line 43 ¶
	Smith.		Smith.
	The OAuth WRAP specification was edited by Dick Hardt and authored by		The OAuth WRAP specification was edited by Dick Hardt and authored by
	Brian Eaton, Yaron Goland, Dick Hardt, and Allen Tom.		Brian Eaton, Yaron Goland, Dick Hardt, and Allen Tom.
	This specification is the work of the OAuth Working Group which		This specification is the work of the OAuth Working Group which
	includes dozens of active and dedicated participants. In particular,		includes dozens of active and dedicated participants. In particular,
	the following individuals contributed ideas, feedback, and wording		the following individuals contributed ideas, feedback, and wording
	which shaped and formed the final specification:		which shaped and formed the final specification:
	Michael Adams, Andrew Arnott, Dirk Balfanz, Scott Cantor, Blaine		Michael Adams, Andrew Arnott, Dirk Balfanz, Aiden Bell, Scott Cantor,
	Cook, Brian Campbell, Brian Eaton, Leah Culver, Bill de hOra, Brian		Marcos Caceres, Blaine Cook, Brian Campbell, Brian Eaton, Leah
	Eaton, Brian Ellin, Igor Faynberg, George Fletcher, Tim Freeman, Evan		Culver, Bill de hOra, Brian Eaton, Brian Ellin, Igor Faynberg, George
	Gilbert, Yaron Goland, Brent Goldman, Kristoffer Gronowski, Justin		Fletcher, Tim Freeman, Evan Gilbert, Yaron Goland, Brent Goldman,
	Hart, Dick Hardt, Craig Heath, Phil Hunt, Michael B. Jones, John		Kristoffer Gronowski, Justin Hart, Dick Hardt, Craig Heath, Phil
	Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara, Rasmus Lerdorf,		Hunt, Michael B. Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen
	Torsten Lodderstedt, Hui-Lan Lu, Paul Madsen, Alastair Mair, Eve		Le Hara, Rasmus Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Paul
	Maler, James Manger, Mark McGloin, Laurence Miao, Chuck Mortimore,		Madsen, Alastair Mair, Eve Maler, James Manger, Mark McGloin,
	Anthony Nadalin, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob		Laurence Miao, Chuck Mortimore, Anthony Nadalin, Justin Richer, Peter
	Sayre, Marius Scurtescu, Naitik Shah, Luke Shepard, Vlad Skvortsov,		Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah,
	Justin Smith, Jeremy Suriel, Christian Stuebner, Paul Tarjan, Allen		Luke Shepard, Vlad Skvortsov, Justin Smith, Jeremy Suriel, Christian
	Tom, Franklin Tse, Nick Walker, Shane Weeden, and Skylar Woodward.		Stuebner, Paul Tarjan, Allen Tom, Franklin Tse, Nick Walker, Shane
			Weeden, and Skylar Woodward.
	Appendix A. Editor's Notes		Appendix A. Editor's Notes
	While many people contributed to this specification throughout its		While many people contributed to this specification throughout its
	long journey, the editor would like to acknowledge and thank a few		long journey, the editor would like to acknowledge and thank a few
	individuals for their outstanding and invaluable efforts leading up		individuals for their outstanding and invaluable efforts leading up
	to the publication of this specification. It is these individuals		to the publication of this specification. It is these individuals
	without whom this work would not have existed or reached its		without whom this work would not have existed or reached its
	successful conclusion.		successful conclusion.
	skipping to change at page 60, line 33 ¶		skipping to change at page 61, line 29 ¶
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[W3C.REC-html401-19991224]		[W3C.REC-html401-19991224]
	Jacobs, I., Hors, A., and D. Raggett, "HTML 4.01		Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01
	Specification", World Wide Web Consortium		Specification", World Wide Web Consortium
	Recommendation REC-html401-19991224, December 1999,		Recommendation REC-html401-19991224, December 1999,
	<http://www.w3.org/TR/1999/REC-html401-19991224>.		<http://www.w3.org/TR/1999/REC-html401-19991224>.
	13.2. Informative References		13.2. Informative References
	[I-D.draft-hardt-oauth-01]		[I-D.draft-hardt-oauth-01]
	Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth		Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth
	Web Resource Authorization Profiles", January 2010.		Web Resource Authorization Profiles", January 2010.
	skipping to change at page 61, line 12 ¶		skipping to change at page 62, line 9 ¶
	Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0		Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0
	Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-04		Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-04
	(work in progress), March 2011.		(work in progress), March 2011.
	[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., Barth, A., and B. Adida, "HTTP
	Authentication: MAC Access Authentication",		Authentication: MAC Access Authentication",
	draft-ietf-oauth-v2-http-mac-00 (work in progress),		draft-ietf-oauth-v2-http-mac-00 (work in progress),
	May 2011.		May 2011.
	[I-D.lodderstedt-oauth-security]		[I-D.ietf-oauth-v2-threatmodel]
	Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0		Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
	Threat Model and Security Considerations",		Threat Model and Security Considerations",
	draft-lodderstedt-oauth-security-01 (work in progress),		draft-ietf-oauth-v2-threatmodel-00 (work in progress),
	March 2011.		July 2011.
	[OASIS.saml-core-2.0-os]		[OASIS.saml-core-2.0-os]
	Cantor, S., Kemp, J., Philpott, R., and E. Maler,		Cantor, S., Kemp, J., Philpott, R., and E. Maler,
	"Assertions and Protocol for the OASIS Security Assertion		"Assertions and Protocol for the OASIS Security Assertion
	Markup Language (SAML) V2.0", OASIS Standard saml-core-		Markup Language (SAML) V2.0", OASIS Standard saml-core-
	2.0-os, March 2005.		2.0-os, March 2005.
	[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,		[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
	April 2010.		April 2010.
End of changes. 44 change blocks.
	191 lines changed or deleted		219 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/