source: draft-ietf-httpbis/11/draft-ietf-httpbis-p7-auth-11.txt @ 973

Last change on this file since 973 was 973, checked in by julian.reschke@…, 9 years ago

prepare publication of -11 drafts on 2010-08-04.

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 28.7 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: February 5, 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                                                          August 4, 2010
23
24
25                    HTTP/1.1, part 7: Authentication
26                     draft-ietf-httpbis-p7-auth-11
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 B.12.
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 February 5, 2011                [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 7                 August 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 February 5, 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 February 5, 2011                [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 7                 August 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.  Header Field 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.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 10
142   Appendix B.  Change Log (to be removed by RFC Editor before
143                publication)  . . . . . . . . . . . . . . . . . . . . 11
144     B.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . . 11
145     B.2.  Since draft-ietf-httpbis-p7-auth-00  . . . . . . . . . . . 11
146     B.3.  Since draft-ietf-httpbis-p7-auth-01  . . . . . . . . . . . 11
147     B.4.  Since draft-ietf-httpbis-p7-auth-02  . . . . . . . . . . . 11
148     B.5.  Since draft-ietf-httpbis-p7-auth-03  . . . . . . . . . . . 11
149     B.6.  Since draft-ietf-httpbis-p7-auth-04  . . . . . . . . . . . 11
150     B.7.  Since draft-ietf-httpbis-p7-auth-05  . . . . . . . . . . . 12
151     B.8.  Since draft-ietf-httpbis-p7-auth-06  . . . . . . . . . . . 12
152     B.9.  Since draft-ietf-httpbis-p7-auth-07  . . . . . . . . . . . 12
153     B.10. Since draft-ietf-httpbis-p7-auth-08  . . . . . . . . . . . 12
154     B.11. Since draft-ietf-httpbis-p7-auth-09  . . . . . . . . . . . 12
155     B.12. Since draft-ietf-httpbis-p7-auth-10  . . . . . . . . . . . 12
156   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
157
158
159
160
161
162
163
164
165
166
167Fielding, et al.        Expires February 5, 2011                [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 7                 August 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 A 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 February 5, 2011                [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 7                 August 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 target resource.  The client MAY repeat the request
248   with a suitable Authorization header field (Section 3.1).  If the
249   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   representation that was given in the response, since that
255   representation might include relevant diagnostic information.  HTTP
256   access authentication is explained in "HTTP Authentication: Basic and
257   Digest Access 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 target 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 February 5, 2011                [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 7                 August 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 February 5, 2011                [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 7                 August 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 February 5, 2011                [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 7                 August 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> shall 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.  Header Field Registration
420
421   The Message Header Field Registry located at <http://www.iana.org/
422   assignments/message-headers/message-header-index.html> shall 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 February 5, 2011                [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 7                 August 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-11
490              (work in progress), August 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-11 (work in
496              progress), August 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 February 5, 2011                [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 7                 August 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.  Collected ABNF
527
528   Authorization = "Authorization:" OWS Authorization-v
529   Authorization-v = credentials
530
531   OWS = <OWS, defined in [Part1], Section 1.2.2>
532
533   Proxy-Authenticate = "Proxy-Authenticate:" OWS Proxy-Authenticate-v
534   Proxy-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS
535    challenge ] )
536   Proxy-Authorization = "Proxy-Authorization:" OWS
537    Proxy-Authorization-v
538   Proxy-Authorization-v = credentials
539
540   WWW-Authenticate = "WWW-Authenticate:" OWS WWW-Authenticate-v
541   WWW-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS
542    challenge ] )
543
544   challenge = <challenge, defined in [RFC2617], Section 1.2>
545   credentials = <credentials, defined in [RFC2617], Section 1.2>
546
547   ABNF diagnostics:
548
549   ; Authorization defined but not used
550   ; Proxy-Authenticate defined but not used
551   ; Proxy-Authorization defined but not used
552   ; WWW-Authenticate defined but not used
553
554
555
556
557
558
559Fielding, et al.        Expires February 5, 2011               [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 7                 August 2010
562
563
564Appendix B.  Change Log (to be removed by RFC Editor before publication)
565
566B.1.  Since RFC2616
567
568   Extracted relevant partitions from [RFC2616].
569
570B.2.  Since draft-ietf-httpbis-p7-auth-00
571
572   Closed issues:
573
574   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
575      Informative references"
576
577B.3.  Since draft-ietf-httpbis-p7-auth-01
578
579   Ongoing work on ABNF conversion
580   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
581
582   o  Explicitly import BNF rules for "challenge" and "credentials" from
583      RFC2617.
584
585   o  Add explicit references to BNF syntax and rules imported from
586      other parts of the specification.
587
588B.4.  Since draft-ietf-httpbis-p7-auth-02
589
590   Ongoing work on IANA Message Header Registration
591   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
592
593   o  Reference RFC 3984, and update header registrations for headers
594      defined in this document.
595
596B.5.  Since draft-ietf-httpbis-p7-auth-03
597
598B.6.  Since draft-ietf-httpbis-p7-auth-04
599
600   Ongoing work on ABNF conversion
601   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
602
603   o  Use "/" instead of "|" for alternatives.
604
605   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
606      whitespace ("OWS") and required whitespace ("RWS").
607
608   o  Rewrite ABNFs to spell out whitespace rules, factor out header
609      value format definitions.
610
611
612
613
614
615Fielding, et al.        Expires February 5, 2011               [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 7                 August 2010
618
619
620B.7.  Since draft-ietf-httpbis-p7-auth-05
621
622   Final work on ABNF conversion
623   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
624
625   o  Add appendix containing collected and expanded ABNF, reorganize
626      ABNF introduction.
627
628B.8.  Since draft-ietf-httpbis-p7-auth-06
629
630   None.
631
632B.9.  Since draft-ietf-httpbis-p7-auth-07
633
634   Closed issues:
635
636   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
637      registrations for optional status codes"
638
639B.10.  Since draft-ietf-httpbis-p7-auth-08
640
641   No significant changes.
642
643B.11.  Since draft-ietf-httpbis-p7-auth-09
644
645   Partly resolved issues:
646
647   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
648      requested resource's URI"
649
650B.12.  Since draft-ietf-httpbis-p7-auth-10
651
652   None yet.
653
654Index
655
656   4
657      401 Unauthorized (status code)  5
658      407 Proxy Authentication Required (status code)  5
659
660   A
661      Authorization header  6
662
663   G
664      Grammar
665         Authorization  6
666         Authorization-v  6
667         challenge  5
668
669
670
671Fielding, et al.        Expires February 5, 2011               [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 7                 August 2010
674
675
676         credentials  5
677         Proxy-Authenticate  7
678         Proxy-Authenticate-v  7
679         Proxy-Authorization  7
680         Proxy-Authorization-v  7
681         WWW-Authenticate  7
682         WWW-Authenticate-v  7
683
684   H
685      Headers
686         Authorization  6
687         Proxy-Authenticate  6
688         Proxy-Authorization  7
689         WWW-Authenticate  7
690
691   P
692      Proxy-Authenticate header  6
693      Proxy-Authorization header  7
694
695   S
696      Status Codes
697         401 Unauthorized  5
698         407 Proxy Authentication Required  5
699
700   W
701      WWW-Authenticate header  7
702
703Authors' Addresses
704
705   Roy T. Fielding (editor)
706   Day Software
707   23 Corporate Plaza DR, Suite 280
708   Newport Beach, CA  92660
709   USA
710
711   Phone: +1-949-706-5300
712   Fax:   +1-949-706-5305
713   EMail: fielding@gbiv.com
714   URI:   http://roy.gbiv.com/
715
716
717
718
719
720
721
722
723
724
725
726
727Fielding, et al.        Expires February 5, 2011               [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 7                 August 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 February 5, 2011               [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 7                 August 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 February 5, 2011               [Page 15]
840
Note: See TracBrowser for help on using the repository browser.