source: draft-ietf-httpbis/16/draft-ietf-httpbis-p7-auth-16.xml @ 1930

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