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

Timestamp:

26/07/11 16:00:04 (12 years ago)

Author:

julian.reschke@…

Message:

Considerations for new authentications schemes (see #257)

File:

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

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

@@ -545 +545 @@
                <li>2.1&nbsp;&nbsp;&nbsp;<a href="#challenge.and.response">Challenge and Response</a></li>
                <li>2.2&nbsp;&nbsp;&nbsp;<a href="#protection.space">Protection Space (Realm)</a></li>
-               <li>2.3&nbsp;&nbsp;&nbsp;<a href="#authentication.scheme.registry">Authentication Scheme Registry</a></li>
+               <li>2.3&nbsp;&nbsp;&nbsp;<a href="#authentication.scheme.registry">Authentication Scheme Registry</a><ul>
+                     <li>2.3.1&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.authentication.schemes">Considerations for New Authentication Schemes</a></li>
+                  </ul>
+               </li>
             </ul>
          </li>
@@ -707 +710 @@
       <p id="rfc.section.2.3.p.4">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-authschemes">http://www.iana.org/assignments/http-authschemes</a>&gt;.
       </p>
+      <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="considerations.for.new.authentication.schemes" href="#considerations.for.new.authentication.schemes">Considerations for New Authentication Schemes</a></h3>
+      <p id="rfc.section.2.3.1.p.1">There are certain aspects of the HTTP Authentication Framework that put constraints on how new authentication schemes can
+         work:
+      </p>
+      <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 whther they are usable in origin-server authentication (i.e., using WWW-Authenticate),
+            and/or proxy authentication (i.e., using Proxy-Authenticate).
+         </li>
+      </ul>
       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1>
       <div id="rfc.iref.8"></div>
@@ -752 +771 @@
       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>
       <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" header field consists of a challenge that indicates the authentication scheme and parameters applicable
-         to the proxy for this 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.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.
+         to the proxy for this 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.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.
       </p>
       <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.2"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
@@ -776 +795 @@
       <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.8"><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>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages.
       </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>
@@ -1089 +1108 @@
          <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>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/257">http://tools.ietf.org/wg/httpbis/trac/ticket/257</a>&gt;: "Considerations for new authentications schemes"
+         </li>
       </ul>
       <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
@@ -1134 +1155 @@
             </li>
             <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
-                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.2.1</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">2.2</a>, <a href="#rfc.xref.Part1.7">4.2</a>, <a href="#rfc.xref.Part1.8">4.4</a>, <a href="#Part1"><b>8.1</b></a><ul>
+                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.2.1</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">2.2</a>, <a href="#rfc.xref.Part1.7">2.3.1</a>, <a href="#rfc.xref.Part1.8">4.2</a>, <a href="#rfc.xref.Part1.9">4.4</a>, <a href="#Part1"><b>8.1</b></a><ul>
                         <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a></li>
                         <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2.1</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a></li>
-                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2.2</a>, <a href="#rfc.xref.Part1.7">4.2</a>, <a href="#rfc.xref.Part1.8">4.4</a></li>
+                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">2.3.1</a></li>
+                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2.2</a>, <a href="#rfc.xref.Part1.8">4.2</a>, <a href="#rfc.xref.Part1.9">4.4</a></li>
                      </ul>
                   </li>