source: draft-ietf-httpbis/17/draft-ietf-httpbis-p7-auth-17.xml @ 1500

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

fix mime types

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/xml
File size: 52.7 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!--
3    This XML document is the output of clean-for-DTD.xslt; a tool that strips
4    extensions to RFC2629(bis) from documents for processing with xml2rfc.
5-->
6<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
7<?rfc toc="yes" ?>
8<?rfc symrefs="yes" ?>
9<?rfc sortrefs="yes" ?>
10<?rfc compact="yes"?>
11<?rfc subcompact="no" ?>
12<?rfc linkmailto="no" ?>
13<?rfc editing="no" ?>
14<?rfc comments="yes"?>
15<?rfc inline="yes"?>
16<?rfc rfcedstyle="yes"?>
17<!DOCTYPE rfc
18  PUBLIC "" "rfc2629.dtd">
19<rfc obsoletes="2616" updates="2617" category="std" ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p7-auth-17">
20<front>
21
22  <title abbrev="HTTP/1.1, Part 7">HTTP/1.1, part 7: Authentication</title>
23
24  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
25    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
26    <address>
27      <postal>
28        <street>345 Park Ave</street>
29        <city>San Jose</city>
30        <region>CA</region>
31        <code>95110</code>
32        <country>USA</country>
33      </postal>
34      <email>fielding@gbiv.com</email>
35      <uri>http://roy.gbiv.com/</uri>
36    </address>
37  </author>
38
39  <author initials="J." surname="Gettys" fullname="Jim Gettys">
40    <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
41    <address>
42      <postal>
43        <street>21 Oak Knoll Road</street>
44        <city>Carlisle</city>
45        <region>MA</region>
46        <code>01741</code>
47        <country>USA</country>
48      </postal>
49      <email>jg@freedesktop.org</email>
50      <uri>http://gettys.wordpress.com/</uri>
51    </address>
52  </author>
53 
54  <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
55    <organization abbrev="HP">Hewlett-Packard Company</organization>
56    <address>
57      <postal>
58        <street>HP Labs, Large Scale Systems Group</street>
59        <street>1501 Page Mill Road, MS 1177</street>
60        <city>Palo Alto</city>
61        <region>CA</region>
62        <code>94304</code>
63        <country>USA</country>
64      </postal>
65      <email>JeffMogul@acm.org</email>
66    </address>
67  </author>
68
69  <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
70    <organization abbrev="Microsoft">Microsoft Corporation</organization>
71    <address>
72      <postal>
73        <street>1 Microsoft Way</street>
74        <city>Redmond</city>
75        <region>WA</region>
76        <code>98052</code>
77        <country>USA</country>
78      </postal>
79      <email>henrikn@microsoft.com</email>
80    </address>
81  </author>
82
83  <author initials="L." surname="Masinter" fullname="Larry Masinter">
84    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
85    <address>
86      <postal>
87        <street>345 Park Ave</street>
88        <city>San Jose</city>
89        <region>CA</region>
90        <code>95110</code>
91        <country>USA</country>
92      </postal>
93      <email>LMM@acm.org</email>
94      <uri>http://larry.masinter.net/</uri>
95    </address>
96  </author>
97 
98  <author initials="P." surname="Leach" fullname="Paul J. Leach">
99    <organization abbrev="Microsoft">Microsoft Corporation</organization>
100    <address>
101      <postal>
102        <street>1 Microsoft Way</street>
103        <city>Redmond</city>
104        <region>WA</region>
105        <code>98052</code>
106      </postal>
107      <email>paulle@microsoft.com</email>
108    </address>
109  </author>
110   
111  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
112    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
113    <address>
114      <postal>
115        <street>MIT Computer Science and Artificial Intelligence Laboratory</street>
116        <street>The Stata Center, Building 32</street>
117        <street>32 Vassar Street</street>
118        <city>Cambridge</city>
119        <region>MA</region>
120        <code>02139</code>
121        <country>USA</country>
122      </postal>
123      <email>timbl@w3.org</email>
124      <uri>http://www.w3.org/People/Berners-Lee/</uri>
125    </address>
126  </author>
127
128  <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
129    <organization abbrev="W3C">World Wide Web Consortium</organization>
130    <address>
131      <postal>
132        <street>W3C / ERCIM</street>
133        <street>2004, rte des Lucioles</street>
134        <city>Sophia-Antipolis</city>
135        <region>AM</region>
136        <code>06902</code>
137        <country>France</country>
138      </postal>
139      <email>ylafon@w3.org</email>
140      <uri>http://www.raubacapeu.net/people/yves/</uri>
141    </address>
142  </author>
143
144  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
145    <organization abbrev="greenbytes">greenbytes GmbH</organization>
146    <address>
147      <postal>
148        <street>Hafenweg 16</street>
149        <city>Muenster</city><region>NW</region><code>48155</code>
150        <country>Germany</country>
151      </postal>
152      <phone>+49 251 2807760</phone>
153      <facsimile>+49 251 2807761</facsimile>
154      <email>julian.reschke@greenbytes.de</email>
155      <uri>http://greenbytes.de/tech/webdav/</uri>
156    </address>
157  </author>
158
159  <date month="October" year="2011" day="31"/>
160  <workgroup>HTTPbis Working Group</workgroup>
161
162<abstract>
163<t>
164   The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
165   distributed, collaborative, hypermedia information systems. HTTP has been in
166   use by the World Wide Web global information initiative since 1990. This
167   document is Part 7 of the seven-part specification that defines the protocol
168   referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616.
169</t>
170<t>
171   Part 7 defines the HTTP Authentication framework.
172</t>
173</abstract>
174
175<note title="Editorial Note (To be removed by RFC Editor)">
176  <t>
177    Discussion of this draft should take place on the HTTPBIS working group
178    mailing list (ietf-http-wg@w3.org), which is archived at
179    <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
180  </t>
181  <t>
182    The current issues list is at
183    <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related
184    documents (including fancy diffs) can be found at
185    <eref target="http://tools.ietf.org/wg/httpbis/"/>.
186  </t>
187  <t>
188    The changes in this draft are summarized in <xref target="changes.since.16"/>.
189  </t>
190</note>
191</front>
192<middle>
193<section title="Introduction" anchor="introduction">
194<t>
195   This document defines HTTP/1.1 access control and authentication. It
196   includes the relevant parts of RFC 2616
197   with only minor changes, plus the general framework for HTTP authentication,
198   as previously defined in "HTTP Authentication: Basic and Digest Access
199   Authentication" (<xref target="RFC2617"/>).
200</t>
201<t>
202   HTTP provides several OPTIONAL challenge-response authentication
203   mechanisms which can be used by a server to challenge a client request and
204   by a client to provide authentication information. The "basic" and "digest"
205   authentication schemes continue to be specified in
206   RFC 2617.
207</t>
208
209<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
210<t>
211   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
212   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
213   document are to be interpreted as described in <xref target="RFC2119"/>.
214</t>
215<t>
216   This document defines conformance criteria for several roles in HTTP
217   communication, including Senders, Recipients, Clients, Servers, User-Agents,
218   Origin Servers, Intermediaries, Proxies and Gateways. See Section 2 of <xref target="Part1"/>
219   for definitions of these terms.
220</t>
221<t>
222   An implementation is considered conformant if it complies with all of the
223   requirements associated with its role(s). Note that SHOULD-level requirements
224   are relevant here, unless one of the documented exceptions is applicable.
225</t>
226<t>
227   This document also uses ABNF to define valid protocol elements
228   (<xref target="notation"/>). In addition to the prose requirements placed
229   upon them, Senders MUST NOT generate protocol elements that are invalid.
230</t>
231<t>
232   Unless noted otherwise, Recipients MAY take steps to recover a usable
233   protocol element from an invalid construct. However, HTTP does not define
234   specific error handling mechanisms, except in cases where it has direct
235   impact on security. This is because different uses of the protocol require
236   different error handling strategies; for example, a Web browser may wish to
237   transparently recover from a response where the Location header field
238   doesn't parse according to the ABNF, whereby in a systems control protocol
239   using HTTP, this type of error recovery could lead to dangerous consequences.
240</t>
241</section>
242
243<section title="Syntax Notation" anchor="notation">
244 
245 
246 
247 
248 
249 
250 
251<t>
252  This specification uses the ABNF syntax defined in Section 1.2 of <xref target="Part1"/> (which
253  extends the syntax defined in <xref target="RFC5234"/> with a list rule).
254  <xref target="collected.abnf"/> shows the collected ABNF, with the list
255  rule expanded.
256</t>
257<t>
258  The following core rules are included by
259  reference, as defined in <xref target="RFC5234"/>, Appendix B.1:
260  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
261  DIGIT (decimal 0-9), DQUOTE (double quote),
262  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
263  OCTET (any 8-bit sequence of data), SP (space), and
264  VCHAR (any visible US-ASCII character).
265</t>
266
267<section title="Core Rules" anchor="core.rules">
268   
269   
270   
271   
272<t>
273   The core rules below are defined in <xref target="Part1"/>:
274</t>
275<figure><artwork type="abnf2616"><![CDATA[
276  BWS           = <BWS, defined in [Part1], Section 1.2.2>
277  OWS           = <OWS, defined in [Part1], Section 1.2.2>
278  quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
279  token         = <token, defined in [Part1], Section 3.2.3>
280]]></artwork></figure>
281</section>
282</section>
283</section>
284
285<section title="Access Authentication Framework" anchor="access.authentication.framework">
286
287<section title="Challenge and Response" anchor="challenge.and.response">
288 
289 
290 
291 
292 
293<t>
294   HTTP provides a simple challenge-response authentication mechanism
295   that can be used by a server to challenge a client request and by a
296   client to provide authentication information. It uses an extensible,
297   case-insensitive token to identify the authentication scheme, followed
298   by additional information necessary for achieving authentication via that
299   scheme. The latter can either be a comma-separated list of attribute-value
300   pairs or a single sequence of characters capable of holding base64-encoded
301   information.
302</t>
303<figure><iref item="auth-scheme" primary="true"/><iref item="auth-param" primary="true"/><iref primary="true" item="Grammar" subitem="auth-scheme"/><iref primary="true" item="Grammar" subitem="auth-param"/><iref item="b64token" primary="true"/><iref primary="true" item="Grammar" subitem="b64token"/><artwork type="abnf2616"><![CDATA[
304  auth-scheme    = token
305 
306  auth-param     = token BWS "=" BWS ( token / quoted-string )
307
308  b64token       = 1*( ALPHA / DIGIT /
309                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
310]]></artwork></figure>
311<t>
312   The "b64token" syntax allows the 66 unreserved URI characters (<xref target="RFC3986"/>),
313   plus a few others, so that it can hold a base64, base64url (URL and filename
314   safe alphabet), base32, or base16 (hex) encoding, with or without padding, but
315   excluding whitespace (<xref target="RFC4648"/>).
316</t>
317<t>
318   The 401 (Unauthorized) response message is used by an origin server
319   to challenge the authorization of a user agent. This response MUST
320   include a WWW-Authenticate header field containing at least one
321   challenge applicable to the requested resource.
322</t>
323<t>   
324   The 407 (Proxy Authentication Required) response message is used by a proxy to
325   challenge the authorization of a client and MUST include a Proxy-Authenticate
326   header field containing at least one challenge
327   applicable to the proxy for the requested resource.
328</t>
329<figure><iref item="challenge" primary="true"/><iref primary="true" item="Grammar" subitem="challenge"/><artwork type="abnf2616"><![CDATA[
330  challenge   = auth-scheme [ 1*SP ( b64token / #auth-param ) ]
331]]></artwork></figure>
332<t><list>
333  <t>
334     Note: User agents will need to take special care in parsing the
335     WWW-Authenticate and Proxy-Authenticate header field values because they
336     can contain more than one challenge, or if more than one of each is
337     provided, since the contents of a challenge can itself contain a
338     comma-separated list of authentication parameters.
339  </t>
340</list></t>
341<t><list>
342  <t>
343     Note: Many browsers fail to parse challenges containing unknown
344     schemes. A workaround for this problem is to list well-supported schemes
345     (such as "basic") first.<!-- see http://greenbytes.de/tech/tc/httpauth/#multibasicunknown2 -->
346  </t>
347</list></t>
348<t>
349   A user agent that wishes to authenticate itself with an origin server
350   — usually, but not necessarily, after receiving a 401 (Unauthorized)
351   — MAY do so by including an Authorization header field with the
352   request.
353</t>
354<t>   
355   A client that wishes to authenticate itself with a proxy — usually,
356   but not necessarily, after receiving a 407 (Proxy Authentication Required)
357   — MAY do so by including a Proxy-Authorization header field with the
358   request.
359</t>
360<t>   
361   Both the Authorization field value and the Proxy-Authorization field value
362   consist of credentials containing the authentication information of the
363   client for the realm of the resource being requested. The user agent MUST
364   choose to use one of the challenges with the strongest auth-scheme it
365   understands and request credentials from the user based upon that challenge.
366</t>
367<figure><iref item="credentials" primary="true"/><iref primary="true" item="Grammar" subitem="credentials"/><artwork type="abnf2616"><![CDATA[
368  credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ]
369]]></artwork></figure>
370<t>
371   If the origin server does not wish to accept the credentials sent
372   with a request, it SHOULD return a 401 (Unauthorized) response. The
373   response MUST include a WWW-Authenticate header field containing at
374   least one (possibly new) challenge applicable to the requested
375   resource.
376</t>
377<t>
378   If a proxy does not accept the credentials sent with a
379   request, it SHOULD return a 407 (Proxy Authentication Required). The
380   response MUST include a Proxy-Authenticate header field containing a
381   (possibly new) challenge applicable to the proxy for the requested
382   resource.
383</t>
384<t>
385   The HTTP protocol does not restrict applications to this simple
386   challenge-response mechanism for access authentication. Additional
387   mechanisms MAY be used, such as encryption at the transport level or
388   via message encapsulation, and with additional header fields
389   specifying authentication information. However, such additional
390   mechanisms are not defined by this specification.
391</t>
392<t>
393   Proxies MUST forward the WWW-Authenticate and Authorization headers
394   unmodified and follow the rules found in <xref target="header.authorization"/>.
395</t>
396</section>
397
398<section title="Protection Space (Realm)" anchor="protection.space">
399  <iref item="Protection Space"/>
400  <iref item="Realm"/>
401<t>
402   The authentication parameter realm is reserved for use by authentication
403   schemes that wish to indicate the scope of protection:
404</t>
405<figure><iref item="realm" primary="true"/><iref item="realm-value" primary="true"/><iref primary="true" item="Grammar" subitem="realm"/><artwork type="abnf2616"><![CDATA[
406  realm       = "realm" BWS "=" BWS realm-value
407  realm-value = quoted-string
408]]></artwork></figure>
409<t>
410   A protection space is defined by the canonical root URI (the
411   scheme and authority components of the effective request URI; see
412   Section 4.3 of <xref target="Part1"/>) of the
413   server being accessed, in combination with the realm value if present.
414   These realms allow the protected resources on a server to be
415   partitioned into a set of protection spaces, each with its own
416   authentication scheme and/or authorization database. The realm value
417   is a string, generally assigned by the origin server, which can have
418   additional semantics specific to the authentication scheme. Note that
419   there can be multiple challenges with the same auth-scheme but
420   different realms.
421</t>
422<t>
423   The protection space determines the domain over which credentials can
424   be automatically applied. If a prior request has been authorized, the
425   same credentials MAY be reused for all other requests within that
426   protection space for a period of time determined by the
427   authentication scheme, parameters, and/or user preference. Unless
428   otherwise defined by the authentication scheme, a single protection
429   space cannot extend outside the scope of its server.
430</t>
431</section>
432
433<section title="Authentication Scheme Registry" anchor="authentication.scheme.registry">
434<t>
435  The HTTP Authentication Scheme Registry defines the name space for the
436  authentication schemes in challenges and credentials.
437</t>
438<t>
439  Registrations MUST include the following fields:
440  <list style="symbols">
441    <t>Authentication Scheme Name</t>
442    <t>Pointer to specification text</t>
443    <t>Notes (optional)</t>
444  </list>
445</t>
446<t>
447  Values to be added to this name space are subject to IETF review
448  (<xref target="RFC5226"/>, Section 4.1).
449</t>
450<t>
451  The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-authschemes"/>.
452</t>
453
454<section title="Considerations for New Authentication Schemes" anchor="considerations.for.new.authentication.schemes">
455<t>
456  There are certain aspects of the HTTP Authentication Framework that put
457  constraints on how new authentication schemes can work:
458</t>
459<t>
460  <list style="symbols">
461    <t>
462      Authentication schemes need to be compatible with the inherent
463      constraints of HTTP; for instance, that messages need to keep their
464      semantics when inspected in isolation, thus an authentication scheme
465      can not bind information to the TCP session over which the message
466      was received (see Section 2.2 of <xref target="Part1"/>).
467    </t>
468    <t>
469      The authentication parameter "realm" is reserved for defining Protection
470      Spaces as defined in <xref target="protection.space"/>. New schemes
471      MUST NOT use it in a way incompatible with that definition.
472    </t>
473    <t>
474      The "b64token" notation was introduced for compatibility with existing
475      authentication schemes and can only be used once per challenge/credentials.
476      New schemes thus ought to use the "auth-param" syntax instead, because
477      otherwise future extensions will be impossible.
478    </t>
479    <t>
480      The parsing of challenges and credentials is defined by this specification,
481      and cannot be modified by new authentication schemes. When the auth-param
482      syntax is used, all parameters ought to support both token and
483      quoted-string syntax, and syntactical constraints ought to be defined on
484      the field value after parsing (i.e., quoted-string processing). This is
485      necessary so that recipients can use a generic parser that applies to
486      all authentication schemes.
487    <vspace blankLines="1"/>
488      Note: the fact that the value syntax for the "realm" parameter
489      is restricted to quoted-string was a bad design choice not to be repeated
490      for new parameters.
491    </t>
492    <t>
493      Authentication schemes need to document whether they are usable in
494      origin-server authentication (i.e., using WWW-Authenticate), and/or
495      proxy authentication (i.e., using Proxy-Authenticate).
496    </t>
497    <t>
498      The credentials carried in an Authorization header field are specific to
499      the User Agent, and therefore have the same effect on HTTP caches as the
500      "private" Cache-Control response directive, within the scope of the
501      request they appear in.
502    <vspace blankLines="1"/>
503      Therefore, new authentication schemes which choose not to carry
504      credentials in the Authorization header (e.g., using a newly defined
505      header) will need to explicitly disallow caching, by mandating the use of
506      either Cache-Control request directives (e.g., "no-store") or response
507      directives (e.g., "private").
508    </t>
509  </list>
510</t>
511</section>
512
513</section>
514
515</section>
516
517<section title="Status Code Definitions" anchor="status.code.definitions">
518<section title="401 Unauthorized" anchor="status.401">
519  <iref primary="true" item="401 Unauthorized (status code)"/>
520  <iref primary="true" item="Status Codes" subitem="401 Unauthorized"/>
521<t>
522   The request requires user authentication. The response MUST include a
523   WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge
524   applicable to the target resource. The client MAY repeat the
525   request with a suitable Authorization header field (<xref target="header.authorization"/>). If
526   the request already included Authorization credentials, then the 401
527   response indicates that authorization has been refused for those
528   credentials. If the 401 response contains the same challenge as the
529   prior response, and the user agent has already attempted
530   authentication at least once, then the user SHOULD be presented the
531   representation that was given in the response, since that representation might
532   include relevant diagnostic information.
533</t>
534</section>
535<section title="407 Proxy Authentication Required" anchor="status.407">
536  <iref primary="true" item="407 Proxy Authentication Required (status code)"/>
537  <iref primary="true" item="Status Codes" subitem="407 Proxy Authentication Required"/>
538<t>
539   This code is similar to 401 (Unauthorized), but indicates that the
540   client ought to first authenticate itself with the proxy. The proxy MUST
541   return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a
542   challenge applicable to the proxy for the target resource. The
543   client MAY repeat the request with a suitable Proxy-Authorization
544   header field (<xref target="header.proxy-authorization"/>).
545</t>
546</section>
547</section>
548
549<section title="Header Field Definitions" anchor="header.field.definitions">
550<t>
551   This section defines the syntax and semantics of HTTP/1.1 header fields
552   related to authentication.
553</t>
554
555<section title="Authorization" anchor="header.authorization">
556  <iref primary="true" item="Authorization header field"/>
557  <iref primary="true" item="Header Fields" subitem="Authorization"/>
558 
559<t>
560   The "Authorization" header field allows a user agent to authenticate
561   itself with a server — usually, but not necessarily, after receiving a 401
562   (Unauthorized) response. Its value consists of credentials containing
563   information of the user agent for the realm of the resource being
564   requested.
565</t>
566<figure><iref primary="true" item="Grammar" subitem="Authorization"/><artwork type="abnf2616"><![CDATA[
567  Authorization = credentials
568]]></artwork></figure>
569<t>
570   If a request is
571   authenticated and a realm specified, the same credentials SHOULD
572   be valid for all other requests within this realm (assuming that
573   the authentication scheme itself does not require otherwise, such
574   as credentials that vary according to a challenge value or using
575   synchronized clocks).
576</t>
577<t>
578      When a shared cache (see Section 1.2 of <xref target="Part6"/>) receives a request
579      containing an Authorization field, it MUST NOT return the
580      corresponding response as a reply to any other request, unless one
581      of the following specific exceptions holds:
582</t>
583<t>
584  <list style="numbers">
585      <t>If the response includes the "s-maxage" cache-control
586         directive, the cache MAY use that response in replying to a
587         subsequent request. But (if the specified maximum age has
588         passed) a proxy cache MUST first revalidate it with the origin
589         server, using the header fields from the new request to allow
590         the origin server to authenticate the new request. (This is the
591         defined behavior for s-maxage.) If the response includes "s-maxage=0",
592         the proxy MUST always revalidate it before re-using
593         it.</t>
594
595      <t>If the response includes the "must-revalidate" cache-control
596         directive, the cache MAY use that response in replying to a
597         subsequent request. But if the response is stale, all caches
598         MUST first revalidate it with the origin server, using the
599         header fields from the new request to allow the origin server
600         to authenticate the new request.</t>
601
602      <t>If the response includes the "public" cache-control directive,
603         it MAY be returned in reply to any subsequent request.</t>
604  </list>
605</t>
606</section>
607
608<section title="Proxy-Authenticate" anchor="header.proxy-authenticate">
609  <iref primary="true" item="Proxy-Authenticate header field"/>
610  <iref primary="true" item="Header Fields" subitem="Proxy-Authenticate"/>
611 
612<t>
613   The "Proxy-Authenticate" header field consists of a challenge that
614   indicates the authentication scheme and parameters applicable to the proxy
615   for this effective request URI (Section 4.3 of <xref target="Part1"/>). It MUST be included as part
616   of a 407 (Proxy Authentication Required) response.
617</t>
618<figure><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/><artwork type="abnf2616"><![CDATA[
619  Proxy-Authenticate = 1#challenge
620]]></artwork></figure>
621<t>
622   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to
623   the current connection and SHOULD NOT  be passed on to downstream
624   clients. However, an intermediate proxy might need to obtain its own
625   credentials by requesting them from the downstream client, which in
626   some circumstances will appear as if the proxy is forwarding the
627   Proxy-Authenticate header field.
628</t>
629</section>
630
631<section title="Proxy-Authorization" anchor="header.proxy-authorization">
632  <iref primary="true" item="Proxy-Authorization header field"/>
633  <iref primary="true" item="Header Fields" subitem="Proxy-Authorization"/>
634 
635<t>
636   The "Proxy-Authorization" header field allows the client to
637   identify itself (or its user) to a proxy which requires
638   authentication. Its value consists of
639   credentials containing the authentication information of the user
640   agent for the proxy and/or realm of the resource being requested.
641</t>
642<figure><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/><artwork type="abnf2616"><![CDATA[
643  Proxy-Authorization = credentials
644]]></artwork></figure>
645<t>
646   Unlike Authorization, the Proxy-Authorization header field applies only to
647   the next outbound proxy that demanded authentication using the Proxy-Authenticate
648   field. When multiple proxies are used in a chain, the
649   Proxy-Authorization header field is consumed by the first outbound
650   proxy that was expecting to receive credentials. A proxy MAY relay
651   the credentials from the client request to the next proxy if that is
652   the mechanism by which the proxies cooperatively authenticate a given
653   request.
654</t>
655</section>
656
657<section title="WWW-Authenticate" anchor="header.www-authenticate">
658  <iref primary="true" item="WWW-Authenticate header field"/>
659  <iref primary="true" item="Header Fields" subitem="WWW-Authenticate"/>
660 
661<t>
662   The "WWW-Authenticate" header field consists of at least one
663   challenge that indicates the authentication scheme(s) and parameters
664   applicable to the effective request URI (Section 4.3 of <xref target="Part1"/>).
665</t>
666<t>   
667   It MUST be included in 401 (Unauthorized) response messages and MAY be
668   included in other response messages to indicate that supplying credentials
669   (or different credentials) might affect the response.
670</t>
671<figure><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/><artwork type="abnf2616"><![CDATA[
672  WWW-Authenticate = 1#challenge
673]]></artwork></figure>
674<t>
675   User agents are advised to take special care in parsing the WWW-Authenticate
676   field value as it might contain more than one challenge,
677   or if more than one WWW-Authenticate header field is provided, the
678   contents of a challenge itself can contain a comma-separated list of
679   authentication parameters.
680</t>
681<figure>
682  <preamble>For instance:</preamble>
683  <artwork type="example"><![CDATA[
684  WWW-Authenticate: Newauth realm="apps", type=1,
685                    title="Login to \"apps\"", Basic realm="simple"
686]]></artwork>
687  <postamble>
688  This header field contains two challenges; one for the "Newauth" scheme
689  with a realm value of "apps", and two additional parameters "type" and
690  "title", and another one for the "Basic" scheme with a realm value of "simple".
691</postamble></figure>
692</section>
693
694</section>
695
696<section title="IANA Considerations" anchor="IANA.considerations">
697
698<section title="Authenticaton Scheme Registry" anchor="authentication.scheme.registration">
699<t>
700  The registration procedure for HTTP Authentication Schemes is defined by
701  <xref target="authentication.scheme.registry"/> of this document.
702</t>
703<t>
704   The HTTP Method Authentication Scheme shall be created at <eref target="http://www.iana.org/assignments/http-authschemes"/>.
705</t>
706</section>
707
708<section title="Status Code Registration" anchor="status.code.registration">
709<t>
710   The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/>
711   shall be updated with the registrations below:
712</t>
713
714<!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually-->
715<texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table">
716   <ttcol>Value</ttcol>
717   <ttcol>Description</ttcol>
718   <ttcol>Reference</ttcol>
719   <c>401</c>
720   <c>Unauthorized</c>
721   <c>
722      <xref target="status.401"/>
723   </c>
724   <c>407</c>
725   <c>Proxy Authentication Required</c>
726   <c>
727      <xref target="status.407"/>
728   </c>
729</texttable>
730<!--(END)-->
731
732</section>
733
734<section title="Header Field Registration" anchor="header.field.registration">
735<t>
736   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
737   with the permanent registrations below (see <xref target="RFC3864"/>):
738</t>
739
740<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
741<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
742   <ttcol>Header Field Name</ttcol>
743   <ttcol>Protocol</ttcol>
744   <ttcol>Status</ttcol>
745   <ttcol>Reference</ttcol>
746
747   <c>Authorization</c>
748   <c>http</c>
749   <c>standard</c>
750   <c>
751      <xref target="header.authorization"/>
752   </c>
753   <c>Proxy-Authenticate</c>
754   <c>http</c>
755   <c>standard</c>
756   <c>
757      <xref target="header.proxy-authenticate"/>
758   </c>
759   <c>Proxy-Authorization</c>
760   <c>http</c>
761   <c>standard</c>
762   <c>
763      <xref target="header.proxy-authorization"/>
764   </c>
765   <c>WWW-Authenticate</c>
766   <c>http</c>
767   <c>standard</c>
768   <c>
769      <xref target="header.www-authenticate"/>
770   </c>
771</texttable>
772<!--(END)-->
773
774<t>
775   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
776</t>
777</section>
778</section>
779
780<section title="Security Considerations" anchor="security.considerations">
781<t>
782   This section is meant to inform application developers, information
783   providers, and users of the security limitations in HTTP/1.1 as
784   described by this document. The discussion does not include
785   definitive solutions to the problems revealed, though it does make
786   some suggestions for reducing security risks.
787</t>
788
789<section title="Authentication Credentials and Idle Clients" anchor="auth.credentials.and.idle.clients">
790<t>
791   Existing HTTP clients and user agents typically retain authentication
792   information indefinitely. HTTP/1.1 does not provide a method for a
793   server to direct clients to discard these cached credentials. This is
794   a significant defect that requires further extensions to HTTP.
795   Circumstances under which credential caching can interfere with the
796   application's security model include but are not limited to:
797  <list style="symbols">
798     <t>Clients which have been idle for an extended period following
799        which the server might wish to cause the client to reprompt the
800        user for credentials.</t>
801
802     <t>Applications which include a session termination indication
803        (such as a "logout" or "commit" button on a page) after which
804        the server side of the application "knows" that there is no
805        further reason for the client to retain the credentials.</t>
806  </list>
807</t>
808<t>
809   This is currently under separate study. There are a number of work-arounds
810   to parts of this problem, and we encourage the use of
811   password protection in screen savers, idle time-outs, and other
812   methods which mitigate the security problems inherent in this
813   problem. In particular, user agents which cache credentials are
814   encouraged to provide a readily accessible mechanism for discarding
815   cached credentials under user control.
816</t>
817</section>
818</section>
819
820<section title="Acknowledgments" anchor="acks">
821<t>
822  This specification takes over the definition of the HTTP Authentication
823  Framework, previously defined in RFC 2617.
824  We thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence,
825  Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work
826  on that specification. See Section 6 of <xref target="RFC2617"/>
827  for further acknowledgements. 
828</t>
829<t>
830  See Section 11 of <xref target="Part1"/> for the Acknowledgments related to this document revision.
831</t>
832</section>
833</middle>
834
835<back>
836
837<references title="Normative References">
838
839<reference anchor="Part1">
840  <front>
841    <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
842    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
843      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
844      <address><email>fielding@gbiv.com</email></address>
845    </author>
846    <author initials="J." surname="Gettys" fullname="Jim Gettys">
847      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
848      <address><email>jg@freedesktop.org</email></address>
849    </author>
850    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
851      <organization abbrev="HP">Hewlett-Packard Company</organization>
852      <address><email>JeffMogul@acm.org</email></address>
853    </author>
854    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
855      <organization abbrev="Microsoft">Microsoft Corporation</organization>
856      <address><email>henrikn@microsoft.com</email></address>
857    </author>
858    <author initials="L." surname="Masinter" fullname="Larry Masinter">
859      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
860      <address><email>LMM@acm.org</email></address>
861    </author>
862    <author initials="P." surname="Leach" fullname="Paul J. Leach">
863      <organization abbrev="Microsoft">Microsoft Corporation</organization>
864      <address><email>paulle@microsoft.com</email></address>
865    </author>
866    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
867      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
868      <address><email>timbl@w3.org</email></address>
869    </author>
870    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
871      <organization abbrev="W3C">World Wide Web Consortium</organization>
872      <address><email>ylafon@w3.org</email></address>
873    </author>
874    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
875      <organization abbrev="greenbytes">greenbytes GmbH</organization>
876      <address><email>julian.reschke@greenbytes.de</email></address>
877    </author>
878    <date month="October" year="2011"/>
879  </front>
880  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-17"/>
881 
882</reference>
883
884<reference anchor="Part6">
885  <front>
886    <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
887    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
888      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
889      <address><email>fielding@gbiv.com</email></address>
890    </author>
891    <author initials="J." surname="Gettys" fullname="Jim Gettys">
892      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
893      <address><email>jg@freedesktop.org</email></address>
894    </author>
895    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
896      <organization abbrev="HP">Hewlett-Packard Company</organization>
897      <address><email>JeffMogul@acm.org</email></address>
898    </author>
899    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
900      <organization abbrev="Microsoft">Microsoft Corporation</organization>
901      <address><email>henrikn@microsoft.com</email></address>
902    </author>
903    <author initials="L." surname="Masinter" fullname="Larry Masinter">
904      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
905      <address><email>LMM@acm.org</email></address>
906    </author>
907    <author initials="P." surname="Leach" fullname="Paul J. Leach">
908      <organization abbrev="Microsoft">Microsoft Corporation</organization>
909      <address><email>paulle@microsoft.com</email></address>
910    </author>
911    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
912      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
913      <address><email>timbl@w3.org</email></address>
914    </author>
915    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
916      <organization abbrev="W3C">World Wide Web Consortium</organization>
917      <address><email>ylafon@w3.org</email></address>
918    </author>
919    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
920      <organization>Rackspace</organization>
921      <address><email>mnot@mnot.net</email></address>
922    </author>
923    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
924      <organization abbrev="greenbytes">greenbytes GmbH</organization>
925      <address><email>julian.reschke@greenbytes.de</email></address>
926    </author>
927    <date month="October" year="2011"/>
928  </front>
929  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-17"/>
930 
931</reference>
932
933<reference anchor="RFC2119">
934  <front>
935    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
936    <author initials="S." surname="Bradner" fullname="Scott Bradner">
937      <organization>Harvard University</organization>
938      <address><email>sob@harvard.edu</email></address>
939    </author>
940    <date month="March" year="1997"/>
941  </front>
942  <seriesInfo name="BCP" value="14"/>
943  <seriesInfo name="RFC" value="2119"/>
944</reference>
945
946<reference anchor="RFC5234">
947  <front>
948    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
949    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
950      <organization>Brandenburg InternetWorking</organization>
951      <address>
952        <email>dcrocker@bbiw.net</email>
953      </address> 
954    </author>
955    <author initials="P." surname="Overell" fullname="Paul Overell">
956      <organization>THUS plc.</organization>
957      <address>
958        <email>paul.overell@thus.net</email>
959      </address>
960    </author>
961    <date month="January" year="2008"/>
962  </front>
963  <seriesInfo name="STD" value="68"/>
964  <seriesInfo name="RFC" value="5234"/>
965</reference>
966
967</references>
968
969<references title="Informative References">
970
971<reference anchor="RFC2616">
972  <front>
973    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
974    <author initials="R." surname="Fielding" fullname="R. Fielding">
975      <organization>University of California, Irvine</organization>
976      <address><email>fielding@ics.uci.edu</email></address>
977    </author>
978    <author initials="J." surname="Gettys" fullname="J. Gettys">
979      <organization>W3C</organization>
980      <address><email>jg@w3.org</email></address>
981    </author>
982    <author initials="J." surname="Mogul" fullname="J. Mogul">
983      <organization>Compaq Computer Corporation</organization>
984      <address><email>mogul@wrl.dec.com</email></address>
985    </author>
986    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
987      <organization>MIT Laboratory for Computer Science</organization>
988      <address><email>frystyk@w3.org</email></address>
989    </author>
990    <author initials="L." surname="Masinter" fullname="L. Masinter">
991      <organization>Xerox Corporation</organization>
992      <address><email>masinter@parc.xerox.com</email></address>
993    </author>
994    <author initials="P." surname="Leach" fullname="P. Leach">
995      <organization>Microsoft Corporation</organization>
996      <address><email>paulle@microsoft.com</email></address>
997    </author>
998    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
999      <organization>W3C</organization>
1000      <address><email>timbl@w3.org</email></address>
1001    </author>
1002    <date month="June" year="1999"/>
1003  </front>
1004  <seriesInfo name="RFC" value="2616"/>
1005</reference>
1006
1007<reference anchor="RFC2617">
1008  <front>
1009    <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
1010    <author initials="J." surname="Franks" fullname="John Franks">
1011      <organization>Northwestern University, Department of Mathematics</organization>
1012      <address><email>john@math.nwu.edu</email></address>
1013    </author>
1014    <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
1015      <organization>Verisign Inc.</organization>
1016      <address><email>pbaker@verisign.com</email></address>
1017    </author>
1018    <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
1019      <organization>AbiSource, Inc.</organization>
1020      <address><email>jeff@AbiSource.com</email></address>
1021    </author>
1022    <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
1023      <organization>Agranat Systems, Inc.</organization>
1024      <address><email>lawrence@agranat.com</email></address>
1025    </author>
1026    <author initials="P.J." surname="Leach" fullname="Paul J. Leach">
1027      <organization>Microsoft Corporation</organization>
1028      <address><email>paulle@microsoft.com</email></address>
1029    </author>
1030    <author initials="A." surname="Luotonen" fullname="Ari Luotonen">
1031      <organization>Netscape Communications Corporation</organization>
1032    </author>
1033    <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
1034      <organization>Open Market, Inc.</organization>
1035      <address><email>stewart@OpenMarket.com</email></address>
1036    </author>
1037    <date month="June" year="1999"/>
1038  </front>
1039  <seriesInfo name="RFC" value="2617"/>
1040</reference>
1041
1042<reference anchor="RFC3864">
1043  <front>
1044    <title>Registration Procedures for Message Header Fields</title>
1045    <author initials="G." surname="Klyne" fullname="G. Klyne">
1046      <organization>Nine by Nine</organization>
1047      <address><email>GK-IETF@ninebynine.org</email></address>
1048    </author>
1049    <author initials="M." surname="Nottingham" fullname="M. Nottingham">
1050      <organization>BEA Systems</organization>
1051      <address><email>mnot@pobox.com</email></address>
1052    </author>
1053    <author initials="J." surname="Mogul" fullname="J. Mogul">
1054      <organization>HP Labs</organization>
1055      <address><email>JeffMogul@acm.org</email></address>
1056    </author>
1057    <date year="2004" month="September"/>
1058  </front>
1059  <seriesInfo name="BCP" value="90"/>
1060  <seriesInfo name="RFC" value="3864"/>
1061</reference>
1062
1063<reference anchor="RFC3986">
1064 <front>
1065  <title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
1066  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1067    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1068    <address>
1069       <email>timbl@w3.org</email>
1070       <uri>http://www.w3.org/People/Berners-Lee/</uri>
1071    </address>
1072  </author>
1073  <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
1074    <organization abbrev="Day Software">Day Software</organization>
1075    <address>
1076      <email>fielding@gbiv.com</email>
1077      <uri>http://roy.gbiv.com/</uri>
1078    </address>
1079  </author>
1080  <author initials="L." surname="Masinter" fullname="Larry Masinter">
1081    <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
1082    <address>
1083      <email>LMM@acm.org</email>
1084      <uri>http://larry.masinter.net/</uri>
1085    </address>
1086  </author>
1087  <date month="January" year="2005"/>
1088 </front>
1089 <seriesInfo name="STD" value="66"/>
1090 <seriesInfo name="RFC" value="3986"/>
1091</reference>
1092
1093<reference anchor="RFC4648">
1094  <front>
1095    <title>The Base16, Base32, and Base64 Data Encodings</title>
1096    <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
1097    <date year="2006" month="October"/>
1098  </front>
1099  <seriesInfo value="4648" name="RFC"/>
1100</reference>
1101
1102<reference anchor="RFC5226">
1103  <front>
1104    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
1105    <author initials="T." surname="Narten" fullname="T. Narten">
1106      <organization>IBM</organization>
1107      <address><email>narten@us.ibm.com</email></address>
1108    </author>
1109    <author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
1110      <organization>Google</organization>
1111      <address><email>Harald@Alvestrand.no</email></address>
1112    </author>
1113    <date year="2008" month="May"/>
1114  </front>
1115  <seriesInfo name="BCP" value="26"/>
1116  <seriesInfo name="RFC" value="5226"/>
1117</reference>
1118
1119</references>
1120
1121<section title="Changes from RFCs 2616 and 2617" anchor="changes.from.rfc.2616">
1122<t>
1123  The "realm" parameter isn't required anymore in general; consequently, the
1124  ABNF allows challenges without any auth parameters.
1125  (<xref target="access.authentication.framework"/>)
1126</t>
1127<t>
1128  The "b64token" alternative to auth-param lists has been added for consistency
1129  with legacy authentication schemes such as "Basic".
1130  (<xref target="access.authentication.framework"/>)
1131</t>
1132<t>
1133  Change ABNF productions for header fields to only define the field value.
1134  (<xref target="header.field.definitions"/>)
1135</t>
1136</section>
1137 
1138
1139<section title="Collected ABNF" anchor="collected.abnf">
1140<figure>
1141<artwork type="abnf" name="p7-auth.parsed-abnf"><![CDATA[
1142Authorization = credentials
1143
1144BWS = <BWS, defined in [Part1], Section 1.2.2>
1145
1146OWS = <OWS, defined in [Part1], Section 1.2.2>
1147
1148Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
1149 challenge ] )
1150Proxy-Authorization = credentials
1151
1152WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
1153 ] )
1154
1155auth-param = token BWS "=" BWS ( token / quoted-string )
1156auth-scheme = token
1157
1158b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
1159 *"="
1160
1161challenge = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) *(
1162 OWS "," [ OWS auth-param ] ) ] ) ]
1163credentials = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param )
1164 *( OWS "," [ OWS auth-param ] ) ] ) ]
1165
1166quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
1167
1168realm = "realm" BWS "=" BWS realm-value
1169realm-value = quoted-string
1170
1171token = <token, defined in [Part1], Section 3.2.3>
1172]]></artwork>
1173</figure>
1174<figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"><![CDATA[
1175; Authorization defined but not used
1176; Proxy-Authenticate defined but not used
1177; Proxy-Authorization defined but not used
1178; WWW-Authenticate defined but not used
1179; realm defined but not used
1180]]></artwork></figure></section>
1181
1182
1183<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
1184
1185<section title="Since RFC 2616">
1186<t>
1187  Extracted relevant partitions from <xref target="RFC2616"/>.
1188</t>
1189</section>
1190
1191<section title="Since draft-ietf-httpbis-p7-auth-00">
1192<t>
1193  Closed issues:
1194  <list style="symbols"> 
1195    <t>
1196      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>:
1197      "Normative and Informative references"
1198    </t>
1199  </list>
1200</t>
1201</section>
1202
1203<section title="Since draft-ietf-httpbis-p7-auth-01">
1204<t>
1205  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
1206  <list style="symbols"> 
1207    <t>
1208      Explicitly import BNF rules for "challenge" and "credentials" from RFC2617.
1209    </t>
1210    <t>
1211      Add explicit references to BNF syntax and rules imported from other parts of the specification.
1212    </t>
1213  </list>
1214</t>
1215</section>
1216
1217<section title="Since draft-ietf-httpbis-p7-auth-02" anchor="changes.since.02">
1218<t>
1219  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
1220  <list style="symbols"> 
1221    <t>
1222      Reference RFC 3984, and update header field registrations for header fields defined
1223      in this document.
1224    </t>
1225  </list>
1226</t>
1227</section>
1228
1229<section title="Since draft-ietf-httpbis-p7-auth-03" anchor="changes.since.03">
1230<t>
1231  None.
1232</t>
1233</section>
1234
1235<section title="Since draft-ietf-httpbis-p7-auth-04" anchor="changes.since.04">
1236<t>
1237  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
1238  <list style="symbols"> 
1239    <t>
1240      Use "/" instead of "|" for alternatives.
1241    </t>
1242    <t>
1243      Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
1244      whitespace ("OWS") and required whitespace ("RWS").
1245    </t>
1246    <t>
1247      Rewrite ABNFs to spell out whitespace rules, factor out
1248      header field value format definitions.
1249    </t>
1250  </list>
1251</t>
1252</section>
1253
1254<section title="Since draft-ietf-httpbis-p7-auth-05" anchor="changes.since.05">
1255<t>
1256  Final work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
1257  <list style="symbols"> 
1258    <t>
1259      Add appendix containing collected and expanded ABNF, reorganize ABNF introduction.
1260    </t>
1261  </list>
1262</t>
1263</section>
1264
1265<section title="Since draft-ietf-httpbis-p7-auth-06" anchor="changes.since.06">
1266<t>
1267  None.
1268</t>
1269</section>
1270
1271<section title="Since draft-ietf-httpbis-p7-auth-07" anchor="changes.since.07">
1272<t>
1273  Closed issues:
1274  <list style="symbols"> 
1275    <t>
1276      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/198"/>:
1277      "move IANA registrations for optional status codes"
1278    </t>
1279  </list>
1280</t>
1281</section>
1282
1283<section title="Since draft-ietf-httpbis-p7-auth-08" anchor="changes.since.08">
1284<t>
1285  No significant changes.
1286</t>
1287</section>
1288
1289<section title="Since draft-ietf-httpbis-p7-auth-09" anchor="changes.since.09">
1290<t>
1291  Partly resolved issues:
1292  <list style="symbols"> 
1293    <t>
1294      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>:
1295      "Term for the requested resource's URI"
1296    </t>
1297  </list>
1298</t>
1299</section>
1300
1301<section title="Since draft-ietf-httpbis-p7-auth-10" anchor="changes.since.10">
1302<t>
1303  None.
1304</t>
1305</section>
1306
1307<section title="Since draft-ietf-httpbis-p7-auth-11" anchor="changes.since.11">
1308<t>
1309  Closed issues:
1310  <list style="symbols"> 
1311    <t>
1312      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/130"/>:
1313      "introduction to part 7 is work-in-progress"
1314    </t>
1315    <t>
1316      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/195"/>:
1317      "auth-param syntax"
1318    </t>
1319    <t>
1320      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/224"/>:
1321      "Header Classification"
1322    </t>
1323    <t>
1324      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/237"/>:
1325      "absorbing the auth framework from 2617"
1326    </t>
1327  </list>
1328</t>
1329<t>
1330  Partly resolved issues:
1331  <list style="symbols"> 
1332    <t>
1333      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/141"/>:
1334      "should we have an auth scheme registry"
1335    </t>
1336  </list>
1337</t>
1338</section>
1339
1340<section title="Since draft-ietf-httpbis-p7-auth-12" anchor="changes.since.12">
1341<t>
1342  None.
1343</t>
1344</section>
1345
1346<section title="Since draft-ietf-httpbis-p7-auth-13" anchor="changes.since.13">
1347<t>
1348  Closed issues:
1349  <list style="symbols">
1350    <t>
1351      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/276"/>:
1352      "untangle ABNFs for header fields"
1353    </t>
1354  </list>
1355</t>
1356</section>
1357
1358<section title="Since draft-ietf-httpbis-p7-auth-14" anchor="changes.since.14">
1359<t>
1360  None.
1361</t>
1362</section>
1363
1364<section title="Since draft-ietf-httpbis-p7-auth-15" anchor="changes.since.15">
1365<t>
1366  Closed issues:
1367  <list style="symbols">
1368    <t>
1369      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/78"/>:
1370      "Relationship between 401, Authorization and WWW-Authenticate"
1371    </t>
1372    <t>
1373      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/177"/>:
1374      "Realm required on challenges"
1375    </t>
1376    <t>
1377      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/195"/>:
1378      "auth-param syntax"
1379    </t>
1380    <t>
1381      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/257"/>:
1382      "Considerations for new authentications schemes"
1383    </t>
1384    <t>
1385      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/287"/>:
1386      "LWS in auth-param ABNF"
1387    </t>
1388    <t>
1389      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/309"/>:
1390      "credentials ABNF missing SP (still using implied LWS?)"
1391    </t>
1392  </list>
1393</t>
1394</section>
1395
1396<section title="Since draft-ietf-httpbis-p7-auth-16" anchor="changes.since.16">
1397<t>
1398  Closed issues:
1399  <list style="symbols"> 
1400    <t>
1401      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>:
1402      "Document HTTP's error-handling philosophy"
1403    </t>
1404    <t>
1405      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/320"/>:
1406      "add advice on defining auth scheme parameters"
1407    </t>
1408  </list>
1409</t>
1410</section>
1411
1412</section>
1413
1414</back>
1415</rfc>
Note: See TracBrowser for help on using the repository browser.