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: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 08 Aug 2011 15:38:13 +0200
Message-ID: <4E3FE6C5.5020406@gmx.de>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 2011-08-07 20:28, Julian Reschke wrote:
> James,
> again sorry for the slow feedback.
> I spent some time on
> <http://greenbytes.de/tech/tc/httpauth/>
> making sure that what RFC 2616/7 specify is actually parseable (it seems
> to, I've done with with XSLT 2 and regexps). (Feedback on more tests
> welcome...).
> 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)
> Best regards, Julian

OK, here's a proposed patch: 
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.

In particular:

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 a comma-separated list of attribute-value pairs which
    carry the parameters necessary for achieving authentication via that

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

    As an alternative to a list of auth parameters, a single string can
    be used:

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

    This includes 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]).


      challenge   = auth-scheme [ 1*SP ( b64token / #auth-param ) ]


      credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ]

--> Note that I made 1*SP optional when nothing follows.

2.3.1.  Considerations for New Authentication Schemes


    o  The "b64token" notation was introduced for compatibility with
       existing authentication schemes, it MUST NOT be used in new

Appendix A.  Changes from RFCs 2616 and 2617


    The "b64token" alternative to auth-param lists has been added for
    consistency with legacy authentication schemes such as "Basic".
    (Section 2)

...feedback appreciated. Once the change is applied I'll update 
<http://greenbytes.de/tech/tc/httpauth/> accordingly.

Best regards, Julian
Received on Monday, 8 August 2011 13:38:48 UTC

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