draft-ietf-httpbis-p7-auth-12.txt   draft-ietf-httpbis-p7-auth-13.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Updates: 2617 (if approved) Alcatel-Lucent Updates: 2617 (if approved) Alcatel-Lucent
Intended status: Standards Track J. Mogul Intended status: Standards Track J. Mogul
Expires: April 28, 2011 HP Expires: September 15, 2011 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
October 25, 2010 March 14, 2011
HTTP/1.1, part 7: Authentication HTTP/1.1, part 7: Authentication
draft-ietf-httpbis-p7-auth-12 draft-ietf-httpbis-p7-auth-13
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 7 of the information initiative since 1990. This document is Part 7 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines
HTTP Authentication. HTTP Authentication.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix B.13. The changes in this draft are summarized in Appendix B.14.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 28, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 4
2. Access Authentication Framework . . . . . . . . . . . . . . . 5 2. Access Authentication Framework . . . . . . . . . . . . . . . 5
2.1. Authentication Scheme Registry . . . . . . . . . . . . . . 7 2.1. Authentication Scheme Registry . . . . . . . . . . . . . . 7
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 7 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 7
3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 8 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 7
4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8
4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 9 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 9
4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 9 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 9
4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 10 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. Authenticaton Scheme Registry . . . . . . . . . . . . . . 10 5.1. Authenticaton Scheme Registry . . . . . . . . . . . . . . 10
5.2. Status Code Registration . . . . . . . . . . . . . . . . . 10 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 10
5.3. Header Field Registration . . . . . . . . . . . . . . . . 10 5.3. Header Field Registration . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. Authentication Credentials and Idle Clients . . . . . . . 11 6.1. Authentication Credentials and Idle Clients . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 13 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 13
Appendix B. Change Log (to be removed by RFC Editor before Appendix B. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 14 publication) . . . . . . . . . . . . . . . . . . . . 13
B.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 14 B.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 13
B.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 14 B.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 14
B.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 14 B.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 14
B.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 14 B.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 14
B.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 14 B.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 14
B.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 14 B.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 14
B.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 15 B.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 14
B.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 15 B.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 15
B.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 15 B.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 15
B.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 15 B.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 15
B.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 15 B.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 15
B.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 15 B.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 15
B.13. Since draft-ietf-httpbis-p7-auth-11 . . . . . . . . . . . 15 B.13. Since draft-ietf-httpbis-p7-auth-11 . . . . . . . . . . . 15
B.14. Since draft-ietf-httpbis-p7-auth-12 . . . . . . . . . . . 16
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document defines HTTP/1.1 access control and authentication. It This document defines HTTP/1.1 access control and authentication. It
includes the relevant parts of RFC 2616 with only minor changes, plus includes the relevant parts of RFC 2616 with only minor changes, plus
the general framework for HTTP authentication, as previously defined the general framework for HTTP authentication, as previously defined
in "HTTP Authentication: Basic and Digest Access Authentication" in "HTTP Authentication: Basic and Digest Access Authentication"
([RFC2617]). ([RFC2617]).
skipping to change at page 7, line 6 skipping to change at page 7, line 6
resource. If a proxy does not accept the credentials sent with a resource. If a proxy does not accept the credentials sent with a
request, it SHOULD return a 407 (Proxy Authentication Required). The request, it SHOULD return a 407 (Proxy Authentication Required). The
response MUST include a Proxy-Authenticate header field containing a response MUST include a Proxy-Authenticate header field containing a
(possibly new) challenge applicable to the proxy for the requested (possibly new) challenge applicable to the proxy for the requested
resource. resource.
The HTTP protocol does not restrict applications to this simple The HTTP protocol does not restrict applications to this simple
challenge-response mechanism for access authentication. Additional challenge-response mechanism for access authentication. Additional
mechanisms MAY be used, such as encryption at the transport level or mechanisms MAY be used, such as encryption at the transport level or
via message encapsulation, and with additional header fields via message encapsulation, and with additional header fields
specifying authentication information. However, these additional specifying authentication information. However, such additional
mechanisms are not defined by this specification. mechanisms are not defined by this specification.
Proxies MUST be completely transparent regarding user agent Proxies MUST forward the WWW-Authenticate and Authorization headers
authentication by origin servers. That is, they MUST forward the unmodified and follow the rules found in Section 4.1.
WWW-Authenticate and Authorization headers untouched, and follow the
rules found in Section 4.1. Both the Proxy-Authenticate and the
Proxy-Authorization header fields are hop-by-hop headers (see Section
7.1.3.1 of [Part1]).
2.1. Authentication Scheme Registry 2.1. Authentication Scheme Registry
The HTTP Authentication Scheme Registry defines the name space for The HTTP Authentication Scheme Registry defines the name space for
the authentication schemes in challenges and credentials. the authentication schemes in challenges and credentials.
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Authentication Scheme Name o Authentication Scheme Name
skipping to change at page 8, line 21 skipping to change at page 8, line 13
resource. The client MAY repeat the request with a suitable Proxy- resource. The client MAY repeat the request with a suitable Proxy-
Authorization header field (Section 4.3). Authorization header field (Section 4.3).
4. Header Field Definitions 4. Header Field Definitions
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to authentication. fields related to authentication.
4.1. Authorization 4.1. Authorization
The "Authorization" request-header field allows a user agent to The "Authorization" header field allows a user agent to authenticate
authenticate itself with a server -- usually, but not necessarily, itself with a server -- usually, but not necessarily, after receiving
after receiving a 401 (Unauthorized) response. Its value consists of a 401 (Unauthorized) response. Its value consists of credentials
credentials containing information of the user agent for the realm of containing information of the user agent for the realm of the
the resource being requested. resource being requested.
Authorization = "Authorization" ":" OWS Authorization-v Authorization = "Authorization" ":" OWS Authorization-v
Authorization-v = credentials Authorization-v = credentials
If a request is authenticated and a realm specified, the same If a request is authenticated and a realm specified, the same
credentials SHOULD be valid for all other requests within this realm credentials SHOULD be valid for all other requests within this realm
(assuming that the authentication scheme itself does not require (assuming that the authentication scheme itself does not require
otherwise, such as credentials that vary according to a challenge otherwise, such as credentials that vary according to a challenge
value or using synchronized clocks). value or using synchronized clocks).
When a shared cache (see Section 1.2 of [Part6]) receives a request When a shared cache (see Section 1.2 of [Part6]) receives a request
containing an Authorization field, it MUST NOT return the containing an Authorization field, it MUST NOT return the
corresponding response as a reply to any other request, unless one of corresponding response as a reply to any other request, unless one of
the following specific exceptions holds: the following specific exceptions holds:
1. If the response includes the "s-maxage" cache-control directive, 1. If the response includes the "s-maxage" cache-control directive,
the cache MAY use that response in replying to a subsequent the cache MAY use that response in replying to a subsequent
request. But (if the specified maximum age has passed) a proxy request. But (if the specified maximum age has passed) a proxy
cache MUST first revalidate it with the origin server, using the cache MUST first revalidate it with the origin server, using the
request-header fields from the new request to allow the origin header fields from the new request to allow the origin server to
server to authenticate the new request. (This is the defined authenticate the new request. (This is the defined behavior for
behavior for s-maxage.) If the response includes "s-maxage=0", s-maxage.) If the response includes "s-maxage=0", the proxy MUST
the proxy MUST always revalidate it before re-using it. always revalidate it before re-using it.
2. If the response includes the "must-revalidate" cache-control 2. If the response includes the "must-revalidate" cache-control
directive, the cache MAY use that response in replying to a directive, the cache MAY use that response in replying to a
subsequent request. But if the response is stale, all caches subsequent request. But if the response is stale, all caches
MUST first revalidate it with the origin server, using the MUST first revalidate it with the origin server, using the header
request-header fields from the new request to allow the origin fields from the new request to allow the origin server to
server to authenticate the new request. authenticate the new request.
3. If the response includes the "public" cache-control directive, it 3. If the response includes the "public" cache-control directive, it
MAY be returned in reply to any subsequent request. MAY be returned in reply to any subsequent request.
4.2. Proxy-Authenticate 4.2. Proxy-Authenticate
The "Proxy-Authenticate" response-header field consists of a The "Proxy-Authenticate" header field consists of a challenge that
challenge that indicates the authentication scheme and parameters indicates the authentication scheme and parameters applicable to the
applicable to the proxy for this effective request URI (Section 4.3 proxy for this effective request URI (Section 4.3 of [Part1]). It
of [Part1]). It MUST be included as part of a 407 (Proxy MUST be included as part of a 407 (Proxy Authentication Required)
Authentication Required) response. response.
Proxy-Authenticate = "Proxy-Authenticate" ":" OWS Proxy-Authenticate = "Proxy-Authenticate" ":" OWS
Proxy-Authenticate-v Proxy-Authenticate-v
Proxy-Authenticate-v = 1#challenge Proxy-Authenticate-v = 1#challenge
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
only to the current connection and SHOULD NOT be passed on to only to the current connection and SHOULD NOT be passed on to
downstream clients. However, an intermediate proxy might need to downstream clients. However, an intermediate proxy might need to
obtain its own credentials by requesting them from the downstream obtain its own credentials by requesting them from the downstream
client, which in some circumstances will appear as if the proxy is client, which in some circumstances will appear as if the proxy is
forwarding the Proxy-Authenticate header field. forwarding the Proxy-Authenticate header field.
4.3. Proxy-Authorization 4.3. Proxy-Authorization
The "Proxy-Authorization" request-header field allows the client to The "Proxy-Authorization" header field allows the client to identify
identify itself (or its user) to a proxy which requires itself (or its user) to a proxy which requires authentication. Its
authentication. Its value consists of credentials containing the value consists of credentials containing the authentication
authentication information of the user agent for the proxy and/or information of the user agent for the proxy and/or realm of the
realm of the resource being requested. resource being requested.
Proxy-Authorization = "Proxy-Authorization" ":" OWS Proxy-Authorization = "Proxy-Authorization" ":" OWS
Proxy-Authorization-v Proxy-Authorization-v
Proxy-Authorization-v = credentials Proxy-Authorization-v = credentials
Unlike Authorization, the Proxy-Authorization header field applies Unlike Authorization, the Proxy-Authorization header field applies
only to the next outbound proxy that demanded authentication using only to the next outbound proxy that demanded authentication using
the Proxy-Authenticate field. When multiple proxies are used in a the Proxy-Authenticate field. When multiple proxies are used in a
chain, the Proxy-Authorization header field is consumed by the first chain, the Proxy-Authorization header field is consumed by the first
outbound proxy that was expecting to receive credentials. A proxy outbound proxy that was expecting to receive credentials. A proxy
MAY relay the credentials from the client request to the next proxy MAY relay the credentials from the client request to the next proxy
if that is the mechanism by which the proxies cooperatively if that is the mechanism by which the proxies cooperatively
authenticate a given request. authenticate a given request.
4.4. WWW-Authenticate 4.4. WWW-Authenticate
The "WWW-Authenticate" response-header field consists of at least one The "WWW-Authenticate" header field consists of at least one
challenge that indicates the authentication scheme(s) and parameters challenge that indicates the authentication scheme(s) and parameters
applicable to the effective request URI (Section 4.3 of [Part1]). It applicable to the effective request URI (Section 4.3 of [Part1]). It
MUST be included in 401 (Unauthorized) response messages. MUST be included in 401 (Unauthorized) response messages.
WWW-Authenticate = "WWW-Authenticate" ":" OWS WWW-Authenticate-v WWW-Authenticate = "WWW-Authenticate" ":" OWS WWW-Authenticate-v
WWW-Authenticate-v = 1#challenge WWW-Authenticate-v = 1#challenge
User agents are advised to take special care in parsing the WWW- User agents are advised to take special care in parsing the WWW-
Authenticate field value as it might contain more than one challenge, Authenticate field value as it might contain more than one challenge,
or if more than one WWW-Authenticate header field is provided, the or if more than one WWW-Authenticate header field is provided, the
skipping to change at page 12, line 16 skipping to change at page 12, line 4
This specification takes over the definition of the HTTP This specification takes over the definition of the HTTP
Authentication Framework, previously defined in RFC 2617. We thank Authentication Framework, previously defined in RFC 2617. We thank
to John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott to John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott
D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for
their work on that specification. their work on that specification.
[[acks: HTTPbis acknowledgements.]] [[acks: HTTPbis acknowledgements.]]
8. References 8. References
8.1. Normative References 8.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-12 and Message Parsing", draft-ietf-httpbis-p1-messaging-13
(work in progress), October 2010. (work in progress), March 2011.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
6: Caching", draft-ietf-httpbis-p6-cache-12 (work in 6: Caching", draft-ietf-httpbis-p6-cache-13 (work in
progress), October 2010. progress), March 2011.
[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.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
8.2. Informative References 8.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
skipping to change at page 15, line 49 skipping to change at page 15, line 41
B.13. Since draft-ietf-httpbis-p7-auth-11 B.13. Since draft-ietf-httpbis-p7-auth-11
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/130>: "introduction o <http://tools.ietf.org/wg/httpbis/trac/ticket/130>: "introduction
to part 7 is work-in-progress" to part 7 is work-in-progress"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/195>: "auth-param o <http://tools.ietf.org/wg/httpbis/trac/ticket/195>: "auth-param
syntax" syntax"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
Classification"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/237>: "absorbing the o <http://tools.ietf.org/wg/httpbis/trac/ticket/237>: "absorbing the
auth framework from 2617" auth framework from 2617"
Partly resolved issues: Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/141>: "should we o <http://tools.ietf.org/wg/httpbis/trac/ticket/141>: "should we
have an auth scheme registry" have an auth scheme registry"
B.14. Since draft-ietf-httpbis-p7-auth-12
None.
Index Index
4 4
401 Unauthorized (status code) 7 401 Unauthorized (status code) 7
407 Proxy Authentication Required (status code) 8 407 Proxy Authentication Required (status code) 7
A A
auth-param 5 auth-param 5
auth-scheme 5 auth-scheme 5
Authorization header 8 Authorization header field 8
C C
challenge 5 challenge 5
credentials 6 credentials 6
G G
Grammar Grammar
Authorization 8 Authorization 8
Authorization-v 8 Authorization-v 8
Proxy-Authenticate 9 Proxy-Authenticate 9
Proxy-Authenticate-v 9 Proxy-Authenticate-v 9
Proxy-Authorization 9 Proxy-Authorization 9
Proxy-Authorization-v 9 Proxy-Authorization-v 9
WWW-Authenticate 10 WWW-Authenticate 9
WWW-Authenticate-v 10 WWW-Authenticate-v 9
H H
Headers Header Fields
Authorization 8 Authorization 8
Proxy-Authenticate 9 Proxy-Authenticate 9
Proxy-Authorization 9 Proxy-Authorization 9
WWW-Authenticate 10 WWW-Authenticate 9
P P
Proxy-Authenticate header 9 Proxy-Authenticate header field 9
Proxy-Authorization header 9 Proxy-Authorization header field 9
R R
realm 5 realm 5
realm-value 5 realm-value 5
S S
Status Codes Status Codes
401 Unauthorized 7 401 Unauthorized 7
407 Proxy Authentication Required 8 407 Proxy Authentication Required 7
W W
WWW-Authenticate header 10 WWW-Authenticate header field 9
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Adobe Systems Incorporated
23 Corporate Plaza DR, Suite 280 345 Park Ave
Newport Beach, CA 92660 San Jose, CA 95110
USA USA
Phone: +1-949-706-5300
Fax: +1-949-706-5305
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Jim Gettys Jim Gettys
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
21 Oak Knoll Road 21 Oak Knoll Road
Carlisle, MA 01741 Carlisle, MA 01741
USA USA
EMail: jg@freedesktop.org EMail: jg@freedesktop.org
skipping to change at page 18, line 5 skipping to change at page 18, line 5
EMail: JeffMogul@acm.org EMail: JeffMogul@acm.org
Henrik Frystyk Nielsen Henrik Frystyk Nielsen
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
EMail: henrikn@microsoft.com EMail: henrikn@microsoft.com
Larry Masinter Larry Masinter
Adobe Systems, Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: LMM@acm.org EMail: LMM@acm.org
URI: http://larry.masinter.net/ URI: http://larry.masinter.net/
Paul J. Leach Paul J. Leach
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
 End of changes. 38 change blocks. 
65 lines changed or deleted 66 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/