W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

RE: #177: Realm required on challenges

From: Manger, James H <James.H.Manger@team.telstra.com>
Date: Mon, 25 Jul 2011 10:47:01 +1000
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <255B9BB34FB7D647A506DC292726F6E112892DE0F1@WSMSG3153V.srv.dir.telstra.com>

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.

The ABNF for <credentials> is still wrong, but I guess that is being tracked by a separate ticket [http://trac.tools.ietf.org/wg/httpbis/trac/ticket/195].

The ABNF for <challenge> should probably be changed in a similar way to <credentials>: accept a base64 blob as an alternative to comma-separated attribute-value pairs. That would match widespread existing behaviour with the NTLM scheme.

James Manger

-----Original Message-----
From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] On Behalf Of Julian Reschke
Sent: Monday, 25 July 2011 5:12 AM

Proposed patch: 

New text of Section 2 (after putting in more structure):

2.  Access Authentication Framework

2.1.  Challenge and Response

    HTTP provides a simple challenge-response authentication mechanism
    that can be used by a server to challenge a client request and by a
    client to provide authentication information.  It uses an extensible,
    case-insensitive token to identify the authentication scheme,
    followed by a comma-separated list of attribute-value pairs which
    carry the parameters necessary for achieving authentication via that

      auth-scheme    = token
      auth-param     = token "=" ( token / quoted-string )

    Both the Authorization field value and the Proxy-Authorization field
    value consist of credentials containing the authentication
    information of the client for the realm of the resource being
    requested.  The user agent MUST choose to use one of the challenges
    with the strongest auth-scheme it understands and request credentials
    from the user based upon that challenge.

      credentials = auth-scheme ( token
                                / quoted-string
                                / #auth-param )

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

    The realm value (case-sensitive), in combination with 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, defines the protection space.  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.

Feedback appreciated, Julian
Received on Monday, 25 July 2011 00:47:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC