Re: Authentication over HTTP

[Amos Jeffries <[e-mail]>]

On 17/07/2013 5:34 a.m., Nico Williams wrote:
> On Tue, Jul 16, 2013 at 7:54 AM, Amos Jeffries <[e-mail]> wrote:
>> *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).
> That's either a strawman or you misunderstood the arguments against
> doing authentication in HTTP.  It's not that "HTTP auth is broken",
> but that HTTP is the *wrong layer* -- that's not because HTTP or HTTP
> auth is broken, but because properties of the stack of protocols
> spoken make HTTP auth a problematic proposition.
>
> BTW, I've not see any arguments about N different mechanisms (fragile
> or not) being a problem.

Maybe I have been misunderstanding some of them. But the auth proposals 
I've seen in the last few years all seem to fall into three brackets 
with regards to their claims about HTTP:

1) "HTTP auth is broken". Aka "do it all in payload entities and have 
HTTP endpoints interpret those" ... well so what? payload format is not 
HTTP. Good luck but go away and do it at a different layer.

2) "HTTP auth is broken". Aka the headers dont let me login user X to 
proxy A and proxy B at the same time, in the same chain, with different 
credentials all controlled by user X ... seem to be making a few wrong 
assumptions about how HTTP works there. Go away and do (1) instead the 
user-application ha sa lot more control over end-to-end pathways in 
application layer.

3) "HTTP auth is broken". Aka its missing a scheme to do mechanism Z ... 
and we do see these followed by specs to do Z in HTTP. But none of them 
are exactly replacing the existing HTTP mechanism design, just extending 
it as it was intended to be extended.

What am I missing?

Amos