Re: Authentication over HTTP

Amos Jeffries <> Tue, 16 July 2013 12:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B87521E8050 for <>; Tue, 16 Jul 2013 05:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.57
X-Spam-Status: No, score=-10.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z3HDWinQUh9K for <>; Tue, 16 Jul 2013 05:56:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6250B21E809A for <>; Tue, 16 Jul 2013 05:56:13 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Uz4mh-00019W-2i for; Tue, 16 Jul 2013 12:55:15 +0000
Resent-Date: Tue, 16 Jul 2013 12:55:15 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Uz4mY-00018D-N4 for; Tue, 16 Jul 2013 12:55:06 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1Uz4mX-0002pI-Kb for; Tue, 16 Jul 2013 12:55:06 +0000
Received: from [] ( []) by (Postfix) with ESMTP id 27D0BE6F48 for <>; Wed, 17 Jul 2013 00:54:41 +1200 (NZST)
Message-ID: <>
Date: Wed, 17 Jul 2013 00:54:37 +1200
From: Amos Jeffries <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-3.267, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1Uz4mX-0002pI-Kb 1befe88500bba820ec368647a97c584f
Subject: Re: Authentication over HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/18808
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 16/07/2013 10:04 p.m., Josh Howlett wrote:
>> That leaves only the application layer as the best suited for
>> authentication of identities (and/or resolution to attributes) that
>> the service needs for authorization (or even in the other direction).
>> This, I know, is a bit of a controversial opinion.  My proposal is
>> here:
>> (ah, I need to submit the WG version).
> I agree with this analysis. No single mechanism will meet every need. It
> is more important that HTTP has the agility to allow different mechanisms
> on a per-application basis, while maintaining a consistent presentation to
> users and application developers (as Nico's proposal allows). Binding
> specific mechanisms to the protocol, as in HTTP/1.1, would be an error IMO.

Binding what exactly? If you look through RFC 2616 there is no mention 
of authentication mechanism limits.

The mechanisms which we are all so familiar with today are defined in 
RFCs outside of the HTTP protocol spec and layered on top of HTTP 
headers. There is none of them which can be pointed at specifically and 
say "that is only possible with HTTP" or "HTTP only permits X, Y, Z 
mechanisms". HTTP simply defines some headers which are reserved for 
sending auth credentials per-hop or end-to-end, limiting to two sets of 
credentials concurrently on any hop. It is the application and 
implementations which determines which one is more appropriate to be 
used on any transaction and/or hop.

*Every single claim* that HTTP-auth is broken and needs re-designing 
seems to me to be based on the flawed assumption that HTTP-auth is not 
extensible and that the common existing schemes are the only ones HTTP 
permits. Or that somehow a user authenticating with N different and 
fragile mechanisms for one transaction is a good thing (I rather 
disagree, the UX on that would be tricky and implementation nightmares).