< draft-ietf-oauth-v2-bearer-17.txt		draft-ietf-oauth-v2-bearer-18.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: August 19, 2012 independent		Expires: September 13, 2012 independent
	D. Recordon		D. Recordon
	Facebook		Facebook
	February 16, 2012		March 12, 2012
	The OAuth 2.0 Authorization Protocol: Bearer Tokens		The OAuth 2.0 Authorization Protocol: Bearer Tokens
	draft-ietf-oauth-v2-bearer-17		draft-ietf-oauth-v2-bearer-18
	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 August 19, 2012.		This Internet-Draft will expire on September 13, 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 21 ¶		skipping to change at page 2, line 21 ¶
	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 . . . . . . . . . . 7
	3.1. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 9		3.1. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 10		4. Example Access Token Response . . . . . . . . . . . . . . . . 9
	4.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	4.2. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 10		5.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Summary of Recommendations . . . . . . . . . . . . . . . . 12		5.2. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 11
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		5.3. Summary of Recommendations . . . . . . . . . . . . . . . . 12
	5.1. OAuth Access Token Type Registration . . . . . . . . . . . 13		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	5.1.1. The "Bearer" OAuth Access Token Type . . . . . . . . . 13		6.1. OAuth Access Token Type Registration . . . . . . . . . . . 13
	5.2. Authentication Scheme Registration . . . . . . . . . . . . 14		6.1.1. The "Bearer" OAuth Access Token Type . . . . . . . . . 13
	5.2.1. The "Bearer" Authentication Scheme . . . . . . . . . . 14		6.2. Authentication Scheme Registration . . . . . . . . . . . . 14
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		6.2.1. The "Bearer" Authentication Scheme . . . . . . . . . . 14
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 14		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	6.2. Informative References . . . . . . . . . . . . . . . . . . 15		7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15		7.2. Informative References . . . . . . . . . . . . . . . . . . 15
			Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 16		Appendix B. Document History . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
	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.
	skipping to change at page 6, line 6 ¶		skipping to change at page 6, line 6 ¶
	than one method to transmit the token in each request.		than one method to transmit the token in each request.
	2.1. Authorization Request Header Field		2.1. Authorization Request Header Field
	When sending the access token in the "Authorization" request header		When sending the access token in the "Authorization" request header
	field defined by HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth], the		field defined by HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth], the
	client uses the "Bearer" authentication scheme to transmit the access		client uses the "Bearer" authentication scheme to transmit the access
	token.		token.
	For example:		For example:
	GET /resource HTTP/1.1		GET /resource HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Authorization: Bearer vF9dft4qmT		Authorization: Bearer mF_9.B5f-4.1JqM
	The "Authorization" header field uses the framework defined by		The "Authorization" header field uses the framework defined by
	HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth] as follows:		HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth] as follows:
	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
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	defined semantics. In particular, this means that the "GET"		defined semantics. In particular, this means that the "GET"
	method MUST NOT be used.		method MUST NOT be used.
	The entity-body MAY include other request-specific parameters, in		The entity-body MAY include other request-specific parameters, in
	which case, the "access_token" parameter MUST be properly separated		which case, the "access_token" parameter MUST be properly separated
	from the request-specific parameters using "&" character(s) (ASCII		from the request-specific parameters using "&" character(s) (ASCII
	code 38).		code 38).
	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:
	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=vF9dft4qmT		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 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:
			GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1
	GET /resource?access_token=vF9dft4qmT HTTP/1.1
	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=vF9dft4qmT&p=q
	Because of the security weaknesses associated with the URI method		Because of the security weaknesses associated with the URI method
	(see Section 4), 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 MAY support this method.		Resource servers MAY support this method.
	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
	skipping to change at page 10, line 6 ¶		skipping to change at page 9, line 44 ¶
	403 (Forbidden) status code and MAY include the "scope"		403 (Forbidden) status code and MAY include the "scope"
	attribute with the scope necessary to access the protected		attribute with the scope necessary to access the protected
	resource.		resource.
	If the request lacks any authentication information (i.e. the client		If the request lacks any authentication information (i.e. the client
	was unaware authentication is necessary or attempted using an		was unaware authentication is necessary or attempted using an
	unsupported authentication method), the resource server SHOULD NOT		unsupported authentication method), the resource server SHOULD NOT
	include an error code or other error information.		include an error code or other error information.
	For example:		For example:
	HTTP/1.1 401 Unauthorized		HTTP/1.1 401 Unauthorized
	WWW-Authenticate: Bearer realm="example"		WWW-Authenticate: Bearer realm="example"
	4. Security Considerations		4. Example Access Token Response
			Typically a bearer token is returned to the client as part of an
			OAuth 2.0 [I-D.ietf-oauth-v2] access token response. An example of
			such a response is:
			HTTP/1.1 200 OK
			Content-Type: application/json;charset=UTF-8
			Cache-Control: no-store
			Pragma: no-cache
			{
			"access_token":"mF_9.B5f-4.1JqM",
			"token_type":"Bearer",
			"expires_in":3600,
			"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
			}
			5. Security Considerations
	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.
	4.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 specification, we exclude a discussion of threats
	that are described there or in related documents.		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
	skipping to change at page 10, line 42 ¶		skipping to change at page 11, line 5 ¶
	Token disclosure: Tokens may contain authentication and attribute		Token disclosure: Tokens may contain authentication and attribute
	statements that include sensitive information.		statements that include sensitive information.
	Token redirect: An attacker uses a token generated for consumption		Token redirect: An attacker uses a token generated for consumption
	by one resource server to gain access to a different resource		by one resource server to gain access to a different resource
	server that mistakenly believes the token to be for it.		server that mistakenly believes the token to be for it.
	Token replay: An attacker attempts to use a token that has already		Token replay: An attacker attempts to use a token that has already
	been used with that resource server in the past.		been used with that resource server in the past.
	4.2. Threat Mitigation		5.2. Threat Mitigation
	A large range of threats can be mitigated by protecting the contents		A large range of threats can be mitigated by protecting the contents
	of the token by using a digital signature or a Message Authentication		of the token by using a digital signature or a Message Authentication
	Code (MAC). Alternatively, a bearer token can contain a reference to		Code (MAC). Alternatively, a bearer token can contain a reference to
	authorization information, rather than encoding the information		authorization information, rather than encoding the information
	directly. Such references MUST be infeasible for an attacker to		directly. Such references MUST be infeasible for an attacker to
	guess; using a reference may require an extra interaction between a		guess; using a reference may require an extra interaction between a
	server and the token issuer to resolve the reference to the		server and the token issuer to resolve the reference to the
	authorization information. The mechanics of such an interaction are		authorization information. The mechanics of such an interaction are
	not defined by this specification.		not defined by this specification.
	skipping to change at page 12, line 28 ¶		skipping to change at page 12, line 38 ¶
	Consequently, such an on-path adversary cannot replay the token.		Consequently, such an on-path adversary cannot replay the token.
	Furthermore, when presenting the token to a resource server, the		Furthermore, when presenting the token to a resource server, the
	client MUST verify the identity of that resource server, as per		client MUST verify the identity of that resource server, as per
	Section 3.1 of HTTP Over TLS [RFC2818]. Note that the client MUST		Section 3.1 of HTTP Over TLS [RFC2818]. Note that the client MUST
	validate the TLS certificate chain when making these requests to		validate the TLS certificate chain when making these requests to
	protected resources. Presenting the token to an unauthenticated and		protected resources. Presenting the token to an unauthenticated and
	unauthorized resource server or failing to validate the certificate		unauthorized resource server or failing to validate the certificate
	chain will allow adversaries to steal the token and gain unauthorized		chain will allow adversaries to steal the token and gain unauthorized
	access to protected resources.		access to protected resources.
	4.3. Summary of Recommendations		5.3. Summary of Recommendations
	Safeguard bearer tokens: Client implementations MUST ensure that		Safeguard bearer tokens: Client implementations MUST ensure that
	bearer tokens are not leaked to unintended parties, as they will		bearer tokens are not leaked to unintended parties, as they will
	be able to use them to gain access to protected resources. This		be able to use them to gain access to protected resources. This
	is the primary security consideration when using bearer tokens and		is the primary security consideration when using bearer tokens and
	underlies all the more specific recommendations that follow.		underlies all the more specific recommendations that follow.
	Validate SSL certificate chains: The client MUST validate the TLS		Validate SSL certificate chains: The client MUST validate the TLS
	certificate chain when making requests to protected resources.		certificate chain when making requests to protected resources.
	Failing to do so may enable DNS hijacking attacks to steal the		Failing to do so may enable DNS hijacking attacks to steal the
	skipping to change at page 13, line 25 ¶		skipping to change at page 13, line 36 ¶
	Don't pass bearer tokens in page URLs: Bearer tokens SHOULD NOT be		Don't pass bearer tokens in page URLs: Bearer tokens SHOULD NOT be
	passed in page URLs (for example as query string parameters).		passed in page URLs (for example as query string parameters).
	Instead, bearer tokens SHOULD be passed in HTTP message headers or		Instead, bearer tokens SHOULD be passed in HTTP message headers or
	message bodies for which confidentiality measures are taken.		message bodies for which confidentiality measures are taken.
	Browsers, web servers, and other software may not adequately		Browsers, web servers, and other software may not adequately
	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.
	5. IANA Considerations		6. IANA Considerations
	5.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.
	5.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 ]]
	5.2. Authentication Scheme Registration		6.2. 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].
	5.2.1. The "Bearer" Authentication Scheme		6.2.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)
	6. References		7. References
	6.1. Normative References		7.1. Normative References
	[I-D.ietf-httpbis-p1-messaging]		[I-D.ietf-httpbis-p1-messaging]
	Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,		Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and
	J. Reschke, "HTTP/1.1, part 1: URIs, Connections, and		J. Reschke, "HTTP/1.1, part 1: URIs, Connections, and
	Message Parsing", draft-ietf-httpbis-p1-messaging-18 (work		Message Parsing", draft-ietf-httpbis-p1-messaging-18 (work
	in progress), January 2012.		in progress), January 2012.
	[I-D.ietf-httpbis-p7-auth]		[I-D.ietf-httpbis-p7-auth]
	Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,		Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and
	J. Reschke, "HTTP/1.1, part 7: Authentication",		J. Reschke, "HTTP/1.1, part 7: Authentication",
	draft-ietf-httpbis-p7-auth-18 (work in progress),		draft-ietf-httpbis-p7-auth-18 (work in progress),
	January 2012.		January 2012.
	[I-D.ietf-oauth-v2]		[I-D.ietf-oauth-v2]
	Hammer, E., Recordon, D., and D. Hardt, "The OAuth 2.0		Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
	Authorization Protocol", draft-ietf-oauth-v2-23 (work in		2.0 Authorization Protocol", draft-ietf-oauth-v2-25 (work
	progress), January 2012.		in progress), March 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 15, line 30 ¶		skipping to change at page 15, line 39 ¶
	[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>.
	6.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.
	[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.
	skipping to change at page 16, line 25 ¶		skipping to change at page 16, line 34 ¶
	William J. Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke,		William J. Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke,
	Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius		Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius
	Scurtescu, Naitik Shah, Justin Smith, Jeremy Suriel, Christian		Scurtescu, Naitik Shah, Justin Smith, Jeremy Suriel, Christian
	Stuebner, Paul Tarjan, Hannes Tschofenig, Franklin Tse, and Shane		Stuebner, Paul Tarjan, Hannes Tschofenig, Franklin Tse, and Shane
	Weeden.		Weeden.
	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 ]]
			-18
			o Changed example bearer token value from vF9dft4qmT to mF_9.B5f-
			4.1JqM.
			o Added example access token response returning a Bearer token.
	-17		-17
	o Restore RFC 2818 reference for server identity verification and		o Restore RFC 2818 reference for server identity verification and
	add RFC 5280 reference for certificate revocation lists, per Gen-		add RFC 5280 reference for certificate revocation lists, per Gen-
	ART review comments.		ART review comments.
	-16		-16
	o Use the HTTPbis auth-param syntax for Bearer challenge attributes.		o Use the HTTPbis auth-param syntax for Bearer challenge attributes.
	o Dropped the sentence "The "realm" value is intended for		o Dropped the sentence "The "realm" value is intended for
	programmatic use and is not meant to be displayed to end users".		programmatic use and is not meant to be displayed to end users".
	o Reordered form-encoded body parameter description bullets for		o Reordered form-encoded body parameter description bullets for
	better readability.		better readability.
	o Added [USASCII] reference.		o Added [USASCII] reference.
End of changes. 29 change blocks.
	44 lines changed or deleted		62 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/