Re: #195, was: ABNF for Authorization header not quite right

On 2011-08-09 01:50, Manger, James H wrote:
>>> Summarizing where we are:
>>>
>>> - we introduce a b64 grammar production
>>>
>>> - we remove the at-least one auth-param requirement from the ABNF
>>> (actually, that should be done as part of issue
>>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/177>
>>>
>>> - we allow b64 both in challenges and credentials *instead* of a list of
>>> auth-params (we believe a single b64 is sufficient for Negotiate&  friends)
>
>> OK, here's a proposed patch:
>> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/195/195.diff>;
>> it introduces a new grammar construct as suggested by James, and allows
>> it *instead* of auth-param lists. Also, it suggests that it's for
>> backwards compatibility and that it should not be used for new schemes.
>
>
> Julian,
>
> I like the new text, except for disallowing<b64token>  for new schemes.

Most of it is yours :-)

> I don't think that extra restriction is necessary, or useful.
>
> Other authentication schemes could well copy how BASIC/NTLM/NEGOTIATE
> do it, for the same reasons (a single blob is a good match for their
> information model).
> draft-ietf-oauth-v2-bearer (currently in Working Group Last Call)
> defines the BEARER HTTP authentication scheme to uses a single
> string (it currently allows any ASCII chars other than controls and space,
> but should be able to adopt<b64token>).

My concern is that b64token is constrained to a single value; if you 
pick it, there are no extension points left. I think this is sufficient 
reason to discourage it. Will come up with new proposed text later on.

Could you please point out to the draft-ietf-oauth-v2-bearer people that 
they are painting themselves into a corner with this, and should just 
use auth-params instead?

>
> So suggested text (with a few<ins>erts and<del>etes):
>
>   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<ins>a single string or</ins>
>      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 BWS "=" BWS ( token / quoted-string )
>
>      <del>As an alternative to a list of auth parameters, a single string can
>      be used:</del>

Ack.

> ...

Best regards, Julian

Received on Tuesday, 9 August 2011 09:13:32 UTC