source: draft-ietf-httpbis/latest/p7-auth.xml @ 1356

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

Considerations for new authentications schemes (see #257)

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