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

Last change on this file since 1690 was 1689, checked in by julian.reschke@…, 7 years ago

tune contact information for Julian Reschke

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