draft-ietf-httpbis-p7-auth-17.txt   draft-ietf-httpbis-p7-auth-18.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe 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: May 3, 2012 HP Expires: July 7, 2012 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe 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 31, 2011 January 4, 2012
HTTP/1.1, part 7: Authentication HTTP/1.1, part 7: Authentication
draft-ietf-httpbis-p7-auth-17 draft-ietf-httpbis-p7-auth-18
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. "HTTP/1.1" and, taken together, obsoletes RFC 2616.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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), which is archived at group mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <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 C.18. The changes in this draft are summarized in Appendix C.19.
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 May 3, 2012. This Internet-Draft will expire on July 7, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
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 2, line 51 skipping to change at page 2, line 51
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 5
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
2. Access Authentication Framework . . . . . . . . . . . . . . . 5 2. Access Authentication Framework . . . . . . . . . . . . . . . 6
2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 5 2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 6
2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 7 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 8
2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7 2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 8
2.3.1. Considerations for New Authentication Schemes . . . . 8 2.3.1. Considerations for New Authentication Schemes . . . . 9
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 10
3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 10
3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 10
4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 10
4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 11
4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 11 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 12
4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 11 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.1. Authenticaton Scheme Registry . . . . . . . . . . . . . . 12 5.1. Authenticaton Scheme Registry . . . . . . . . . . . . . . 13
5.2. Status Code Registration . . . . . . . . . . . . . . . . . 12 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 13
5.3. Header Field Registration . . . . . . . . . . . . . . . . 12 5.3. Header Field Registration . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. Authentication Credentials and Idle Clients . . . . . . . 13 6.1. Authentication Credentials and Idle Clients . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 14 Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 16
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 15 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 16
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 16 publication) . . . . . . . . . . . . . . . . . . . . 17
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 16 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 17
C.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 16 C.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 17
C.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 16 C.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 17
C.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 16 C.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 17
C.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 16 C.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 17
C.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 16 C.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 17
C.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 17 C.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 18
C.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 17 C.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 18
C.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 17 C.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 18
C.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 17 C.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 18
C.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 17 C.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 18
C.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 17 C.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 18
C.13. Since draft-ietf-httpbis-p7-auth-11 . . . . . . . . . . . 17 C.13. Since draft-ietf-httpbis-p7-auth-11 . . . . . . . . . . . 18
C.14. Since draft-ietf-httpbis-p7-auth-12 . . . . . . . . . . . 18 C.14. Since draft-ietf-httpbis-p7-auth-12 . . . . . . . . . . . 19
C.15. Since draft-ietf-httpbis-p7-auth-13 . . . . . . . . . . . 18 C.15. Since draft-ietf-httpbis-p7-auth-13 . . . . . . . . . . . 19
C.16. Since draft-ietf-httpbis-p7-auth-14 . . . . . . . . . . . 18 C.16. Since draft-ietf-httpbis-p7-auth-14 . . . . . . . . . . . 19
C.17. Since draft-ietf-httpbis-p7-auth-15 . . . . . . . . . . . 18 C.17. Since draft-ietf-httpbis-p7-auth-15 . . . . . . . . . . . 19
C.18. Since draft-ietf-httpbis-p7-auth-16 . . . . . . . . . . . 19 C.18. Since draft-ietf-httpbis-p7-auth-16 . . . . . . . . . . . 20
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 C.19. Since draft-ietf-httpbis-p7-auth-17 . . . . . . . . . . . 20
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
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]).
HTTP provides several OPTIONAL challenge-response authentication HTTP provides several OPTIONAL challenge-response authentication
skipping to change at page 5, line 33 skipping to change at page 6, line 33
2. Access Authentication Framework 2. Access Authentication Framework
2.1. Challenge and Response 2.1. Challenge and Response
HTTP provides a simple challenge-response authentication mechanism HTTP provides a simple challenge-response authentication mechanism
that can be used by a server to challenge a client request and by a that can be used by a server to challenge a client request and by a
client to provide authentication information. It uses an extensible, client to provide authentication information. It uses an extensible,
case-insensitive token to identify the authentication scheme, case-insensitive token to identify the authentication scheme,
followed by additional information necessary for achieving followed by additional information necessary for achieving
authentication via that scheme. The latter can either be a comma- authentication via that scheme. The latter can either be a comma-
separated list of attribute-value pairs or a single sequence of separated list of parameters or a single sequence of characters
characters capable of holding base64-encoded information. capable of holding base64-encoded information.
Parameters are name-value pairs where the name is matched case-
insensitively, and each parameter name MUST only occur once per
challenge.
auth-scheme = token auth-scheme = token
auth-param = token BWS "=" BWS ( token / quoted-string ) auth-param = token BWS "=" BWS ( token / quoted-string )
b64token = 1*( ALPHA / DIGIT / b64token = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"=" "-" / "." / "_" / "~" / "+" / "/" ) *"="
The "b64token" syntax allows the 66 unreserved URI characters The "b64token" syntax allows the 66 unreserved URI characters
([RFC3986]), plus a few others, so that it can hold a base64, ([RFC3986]), plus a few others, so that it can hold a base64,
skipping to change at page 7, line 19 skipping to change at page 8, line 23
via message encapsulation, and with additional header fields via message encapsulation, and with additional header fields
specifying authentication information. However, such additional specifying authentication information. However, such additional
mechanisms are not defined by this specification. mechanisms are not defined by this specification.
Proxies MUST forward the WWW-Authenticate and Authorization headers Proxies MUST forward the WWW-Authenticate and Authorization headers
unmodified and follow the rules found in Section 4.1. unmodified and follow the rules found in Section 4.1.
2.2. Protection Space (Realm) 2.2. Protection Space (Realm)
The authentication parameter realm is reserved for use by The authentication parameter realm is reserved for use by
authentication schemes that wish to indicate the scope of protection: authentication schemes that wish to indicate the scope of protection.
realm = "realm" BWS "=" BWS realm-value
realm-value = quoted-string
A protection space is defined by the canonical root URI (the scheme A protection space is defined by the canonical root URI (the scheme
and authority components of the effective request URI; see Section and authority components of the effective request URI; see Section
4.3 of [Part1]) of the server being accessed, in combination with the 4.3 of [Part1]) of the server being accessed, in combination with the
realm value if present. These realms allow the protected resources realm value if present. These realms allow the protected resources
on a server to be partitioned into a set of protection spaces, each on a server to be partitioned into a set of protection spaces, each
with its own authentication scheme and/or authorization database. with its own authentication scheme and/or authorization database.
The realm value is a string, generally assigned by the origin server, The realm value is a string, generally assigned by the origin server,
which can have additional semantics specific to the authentication which can have additional semantics specific to the authentication
scheme. Note that there can be multiple challenges with the same scheme. Note that there can be multiple challenges with the same
auth-scheme but different realms. auth-scheme but different realms.
The protection space determines the domain over which credentials can The protection space determines the domain over which credentials can
be automatically applied. If a prior request has been authorized, be automatically applied. If a prior request has been authorized,
the same credentials MAY be reused for all other requests within that the same credentials MAY be reused for all other requests within that
protection space for a period of time determined by the protection space for a period of time determined by the
authentication scheme, parameters, and/or user preference. Unless authentication scheme, parameters, and/or user preference. Unless
otherwise defined by the authentication scheme, a single protection otherwise defined by the authentication scheme, a single protection
space cannot extend outside the scope of its server. space cannot extend outside the scope of its server.
For historical reasons, senders MUST only use the quoted-string
syntax. Recipients might have to support both token and quoted-
string syntax for maximum interoperability with existing clients that
have been accepting both notations for a long time.
2.3. Authentication Scheme Registry 2.3. 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
o Pointer to specification text o Pointer to specification text
o Notes (optional) o Notes (optional)
Values to be added to this name space are subject to IETF review Values to be added to this name space are subject to IETF review
([RFC5226], Section 4.1). ([RFC5226], Section 4.1).
The registry itself is maintained at The registry itself is maintained at
<http://www.iana.org/assignments/http-authschemes>. <http://www.iana.org/assignments/http-authschemes>.
skipping to change at page 13, line 50 skipping to change at page 15, line 12
See Section 11 of [Part1] for the Acknowledgments related to this See Section 11 of [Part1] for the Acknowledgments related to this
document revision. document revision.
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-17 and Message Parsing", draft-ietf-httpbis-p1-messaging-18
(work in progress), October 2011. (work in progress), January 2012.
[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-17 (work in 6: Caching", draft-ietf-httpbis-p6-cache-18 (work in
progress), October 2011. progress), January 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.
[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 35 skipping to change at page 16, line 46
b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
*"=" *"="
challenge = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) *( challenge = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) *(
OWS "," [ OWS auth-param ] ) ] ) ] OWS "," [ OWS auth-param ] ) ] ) ]
credentials = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) credentials = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param )
*( OWS "," [ OWS auth-param ] ) ] ) ] *( OWS "," [ OWS auth-param ] ) ] ) ]
quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
realm = "realm" BWS "=" BWS realm-value
realm-value = quoted-string
token = <token, defined in [Part1], Section 3.2.3> token = <token, defined in [Part1], Section 3.2.3>
ABNF diagnostics: ABNF diagnostics:
; Authorization defined but not used ; Authorization defined but not used
; Proxy-Authenticate defined but not used ; Proxy-Authenticate defined but not used
; Proxy-Authorization defined but not used ; Proxy-Authorization defined but not used
; WWW-Authenticate defined but not used ; WWW-Authenticate defined but not used
; realm defined but not used
Appendix C. Change Log (to be removed by RFC Editor before publication) Appendix C. Change Log (to be removed by RFC Editor before publication)
C.1. Since RFC 2616 C.1. Since RFC 2616
Extracted relevant partitions from [RFC2616]. Extracted relevant partitions from [RFC2616].
C.2. Since draft-ietf-httpbis-p7-auth-00 C.2. Since draft-ietf-httpbis-p7-auth-00
Closed issues: Closed issues:
skipping to change at page 19, line 15 skipping to change at page 20, line 18
C.18. Since draft-ietf-httpbis-p7-auth-16 C.18. Since draft-ietf-httpbis-p7-auth-16
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
HTTP's error-handling philosophy" HTTP's error-handling philosophy"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/320>: "add advice on o <http://tools.ietf.org/wg/httpbis/trac/ticket/320>: "add advice on
defining auth scheme parameters" defining auth scheme parameters"
C.19. Since draft-ietf-httpbis-p7-auth-17
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/314>: "allow
unquoted realm parameters"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/321>: "Repeating
auth-params"
Index Index
4 4
401 Unauthorized (status code) 9 401 Unauthorized (status code) 10
407 Proxy Authentication Required (status code) 9 407 Proxy Authentication Required (status code) 10
A A
auth-param 5 auth-param 6
auth-scheme 5 auth-scheme 6
Authorization header field 9 Authorization header field 11
B B
b64token 5 b64token 6
C C
challenge 6 challenge 7
credentials 6 credentials 7
G G
Grammar Grammar
auth-param 5 auth-param 6
auth-scheme 5 auth-scheme 6
Authorization 10 Authorization 11
b64token 5 b64token 6
challenge 6 challenge 7
credentials 6 credentials 7
Proxy-Authenticate 10 Proxy-Authenticate 11
Proxy-Authorization 11 Proxy-Authorization 12
realm 7 WWW-Authenticate 12
WWW-Authenticate 11
H H
Header Fields Header Fields
Authorization 9 Authorization 11
Proxy-Authenticate 10 Proxy-Authenticate 11
Proxy-Authorization 11 Proxy-Authorization 12
WWW-Authenticate 11 WWW-Authenticate 12
P P
Protection Space 7 Protection Space 8
Proxy-Authenticate header field 10 Proxy-Authenticate header field 11
Proxy-Authorization header field 11 Proxy-Authorization header field 12
R R
Realm 7 Realm 8
realm 7
realm-value 7
S S
Status Codes Status Codes
401 Unauthorized 9 401 Unauthorized 10
407 Proxy Authentication Required 9 407 Proxy Authentication Required 10
W W
WWW-Authenticate header field 11 WWW-Authenticate header field 12
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
 End of changes. 28 change blocks. 
101 lines changed or deleted 112 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/