W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

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

From: Manger, James H <James.H.Manger@team.telstra.com>
Date: Thu, 28 Jul 2011 10:45:49 +1000
To: Julian Reschke <julian.reschke@gmx.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <255B9BB34FB7D647A506DC292726F6E112895C9C1F@WSMSG3153V.srv.dir.telstra.com>
>> 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.

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

>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 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 00:46:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC