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: Tue, 9 Aug 2011 09:50:19 +1000
To: Julian Reschke <julian.reschke@gmx.de>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <255B9BB34FB7D647A506DC292726F6E1128B14C697@WSMSG3153V.srv.dir.telstra.com>
>> 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.


I like the new text, except for disallowing <b64token> for new schemes.
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>).

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

      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>

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

    <ins>The single sting alternative <b64token></ins>
    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 ) ]

 2.3.1.  Considerations for New Authentication Schemes


    o  The "b64token" notation was introduced for compatibility with
       existing authentication schemes<del>, it MUST NOT be used in new
Received on Monday, 8 August 2011 23:51:01 UTC

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