< draft-ietf-oauth-v2-bearer-19.txt		draft-ietf-oauth-v2-bearer-20.txt >
	OAuth Working Group M. Jones		OAuth Working Group M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track D. Hardt		Intended status: Standards Track D. Hardt
	Expires: October 25, 2012 independent		Expires: December 10, 2012 independent
	D. Recordon		D. Recordon
	Facebook		Facebook
	April 23, 2012		June 8, 2012
	The OAuth 2.0 Authorization Protocol: Bearer Tokens		The OAuth 2.0 Authorization Framework: Bearer Token Usage
	draft-ietf-oauth-v2-bearer-19		draft-ietf-oauth-v2-bearer-20
	Abstract		Abstract
	This specification describes how to use bearer tokens in HTTP		This specification describes how to use bearer tokens in HTTP
	requests to access OAuth 2.0 protected resources. Any party in		requests to access OAuth 2.0 protected resources. Any party in
	possession of a bearer token (a "bearer") can use it to get access to		possession of a bearer token (a "bearer") can use it to get access to
	the associated resources (without demonstrating possession of a		the associated resources (without demonstrating possession of a
	cryptographic key). To prevent misuse, bearer tokens need to be		cryptographic key). To prevent misuse, bearer tokens need to be
	protected from disclosure in storage and in transport.		protected from disclosure in storage and in transport.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 25, 2012.		This Internet-Draft will expire on December 10, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Authenticated Requests . . . . . . . . . . . . . . . . . . . . 5		2. Authenticated Requests . . . . . . . . . . . . . . . . . . . . 5
	2.1. Authorization Request Header Field . . . . . . . . . . . . 5		2.1. Authorization Request Header Field . . . . . . . . . . . . 5
	2.2. Form-Encoded Body Parameter . . . . . . . . . . . . . . . 6		2.2. Form-Encoded Body Parameter . . . . . . . . . . . . . . . 6
	2.3. URI Query Parameter . . . . . . . . . . . . . . . . . . . 7		2.3. URI Query Parameter . . . . . . . . . . . . . . . . . . . 7
	3. The WWW-Authenticate Response Header Field . . . . . . . . . . 7		3. The WWW-Authenticate Response Header Field . . . . . . . . . . 8
	3.1. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 9		3.1. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 9
	4. Example Access Token Response . . . . . . . . . . . . . . . . 10		4. Example Access Token Response . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	5.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 10		5.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 11
	5.2. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 11		5.2. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 11
	5.3. Summary of Recommendations . . . . . . . . . . . . . . . . 13		5.3. Summary of Recommendations . . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	6.1. OAuth Access Token Type Registration . . . . . . . . . . . 14		6.1. OAuth Access Token Type Registration . . . . . . . . . . . 14
	6.1.1. The "Bearer" OAuth Access Token Type . . . . . . . . . 14		6.1.1. The "Bearer" OAuth Access Token Type . . . . . . . . . 14
	6.2. Authentication Scheme Registration . . . . . . . . . . . . 14		6.2. OAuth Extensions Error Registration . . . . . . . . . . . 14
	6.2.1. The "Bearer" Authentication Scheme . . . . . . . . . . 14		6.2.1. The "invalid_request" Error Value . . . . . . . . . . 14
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		6.2.2. The "invalid_token" Error Value . . . . . . . . . . . 15
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 14		6.2.3. The "insufficient_scope" Error Value . . . . . . . . . 15
	7.2. Informative References . . . . . . . . . . . . . . . . . . 16		6.3. Authentication Scheme Registration . . . . . . . . . . . . 16
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16		6.3.1. The "Bearer" Authentication Scheme . . . . . . . . . . 16
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 17		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23		7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
			7.2. Informative References . . . . . . . . . . . . . . . . . . 17
			Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18
			Appendix B. Document History . . . . . . . . . . . . . . . . . . 18
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	OAuth enables clients to access protected resources by obtaining an		OAuth enables clients to access protected resources by obtaining an
	access token, which is defined in OAuth 2.0 Authorization		access token, which is defined in OAuth 2.0 Authorization
	[I-D.ietf-oauth-v2] as "a string representing an access authorization		[I-D.ietf-oauth-v2] as "a string representing an access authorization
	issued to the client", rather than using the resource owner's		issued to the client", rather than using the resource owner's
	credentials directly.		credentials directly.
	Tokens are issued to clients by an authorization server with the		Tokens are issued to clients by an authorization server with the
	skipping to change at page 3, line 35 ¶		skipping to change at page 3, line 35 ¶
	[I-D.ietf-oauth-v2] flows to access OAuth protected resources, this		[I-D.ietf-oauth-v2] flows to access OAuth protected resources, this
	specification actually defines a general HTTP authorization method		specification actually defines a general HTTP authorization method
	that can be used with bearer tokens from any source to access any		that can be used with bearer tokens from any source to access any
	resources protected by those bearer tokens. The Bearer		resources protected by those bearer tokens. The Bearer
	authentication scheme is intended primarily for server authentication		authentication scheme is intended primarily for server authentication
	using the WWW-Authenticate and Authorization HTTP headers, but does		using the WWW-Authenticate and Authorization HTTP headers, but does
	not preclude its use for proxy authentication.		not preclude its use for proxy authentication.
	1.1. Notational Conventions		1.1. Notational Conventions
	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 Key words for use in		document are to be interpreted as described in Key words for use in
	RFCs to Indicate Requirement Levels [RFC2119].		RFCs to Indicate Requirement Levels [RFC2119].
	This document uses the Augmented Backus-Naur Form (ABNF) notation of		This document uses the Augmented Backus-Naur Form (ABNF) notation of
	[RFC5234]. Additionally, the following rules are included from		[RFC5234]. Additionally, the following rules are included from
	HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]: auth-param, auth-scheme,		HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]: auth-param, auth-scheme,
	and b64token; and from Uniform Resource Identifier (URI) [RFC3986]:		and b64token; and from Uniform Resource Identifier (URI) [RFC3986]:
	URI-Reference.		URI-Reference.
	Unless otherwise noted, all the protocol parameter names and values		Unless otherwise noted, all the protocol parameter names and values
	skipping to change at page 6, line 22 ¶		skipping to change at page 6, line 22 ¶
	credentials = "Bearer" 1*SP b64token		credentials = "Bearer" 1*SP b64token
	The b64token syntax was chosen over the alternative #auth-param		The b64token syntax was chosen over the alternative #auth-param
	syntax also defined by HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]		syntax also defined by HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]
	both for simplicity and for compatibility with existing		both for simplicity and for compatibility with existing
	implementations. If additional parameters are needed in the future,		implementations. If additional parameters are needed in the future,
	a different scheme would need to be defined.		a different scheme would need to be defined.
	Clients SHOULD make authenticated requests with a bearer token using		Clients SHOULD make authenticated requests with a bearer token using
	the "Authorization" request header field with the "Bearer" HTTP		the "Authorization" request header field with the "Bearer" HTTP
	authorization scheme. Resource servers compliant with this		authorization scheme. Resource servers MUST support this method.
	specification MUST support this method.
	2.2. Form-Encoded Body Parameter		2.2. Form-Encoded Body Parameter
	When sending the access token in the HTTP request entity-body, the		When sending the access token in the HTTP request entity-body, the
	client adds the access token to the request body using the		client adds the access token to the request body using the
	"access_token" parameter. The client MUST NOT use this method unless		"access_token" parameter. The client MUST NOT use this method unless
	all of the following conditions are met:		all of the following conditions are met:
	o The HTTP request entity-header includes the "Content-Type" header		o The HTTP request entity-header includes the "Content-Type" header
	field set to "application/x-www-form-urlencoded".		field set to "application/x-www-form-urlencoded".
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 16 ¶
	transport-layer security:		transport-layer security:
	POST /resource HTTP/1.1		POST /resource HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	access_token=mF_9.B5f-4.1JqM		access_token=mF_9.B5f-4.1JqM
	The "application/x-www-form-urlencoded" method SHOULD NOT be used		The "application/x-www-form-urlencoded" method SHOULD NOT be used
	except in application contexts where participating browsers do not		except in application contexts where participating browsers do not
	have access to the "Authorization" request header field. Resource		have access to the "Authorization" request header field. Resource
	servers compliant with this specification MAY support this method.		servers MAY support this method.
	2.3. URI Query Parameter		2.3. URI Query Parameter
	When sending the access token in the HTTP request URI, the client		When sending the access token in the HTTP request URI, the client
	adds the access token to the request URI query component as defined		adds the access token to the request URI query component as defined
	by Uniform Resource Identifier (URI) [RFC3986] using the		by Uniform Resource Identifier (URI) [RFC3986] using the
	"access_token" parameter.		"access_token" parameter.
	For example, the client makes the following HTTP request using		For example, the client makes the following HTTP request using
	transport-layer security:		transport-layer security:
	skipping to change at page 7, line 38 ¶		skipping to change at page 7, line 38 ¶
	Host: server.example.com		Host: server.example.com
	The HTTP request URI query can include other request-specific		The HTTP request URI query can include other request-specific
	parameters, in which case, the "access_token" parameter MUST be		parameters, in which case, the "access_token" parameter MUST be
	properly separated from the request-specific parameters using "&"		properly separated from the request-specific parameters using "&"
	character(s) (ASCII code 38).		character(s) (ASCII code 38).
	For example:		For example:
	https://server.example.com/resource?x=y&access_token=mF_9.B5f-4.1JqM&p=q		https://server.example.com/resource?x=y&access_token=mF_9.B5f-4.1JqM&p=q
			Clients using the URI Query Parameter method SHOULD also send a
			Cache-Control header containing the "no-store" option. Server
			success (2XX status) responses to these requests SHOULD contain a
			Cache-Control header with the "private" option.
	Because of the security weaknesses associated with the URI method		Because of the security weaknesses associated with the URI method
	(see Section 5), including the high likelihood that the URL		(see Section 5), including the high likelihood that the URL
	containing the access token will be logged, it SHOULD NOT be used		containing the access token will be logged, it SHOULD NOT be used
	unless it is impossible to transport the access token in the		unless it is impossible to transport the access token in the
	"Authorization" request header field or the HTTP request entity-body.		"Authorization" request header field or the HTTP request entity-body.
	Resource servers compliant with this specification MAY support this		Resource servers MAY support this method.
	method.
			This method is included to document current use; its use is NOT
			RECOMMENDED, both due to its security deficiencies (see Section 5)
			and because it uses a reserved query parameter name, which is counter
			to URI namespace best practices, per the Architecture of the World
			Wide Web [W3C.REC-webarch-20041215].
	3. The WWW-Authenticate Response Header Field		3. The WWW-Authenticate Response Header Field
	If the protected resource request does not include authentication		If the protected resource request does not include authentication
	credentials or does not contain an access token that enables access		credentials or does not contain an access token that enables access
	to the protected resource, the resource server MUST include the HTTP		to the protected resource, the resource server MUST include the HTTP
	"WWW-Authenticate" response header field; it MAY include it in		"WWW-Authenticate" response header field; it MAY include it in
	response to other conditions as well. The "WWW-Authenticate" header		response to other conditions as well. The "WWW-Authenticate" header
	field uses the framework defined by HTTP/1.1, Part 7		field uses the framework defined by HTTP/1.1, Part 7
	[I-D.ietf-httpbis-p7-auth].		[I-D.ietf-httpbis-p7-auth].
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 14 ¶
	request was declined. The parameter value is described in		request was declined. The parameter value is described in
	Section 3.1. In addition, the resource server MAY include the		Section 3.1. In addition, the resource server MAY include the
	"error_description" attribute to provide developers a human-readable		"error_description" attribute to provide developers a human-readable
	explanation that is not meant to be displayed to end users. It also		explanation that is not meant to be displayed to end users. It also
	MAY include the "error_uri" attribute with an absolute URI		MAY include the "error_uri" attribute with an absolute URI
	identifying a human-readable web page explaining the error. The		identifying a human-readable web page explaining the error. The
	"error", "error_description", and "error_uri" attributes MUST NOT		"error", "error_description", and "error_uri" attributes MUST NOT
	appear more than once.		appear more than once.
	Values for the "scope" attribute MUST NOT include characters outside		Values for the "scope" attribute MUST NOT include characters outside
	the set %x21 / %x23-5B / %x5D-7E for representing scope values and		the set %x21 / %x23-5B / %x5D-7E specified in Section A.4 of OAuth
	%x20 for delimiters between scope values. Values for the "error" and		2.0 Authorization [I-D.ietf-oauth-v2] for representing scope values
	"error_description" attributes MUST NOT include characters outside		and %x20 for delimiters between scope values. Values for the "error"
	the set %x20-21 / %x23-5B / %x5D-7E. Values for the "error_uri"		and "error_description" attributes MUST NOT include characters
			outside the set %x20-21 / %x23-5B / %x5D-7E specified in Sections A.7
			and A.8 of OAuth 2.0 Authorization. Values for the "error_uri"
	attribute MUST conform to the URI-Reference syntax, and thus MUST NOT		attribute MUST conform to the URI-Reference syntax, and thus MUST NOT
	include characters outside the set %x21 / %x23-5B / %x5D-7E.		include characters outside the set %x21 / %x23-5B / %x5D-7E specified
			in Section A.9 of OAuth 2.0 Authorization.
	For example, in response to a protected resource request without		For example, in response to a protected resource request without
	authentication:		authentication:
	HTTP/1.1 401 Unauthorized		HTTP/1.1 401 Unauthorized
	WWW-Authenticate: Bearer realm="example"		WWW-Authenticate: Bearer realm="example"
	And in response to a protected resource request with an		And in response to a protected resource request with an
	authentication attempt using an expired access token:		authentication attempt using an expired access token:
	HTTP/1.1 401 Unauthorized		HTTP/1.1 401 Unauthorized
	WWW-Authenticate: Bearer realm="example",		WWW-Authenticate: Bearer realm="example",
	skipping to change at page 10, line 39 ¶		skipping to change at page 11, line 10 ¶
	This section describes the relevant security threats regarding token		This section describes the relevant security threats regarding token
	handling when using bearer tokens and describes how to mitigate these		handling when using bearer tokens and describes how to mitigate these
	threats.		threats.
	5.1. Security Threats		5.1. Security Threats
	The following list presents several common threats against protocols		The following list presents several common threats against protocols
	utilizing some form of tokens. This list of threats is based on NIST		utilizing some form of tokens. This list of threats is based on NIST
	Special Publication 800-63 [NIST800-63]. Since this document builds		Special Publication 800-63 [NIST800-63]. Since this document builds
	on the OAuth 2.0 specification, we exclude a discussion of threats		on the OAuth 2.0 Authorization specification, we exclude a discussion
	that are described there or in related documents.		of threats that are described there or in related documents.
	Token manufacture/modification: An attacker may generate a bogus		Token manufacture/modification: An attacker may generate a bogus
	token or modify the token contents (such as the authentication or		token or modify the token contents (such as the authentication or
	attribute statements) of an existing token, causing the resource		attribute statements) of an existing token, causing the resource
	server to grant inappropriate access to the client. For example,		server to grant inappropriate access to the client. For example,
	an attacker may modify the token to extend the validity period; a		an attacker may modify the token to extend the validity period; a
	malicious client may modify the assertion to gain access to		malicious client may modify the assertion to gain access to
	information that they should not be able to view.		information that they should not be able to view.
	Token disclosure: Tokens may contain authentication and attribute		Token disclosure: Tokens may contain authentication and attribute
	skipping to change at page 14, line 10 ¶		skipping to change at page 14, line 20 ¶
	secure URLs in the browser history, web server logs, and other		secure URLs in the browser history, web server logs, and other
	data structures. If bearer tokens are passed in page URLs,		data structures. If bearer tokens are passed in page URLs,
	attackers might be able to steal them from the history data, logs,		attackers might be able to steal them from the history data, logs,
	or other unsecured locations.		or other unsecured locations.
	6. IANA Considerations		6. IANA Considerations
	6.1. OAuth Access Token Type Registration		6.1. OAuth Access Token Type Registration
	This specification registers the following access token type in the		This specification registers the following access token type in the
	OAuth Access Token Type Registry.		OAuth Access Token Type Registry defined in OAuth 2.0 Authorization
			[I-D.ietf-oauth-v2].
	6.1.1. The "Bearer" OAuth Access Token Type		6.1.1. The "Bearer" OAuth Access Token Type
	Type name:		Type name:
	Bearer		Bearer
	Additional Token Endpoint Response Parameters:		Additional Token Endpoint Response Parameters:
	(none)		(none)
	HTTP Authentication Scheme(s):		HTTP Authentication Scheme(s):
	Bearer		Bearer
	Change controller:		Change controller:
	IETF		IETF
	Specification document(s):		Specification document(s):
	[[ this document ]]		[[ this document ]]
	6.2. Authentication Scheme Registration		6.2. OAuth Extensions Error Registration
			This specification registers the following error values in the OAuth
			Extensions Error Registry defined in OAuth 2.0 Authorization
			[I-D.ietf-oauth-v2].
			6.2.1. The "invalid_request" Error Value
			Error name:
			invalid_request
			Error usage location:
			Resource access error response
			Related protocol extension:
			Bearer access token type
			Change controller:
			IETF
			Specification document(s):
			[[ this document ]]
			6.2.2. The "invalid_token" Error Value
			Error name:
			invalid_token
			Error usage location:
			Resource access error response
			Related protocol extension:
			Bearer access token type
			Change controller:
			IETF
			Specification document(s):
			[[ this document ]]
			6.2.3. The "insufficient_scope" Error Value
			Error name:
			insufficient_scope
			Error usage location:
			Resource access error response
			Related protocol extension:
			Bearer access token type
			Change controller:
			IETF
			Specification document(s):
			[[ this document ]]
			6.3. Authentication Scheme Registration
	This specification registers the following authentication scheme in		This specification registers the following authentication scheme in
	the Authentication Scheme Registry defined in HTTP/1.1, Part 7		the Authentication Scheme Registry defined in HTTP/1.1, Part 7
	[I-D.ietf-httpbis-p7-auth].		[I-D.ietf-httpbis-p7-auth].
	6.2.1. The "Bearer" Authentication Scheme		6.3.1. The "Bearer" Authentication Scheme
	Authentication Scheme Name:		Authentication Scheme Name:
	Bearer		Bearer
	Pointer to specification text:		Pointer to specification text:
	[[ this document ]]		[[ this document ]]
	Notes (optional):		Notes (optional):
	(none)		(none)
	skipping to change at page 15, line 14 ¶		skipping to change at page 16, line 41 ¶
	1: URIs, Connections, and Message Parsing",		1: URIs, Connections, and Message Parsing",
	draft-ietf-httpbis-p1-messaging-19 (work in progress),		draft-ietf-httpbis-p1-messaging-19 (work in progress),
	March 2012.		March 2012.
	[I-D.ietf-httpbis-p7-auth]		[I-D.ietf-httpbis-p7-auth]
	Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part		Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part
	7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in		7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in
	progress), March 2012.		progress), March 2012.
	[I-D.ietf-oauth-v2]		[I-D.ietf-oauth-v2]
	Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth		Hammer, E., Recordon, D., and D. Hardt, "The OAuth 2.0
	2.0 Authorization Protocol", draft-ietf-oauth-v2-25 (work		Authorization Framework", draft-ietf-oauth-v2-27 (work in
	in progress), March 2012.		progress), June 2012.
	[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.
	[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",		[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
	RFC 2246, January 1999.		RFC 2246, January 1999.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	skipping to change at page 16, line 6 ¶		skipping to change at page 17, line 33 ¶
	[USASCII] American National Standards Institute, "Coded Character		[USASCII] American National Standards Institute, "Coded Character
	Set -- 7-bit American Standard Code for Information		Set -- 7-bit American Standard Code for Information
	Interchange", ANSI X3.4, 1986.		Interchange", ANSI X3.4, 1986.
	[W3C.REC-html401-19991224]		[W3C.REC-html401-19991224]
	Hors, A., Raggett, D., and I. Jacobs, "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>.
			[W3C.REC-webarch-20041215]
			Jacobs, I. and N. Walsh, "Architecture of the World Wide
			Web, Volume One", World Wide Web Consortium
			Recommendation REC-webarch-20041215, December 2004,
			<http://www.w3.org/TR/2004/REC-webarch-20041215>.
	7.2. Informative References		7.2. Informative References
	[NIST800-63]		[NIST800-63]
	Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S.,		Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S.,
	and E. Nabbus, "NIST Special Publication 800-63-1,		and E. Nabbus, "NIST Special Publication 800-63-1,
	INFORMATION SECURITY", December 2008.		INFORMATION SECURITY", December 2008.
	[OMAP] Huff, J., Schlacht, D., Nadalin, A., Simmons, J.,		[OMAP] Huff, J., Schlacht, D., Nadalin, A., Simmons, J.,
	Rosenberg, P., Madsen, P., Ace, T., Rickelton-Abdi, C.,		Rosenberg, P., Madsen, P., Ace, T., Rickelton-Abdi, C.,
	and B. Boyer, "Online Multimedia Authorization Protocol:		and B. Boyer, "Online Multimedia Authorization Protocol:
	An Industry Standard for Authorized Access to Internet		An Industry Standard for Authorized Access to Internet
	Multimedia Resources", April 2012.		Multimedia Resources", April 2012.
	[OpenID.Messages]		[OpenID.Messages]
	Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B.,		Sakimura, N., Bradley, J., Jones, M., de Medeiros, B.,
	Jones, M., and E. Jay, "OpenID Connect Messages 1.0",		Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0",
	April 2012.		May 2012.
	[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.
	skipping to change at page 16, line 44 ¶		skipping to change at page 18, line 28 ¶
	The following people contributed to preliminary versions of this		The following people contributed to preliminary versions of this
	document: Blaine Cook (BT), Brian Eaton (Google), Yaron Y. Goland		document: Blaine Cook (BT), Brian Eaton (Google), Yaron Y. Goland
	(Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter),		(Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter),
	Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and		Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and
	concepts within are a product of the OAuth community, the WRAP		concepts within are a product of the OAuth community, the WRAP
	community, and the OAuth Working Group.		community, and the OAuth Working Group.
	The OAuth Working Group has dozens of very active contributors who		The OAuth Working Group has dozens of very active contributors who
	proposed ideas and wording for this document, including: Michael		proposed ideas and wording for this document, including: Michael
	Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, John Bradley,		Adams, Amanda Anganes, Andrew Arnott, Derek Atkins, Dirk Balfanz,
	Brian Campbell, Leah Culver, Bill de hOra, Brian Ellin, Igor		John Bradley, Brian Campbell, Francisco Corella, Leah Culver, Bill de
	Faynberg, Stephen Farrell, George Fletcher, Tim Freeman, Evan		hOra, Breno de Medeiros, Brian Ellin, Igor Faynberg, Stephen Farrell,
	Gilbert, Yaron Y. Goland, Thomas Hardjono, Justin Hart, Phil Hunt,		Igor Faynberg, George Fletcher, Tim Freeman, Evan Gilbert, Yaron Y.
	John Kemp, Eran Hammer, Chasen Le Hara, Barry Leiba, Michael B.		Goland, Thomas Hardjono, Justin Hart, Phil Hunt, John Kemp, Eran
	Jones, Torsten Lodderstedt, Eve Maler, James Manger, Laurence Miao,		Hammer, Chasen Le Hara, Dick Hardt, Barry Leiba, Amos Jeffries,
	William J. Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke,		Michael B. Jones, Torsten Lodderstedt, Paul Madsen, Eve Maler, James
	Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius		Manger, Laurence Miao, William J. Mills, Chuck Mortimore, Anthony
	Scurtescu, Naitik Shah, Justin Smith, Jeremy Suriel, Christian		Nadalin, Axel Nennker, Mark Nottingham, David Recordon, Julian
	Stuebner, Paul Tarjan, Hannes Tschofenig, Franklin Tse, and Shane		Reschke, Rob Richards, Justin Richer, Peter Saint-Andre, Nat
	Weeden.		Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Justin Smith,
			Jeremy Suriel, Christian Stuebner, Doug Tangren, Paul Tarjan, Hannes
			Tschofenig, Franklin Tse, Sean Turner, Paul Walker, Shane Weeden,
			Skylar Woodward, and Zachary Zeltsan.
	Appendix B. Document History		Appendix B. Document History
	[[ to be removed by the RFC editor before publication as an RFC ]]		[[ to be removed by the RFC editor before publication as an RFC ]]
			-20
			o Added caveat about using a reserved query parameter name being
			counter to URI namespace best practices.
			o Specified use of Cache-Control options when using the URI Query
			Parameter method.
			o Changed title to "The OAuth 2.0 Authorization Framework: Bearer
			Token Usage".
			o Referenced syntax definitions for the "scope", "error",
			"error_description", and "error_uri" parameters in the OAuth 2.0
			core spec.
			o Registered the "invalid_request", "invalid_token", and
			"insufficient_scope" error values in the OAuth Extensions Error
			Registry.
			o Acknowledged additional individuals.
	-19		-19
	o Addressed DISCUSS issues and comments raised for which resultions		o Addressed DISCUSS issues and comments raised for which resolutions
	have been agreed to. No normative changes were made. Changes		have been agreed to. No normative changes were made. Changes
	made were:		made were:
	o Use ABNF from RFC 5234.		o Use ABNF from RFC 5234.
	o Added sentence "The Bearer authentication scheme is intended		o Added sentence "The Bearer authentication scheme is intended
	primarily for server authentication using the WWW-Authenticate and		primarily for server authentication using the WWW-Authenticate and
	Authorization HTTP headers, but does not preclude its use for		Authorization HTTP headers, but does not preclude its use for
	proxy authentication" to the introduction.		proxy authentication" to the introduction.
End of changes. 24 change blocks.
	50 lines changed or deleted		152 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/