Changeset 1360 for draft-ietf-httpbis


Ignore:
Timestamp:
Jul 27, 2011, 6:21:29 AM (8 years ago)
Author:
julian.reschke@…
Message:

Relationship between 401, Authorization and WWW-Authenticate (see #78)

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p7-auth.html

    r1357 r1360  
    359359  }
    360360  @bottom-center {
    361        content: "Expires January 27, 2012";
     361       content: "Expires January 28, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2011-07-26">
     406      <meta name="dct.issued" scheme="ISO8601" content="2011-07-27">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication.">
    … …  
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: January 27, 2012</td>
     437               <td class="left">Expires: January 28, 2012</td>
    438438               <td class="right">HP</td>
    439439            </tr>
    … …  
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">July 26, 2011</td>
     490               <td class="right">July 27, 2011</td>
    491491            </tr>
    492492         </tbody>
    … …  
    516516         in progress”.
    517517      </p>
    518       <p>This Internet-Draft will expire on January 27, 2012.</p>
     518      <p>This Internet-Draft will expire on January 28, 2012.</p>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    716716      <p id="rfc.section.2.3.1.p.2"> </p>
    717717      <ul>
    718          <li>Authentication schemes need to be compatible with the inherent constraints of HTTP; for instance, that messages need to keep
    719             their semantics when inspected in isolation, thus an authentication scheme can not bind information to the TCP session over
    720             which the message was received (see <a href="p1-messaging.html#message-orientation-and-buffering" title="Message Orientation and Buffering">Section 2.2</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    721          </li>
    722          <li>The authentication parameter "realm" is reserved for defining Protection Spaces as defined in <a href="#protection.space" title="Protection Space (Realm)">Section&nbsp;2.2</a>. New schemes <em class="bcp14">MUST NOT</em> use it in a way incompatible with that definition.
    723          </li>
    724          <li>Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using WWW-Authenticate),
    725             and/or proxy authentication (i.e., using Proxy-Authenticate).
     718         <li>
     719            <p>Authentication schemes need to be compatible with the inherent constraints of HTTP; for instance, that messages need to keep
     720               their semantics when inspected in isolation, thus an authentication scheme can not bind information to the TCP session over
     721               which the message was received (see <a href="p1-messaging.html#message-orientation-and-buffering" title="Message Orientation and Buffering">Section 2.2</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     722            </p>
     723         </li>
     724         <li>
     725            <p>The authentication parameter "realm" is reserved for defining Protection Spaces as defined in <a href="#protection.space" title="Protection Space (Realm)">Section&nbsp;2.2</a>. New schemes <em class="bcp14">MUST NOT</em> use it in a way incompatible with that definition.
     726            </p>
     727         </li>
     728         <li>
     729            <p>Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using WWW-Authenticate),
     730               and/or proxy authentication (i.e., using Proxy-Authenticate).
     731            </p>
     732         </li>
     733         <li>
     734            <p>The credentials carried in an Authorization header field are specific to the User Agent, and therefore have the same effect
     735               on HTTP caches as the "private" Cache-Control response directive, within the scope of the request they appear in.
     736            </p>
     737            <p>Therefore, new authentication schemes which choose not to carry credentials in the Authorization header (e.g., using a newly
     738               defined header) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives
     739               (e.g., "no-store") or response directives (e.g., "private").
     740            </p>
    726741         </li>
    727742      </ul>
    … …  
    795810      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2>
    796811      <p id="rfc.section.4.4.p.1">The "WWW-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters
    797          applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages.
     812         applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     813      </p>
     814      <p id="rfc.section.4.4.p.2">It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages and <em class="bcp14">MAY</em> be included in other response messages to indicate that supplying credentials (or different credentials) might affect the
     815         response.
    798816      </p>
    799817      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.4"></span>  <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
    800 </pre><p id="rfc.section.4.4.p.3">User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one
     818</pre><p id="rfc.section.4.4.p.4">User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one
    801819         challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a
    802820         comma-separated list of authentication parameters.
    … …  
    11061124      <p id="rfc.section.C.17.p.1">Closed issues: </p>
    11071125      <ul>
     1126         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/78">http://tools.ietf.org/wg/httpbis/trac/ticket/78</a>&gt;: "Relationship between 401, Authorization and WWW-Authenticate"
     1127         </li>
    11081128         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/177">http://tools.ietf.org/wg/httpbis/trac/ticket/177</a>&gt;: "Realm required on challenges"
    11091129         </li>

  • draft-ietf-httpbis/latest/p7-auth.xml

    r1357 r1360  
    450450<t>
    451451  <list style="symbols">
     452    <x:lt>
    452453    <t>
    453454      Authentication schemes need to be compatible with the inherent
    … …  
    457458      was received (see &msg-orient-and-buffering;).
    458459    </t>
     460    </x:lt>
     461    <x:lt>
    459462    <t>
    460463      The authentication parameter "realm" is reserved for defining Protection
    … …  
    462465      &MUST-NOT; use it in a way incompatible with that definition.
    463466    </t>
     467    </x:lt>
     468    <x:lt>
    464469    <t>
    465470      Authentication schemes need to document whether they are usable in
    466471      origin-server authentication (i.e., using WWW-Authenticate), and/or
    467472      proxy authentication (i.e., using Proxy-Authenticate).
    468     </t>   
    469     <!-- note about Authorization header -->
     473    </t>
     474    </x:lt>
     475    <x:lt>
     476    <t>
     477      The credentials carried in an Authorization header field are specific to
     478      the User Agent, and therefore have the same effect on HTTP caches as the
     479      "private" Cache-Control response directive, within the scope of the
     480      request they appear in.
     481    </t>
     482    <t>
     483      Therefore, new authentication schemes which choose not to carry
     484      credentials in the Authorization header (e.g., using a newly defined
     485      header) will need to explicitly disallow caching, by mandating the use of
     486      either Cache-Control request directives (e.g., "no-store") or response
     487      directives (e.g., "private").
     488    </t>
     489    </x:lt>
    470490  </list>
    471491</t>
    … …  
    623643   The "WWW-Authenticate" header field consists of at least one
    624644   challenge that indicates the authentication scheme(s) and parameters
    625    applicable to the effective request URI (&effective-request-uri;). It &MUST; be included in 401
    626    (Unauthorized) response messages.
     645   applicable to the effective request URI (&effective-request-uri;).
     646</t>
     647<t>   
     648   It &MUST; be included in 401 (Unauthorized) response messages and &MAY; be
     649   included in other response messages to indicate that supplying credentials
     650   (or different credentials) might affect the response.
    627651</t>
    628652<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/>
    … …  
    12561280  <list style="symbols">
    12571281    <t>
     1282      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/78"/>:
     1283      "Relationship between 401, Authorization and WWW-Authenticate"
     1284    </t>
     1285    <t>
    12581286      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/177"/>:
    12591287      "Realm required on challenges"
Note: See TracChangeset for help on using the changeset viewer.