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

On 2011-07-28 02:45, Manger, James H wrote:
>>> I suggest changing the ABNF to the following:
>>>
>>>     credentials = auth-scheme SP ( b64 / #auth-param )
>>>
>>>     b64 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="
>>>
>>>     <b64>   includes the 66 unreserved URI characters plus a few others.
>>>     It can hold a base64, base64url (URL and filename safe alphabet),
>>>     base32, or base16 (hex) encoding, with or without padding, but
>>>     excluding whitespace [RFC4648].
>>>
>>>
>>> This accepts authentication schemes that transmit a base64 blob instead of name=value pairs (such as BASIC, NTLM, NEGOTIATE). It also accepts dot-separated base64url blobs, as proposed in new specs such as JSON Web Tokens.
>>>
>>> I dropped<quoted-string>   as I don't know where that came from. Perhaps it was added with<token>   as they are often a pair. If there are no existing uses (and I don't know of any) it adds no value.
>
>> Indeed.
>>
>> Maybe we need
>>
>>    credentials = auth-scheme SP #( b64 / auth-param )
>
> I doubt we need that. I have never seen a NTLM or Negotiate scheme header with more than 1 base64 blob.

Ack.

>> though? As far as I can tell, RFC 4559 uses that.
>>
>> Also: RFC 4559 seems to need this for the challenge as well...
>
>
> RFC 4559 "SPEGNO/NTLM/Negotiate" might specify that, but I don't think it can work as it makes parsing ambiguous. For instance, does the following response header include 1 scheme with 4 parameters, or 2 or 3 schemes? Is "tuv" another authentication scheme supported by this server, or a parameter of the "ABC" scheme?
>    WWW-Authenticate: ABC xyz, a=1, qrs, tuv

The ABNF says:

    challenge   = auth-scheme 1*SP 1#auth-param

so there needs to be at least one auth-param, separated by one or more SPs.

That being said, we may have to rethink the use of the list production here.

Keep in mind that 1#auth-param allosws

	scheme auth-param

but also

	scheme ,auth-param

because of the specific rules for empty list elements.

*That* would be impossible to parse, and thus we may want not to use the 
# notation over here.

Best regards, Julian

> The ambiguity that occurs for<challenge>  might not occur for<credentials>  if only 1 Authorization header is allowed, but it does show that we cannot match what the ABNF in RFC 4559 theoretically needs. We should match what is actually in use -- which seems to be a single base64 blob.
>
> I prefer
>    ( b64 / #auth-param )
> instead of
>    #( b64 / auth-param )
> That is, I think a<b64>  blob should only be allowed when it is the first (and only) parameter.
>
> --
> James Manger
>
>

Received on Thursday, 28 July 2011 15:07:10 UTC