Changeset 1360 for draft-ietf-httpbis/latest/p7-auth.html

Timestamp:

27/07/11 13:21:29 (12 years ago)

Author:

julian.reschke@…

Message:

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

File:

• draft-ietf-httpbis/latest/p7-auth.html (modified) (8 diffs)

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

@@ -359 +359 @@
   } 
   @bottom-center {
-       content: "Expires January 27, 2012"; 
+       content: "Expires January 28, 2012"; 
   } 
   @bottom-right {
@@ -404 +404 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2011-07-26">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-07-27">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -435 +435 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 27, 2012</td>
+               <td class="left">Expires: January 28, 2012</td>
                <td class="right">HP</td>
             </tr>
@@ -488 +488 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 26, 2011</td>
+               <td class="right">July 27, 2011</td>
             </tr>
          </tbody>
@@ -516 +516 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 27, 2012.</p>
+      <p>This Internet-Draft will expire on January 28, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -716 +716 @@
       <p id="rfc.section.2.3.1.p.2"> </p>
       <ul>
-         <li>Authentication schemes need to be compatible with the inherent constraints of HTTP; for instance, that messages need to keep
-            their semantics when inspected in isolation, thus an authentication scheme can not bind information to the TCP session over
-            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>).
-         </li>
-         <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.
-         </li>
-         <li>Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using WWW-Authenticate),
-            and/or proxy authentication (i.e., using Proxy-Authenticate).
+         <li>
+            <p>Authentication schemes need to be compatible with the inherent constraints of HTTP; for instance, that messages need to keep
+               their semantics when inspected in isolation, thus an authentication scheme can not bind information to the TCP session over
+               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>).
+            </p>
+         </li>
+         <li>
+            <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.
+            </p>
+         </li>
+         <li>
+            <p>Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using WWW-Authenticate),
+               and/or proxy authentication (i.e., using Proxy-Authenticate).
+            </p>
+         </li>
+         <li>
+            <p>The credentials carried in an Authorization header field are specific to the User Agent, and therefore have the same effect
+               on HTTP caches as the "private" Cache-Control response directive, within the scope of the request they appear in.
+            </p>
+            <p>Therefore, new authentication schemes which choose not to carry credentials in the Authorization header (e.g., using a newly
+               defined header) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives
+               (e.g., "no-store") or response directives (e.g., "private").
+            </p>
          </li>
       </ul>
@@ -795 +810 @@
       <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>
       <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
-         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.
+         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>).
+      </p>
+      <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
+         response.
       </p>
       <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>
-</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
+</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
          challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a
          comma-separated list of authentication parameters.
@@ -1106 +1124 @@
       <p id="rfc.section.C.17.p.1">Closed issues: </p>
       <ul>
+         <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"
+         </li>
          <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"
          </li>