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.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/