Ignore:
Timestamp:
07/05/13 14:04:14 (9 years ago)
Author:
julian.reschke@…
Message:

Move sections about new auth schemes registration, other considerations) into IANA section (see #464).

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r2232 r2242  
    314314</section>
    315315
    316 <section title="Authentication Scheme Registry" anchor="authentication.scheme.registry">
    317 <t>
    318   The HTTP Authentication Scheme Registry defines the name space for the
    319   authentication schemes in challenges and credentials.
    320 </t>
    321 <t>
    322   Registrations &MUST; include the following fields:
    323   <list style="symbols">
    324     <t>Authentication Scheme Name</t>
    325     <t>Pointer to specification text</t>
    326     <t>Notes (optional)</t>
    327   </list>
    328 </t>
    329 <t>
    330   Values to be added to this name space require IETF Review
    331   (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>).
    332 </t>
    333 <t>
    334   The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-authschemes"/>.
    335 </t>
    336 
    337 <section title="Considerations for New Authentication Schemes" anchor="considerations.for.new.authentication.schemes">
    338 <t>
    339   There are certain aspects of the HTTP Authentication Framework that put
    340   constraints on how new authentication schemes can work:
    341 </t>
    342 <t>
    343   <list style="symbols">
    344     <x:lt>
    345     <t>
    346       HTTP authentication is presumed to be stateless: all of the information
    347       necessary to authenticate a request &MUST; be provided in the request,
    348       rather than be dependent on the server remembering prior requests.
    349       Authentication based on, or bound to, the underlying connection is
    350       outside the scope of this specification and inherently flawed unless
    351       steps are taken to ensure that the connection cannot be used by any
    352       party other than the authenticated user
    353       (see &msg-orient-and-buffering;).
    354     </t>
    355     </x:lt>
    356     <x:lt>
    357     <t>
    358       The authentication parameter "realm" is reserved for defining Protection
    359       Spaces as defined in <xref target="protection.space"/>. New schemes
    360       &MUST-NOT; use it in a way incompatible with that definition.
    361     </t>
    362     </x:lt>
    363     <x:lt>
    364     <t>
    365       The "token68" notation was introduced for compatibility with existing
    366       authentication schemes and can only be used once per challenge or credential.
    367       New schemes thus ought to use the "auth-param" syntax instead, because
    368       otherwise future extensions will be impossible.
    369     </t>
    370     </x:lt>
    371     <x:lt>
    372     <t>
    373       The parsing of challenges and credentials is defined by this specification,
    374       and cannot be modified by new authentication schemes. When the auth-param
    375       syntax is used, all parameters ought to support both token and
    376       quoted-string syntax, and syntactical constraints ought to be defined on
    377       the field value after parsing (i.e., quoted-string processing). This is
    378       necessary so that recipients can use a generic parser that applies to
    379       all authentication schemes.
    380     </t>
    381     <t>
    382       &Note; The fact that the value syntax for the "realm" parameter
    383       is restricted to quoted-string was a bad design choice not to be repeated
    384       for new parameters.
    385     </t>
    386     </x:lt>
    387     <x:lt>
    388     <t>
    389       Definitions of new schemes ought to define the treatment of unknown
    390       extension parameters. In general, a "must-ignore" rule is preferable
    391       over "must-understand", because otherwise it will be hard to introduce
    392       new parameters in the presence of legacy recipients. Furthermore,
    393       it's good to describe the policy for defining new parameters (such
    394       as "update the specification", or "use this registry").
    395     </t>
    396     </x:lt>
    397     <x:lt>
    398     <t>
    399       Authentication schemes need to document whether they are usable in
    400       origin-server authentication (i.e., using <x:ref>WWW-Authenticate</x:ref>),
    401       and/or proxy authentication (i.e., using <x:ref>Proxy-Authenticate</x:ref>).
    402     </t>
    403     </x:lt>
    404     <x:lt>
    405     <t>
    406       The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to
    407       the User Agent, and therefore have the same effect on HTTP caches as the
    408       "private" Cache-Control response directive (&caching-rsd-private;),
    409       within the scope of the request they appear in.
    410     </t>
    411     <t>
    412       Therefore, new authentication schemes that choose not to carry
    413       credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined
    414       header field) will need to explicitly disallow caching, by mandating the use of
    415       either Cache-Control request directives (e.g., "no-store",
    416       &caching-rqd-no-store;) or response directives (e.g., "private").
    417     </t>
    418     </x:lt>
    419   </list>
    420 </t>
    421 </section>
    422 
    423 </section>
    424 
    425316</section>
    426317
    … …  
    597488<section title="IANA Considerations" anchor="IANA.considerations">
    598489
    599 <section title="Authentication Scheme Registry" anchor="authentication.scheme.registration">
    600 <t>
    601   The registration procedure for HTTP Authentication Schemes is defined by
    602   <xref target="authentication.scheme.registry"/> of this document.
    603 </t>
    604 <t>
    605    The HTTP Method Authentication Scheme shall be created at <eref target="http://www.iana.org/assignments/http-authschemes"/>.
    606 </t>
     490<section title="Authentication Scheme Registry" anchor="authentication.scheme.registry">
     491<t>
     492   The HTTP Authentication Scheme Registry defines the name space for the
     493   authentication schemes in challenges and credentials. It is maintained at
     494   <eref target="http://www.iana.org/assignments/http-authschemes"/>.
     495</t>
     496
     497<section title="Procedure" anchor="authentication.scheme.registry.procedure">
     498<t>
     499  Registrations &MUST; include the following fields:
     500  <list style="symbols">
     501    <t>Authentication Scheme Name</t>
     502    <t>Pointer to specification text</t>
     503    <t>Notes (optional)</t>
     504  </list>
     505</t>
     506<t>
     507  Values to be added to this name space require IETF Review
     508  (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>).
     509</t>
     510</section>
     511
     512<section title="Considerations for New Authentication Schemes" anchor="considerations.for.new.authentication.schemes">
     513<t>
     514  There are certain aspects of the HTTP Authentication Framework that put
     515  constraints on how new authentication schemes can work:
     516</t>
     517<t>
     518  <list style="symbols">
     519    <x:lt>
     520    <t>
     521      HTTP authentication is presumed to be stateless: all of the information
     522      necessary to authenticate a request &MUST; be provided in the request,
     523      rather than be dependent on the server remembering prior requests.
     524      Authentication based on, or bound to, the underlying connection is
     525      outside the scope of this specification and inherently flawed unless
     526      steps are taken to ensure that the connection cannot be used by any
     527      party other than the authenticated user
     528      (see &msg-orient-and-buffering;).
     529    </t>
     530    </x:lt>
     531    <x:lt>
     532    <t>
     533      The authentication parameter "realm" is reserved for defining Protection
     534      Spaces as defined in <xref target="protection.space"/>. New schemes
     535      &MUST-NOT; use it in a way incompatible with that definition.
     536    </t>
     537    </x:lt>
     538    <x:lt>
     539    <t>
     540      The "token68" notation was introduced for compatibility with existing
     541      authentication schemes and can only be used once per challenge or credential.
     542      New schemes thus ought to use the "auth-param" syntax instead, because
     543      otherwise future extensions will be impossible.
     544    </t>
     545    </x:lt>
     546    <x:lt>
     547    <t>
     548      The parsing of challenges and credentials is defined by this specification,
     549      and cannot be modified by new authentication schemes. When the auth-param
     550      syntax is used, all parameters ought to support both token and
     551      quoted-string syntax, and syntactical constraints ought to be defined on
     552      the field value after parsing (i.e., quoted-string processing). This is
     553      necessary so that recipients can use a generic parser that applies to
     554      all authentication schemes.
     555    </t>
     556    <t>
     557      &Note; The fact that the value syntax for the "realm" parameter
     558      is restricted to quoted-string was a bad design choice not to be repeated
     559      for new parameters.
     560    </t>
     561    </x:lt>
     562    <x:lt>
     563    <t>
     564      Definitions of new schemes ought to define the treatment of unknown
     565      extension parameters. In general, a "must-ignore" rule is preferable
     566      over "must-understand", because otherwise it will be hard to introduce
     567      new parameters in the presence of legacy recipients. Furthermore,
     568      it's good to describe the policy for defining new parameters (such
     569      as "update the specification", or "use this registry").
     570    </t>
     571    </x:lt>
     572    <x:lt>
     573    <t>
     574      Authentication schemes need to document whether they are usable in
     575      origin-server authentication (i.e., using <x:ref>WWW-Authenticate</x:ref>),
     576      and/or proxy authentication (i.e., using <x:ref>Proxy-Authenticate</x:ref>).
     577    </t>
     578    </x:lt>
     579    <x:lt>
     580    <t>
     581      The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to
     582      the User Agent, and therefore have the same effect on HTTP caches as the
     583      "private" Cache-Control response directive (&caching-rsd-private;),
     584      within the scope of the request they appear in.
     585    </t>
     586    <t>
     587      Therefore, new authentication schemes that choose not to carry
     588      credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined
     589      header field) will need to explicitly disallow caching, by mandating the use of
     590      either Cache-Control request directives (e.g., "no-store",
     591      &caching-rqd-no-store;) or response directives (e.g., "private").
     592    </t>
     593    </x:lt>
     594  </list>
     595</t>
     596</section>
    607597</section>
    608598
    … …  
    11761166      "Editorial suggestions"
    11771167    </t>
     1168    <t>
     1169      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/464"/>:
     1170      "placement of extension point considerations"
     1171    </t>
    11781172  </list>
    11791173</t>
Note: See TracChangeset for help on using the changeset viewer.