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

Hi,

so I went ahead and applied the following change: 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1394>

> ...
>> 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.

New text:

    o  The "b64token" notation was introduced for compatibility with
       existing authentication schemes and can only be used once per
       challenge/credentials.  New schemes thus ought to use the "auth-
       param" syntax instead, because otherwise future extensions will be
       impossible.

> ...
>> 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>
> ...

Now...:

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 additional information necessary for achieving
    authentication via that scheme.  The latter can either be a comma-
    separated list of attribute-value pairs or a single sequence of
    characters capable of holding base64-encoded information.

      auth-scheme    = token

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

      b64token       = 1*( ALPHA / DIGIT /
                           "-" / "." / "_" / "~" / "+" / "/" ) *"="

    The "b64token" syntax allows the 66 unreserved URI characters
    ([RFC3986]), plus a few others, so that it can hold a base64,
    base64url (URL and filename safe alphabet), base32, or base16 (hex)
    encoding, with or without padding, but excluding whitespace
    ([RFC4648]).


(reminder: this is only our development version, so we can still tune 
it...).

Best regards, Julian

Received on Tuesday, 9 August 2011 11:25:07 UTC