draft-ietf-httpbis-p7-auth-24.txt   draft-ietf-httpbis-p7-auth-25.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Reschke, Ed. Obsoletes: 2616 (if approved) J. Reschke, Ed.
Updates: 2617 (if approved) greenbytes Updates: 2617 (if approved) greenbytes
Intended status: Standards Track September 25, 2013 Intended status: Standards Track November 17, 2013
Expires: March 29, 2014 Expires: May 21, 2014
Hypertext Transfer Protocol (HTTP/1.1): Authentication Hypertext Transfer Protocol (HTTP/1.1): Authentication
draft-ietf-httpbis-p7-auth-24 draft-ietf-httpbis-p7-auth-25
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. This document defines the HTTP Authentication framework. systems. This document defines the HTTP Authentication framework.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at 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 D.5. The changes in this draft are summarized in Appendix D.1.
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 March 29, 2014. This Internet-Draft will expire on May 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
2. Access Authentication Framework . . . . . . . . . . . . . . . 4 2. Access Authentication Framework . . . . . . . . . . . . . . . 4
2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 4 2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 4
2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . 7 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 7
4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7
4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 8 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 8
4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 8 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 8
4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 9 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 10 5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 10
5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 10 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 10
5.1.2. Considerations for New Authentication Schemes . . . . 10 5.1.2. Considerations for New Authentication Schemes . . . . 10
5.2. Status Code Registration . . . . . . . . . . . . . . . . . 11 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 11
5.3. Header Field Registration . . . . . . . . . . . . . . . . 12 5.3. Header Field Registration . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 3, line 39 skipping to change at page 3, line 39
6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 13 6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15 Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 15 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 15
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 16 publication) . . . . . . . . . . . . . . . . . . . . 16
D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16 D.1. Since draft-ietf-httpbis-p7-auth-24 . . . . . . . . . . . 16
D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
D.3. Since draft-ietf-httpbis-p7-auth-21 . . . . . . . . . . . 17
D.4. Since draft-ietf-httpbis-p7-auth-22 . . . . . . . . . . . 17
D.5. Since draft-ietf-httpbis-p7-auth-23 . . . . . . . . . . . 17
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
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 includes the relevant parts of RFC 2616 with only minor changes
([RFC2616]), plus the general framework for HTTP authentication, as ([RFC2616]), plus the general framework for HTTP authentication, as
previously defined in "HTTP Authentication: Basic and Digest Access previously defined in "HTTP Authentication: Basic and Digest Access
Authentication" ([RFC2617]). Authentication" ([RFC2617]).
HTTP provides several OPTIONAL challenge-response authentication HTTP provides several OPTIONAL challenge-response authentication
skipping to change at page 5, line 30 skipping to change at page 5, line 30
include a WWW-Authenticate header field containing at least one include a WWW-Authenticate header field containing at least one
challenge applicable to the requested resource. challenge applicable to the requested resource.
The 407 (Proxy Authentication Required) response message is used by a The 407 (Proxy Authentication Required) response message is used by a
proxy to challenge the authorization of a client and MUST include a proxy to challenge the authorization of a client and MUST include a
Proxy-Authenticate header field containing at least one challenge Proxy-Authenticate header field containing at least one challenge
applicable to the proxy for the requested resource. applicable to the proxy for the requested resource.
challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ] challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Note: User agents will need to take special care in parsing the
WWW-Authenticate and Proxy-Authenticate header field values
because they can contain more than one challenge, or if more than
one of each is provided, since the contents of a challenge can
itself contain a comma-separated list of authentication
parameters.
Note: Many clients fail to parse challenges containing unknown Note: Many clients fail to parse challenges containing unknown
schemes. A workaround for this problem is to list well-supported schemes. A workaround for this problem is to list well-supported
schemes (such as "basic") first. schemes (such as "basic") first.
A user agent that wishes to authenticate itself with an origin server A user agent that wishes to authenticate itself with an origin server
-- usually, but not necessarily, after receiving a 401 (Unauthorized) -- usually, but not necessarily, after receiving a 401 (Unauthorized)
-- can do so by including an Authorization header field with the -- can do so by including an Authorization header field with the
request. request.
A client that wishes to authenticate itself with a proxy -- usually, A client that wishes to authenticate itself with a proxy -- usually,
skipping to change at page 6, line 12 skipping to change at page 6, line 5
Both the Authorization field value and the Proxy-Authorization field Both the Authorization field value and the Proxy-Authorization field
value contain the client's credentials for the realm of the resource value contain the client's credentials for the realm of the resource
being requested, based upon a challenge received in a response being requested, based upon a challenge received in a response
(possibly at some point in the past). When creating their values, (possibly at some point in the past). When creating their values,
the user agent ought to do so by selecting the challenge with what it the user agent ought to do so by selecting the challenge with what it
considers to be the most secure auth-scheme that it understands, considers to be the most secure auth-scheme that it understands,
obtaining credentials from the user as appropriate. obtaining credentials from the user as appropriate.
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Upon a request for a protected resource that omits credentials, Upon receipt of a request for a protected resource that omits
contains invalid credentials (e.g., a bad password) or partial credentials, contains invalid credentials (e.g., a bad password) or
credentials (e.g., when the authentication scheme requires more than partial credentials (e.g., when the authentication scheme requires
one round trip), an origin server SHOULD send a 401 (Unauthorized) more than one round trip), an origin server SHOULD send a 401
response that contains a WWW-Authenticate header field with at least (Unauthorized) response that contains a WWW-Authenticate header field
one (possibly new) challenge applicable to the requested resource. with at least one (possibly new) challenge applicable to the
requested resource.
Likewise, upon a request that requires authentication by proxies that Likewise, upon receipt of a request that requires authentication by
omit credentials or contain invalid or partial credentials, a proxy proxies that omit credentials or contain invalid or partial
SHOULD send a 407 (Proxy Authentication Required) response that credentials, a proxy SHOULD send a 407 (Proxy Authentication
contains a Proxy-Authenticate header field with a (possibly new) Required) response that contains a Proxy-Authenticate header field
challenge applicable to the proxy. with a (possibly new) challenge applicable to the proxy.
A server receiving credentials that are valid, but not adequate to A server receiving credentials that are valid, but not adequate to
gain access, ought to respond with the 403 (Forbidden) status code gain access, ought to respond with the 403 (Forbidden) status code
(Section 6.5.3 of [Part2]). (Section 6.5.3 of [Part2]).
The HTTP protocol does not restrict applications to this simple HTTP does not restrict applications to this simple challenge-response
challenge-response framework for access authentication. Additional framework for access authentication. Additional mechanisms can be
mechanisms MAY be used, such as encryption at the transport level or used, such as authentication at the transport level or via message
via message encapsulation, and with additional header fields encapsulation, and with additional header fields specifying
specifying authentication information. However, such additional authentication information. However, such additional mechanisms are
mechanisms are not defined by this specification. not defined by this specification.
A proxy MUST forward the WWW-Authenticate and Authorization header A proxy MUST forward the WWW-Authenticate and Authorization header
fields unmodified and follow the rules found in Section 4.1. fields 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.
A protection space is defined by the canonical root URI (the scheme A protection space is defined by the canonical root URI (the scheme
skipping to change at page 7, line 11 skipping to change at page 7, line 4
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 a response can have multiple challenges with the scheme. Note that a response can have multiple challenges with the
same auth-scheme but different realms. same 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 user agent MAY reuse the same credentials for all other requests the user agent MAY reuse the same credentials for all other requests
within that protection space for a period of time determined by the within that protection space for a period of time determined by the
authentication scheme, parameters, and/or user preference. Unless authentication scheme, parameters, and/or user preferences (such as a
specifically allowed by the authentication scheme, a single configurable inactivity timeout). Unless specifically allowed by the
protection space cannot extend outside the scope of its server. authentication scheme, a single protection space cannot extend
outside the scope of its server.
For historical reasons, a sender MUST only generate the quoted-string For historical reasons, a sender MUST only generate the quoted-string
syntax. Recipients might have to support both token and quoted- syntax. Recipients might have to support both token and quoted-
string syntax for maximum interoperability with existing clients that string syntax for maximum interoperability with existing clients that
have been accepting both notations for a long time. have been accepting both notations for a long time.
3. Status Code Definitions 3. Status Code Definitions
3.1. 401 Unauthorized 3.1. 401 Unauthorized
skipping to change at page 9, line 31 skipping to change at page 9, line 26
The "WWW-Authenticate" 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 5.5 of [Part1]). applicable to the effective request URI (Section 5.5 of [Part1]).
It MUST be included in 401 (Unauthorized) response messages and MAY It MUST be included in 401 (Unauthorized) response messages and MAY
be included in other response messages to indicate that supplying be included in other response messages to indicate that supplying
credentials (or different credentials) might affect the response. credentials (or different credentials) might affect the response.
WWW-Authenticate = 1#challenge WWW-Authenticate = 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 field
Authenticate field value as it might contain more than one challenge, value, as it might contain more than one challenge, and each
or if more than one WWW-Authenticate header field is provided, the challenge can contain a comma-separated list of authentication
contents of a challenge itself can contain a comma-separated list of parameters. Furthermore, the header field itself can occur multiple
authentication parameters. times.
For instance: For instance:
WWW-Authenticate: Newauth realm="apps", type=1, WWW-Authenticate: Newauth realm="apps", type=1,
title="Login to \"apps\"", Basic realm="simple" title="Login to \"apps\"", Basic realm="simple"
This header field contains two challenges; one for the "Newauth" This header field contains two challenges; one for the "Newauth"
scheme with a realm value of "apps", and two additional parameters scheme with a realm value of "apps", and two additional parameters
"type" and "title", and another one for the "Basic" scheme with a "type" and "title", and another one for the "Basic" scheme with a
realm value of "simple". realm value of "simple".
Note: The challenge grammar production uses the list syntax as Note: The challenge grammar production uses the list syntax as
well. Therefore, a sequence of comma, whitespace, and comma can well. Therefore, a sequence of comma, whitespace, and comma can
be considered both as applying to the preceding challenge, or to be considered either as applying to the preceding challenge, or to
be an empty entry in the list of challenges. In practice, this be an empty entry in the list of challenges. In practice, this
ambiguity does not affect the semantics of the header field value ambiguity does not affect the semantics of the header field value
and thus is harmless. and thus is harmless.
5. IANA Considerations 5. IANA Considerations
5.1. Authentication Scheme Registry 5.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. It will be the authentication schemes in challenges and credentials. It will be
created and maintained at created and maintained at (the suggested URI)
<http://www.iana.org/assignments/http-authschemes>. <http://www.iana.org/assignments/http-authschemes>.
5.1.1. Procedure 5.1.1. Procedure
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
skipping to change at page 14, line 8 skipping to change at page 14, line 8
further acknowledgements. further acknowledgements.
See Section 10 of [Part1] for the Acknowledgments related to this See Section 10 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. and J. Reschke, Ed., "Hypertext Transfer [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-24 (work in progress), draft-ietf-httpbis-p1-messaging-25 (work in progress),
September 2013. November 2013.
[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-24 (work in progress), draft-ietf-httpbis-p2-semantics-25 (work in progress),
September 2013. November 2013.
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-24 (work in progress), draft-ietf-httpbis-p6-cache-25 (work in progress),
September 2013. November 2013.
[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
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
skipping to change at page 16, line 34 skipping to change at page 16, line 34
*( OWS "," [ OWS auth-param ] ) ] ) ] *( OWS "," [ OWS auth-param ] ) ] ) ]
quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>
token = <token, defined in [Part1], Section 3.2.6> token = <token, defined in [Part1], Section 3.2.6>
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
*"=" *"="
Appendix D. Change Log (to be removed by RFC Editor before publication) Appendix D. Change Log (to be removed by RFC Editor before publication)
Changes up to the first Working Group Last Call draft are summarized Changes up to the IETF Last Call draft are summarized in <http://
in <http://trac.tools.ietf.org/html/ trac.tools.ietf.org/html/draft-ietf-httpbis-p7-auth-24#appendix-D>.
draft-ietf-httpbis-p7-auth-19#appendix-C>.
D.1. Since draft-ietf-httpbis-p7-auth-19
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/348>: "Realms and
scope"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/349>: "Strength"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/357>:
"Authentication exchanges"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
requirements for recipients"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note
introduction of new IANA registries as normative changes"
D.2. Since draft-ietf-httpbis-p7-auth-20
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/376>: "rename
b64token for clarity"
Other changes:
o Conformance criteria and considerations regarding error handling
are now defined in Part 1.
D.3. Since draft-ietf-httpbis-p7-auth-21
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/403>:
"Authentication and caching - max-age"
D.4. Since draft-ietf-httpbis-p7-auth-22 D.1. Since draft-ietf-httpbis-p7-auth-24
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list o <http://tools.ietf.org/wg/httpbis/trac/ticket/510>: "SECDIR review
expansion in ABNF appendices" of draft-ietf-httpbis-p7-auth-24"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/439>: "terminology:
mechanism vs framework vs scheme"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/463>: "Editorial
suggestions"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of
extension point considerations"
D.5. Since draft-ietf-httpbis-p7-auth-23
Closed issues: o <http://tools.ietf.org/wg/httpbis/trac/ticket/513>: "APPSDIR
review of draft-ietf-httpbis-p7-auth-24"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/473>: "Forwarding o <http://tools.ietf.org/wg/httpbis/trac/ticket/516>: "note about
Proxy-*" WWW-A parsing potentially misleading"
Index Index
4 4
401 Unauthorized (status code) 7 401 Unauthorized (status code) 7
407 Proxy Authentication Required (status code) 7 407 Proxy Authentication Required (status code) 7
A A
Authorization header field 8 Authorization header field 7
C C
Canonical Root URI 6 Canonical Root URI 6
G G
Grammar Grammar
auth-param 5 auth-param 5
auth-scheme 5 auth-scheme 5
Authorization 8 Authorization 8
challenge 5 challenge 5
credentials 6 credentials 5
Proxy-Authenticate 8 Proxy-Authenticate 8
Proxy-Authorization 9 Proxy-Authorization 8
token68 5 token68 5
WWW-Authenticate 9 WWW-Authenticate 9
P P
Protection Space 6 Protection Space 6
Proxy-Authenticate header field 8 Proxy-Authenticate header field 8
Proxy-Authorization header field 8 Proxy-Authorization header field 8
R R
Realm 6 Realm 6
 End of changes. 25 change blocks. 
112 lines changed or deleted 55 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/