source: draft-ietf-httpbis/10/draft-ietf-httpbis-p7-auth-10.txt @ 1697

Last change on this file since 1697 was 956, checked in by fielding@…, 9 years ago

forgot to set eol-style

  • Property svn:eol-style set to native
File size: 28.8 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2616 (if approved)                                  J. Gettys
7Updates: 2617 (if approved)                               Alcatel-Lucent
8Intended status: Standards Track                                J. Mogul
9Expires: January 13, 2011                                             HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                           Adobe Systems
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                           July 12, 2010
23
24
25                    HTTP/1.1, part 7: Authentication
26                     draft-ietf-httpbis-p7-auth-10
27
28Abstract
29
30   The Hypertext Transfer Protocol (HTTP) is an application-level
31   protocol for distributed, collaborative, hypermedia information
32   systems.  HTTP has been in use by the World Wide Web global
33   information initiative since 1990.  This document is Part 7 of the
34   seven-part specification that defines the protocol referred to as
35   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 7 defines
36   HTTP Authentication.
37
38Editorial Note (To be removed by RFC Editor)
39
40   Discussion of this draft should take place on the HTTPBIS working
41   group mailing list (ietf-http-wg@w3.org).  The current issues list is
42   at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
43   documents (including fancy diffs) can be found at
44   <http://tools.ietf.org/wg/httpbis/>.
45
46   The changes in this draft are summarized in Appendix C.11.
47
48Status of This Memo
49
50   This Internet-Draft is submitted in full conformance with the
51   provisions of BCP 78 and BCP 79.
52
53
54
55Fielding, et al.        Expires January 13, 2011                [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 7                   July 2010
58
59
60   Internet-Drafts are working documents of the Internet Engineering
61   Task Force (IETF).  Note that other groups may also distribute
62   working documents as Internet-Drafts.  The list of current Internet-
63   Drafts is at http://datatracker.ietf.org/drafts/current/.
64
65   Internet-Drafts are draft documents valid for a maximum of six months
66   and may be updated, replaced, or obsoleted by other documents at any
67   time.  It is inappropriate to use Internet-Drafts as reference
68   material or to cite them other than as "work in progress."
69
70   This Internet-Draft will expire on January 13, 2011.
71
72Copyright Notice
73
74   Copyright (c) 2010 IETF Trust and the persons identified as the
75   document authors.  All rights reserved.
76
77   This document is subject to BCP 78 and the IETF Trust's Legal
78   Provisions Relating to IETF Documents
79   (http://trustee.ietf.org/license-info) in effect on the date of
80   publication of this document.  Please review these documents
81   carefully, as they describe your rights and restrictions with respect
82   to this document.  Code Components extracted from this document must
83   include Simplified BSD License text as described in Section 4.e of
84   the Trust Legal Provisions and are provided without warranty as
85   described in the Simplified BSD License.
86
87   This document may contain material from IETF Documents or IETF
88   Contributions published or made publicly available before November
89   10, 2008.  The person(s) controlling the copyright in some of this
90   material may not have granted the IETF Trust the right to allow
91   modifications of such material outside the IETF Standards Process.
92   Without obtaining an adequate license from the person(s) controlling
93   the copyright in such materials, this document may not be modified
94   outside the IETF Standards Process, and derivative works of it may
95   not be created outside the IETF Standards Process, except to format
96   it for publication as an RFC or to translate it into languages other
97   than English.
98
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.        Expires January 13, 2011                [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 7                   July 2010
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
120     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
121       1.2.1.  Core Rules . . . . . . . . . . . . . . . . . . . . . .  5
122       1.2.2.  ABNF Rules defined in other Parts of the
123               Specification  . . . . . . . . . . . . . . . . . . . .  5
124   2.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  5
125     2.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  5
126     2.2.  407 Proxy Authentication Required  . . . . . . . . . . . .  5
127   3.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  5
128     3.1.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  6
129     3.2.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . .  6
130     3.3.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . .  7
131     3.4.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . .  7
132   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
133     4.1.  Status Code Registration . . . . . . . . . . . . . . . . .  8
134     4.2.  Message Header Registration  . . . . . . . . . . . . . . .  8
135   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
136     5.1.  Authentication Credentials and Idle Clients  . . . . . . .  9
137   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
138   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
139     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
140     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
141   Appendix A.  Compatibility with Previous Versions  . . . . . . . . 10
142     A.1.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 10
143   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 10
144   Appendix C.  Change Log (to be removed by RFC Editor before
145                publication)  . . . . . . . . . . . . . . . . . . . . 11
146     C.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . . 11
147     C.2.  Since draft-ietf-httpbis-p7-auth-00  . . . . . . . . . . . 11
148     C.3.  Since draft-ietf-httpbis-p7-auth-01  . . . . . . . . . . . 11
149     C.4.  Since draft-ietf-httpbis-p7-auth-02  . . . . . . . . . . . 11
150     C.5.  Since draft-ietf-httpbis-p7-auth-03  . . . . . . . . . . . 11
151     C.6.  Since draft-ietf-httpbis-p7-auth-04  . . . . . . . . . . . 11
152     C.7.  Since draft-ietf-httpbis-p7-auth-05  . . . . . . . . . . . 12
153     C.8.  Since draft-ietf-httpbis-p7-auth-06  . . . . . . . . . . . 12
154     C.9.  Since draft-ietf-httpbis-p7-auth-07  . . . . . . . . . . . 12
155     C.10. Since draft-ietf-httpbis-p7-auth-08  . . . . . . . . . . . 12
156     C.11. Since draft-ietf-httpbis-p7-auth-09  . . . . . . . . . . . 12
157   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
158
159
160
161
162
163
164
165
166
167Fielding, et al.        Expires January 13, 2011                [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 7                   July 2010
170
171
1721.  Introduction
173
174   This document defines HTTP/1.1 access control and authentication.
175   Right now it includes the extracted relevant sections of RFC 2616
176   with only minor changes.  The intention is to move the general
177   framework for HTTP authentication here, as currently specified in
178   [RFC2617], and allow the individual authentication mechanisms to be
179   defined elsewhere.  This introduction will be rewritten when that
180   occurs.
181
182   HTTP provides several OPTIONAL challenge-response authentication
183   mechanisms which can be used by a server to challenge a client
184   request and by a client to provide authentication information.  The
185   general framework for access authentication, and the specification of
186   "basic" and "digest" authentication, are specified in "HTTP
187   Authentication: Basic and Digest Access Authentication" [RFC2617].
188   This specification adopts the definitions of "challenge" and
189   "credentials" from that specification.
190
1911.1.  Requirements
192
193   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
194   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
195   document are to be interpreted as described in [RFC2119].
196
197   An implementation is not compliant if it fails to satisfy one or more
198   of the "MUST" or "REQUIRED" level requirements for the protocols it
199   implements.  An implementation that satisfies all the "MUST" or
200   "REQUIRED" level and all the "SHOULD" level requirements for its
201   protocols is said to be "unconditionally compliant"; one that
202   satisfies all the "MUST" level requirements but not all the "SHOULD"
203   level requirements for its protocols is said to be "conditionally
204   compliant".
205
2061.2.  Syntax Notation
207
208   This specification uses the ABNF syntax defined in Section 1.2 of
209   [Part1] (which extends the syntax defined in [RFC5234] with a list
210   rule).  Appendix B shows the collected ABNF, with the list rule
211   expanded.
212
213   The following core rules are included by reference, as defined in
214   [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
215   (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
216   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
217   sequence of data), SP (space), VCHAR (any visible USASCII character),
218   and WSP (whitespace).
219
220
221
222
223Fielding, et al.        Expires January 13, 2011                [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 7                   July 2010
226
227
2281.2.1.  Core Rules
229
230   The core rules below are defined in Section 1.2.2 of [Part1]:
231
232     OWS         = <OWS, defined in [Part1], Section 1.2.2>
233
2341.2.2.  ABNF Rules defined in other Parts of the Specification
235
236   The ABNF rules below are defined in other specifications:
237
238     challenge   = <challenge, defined in [RFC2617], Section 1.2>
239     credentials = <credentials, defined in [RFC2617], Section 1.2>
240
2412.  Status Code Definitions
242
2432.1.  401 Unauthorized
244
245   The request requires user authentication.  The response MUST include
246   a WWW-Authenticate header field (Section 3.4) containing a challenge
247   applicable to the requested resource.  The client MAY repeat the
248   request with a suitable Authorization header field (Section 3.1).  If
249   the request already included Authorization credentials, then the 401
250   response indicates that authorization has been refused for those
251   credentials.  If the 401 response contains the same challenge as the
252   prior response, and the user agent has already attempted
253   authentication at least once, then the user SHOULD be presented the
254   entity that was given in the response, since that entity might
255   include relevant diagnostic information.  HTTP access authentication
256   is explained in "HTTP Authentication: Basic and Digest Access
257   Authentication" [RFC2617].
258
2592.2.  407 Proxy Authentication Required
260
261   This code is similar to 401 (Unauthorized), but indicates that the
262   client must first authenticate itself with the proxy.  The proxy MUST
263   return a Proxy-Authenticate header field (Section 3.2) containing a
264   challenge applicable to the proxy for the requested resource.  The
265   client MAY repeat the request with a suitable Proxy-Authorization
266   header field (Section 3.3).  HTTP access authentication is explained
267   in "HTTP Authentication: Basic and Digest Access Authentication"
268   [RFC2617].
269
2703.  Header Field Definitions
271
272   This section defines the syntax and semantics of HTTP/1.1 header
273   fields related to authentication.
274
275
276
277
278
279Fielding, et al.        Expires January 13, 2011                [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 7                   July 2010
282
283
2843.1.  Authorization
285
286   The "Authorization" request-header field allows a user agent to
287   authenticate itself with a server -- usually, but not necessarily,
288   after receiving a 401 (Unauthorized) response.  Its value consists of
289   credentials containing information of the user agent for the realm of
290   the resource being requested.
291
292     Authorization   = "Authorization" ":" OWS Authorization-v
293     Authorization-v = credentials
294
295   HTTP access authentication is described in "HTTP Authentication:
296   Basic and Digest Access Authentication" [RFC2617].  If a request is
297   authenticated and a realm specified, the same credentials SHOULD be
298   valid for all other requests within this realm (assuming that the
299   authentication scheme itself does not require otherwise, such as
300   credentials that vary according to a challenge value or using
301   synchronized clocks).
302
303   When a shared cache (see Section 1.2 of [Part6]) receives a request
304   containing an Authorization field, it MUST NOT return the
305   corresponding response as a reply to any other request, unless one of
306   the following specific exceptions holds:
307
308   1.  If the response includes the "s-maxage" cache-control directive,
309       the cache MAY use that response in replying to a subsequent
310       request.  But (if the specified maximum age has passed) a proxy
311       cache MUST first revalidate it with the origin server, using the
312       request-headers from the new request to allow the origin server
313       to authenticate the new request.  (This is the defined behavior
314       for s-maxage.)  If the response includes "s-maxage=0", the proxy
315       MUST always revalidate it before re-using it.
316
317   2.  If the response includes the "must-revalidate" cache-control
318       directive, the cache MAY use that response in replying to a
319       subsequent request.  But if the response is stale, all caches
320       MUST first revalidate it with the origin server, using the
321       request-headers from the new request to allow the origin server
322       to authenticate the new request.
323
324   3.  If the response includes the "public" cache-control directive, it
325       MAY be returned in reply to any subsequent request.
326
3273.2.  Proxy-Authenticate
328
329   The "Proxy-Authenticate" response-header field consists of a
330   challenge that indicates the authentication scheme and parameters
331   applicable to the proxy for this Effective Request URI (Section 4.3
332
333
334
335Fielding, et al.        Expires January 13, 2011                [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 7                   July 2010
338
339
340   of [Part1]).  It MUST be included as part of a 407 (Proxy
341   Authentication Required) response.
342
343     Proxy-Authenticate   = "Proxy-Authenticate" ":" OWS
344                            Proxy-Authenticate-v
345     Proxy-Authenticate-v = 1#challenge
346
347   The HTTP access authentication process is described in "HTTP
348   Authentication: Basic and Digest Access Authentication" [RFC2617].
349   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
350   only to the current connection and SHOULD NOT be passed on to
351   downstream clients.  However, an intermediate proxy might need to
352   obtain its own credentials by requesting them from the downstream
353   client, which in some circumstances will appear as if the proxy is
354   forwarding the Proxy-Authenticate header field.
355
3563.3.  Proxy-Authorization
357
358   The "Proxy-Authorization" request-header field allows the client to
359   identify itself (or its user) to a proxy which requires
360   authentication.  Its value consists of credentials containing the
361   authentication information of the user agent for the proxy and/or
362   realm of the resource being requested.
363
364     Proxy-Authorization   = "Proxy-Authorization" ":" OWS
365                             Proxy-Authorization-v
366     Proxy-Authorization-v = credentials
367
368   The HTTP access authentication process is described in "HTTP
369   Authentication: Basic and Digest Access Authentication" [RFC2617].
370   Unlike Authorization, the Proxy-Authorization header field applies
371   only to the next outbound proxy that demanded authentication using
372   the Proxy-Authenticate field.  When multiple proxies are used in a
373   chain, the Proxy-Authorization header field is consumed by the first
374   outbound proxy that was expecting to receive credentials.  A proxy
375   MAY relay the credentials from the client request to the next proxy
376   if that is the mechanism by which the proxies cooperatively
377   authenticate a given request.
378
3793.4.  WWW-Authenticate
380
381   The "WWW-Authenticate" response-header field consists of at least one
382   challenge that indicates the authentication scheme(s) and parameters
383   applicable to the Effective Request URI (Section 4.3 of [Part1]).  It
384   MUST be included in 401 (Unauthorized) response messages.
385
386     WWW-Authenticate   = "WWW-Authenticate" ":" OWS WWW-Authenticate-v
387     WWW-Authenticate-v = 1#challenge
388
389
390
391Fielding, et al.        Expires January 13, 2011                [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 7                   July 2010
394
395
396   The HTTP access authentication process is described in "HTTP
397   Authentication: Basic and Digest Access Authentication" [RFC2617].
398   User agents are advised to take special care in parsing the WWW-
399   Authenticate field value as it might contain more than one challenge,
400   or if more than one WWW-Authenticate header field is provided, the
401   contents of a challenge itself can contain a comma-separated list of
402   authentication parameters.
403
4044.  IANA Considerations
405
4064.1.  Status Code Registration
407
408   The HTTP Status Code Registry located at
409   <http://www.iana.org/assignments/http-status-codes> should be updated
410   with the registrations below:
411
412   +-------+-------------------------------+-------------+
413   | Value | Description                   | Reference   |
414   +-------+-------------------------------+-------------+
415   | 401   | Unauthorized                  | Section 2.1 |
416   | 407   | Proxy Authentication Required | Section 2.2 |
417   +-------+-------------------------------+-------------+
418
4194.2.  Message Header Registration
420
421   The Message Header Registry located at <http://www.iana.org/
422   assignments/message-headers/message-header-index.html> should be
423   updated with the permanent registrations below (see [RFC3864]):
424
425   +---------------------+----------+----------+-------------+
426   | Header Field Name   | Protocol | Status   | Reference   |
427   +---------------------+----------+----------+-------------+
428   | Authorization       | http     | standard | Section 3.1 |
429   | Proxy-Authenticate  | http     | standard | Section 3.2 |
430   | Proxy-Authorization | http     | standard | Section 3.3 |
431   | WWW-Authenticate    | http     | standard | Section 3.4 |
432   +---------------------+----------+----------+-------------+
433
434   The change controller is: "IETF (iesg@ietf.org) - Internet
435   Engineering Task Force".
436
4375.  Security Considerations
438
439   This section is meant to inform application developers, information
440   providers, and users of the security limitations in HTTP/1.1 as
441   described by this document.  The discussion does not include
442   definitive solutions to the problems revealed, though it does make
443   some suggestions for reducing security risks.
444
445
446
447Fielding, et al.        Expires January 13, 2011                [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 7                   July 2010
450
451
4525.1.  Authentication Credentials and Idle Clients
453
454   Existing HTTP clients and user agents typically retain authentication
455   information indefinitely.  HTTP/1.1 does not provide a method for a
456   server to direct clients to discard these cached credentials.  This
457   is a significant defect that requires further extensions to HTTP.
458   Circumstances under which credential caching can interfere with the
459   application's security model include but are not limited to:
460
461   o  Clients which have been idle for an extended period following
462      which the server might wish to cause the client to reprompt the
463      user for credentials.
464
465   o  Applications which include a session termination indication (such
466      as a "logout" or "commit" button on a page) after which the server
467      side of the application "knows" that there is no further reason
468      for the client to retain the credentials.
469
470   This is currently under separate study.  There are a number of work-
471   arounds to parts of this problem, and we encourage the use of
472   password protection in screen savers, idle time-outs, and other
473   methods which mitigate the security problems inherent in this
474   problem.  In particular, user agents which cache credentials are
475   encouraged to provide a readily accessible mechanism for discarding
476   cached credentials under user control.
477
4786.  Acknowledgments
479
480   [[acks: TBD.]]
481
4827.  References
483
4847.1.  Normative References
485
486   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
487              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
488              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
489              and Message Parsing", draft-ietf-httpbis-p1-messaging-10
490              (work in progress), July 2010.
491
492   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
493              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
494              Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
495              6: Caching", draft-ietf-httpbis-p6-cache-10 (work in
496              progress), July 2010.
497
498   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
499              Requirement Levels", BCP 14, RFC 2119, March 1997.
500
501
502
503Fielding, et al.        Expires January 13, 2011                [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 7                   July 2010
506
507
508   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
509              Leach, P., Luotonen, A., and L. Stewart, "HTTP
510              Authentication: Basic and Digest Access Authentication",
511              RFC 2617, June 1999.
512
513   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
514              Specifications: ABNF", STD 68, RFC 5234, January 2008.
515
5167.2.  Informative References
517
518   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
519              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
520              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
521
522   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
523              Procedures for Message Header Fields", BCP 90, RFC 3864,
524              September 2004.
525
526Appendix A.  Compatibility with Previous Versions
527
528A.1.  Changes from RFC 2616
529
530Appendix B.  Collected ABNF
531
532   Authorization = "Authorization:" OWS Authorization-v
533   Authorization-v = credentials
534
535   OWS = <OWS, defined in [Part1], Section 1.2.2>
536
537   Proxy-Authenticate = "Proxy-Authenticate:" OWS Proxy-Authenticate-v
538   Proxy-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS
539    challenge ] )
540   Proxy-Authorization = "Proxy-Authorization:" OWS
541    Proxy-Authorization-v
542   Proxy-Authorization-v = credentials
543
544   WWW-Authenticate = "WWW-Authenticate:" OWS WWW-Authenticate-v
545   WWW-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS
546    challenge ] )
547
548   challenge = <challenge, defined in [RFC2617], Section 1.2>
549   credentials = <credentials, defined in [RFC2617], Section 1.2>
550
551
552
553
554
555
556
557
558
559Fielding, et al.        Expires January 13, 2011               [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 7                   July 2010
562
563
564   ABNF diagnostics:
565
566   ; Authorization defined but not used
567   ; Proxy-Authenticate defined but not used
568   ; Proxy-Authorization defined but not used
569   ; WWW-Authenticate defined but not used
570
571Appendix C.  Change Log (to be removed by RFC Editor before publication)
572
573C.1.  Since RFC2616
574
575   Extracted relevant partitions from [RFC2616].
576
577C.2.  Since draft-ietf-httpbis-p7-auth-00
578
579   Closed issues:
580
581   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
582      Informative references"
583
584C.3.  Since draft-ietf-httpbis-p7-auth-01
585
586   Ongoing work on ABNF conversion
587   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
588
589   o  Explicitly import BNF rules for "challenge" and "credentials" from
590      RFC2617.
591
592   o  Add explicit references to BNF syntax and rules imported from
593      other parts of the specification.
594
595C.4.  Since draft-ietf-httpbis-p7-auth-02
596
597   Ongoing work on IANA Message Header Registration
598   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
599
600   o  Reference RFC 3984, and update header registrations for headers
601      defined in this document.
602
603C.5.  Since draft-ietf-httpbis-p7-auth-03
604
605C.6.  Since draft-ietf-httpbis-p7-auth-04
606
607   Ongoing work on ABNF conversion
608   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
609
610   o  Use "/" instead of "|" for alternatives.
611
612
613
614
615Fielding, et al.        Expires January 13, 2011               [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 7                   July 2010
618
619
620   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
621      whitespace ("OWS") and required whitespace ("RWS").
622
623   o  Rewrite ABNFs to spell out whitespace rules, factor out header
624      value format definitions.
625
626C.7.  Since draft-ietf-httpbis-p7-auth-05
627
628   Final work on ABNF conversion
629   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
630
631   o  Add appendix containing collected and expanded ABNF, reorganize
632      ABNF introduction.
633
634C.8.  Since draft-ietf-httpbis-p7-auth-06
635
636   None.
637
638C.9.  Since draft-ietf-httpbis-p7-auth-07
639
640   Closed issues:
641
642   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
643      registrations for optional status codes"
644
645C.10.  Since draft-ietf-httpbis-p7-auth-08
646
647   No significant changes.
648
649C.11.  Since draft-ietf-httpbis-p7-auth-09
650
651   Partly resolved issues:
652
653   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
654      requested resource's URI"
655
656Index
657
658   4
659      401 Unauthorized (status code)  5
660      407 Proxy Authentication Required (status code)  5
661
662   A
663      Authorization header  6
664
665   G
666      Grammar
667         Authorization  6
668
669
670
671Fielding, et al.        Expires January 13, 2011               [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 7                   July 2010
674
675
676         Authorization-v  6
677         challenge  5
678         credentials  5
679         Proxy-Authenticate  7
680         Proxy-Authenticate-v  7
681         Proxy-Authorization  7
682         Proxy-Authorization-v  7
683         WWW-Authenticate  7
684         WWW-Authenticate-v  7
685
686   H
687      Headers
688         Authorization  6
689         Proxy-Authenticate  6
690         Proxy-Authorization  7
691         WWW-Authenticate  7
692
693   P
694      Proxy-Authenticate header  6
695      Proxy-Authorization header  7
696
697   S
698      Status Codes
699         401 Unauthorized  5
700         407 Proxy Authentication Required  5
701
702   W
703      WWW-Authenticate header  7
704
705Authors' Addresses
706
707   Roy T. Fielding (editor)
708   Day Software
709   23 Corporate Plaza DR, Suite 280
710   Newport Beach, CA  92660
711   USA
712
713   Phone: +1-949-706-5300
714   Fax:   +1-949-706-5305
715   EMail: fielding@gbiv.com
716   URI:   http://roy.gbiv.com/
717
718
719
720
721
722
723
724
725
726
727Fielding, et al.        Expires January 13, 2011               [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 7                   July 2010
730
731
732   Jim Gettys
733   Alcatel-Lucent Bell Labs
734   21 Oak Knoll Road
735   Carlisle, MA  01741
736   USA
737
738   EMail: jg@freedesktop.org
739   URI:   http://gettys.wordpress.com/
740
741
742   Jeffrey C. Mogul
743   Hewlett-Packard Company
744   HP Labs, Large Scale Systems Group
745   1501 Page Mill Road, MS 1177
746   Palo Alto, CA  94304
747   USA
748
749   EMail: JeffMogul@acm.org
750
751
752   Henrik Frystyk Nielsen
753   Microsoft Corporation
754   1 Microsoft Way
755   Redmond, WA  98052
756   USA
757
758   EMail: henrikn@microsoft.com
759
760
761   Larry Masinter
762   Adobe Systems, Incorporated
763   345 Park Ave
764   San Jose, CA  95110
765   USA
766
767   EMail: LMM@acm.org
768   URI:   http://larry.masinter.net/
769
770
771   Paul J. Leach
772   Microsoft Corporation
773   1 Microsoft Way
774   Redmond, WA  98052
775
776   EMail: paulle@microsoft.com
777
778
779
780
781
782
783Fielding, et al.        Expires January 13, 2011               [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 7                   July 2010
786
787
788   Tim Berners-Lee
789   World Wide Web Consortium
790   MIT Computer Science and Artificial Intelligence Laboratory
791   The Stata Center, Building 32
792   32 Vassar Street
793   Cambridge, MA  02139
794   USA
795
796   EMail: timbl@w3.org
797   URI:   http://www.w3.org/People/Berners-Lee/
798
799
800   Yves Lafon (editor)
801   World Wide Web Consortium
802   W3C / ERCIM
803   2004, rte des Lucioles
804   Sophia-Antipolis, AM  06902
805   France
806
807   EMail: ylafon@w3.org
808   URI:   http://www.raubacapeu.net/people/yves/
809
810
811   Julian F. Reschke (editor)
812   greenbytes GmbH
813   Hafenweg 16
814   Muenster, NW  48155
815   Germany
816
817   Phone: +49 251 2807760
818   Fax:   +49 251 2807761
819   EMail: julian.reschke@greenbytes.de
820   URI:   http://greenbytes.de/tech/webdav/
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839Fielding, et al.        Expires January 13, 2011               [Page 15]
840
Note: See TracBrowser for help on using the repository browser.