Re: [hybi] About authentication mechanism

Greg Wilkins <> Thu, 30 June 2011 01:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A8E11F0C3B for <>; Wed, 29 Jun 2011 18:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OhciYwi+vh71 for <>; Wed, 29 Jun 2011 18:43:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 94DFF1F0C36 for <>; Wed, 29 Jun 2011 18:43:26 -0700 (PDT)
Received: by vxi40 with SMTP id 40so1580032vxi.31 for <>; Wed, 29 Jun 2011 18:43:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id hv4mr2097621vdb.42.1309398205712; Wed, 29 Jun 2011 18:43:25 -0700 (PDT)
Received: by with HTTP; Wed, 29 Jun 2011 18:43:25 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 30 Jun 2011 11:43:25 +1000
Message-ID: <>
From: Greg Wilkins <>
To: Hybi <>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [hybi] About authentication mechanism
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jun 2011 01:43:27 -0000

Sorry if this is a duplicate - there was an error in sending and I
also notice I left out a .net from my example:

I do not think that this WG should be in the business of mandating
Authentication mechanisms. There is no one-size-fits all
authentication mechanism and best practises change. I believe that we
need WS to support a variety of authentication mechanisms and thus
avoid the "you don't want to use that mechanism" debate.

For cookie based authentication mechanisms, the protocol already
supports sending and setting cookies in handshakes and handshake
responses.  However I cannot see any requirements on the browsers to
actually send any cookies - so perhaps we need to strengthen the spec
here with some recommendations (ie SHOULD send appropriate cookies
rather than MAY send).

For the HTTP authentication mechanisms of BASIC and DIGEST, the spec
does allow a 401 challenge to be sent, however I do not think that we
currently don't explicitly allow the WWW-Authenticate or Authorisation
headers in the handshake.   So I think we should add a point in 5.1
saying that a handshake request MAY include other HTTP headers such as
Authorisation.  Currently we only say MAY include
Sec-WebSocket-Protocol, Sec-WebSocket-Extensions and cookie headers -
which by omission implies we can't have arbitrary headers (which I do
not think was the intent).       Note I do recognise that there are
issues with collecting credentials for these mechanisms and thus I
think we should defer to the browsers if and how they will be
supported, but we should definitely allow them in the protocol.

For token passing authentication mechanisms, there is currently no way
for users to set HTTP headers in the handshake.  This is probably a
good thing!    The only user settable field in the handshake is the
subprotocol fields, and as I have said before, I would not be
surprised if this was used (or abused?) to send OAUTH tokens. Perhaps
usage of OAUTH is a subprotocol and we should allow multiple
subprotocols and  parameters to subprotocols for passing data, eg.

       GET /chat HTTP/1.1
       Upgrade: websocket
       Connection: Upgrade
       Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
       Sec-WebSocket-Version: 8

       HTTP/1.1 101 Switching Protocols
       Upgrade: websocket
       Connection: Upgrade
       Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

So in summary, I think to better support flexible authentication we should
1. say that clients SHOULD send appropriate cookies (rather than MAY)
2. expand 5.1 to so that clients MAY send arbitrary HTTP headers,
including Authorisation (which can be listed as an example).
3. Allow multiple parameterised subprotocols, so that they may be used
for token based authentication.