< draft-ietf-oauth-v2-bearer-18.txt   draft-ietf-oauth-v2-bearer-19.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: September 13, 2012 independent Expires: October 25, 2012 independent
D. Recordon D. Recordon
Facebook Facebook
March 12, 2012 April 23, 2012
The OAuth 2.0 Authorization Protocol: Bearer Tokens The OAuth 2.0 Authorization Protocol: Bearer Tokens
draft-ietf-oauth-v2-bearer-18 draft-ietf-oauth-v2-bearer-19
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 September 13, 2012. This Internet-Draft will expire on October 25, 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. Example Access Token Response . . . . . . . . . . . . . . . . 9 4. Example Access Token Response . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 10 5.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 10
5.2. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 11 5.2. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 11
5.3. Summary of Recommendations . . . . . . . . . . . . . . . . 12 5.3. Summary of Recommendations . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. OAuth Access Token Type Registration . . . . . . . . . . . 13 6.1. OAuth Access Token Type Registration . . . . . . . . . . . 14
6.1.1. The "Bearer" OAuth Access Token Type . . . . . . . . . 13 6.1.1. The "Bearer" OAuth Access Token Type . . . . . . . . . 14
6.2. Authentication Scheme Registration . . . . . . . . . . . . 14 6.2. Authentication Scheme Registration . . . . . . . . . . . . 14
6.2.1. The "Bearer" Authentication Scheme . . . . . . . . . . 14 6.2.1. The "Bearer" Authentication Scheme . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Appendix B. Document History . . . . . . . . . . . . . . . . . . 16 Appendix B. Document History . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 28 skipping to change at page 3, line 28
This specification defines the use of bearer tokens over HTTP/1.1 This specification defines the use of bearer tokens over HTTP/1.1
[I-D.ietf-httpbis-p1-messaging] using TLS [RFC5246] to access [I-D.ietf-httpbis-p1-messaging] using TLS [RFC5246] to access
protected resources. TLS is mandatory to implement and use with this protected resources. TLS is mandatory to implement and use with this
specification; other specifications may extend this specification for specification; other specifications may extend this specification for
use with other transport protocols. While designed for use with use with other transport protocols. While designed for use with
access tokens resulting from OAuth 2.0 Authorization access tokens resulting from OAuth 2.0 Authorization
[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. resources protected by those bearer tokens. The Bearer
authentication scheme is intended primarily for server authentication
using the WWW-Authenticate and Authorization HTTP headers, but does
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
HTTP/1.1, Part 1 [I-D.ietf-httpbis-p1-messaging], which is based upon [RFC5234]. Additionally, the following rules are included from
the Augmented Backus-Naur Form (ABNF) [RFC5234] notation. HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]: auth-param, auth-scheme,
Additionally, the following rules are included from HTTP/1.1, Part 7 and b64token; and from Uniform Resource Identifier (URI) [RFC3986]:
[I-D.ietf-httpbis-p7-auth]: auth-param, auth-scheme, and b64token; URI-Reference.
and from Uniform Resource Identifier (URI) [RFC3986]: URI-Reference.
Unless otherwise noted, all the protocol parameter names and values Unless otherwise noted, all the protocol parameter names and values
are case sensitive. are case sensitive.
1.2. Terminology 1.2. Terminology
Bearer Token Bearer Token
A security token with the property that any party in possession of A security token with the property that any party in possession of
the token (a "bearer") can use the token in any way that any other the token (a "bearer") can use the token in any way that any other
party in possession of it can. Using a bearer token does not party in possession of it can. Using a bearer token does not
require a bearer to prove possession of cryptographic key material require a bearer to prove possession of cryptographic key material
skipping to change at page 5, line 35 skipping to change at page 5, line 35
The abstract flow illustrated in Figure 1 describes the overall OAuth The abstract flow illustrated in Figure 1 describes the overall OAuth
2.0 protocol architecture. The following steps are specified within 2.0 protocol architecture. The following steps are specified within
this document: this document:
E) The client makes a protected resource request to the resource E) The client makes a protected resource request to the resource
server by presenting the access token. server by presenting the access token.
F) The resource server validates the access token, and if valid, F) The resource server validates the access token, and if valid,
serves the request. serves the request.
This document also imposes semantic requirements upon the access
token returned in Step D.
2. Authenticated Requests 2. Authenticated Requests
This section defines three methods of sending bearer access tokens in This section defines three methods of sending bearer access tokens in
resource requests to resource servers. Clients MUST NOT use more resource requests to resource servers. Clients MUST NOT use more
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
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 MUST support this method. authorization scheme. Resource servers compliant with this
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 MAY support this method. servers compliant with this specification 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 43 skipping to change at page 7, line 43
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
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 MAY support this method. Resource servers compliant with this specification 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
"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 8, line 18 skipping to change at page 8, line 19
value "Bearer". This scheme MUST be followed by one or more auth- value "Bearer". This scheme MUST be followed by one or more auth-
param values. The auth-param attributes used or defined by this param values. The auth-param attributes used or defined by this
specification are as follows. Other auth-param attributes MAY be specification are as follows. Other auth-param attributes MAY be
used as well. used as well.
A "realm" attribute MAY be included to indicate the scope of A "realm" attribute MAY be included to indicate the scope of
protection in the manner described in HTTP/1.1, Part 7 protection in the manner described in HTTP/1.1, Part 7
[I-D.ietf-httpbis-p7-auth]. The "realm" attribute MUST NOT appear [I-D.ietf-httpbis-p7-auth]. The "realm" attribute MUST NOT appear
more than once. more than once.
The "scope" attribute is a space-delimited list of scope values The "scope" attribute is defined in Section 3.3 of OAuth 2.0
indicating the required scope of the access token for accessing the Authorization [I-D.ietf-oauth-v2]. The "scope" attribute is a space-
requested resource. In some cases, the "scope" value will be used delimited list of case sensitive scope values indicating the required
when requesting a new access token with sufficient scope of access to scope of the access token for accessing the requested resource.
utilize the protected resource. Use of the "scope" attribute is "scope" values are implementation defined; there is no centralized
OPTIONAL. The "scope" attribute MUST NOT appear more than once. The registry for them; allowed values are defined by the authorization
"scope" value is intended for programmatic use and is not meant to be server. The order of "scope" values is not significant. In some
displayed to end users. cases, the "scope" value will be used when requesting a new access
token with sufficient scope of access to utilize the protected
resource. Use of the "scope" attribute is OPTIONAL. The "scope"
attribute MUST NOT appear more than once. The "scope" value is
intended for programmatic use and is not meant to be displayed to end
users.
Two example scope values follow; these are taken from the OpenID
Connect [OpenID.Messages] and OATC Online Multimedia Authorization
Protocol [OMAP] OAuth 2.0 use cases, respectively:
scope="openid profile email"
scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"
If the protected resource request included an access token and failed If the protected resource request included an access token and failed
authentication, the resource server SHOULD include the "error" authentication, the resource server SHOULD include the "error"
attribute to provide the client with the reason why the access attribute to provide the client with the reason why the access
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
skipping to change at page 12, line 8 skipping to change at page 12, line 18
client is prevented from observing the contents of the token, token client is prevented from observing the contents of the token, token
encryption MUST be applied in addition to the usage of TLS encryption MUST be applied in addition to the usage of TLS
protection. As a further defense against token disclosure, the protection. As a further defense against token disclosure, the
client MUST validate the TLS certificate chain when making requests client MUST validate the TLS certificate chain when making requests
to protected resources, including checking the Certificate Revocation to protected resources, including checking the Certificate Revocation
List (CRL) [RFC5280]. List (CRL) [RFC5280].
Cookies are typically transmitted in the clear. Thus, any Cookies are typically transmitted in the clear. Thus, any
information contained in them is at risk of disclosure. Therefore, information contained in them is at risk of disclosure. Therefore,
bearer tokens MUST NOT be stored in cookies that can be sent in the bearer tokens MUST NOT be stored in cookies that can be sent in the
clear. clear. See HTTP State Management Mechanism [RFC6265] for security
considerations about cookies.
In some deployments, including those utilizing load balancers, the In some deployments, including those utilizing load balancers, the
TLS connection to the resource server terminates prior to the actual TLS connection to the resource server terminates prior to the actual
server that provides the resource. This could leave the token server that provides the resource. This could leave the token
unprotected between the front end server where the TLS connection unprotected between the front end server where the TLS connection
terminates and the back end server that provides the resource. In terminates and the back end server that provides the resource. In
such deployments, sufficient measures MUST be employed to ensure such deployments, sufficient measures MUST be employed to ensure
confidentiality of the token between the front end and back end confidentiality of the token between the front end and back end
servers; encryption of the token is one possible such measure. servers; encryption of the token is one possible such measure.
skipping to change at page 12, line 46 skipping to change at page 13, line 13
access to protected resources. access to protected resources.
5.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 TLS 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
token and gain unintended access. token and gain unintended access.
Always use TLS (https): Clients MUST always use TLS [RFC5246] Always use TLS (https): Clients MUST always use TLS [RFC5246]
(https) or equivalent transport security when making requests with (https) or equivalent transport security when making requests with
bearer tokens. Failing to do so exposes the token to numerous bearer tokens. Failing to do so exposes the token to numerous
attacks that could give attackers unintended access. attacks that could give attackers unintended access.
Don't store bearer tokens in cookies: Implementations MUST NOT store Don't store bearer tokens in cookies: Implementations MUST NOT store
skipping to change at page 14, line 36 skipping to change at page 14, line 51
[[ this document ]] [[ this document ]]
Notes (optional): Notes (optional):
(none) (none)
7. References 7. References
7.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., Lafon, Y., and J. Reschke, "HTTP/1.1, part
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 1: URIs, Connections, and Message Parsing",
J. Reschke, "HTTP/1.1, part 1: URIs, Connections, and draft-ietf-httpbis-p1-messaging-19 (work in progress),
Message Parsing", draft-ietf-httpbis-p1-messaging-18 (work March 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., Lafon, Y., and J. Reschke, "HTTP/1.1, part
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and 7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in
J. Reschke, "HTTP/1.1, part 7: Authentication", progress), March 2012.
draft-ietf-httpbis-p7-auth-18 (work in progress),
January 2012.
[I-D.ietf-oauth-v2] [I-D.ietf-oauth-v2]
Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
2.0 Authorization Protocol", draft-ietf-oauth-v2-25 (work 2.0 Authorization Protocol", draft-ietf-oauth-v2-25 (work
in progress), March 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",
skipping to change at page 15, line 29 skipping to change at page 15, line 41
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.
[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>.
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.,
Rosenberg, P., Madsen, P., Ace, T., Rickelton-Abdi, C.,
and B. Boyer, "Online Multimedia Authorization Protocol:
An Industry Standard for Authorized Access to Internet
Multimedia Resources", April 2012.
[OpenID.Messages]
Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B.,
Jones, M., and E. Jay, "OpenID Connect Messages 1.0",
April 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.
Appendix A. Acknowledgements Appendix A. Acknowledgements
skipping to change at page 16, line 34 skipping to change at page 17, line 13
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 ]]
-19
o Addressed DISCUSS issues and comments raised for which resultions
have been agreed to. No normative changes were made. Changes
made were:
o Use ABNF from RFC 5234.
o Added sentence "The Bearer authentication scheme is intended
primarily for server authentication using the WWW-Authenticate and
Authorization HTTP headers, but does not preclude its use for
proxy authentication" to the introduction.
o In the introduction, state that this document also imposes
semantic requirements upon the access token.
o Reference the "scope" definition in the OAuth core spec.
o Added "scope" examples.
o Reference RFC 6265 for security considerations about cookies.
-18 -18
o Changed example bearer token value from vF9dft4qmT to mF_9.B5f- o Changed example bearer token value from vF9dft4qmT to mF_9.B5f-
4.1JqM. 4.1JqM.
o Added example access token response returning a Bearer token. 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
 End of changes. 22 change blocks. 
41 lines changed or deleted 93 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/