- 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>
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. 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: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/177/177.diff> 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 scheme. 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