draft-ietf-oauth-v2-bearer-12.txt   draft-ietf-oauth-v2-bearer-13.txt 
Network Working Group M. Jones Network Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track D. Hardt Intended status: Standards Track D. Hardt
Expires: April 29, 2012 independent Expires: May 2, 2012 independent
D. Recordon D. Recordon
Facebook Facebook
October 27, 2011 October 30, 2011
The OAuth 2.0 Authorization Protocol: Bearer Tokens The OAuth 2.0 Authorization Protocol: Bearer Tokens
draft-ietf-oauth-v2-bearer-12 draft-ietf-oauth-v2-bearer-13
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
granted resources (without demonstrating possession of a granted resources (without demonstrating possession of a
cryptographic key). To prevent misuse, the bearer token needs to be cryptographic key). To prevent misuse, the bearer token needs 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 April 29, 2012. This Internet-Draft will expire on May 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 7, line 23 skipping to change at page 7, line 23
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 [I-D.ietf-httpbis-p7-auth] as field uses the framework defined by [I-D.ietf-httpbis-p7-auth] as
follows: follows:
challenge = "Bearer" [ 1*SP 1#param ] challenge = "Bearer" [ 1*SP 1#param ]
param = realm / scope /
error / error-desc / error-uri /
auth-param
scope = "scope" "=" DQUOTE scope-val *( SP scope-val ) DQUOTE param = realm / scope /
scope-val = 1*scope-val-char error / error-desc / error-uri /
scope-val-char = %x21 / %x23-5B / %x5D-7E auth-param
; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII
error = "error" "=" quoted-string scope = "scope" "=" quoted-string
error-desc = "error_description" "=" DQUOTE *error-desc-char DQUOTE error = "error" "=" quoted-string
error-desc-char = SP / VCHAR error-desc = "error_description" "=" quoted-string
error-uri = "error_uri" "=" DQUOTE URI-reference DQUOTE error-uri = "error_uri" "=" quoted-string
The "scope" attribute is a space-delimited list of scope values The "scope" attribute is a space-delimited list of scope values
indicating the required scope of the access token for accessing the indicating the required scope of the access token for accessing the
requested resource. The "scope" attribute MUST NOT appear more than requested resource. The "scope" attribute MUST NOT appear more than
once. The "scope" value is intended for programmatic use and is not once. The "scope" value is intended for programmatic use and is not
meant to be displayed to end users. (Note that receivers are free to meant to be displayed to end users.
parse the "scope" attribute using a standard quoted-string parser,
since it will correctly process all legal "scope" values. No
character quoting will occur in practice, as senders are prohibited
from using the '\' character.)
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
"error", "error_description", and "error_uri" attribute MUST NOT "error", "error_description", and "error_uri" attribute MUST NOT
appear more than once. appear more than once.
Producers of "scope" strings MUST NOT use characters outside the set
%x21 / %x23-5B / %x5D-7E for representing the scope values and %x20
for the delimiter. Producers of "error" and "error_description"
strings MUST NOT use characters outside the set %x20-21 / %x23-5B /
%x5D-7E for representing these values. Producers of "error-uri"
strings MUST NOT use characters outside the set %x21 / %x23-5B /
%x5D-7E for representing these values. Furthermore, "error-uri"
strings MUST conform to the URI-reference syntax. In all these
cases, no character quoting will occur, as senders are prohibited
from using the %5C ('\') character.
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
skipping to change at page 14, line 44 skipping to change at page 14, line 44
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 ]]
-13
o At the request of Hannes Tschofenig, made ABNF changes to make it
clear that no special WWW-Authenticate response header field
parsers are needed. The "scope", "error-description", and
"error-uri" parameters are all now defined as quoted-string in the
ABNF (as "error" already was). Restrictions on these values that
were formerly described in the ABNFs are now described in
normative text instead.
-12 -12
o Made non-normative editorial changes that Hannes Tschofenig o Made non-normative editorial changes that Hannes Tschofenig
requested be applied prior to forwarding the specification to the requested be applied prior to forwarding the specification to the
IESG. IESG.
o Added rationale for the choice of the b64token syntax. o Added rationale for the choice of the b64token syntax.
o Added rationale stating that receivers are free to parse the o Added rationale stating that receivers are free to parse the
"scope" attribute using a standard quoted-string parser, since it "scope" attribute using a standard quoted-string parser, since it
 End of changes. 10 change blocks. 
22 lines changed or deleted 34 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/