RE: Multiple challenges in a single WWW-Authenticate header field

I wasn't questioning the need to provide multiple challenges in a single response. I was only questioning the wisdom in allowing multiple challenges in a single header field, given the odd combination of separators it creates. It would be nice to try and deprecate this practice, while still requiring clients to deal with it for backwards compatibility.

EHL

> -----Original Message-----
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]
> On Behalf Of Thomas Broyer
> Sent: Thursday, December 03, 2009 11:48 PM
> To: HTTP Working Group (ietf-http-wg@w3.org)
> Subject: Re: Multiple challenges in a single WWW-Authenticate header field
> 
> [re-sent to list, sorry for the dupe Eran]
> 
> 
> On Fri, Dec 4, 2009 at 5:08 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
> > draft-ietf-httpbis-p7-auth defines the WWW-Authenticate as:
> >
> >     WWW-Authenticate   = "WWW-Authenticate" ":" OWS WWW-
> Authenticate-v
> >     WWW-Authenticate-v = 1#challenge
> >
> > Importing challenge from RFC 2617:
> >
> >      challenge   = auth-scheme 1*SP 1#auth-param
> >
> > Which means a single header can contain multiple comma-separated
> challenges:
> >
> > WWW-Autenticate: Basic realm="X1", Digest realm="X1",
> domain="http://example.com", Basic realm="X2"
> >
> > Is this right?
> 
> Yes
> 
> > It seems odd to rely parsing multiple challenges on the presence of a space
> between the auth-scheme and list of auth-param.
> 
> Hence the following note in RFC 2617:
>   Note: User agents will need to take special care in parsing the WWW-
>   Authenticate or Proxy-Authenticate header field value if it contains
>   more than one challenge, or if more than one WWW-Authenticate header
>   field is provided, since the contents of a challenge may itself
>   contain a comma-separated list of authentication parameters.
> 
> > I am not sure why multiple challenges are even allowed,
> 
> WWW-Authenticate: Basic realm="sent in the clear"
> WWW-Authenticate: Digest realm="more secure", <other auth-params>
> WWW-Authenticate: HMACDigest realm="even more secure", <other auth-
> params>
> WWW-Authenticate: WSSE realm="some other scheme"
> (where HMACDigest is
> http://tools.ietf.org/html/draft-sayre-http-hmac-digest and WSSE is
> described at http://www.xml.com/pub/a/2003/12/17/dive.html )
> 
> or
> WWW-Authenticate: GoogleLogin realm="use your Google Account", <other
> auth-params>
> WWW-Authenticate: Cookie realm="or a local HTML form", <other auth-
> params>
> WWW-Authenticate: OpenID realm="or your OpenID", <other auth-params>
> (where Cookie is http://tools.ietf.org/html/draft-broyer-http-cookie-auth

> and OpenID is something like http://www.ietf.org/mail-

> archive/web/dix/current/msg00581.html
> or http://wiki2008.openid.net/OpenID_HTTP_Authentication )
> 
> The goal is that the client uses the most secure scheme it supports (in the
> first example, browsers would use Digest or Basic, while
> HttpLib2 would use HmacDigest)
> 
> > but either way, they should be separated using something other than a
> comma.
> 
> Using commas is the way to go in HTTP so that you can have multiple WWW-
> Authenticate headers (the exception being "Set-Cookie in-the-wild").
> 
> But parsing WWW-Authenticate is really not that hard:
> http://code.google.com/p/httplib2/source/browse/httplib2/__init__.py#22

> 8
> 
> 
> 
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/

Received on Friday, 4 December 2009 08:02:14 UTC