Re: #177: Realm required on challenges

On 2011-07-25 02:47, Manger, James H wrote:
> Julian,
>
> The concept of a "protection space" is quite important (eg for automatically applying credentials), regardless of whether or not a 'realm' parameter is present. Unfortunately, the proposed patch to make 'realm' optional also effectively makes a protection space optional. How about changing the 1st sentence of the 2nd paragraph of 2.2 "Protection Space (Realm)" to the following:
>
>    A protection space is defined by the canonical root URI (...)
>    of the server being accessed, in combination with the realm
>    value if present.
 > ...

OK; new proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/177/177.diff>. 
The subsection would then read:


2.2.  Protection Space (Realm)

    The authentication parameter realm is reserved for use by
    authentication schemes that wish to indicate the scope of protection:

      realm       = "realm" "=" realm-value
      realm-value = quoted-string

    A protection space is defined by the canonical root URI (the scheme
    and authority components of the effective request URI; see Section
    4.3 of [Part1]) of the server being accessed, in combination with the
    realm value if present.  These realms allow the protected resources
    on a server to be partitioned into a set of protection spaces, each
    with its own authentication scheme and/or authorization database.
    The realm value is a string, generally assigned by the origin server,
    which can have additional semantics specific to the authentication
    scheme.  Note that there can be multiple challenges with the same
    auth-scheme but different realms.

    The protection space determines the domain over which credentials can
    be automatically applied.  If a prior request has been authorized,
    the same credentials MAY be reused for all other requests within that
    protection space for a period of time determined by the
    authentication scheme, parameters, and/or user preference.  Unless
    otherwise defined by the authentication scheme, a single protection
    space cannot extend outside the scope of its server.



Best regards, Julian

Received on Monday, 25 July 2011 13:48:45 UTC