| draft-ietf-httpbis-p7-auth-16.txt |  | draft-ietf-httpbis-p7-auth-17.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: February 25, 2012 HP |  | Expires: May 3, 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 |
| August 24, 2011 |  | October 31, 2011 |
| HTTP/1.1, part 7: Authentication |  | HTTP/1.1, part 7: Authentication |
| draft-ietf-httpbis-p7-auth-16 |  | draft-ietf-httpbis-p7-auth-17 |
| 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.17. |  | The changes in this draft are summarized in Appendix C.18. |
| 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 February 25, 2012. |  | This Internet-Draft will expire on May 3, 2012. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2011 IETF Trust and the persons identified as the |  | Copyright (c) 2011 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 2, line 52 |  | skipping to change at page 2, line 52 |
| 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 |
| 2. Access Authentication Framework . . . . . . . . . . . . . . . 5 |  | 2. Access Authentication Framework . . . . . . . . . . . . . . . 5 |
| 2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 5 |  | 2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 5 |
| 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 7 |  | 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 7 |
| 2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7 |  | 2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7 |
| 2.3.1. Considerations for New Authentication Schemes . . . . 8 |  | 2.3.1. Considerations for New Authentication Schemes . . . . 8 |
| 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 8 |  | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9 |
| 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 8 |  | 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9 |
| 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9 |  | 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9 |
| 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 |  | 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 |
| 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 |  | 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 |
| 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10 |  | 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10 |
| 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10 |  | 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 11 |
| 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 11 |  | 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 11 |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 |
| 5.1. Authenticaton Scheme Registry . . . . . . . . . . . . . . 11 |  | 5.1. Authenticaton Scheme Registry . . . . . . . . . . . . . . 12 |
| 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 11 |  | 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 12 |
| 5.3. Header Field Registration . . . . . . . . . . . . . . . . 11 |  | 5.3. Header Field Registration . . . . . . . . . . . . . . . . 12 |
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 |  | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 |
| 6.1. Authentication Credentials and Idle Clients . . . . . . . 12 |  | 6.1. Authentication Credentials and Idle Clients . . . . . . . 13 |
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 |  | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 |
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 |  | 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 |
| Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 14 |  | Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 14 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 15 |  | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 15 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 15 |  | publication) . . . . . . . . . . . . . . . . . . . . 16 |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 15 |  | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 16 |
| C.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 16 |  | C.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 16 |
| C.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 16 |  | C.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 16 |
| C.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 16 |  | C.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 16 |
| C.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 16 |  | C.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 16 |
| C.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 16 |  | C.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 16 |
| C.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 16 |  | C.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 17 |
| C.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 17 |  | C.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 17 |
| C.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 17 |  | C.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 17 |
| C.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 17 |  | C.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 17 |
| C.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 17 |  | C.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 17 |
| C.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 17 |  | C.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 17 |
| C.13. Since draft-ietf-httpbis-p7-auth-11 . . . . . . . . . . . 17 |  | C.13. Since draft-ietf-httpbis-p7-auth-11 . . . . . . . . . . . 17 |
| C.14. Since draft-ietf-httpbis-p7-auth-12 . . . . . . . . . . . 18 |  | C.14. Since draft-ietf-httpbis-p7-auth-12 . . . . . . . . . . . 18 |
| C.15. Since draft-ietf-httpbis-p7-auth-13 . . . . . . . . . . . 18 |  | C.15. Since draft-ietf-httpbis-p7-auth-13 . . . . . . . . . . . 18 |
| C.16. Since draft-ietf-httpbis-p7-auth-14 . . . . . . . . . . . 18 |  | C.16. Since draft-ietf-httpbis-p7-auth-14 . . . . . . . . . . . 18 |
| C.17. Since draft-ietf-httpbis-p7-auth-15 . . . . . . . . . . . 18 |  | C.17. Since draft-ietf-httpbis-p7-auth-15 . . . . . . . . . . . 18 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | C.18. Since draft-ietf-httpbis-p7-auth-16 . . . . . . . . . . . 19 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 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 |
| mechanisms which can be used by a server to challenge a client |  | mechanisms which can be used by a server to challenge a client |
| request and by a client to provide authentication information. The |  | request and by a client to provide authentication information. The |
| "basic" and "digest" authentication schemes continue to be specified |  | "basic" and "digest" authentication schemes continue to be specified |
| in RFC 2617. |  | in RFC 2617. |
| 1.1. Requirements |  | 1.1. Conformance and Error Handling |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| An implementation is not compliant if it fails to satisfy one or more |  | This document defines conformance criteria for several roles in HTTP |
| of the "MUST" or "REQUIRED" level requirements for the protocols it |  | communication, including Senders, Recipients, Clients, Servers, User- |
| implements. An implementation that satisfies all the "MUST" or |  | Agents, Origin Servers, Intermediaries, Proxies and Gateways. See |
| "REQUIRED" level and all the "SHOULD" level requirements for its |  | Section 2 of [Part1] for definitions of these terms. |
| protocols is said to be "unconditionally compliant"; one that |  |  |
| satisfies all the "MUST" level requirements but not all the "SHOULD" |  | An implementation is considered conformant if it complies with all of |
| level requirements for its protocols is said to be "conditionally |  | the requirements associated with its role(s). Note that SHOULD-level |
| compliant". |  | requirements are relevant here, unless one of the documented |
|  |  | exceptions is applicable. |
|  |  | This document also uses ABNF to define valid protocol elements |
|  |  | (Section 1.2). In addition to the prose requirements placed upon |
|  |  | them, Senders MUST NOT generate protocol elements that are invalid. |
|  |  | Unless noted otherwise, Recipients MAY take steps to recover a usable |
|  |  | protocol element from an invalid construct. However, HTTP does not |
|  |  | define specific error handling mechanisms, except in cases where it |
|  |  | has direct impact on security. This is because different uses of the |
|  |  | protocol require different error handling strategies; for example, a |
|  |  | Web browser may wish to transparently recover from a response where |
|  |  | the Location header field doesn't parse according to the ABNF, |
|  |  | whereby in a systems control protocol using HTTP, this type of error |
|  |  | recovery could lead to dangerous consequences. |
| 1.2. Syntax Notation |  | 1.2. Syntax Notation |
| This specification uses the ABNF syntax defined in Section 1.2 of |  | This specification uses the ABNF syntax defined in Section 1.2 of |
| [Part1] (which extends the syntax defined in [RFC5234] with a list |  | [Part1] (which extends the syntax defined in [RFC5234] with a list |
| rule). Appendix B shows the collected ABNF, with the list rule |  | rule). Appendix B shows the collected ABNF, with the list rule |
| expanded. |  | expanded. |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |  | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
| HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |  | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |
| sequence of data), SP (space), VCHAR (any visible USASCII character), |  | sequence of data), SP (space), and VCHAR (any visible US-ASCII |
| and WSP (whitespace). |  | character). |
| 1.2.1. Core Rules |  | 1.2.1. Core Rules |
| The core rules below are defined in [Part1]: |  | The core rules below are defined in [Part1]: |
| BWS = <BWS, defined in [Part1], Section 1.2.2> |  | BWS = <BWS, defined in [Part1], Section 1.2.2> |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> |
| token = <token, defined in [Part1], Section 3.2.3> |  | token = <token, defined in [Part1], Section 3.2.3> |
| skipping to change at page 8, line 26 |  | skipping to change at page 8, line 35 |
| o The authentication parameter "realm" is reserved for defining |  | o The authentication parameter "realm" is reserved for defining |
| Protection Spaces as defined in Section 2.2. New schemes MUST NOT |  | Protection Spaces as defined in Section 2.2. New schemes MUST NOT |
| use it in a way incompatible with that definition. |  | use it in a way incompatible with that definition. |
| o The "b64token" notation was introduced for compatibility with |  | o The "b64token" notation was introduced for compatibility with |
| existing authentication schemes and can only be used once per |  | existing authentication schemes and can only be used once per |
| challenge/credentials. New schemes thus ought to use the "auth- |  | challenge/credentials. New schemes thus ought to use the "auth- |
| param" syntax instead, because otherwise future extensions will be |  | param" syntax instead, because otherwise future extensions will be |
| impossible. |  | impossible. |
|  |  | o The parsing of challenges and credentials is defined by this |
|  |  | specification, and cannot be modified by new authentication |
|  |  | schemes. When the auth-param syntax is used, all parameters ought |
|  |  | to support both token and quoted-string syntax, and syntactical |
|  |  | constraints ought to be defined on the field value after parsing |
|  |  | (i.e., quoted-string processing). This is necessary so that |
|  |  | recipients can use a generic parser that applies to all |
|  |  | authentication schemes. |
|  |  | Note: the fact that the value syntax for the "realm" parameter is |
|  |  | restricted to quoted-string was a bad design choice not to be |
|  |  | repeated for new parameters. |
| o Authentication schemes need to document whether they are usable in |  | o Authentication schemes need to document whether they are usable in |
| origin-server authentication (i.e., using WWW-Authenticate), |  | origin-server authentication (i.e., using WWW-Authenticate), |
| and/or proxy authentication (i.e., using Proxy-Authenticate). |  | and/or proxy authentication (i.e., using Proxy-Authenticate). |
| o The credentials carried in an Authorization header field are |  | o The credentials carried in an Authorization header field are |
| specific to the User Agent, and therefore have the same effect on |  | specific to the User Agent, and therefore have the same effect on |
| HTTP caches as the "private" Cache-Control response directive, |  | HTTP caches as the "private" Cache-Control response directive, |
| within the scope of the request they appear in. |  | within the scope of the request they appear in. |
| Therefore, new authentication schemes which choose not to carry |  | Therefore, new authentication schemes which choose not to carry |
| skipping to change at page 11, line 23 |  | skipping to change at page 11, line 42 |
| 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 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 |
| contents of a challenge itself can contain a comma-separated list of |  | contents of a challenge itself can contain a comma-separated list of |
| authentication parameters. |  | authentication parameters. |
|  |  | For instance: |
|  |  | WWW-Authenticate: Newauth realm="apps", type=1, |
|  |  | title="Login to \"apps\"", Basic realm="simple" |
|  |  | This header field contains two challenges; one for the "Newauth" |
|  |  | scheme with a realm value of "apps", and two additional parameters |
|  |  | "type" and "title", and another one for the "Basic" scheme with a |
|  |  | realm value of "simple". |
| 5. IANA Considerations |  | 5. IANA Considerations |
| 5.1. Authenticaton Scheme Registry |  | 5.1. Authenticaton Scheme Registry |
| The registration procedure for HTTP Authentication Schemes is defined |  | The registration procedure for HTTP Authentication Schemes is defined |
| by Section 2.3 of this document. |  | by Section 2.3 of this document. |
| The HTTP Method Authentication Scheme shall be created at |  | The HTTP Method Authentication Scheme shall be created at |
| <http://www.iana.org/assignments/http-authschemes>. |  | <http://www.iana.org/assignments/http-authschemes>. |
| skipping to change at page 13, line 14 |  | skipping to change at page 13, line 40 |
| 7. Acknowledgments |  | 7. Acknowledgments |
| 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 |
| John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. |  | John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. |
| Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for |  | Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for |
| their work on that specification. See Section 6 of [RFC2617] for |  | their work on that specification. See Section 6 of [RFC2617] for |
| further acknowledgements. |  | further acknowledgements. |
| See Section 12 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-16 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-17 |
| (work in progress), August 2011. |  | (work in progress), October 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-16 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-17 (work in |
| progress), August 2011. |  | progress), October 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 18, line 45 |  | skipping to change at page 19, line 5 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/257>: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/257>: |
| "Considerations for new authentications schemes" |  | "Considerations for new authentications schemes" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/287>: "LWS in auth- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/287>: "LWS in auth- |
| param ABNF" |  | param ABNF" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/309>: "credentials |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/309>: "credentials |
| ABNF missing SP (still using implied LWS?)" |  | ABNF missing SP (still using implied LWS?)" |
|  |  | C.18. Since draft-ietf-httpbis-p7-auth-16 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |
|  |  | HTTP's error-handling philosophy" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/320>: "add advice on |
|  |  | defining auth scheme parameters" |
| Index |  | Index |
| 4 |  | 4 |
| 401 Unauthorized (status code) 8 |  | 401 Unauthorized (status code) 9 |
| 407 Proxy Authentication Required (status code) 9 |  | 407 Proxy Authentication Required (status code) 9 |
| A |  | A |
| auth-param 5 |  | auth-param 5 |
| auth-scheme 5 |  | auth-scheme 5 |
| Authorization header field 9 |  | Authorization header field 9 |
| B |  | B |
| b64token 5 |  | b64token 5 |
| C |  | C |
| challenge 5 |  | challenge 6 |
| credentials 6 |  | credentials 6 |
| G |  | G |
| Grammar |  | Grammar |
| auth-param 5 |  | auth-param 5 |
| auth-scheme 5 |  | auth-scheme 5 |
| Authorization 9 |  | Authorization 10 |
| b64token 5 |  | b64token 5 |
| challenge 5 |  | challenge 6 |
| credentials 6 |  | credentials 6 |
| Proxy-Authenticate 10 |  | Proxy-Authenticate 10 |
| Proxy-Authorization 10 |  | Proxy-Authorization 11 |
| realm 7 |  | realm 7 |
| WWW-Authenticate 11 |  | WWW-Authenticate 11 |
| H |  | H |
| Header Fields |  | Header Fields |
| Authorization 9 |  | Authorization 9 |
| Proxy-Authenticate 10 |  | Proxy-Authenticate 10 |
| Proxy-Authorization 10 |  | Proxy-Authorization 11 |
| WWW-Authenticate 11 |  | WWW-Authenticate 11 |
| P |  | P |
| Protection Space 7 |  | Protection Space 7 |
| Proxy-Authenticate header field 10 |  | Proxy-Authenticate header field 10 |
| Proxy-Authorization header field 10 |  | Proxy-Authorization header field 11 |
| R |  | R |
| Realm 7 |  | Realm 7 |
| realm 7 |  | realm 7 |
| realm-value 7 |  | realm-value 7 |
| S |  | S |
| Status Codes |  | Status Codes |
| 401 Unauthorized 8 |  | 401 Unauthorized 9 |
| 407 Proxy Authentication Required 9 |  | 407 Proxy Authentication Required 9 |
| W |  | W |
| WWW-Authenticate header field 11 |  | WWW-Authenticate header field 11 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
End of changes. 32 change blocks.
| 44 lines changed or deleted |  | 93 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/