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