RE: Backwards definition of authentication header

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Friday, December 04, 2009 7:59 AM
> To: Eran Hammer-Lahav
> Cc: HTTP Working Group (ietf-http-wg@w3.org)
> Subject: Re: Backwards definition of authentication header
> 
> Eran Hammer-Lahav wrote:
> > (I'm in the process of writing a new HTTP authentication scheme per
> > the OAuth WG charter. I will be sending questions and issues regarding
> > RFC 2617 and draft-ietf-httpbis-p7-auth in the hopes that someone will
> > both be able to clarify them as well as find this feedback useful.)
> 
> Feedback from somebody trying to define a new HTTP auth scheme it
> *totally* useful. Thanks for that in advance.
> 
> > Trying to follow the definition of the WWW-Authenticate and Authorization
> headers is like chasing one's own tail. The headers are defined in draft-ietf-
> httpbis-p7-auth but their content is defined using an imported definition
> from 2617, which in turn relies on the header definition in 2616. There isn't a
> single place where an implementer can read about the complete structure of
> these headers.
> 
> When you say "which in turn relies on the header definition in 2616", do you
> refer to more than "token" and "quoted-string"?

Yes, the actual header definition. Because draft-ietf-httpbis-p7-auth only updates 2617, but obsoletes 2616, it gets confusing as to where should someone reading 2617 go when trying to get the full authenticating picture. Moving the entire section 1 from 2617 to draft-ietf-httpbis-p7-auth will solve this.

> > Why not move the entire section 1 from 2617 into draft-ietf-httpbis-p7-
> auth?
> 
> I think I came to the conclusion a long time ago and thought that I opened a
> ticket for that; apparently I didn't. Yes, we need to make sure that Part 7
> contains all but the actual authentication scheme definitions.

This will be a significant improvement.

> > It is also confusing that Basic auth does not comply with the syntax defined
> for 'credentials' (no key="value" pair, only base64 username and password). I
> am not suggesting changing Basic, but I am suggesting changing the definition
> of 'credentials' to better reflect reality or at lease note why basic is different
> (I assume for historical reasons).
> 
> I assume the reasons are historical.
> 
> It appears the ABNF was broken when RFC2068/9 was revised as RFC2616/7,
> see <http://tools.ietf.org/html/rfc2068#section-11> which has:
> 
>            credentials    = basic-credentials
>                           | auth-scheme #auth-param
> 
> We probably should record an erratum for RFC 2617 for now.
> 
> > What is not clear to me is if the definition provided for 'credentials' is
> binding for new schemes, or if these schemes can go and redefine it as they
> see if.
> 
> Is there anything *except* for the broken ABNF with respect to Basic that
> makes you think the definition isn't binding?

No. But since Basic is 50% of 2617, it is a pretty big exception... :-)

EHL

Received on Friday, 4 December 2009 16:54:34 UTC