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