Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

I wonder if it would be helpful for people to outline what they expect 
are the issues to be solved by doing more work on an HTTP auth mechanism.

I get the feeling that some think the scope would encompass providing 
auth support for web applications, whereas others are mainly concerned 
with the transport level auth.

IMO http auth is not particularly suited to solve the issues required 
for web site authors, for the simple issue of administrative boundaries 
and realms of accounts.

For example the web server that sits on an OS that has 1 user database, 
yet hosts 10 web sites each of which require their own independent user 
database, and require the ability to create and destroy accounts, and 
these accounts NOT be OS ones (i.e. not grant any access to the OS).  
Sure these issues could be engineered around, but it would add to the 
current scope (for change) every web application that currently manages 
accounts (a great deal of them).

If we're just talking about transport auth, then what's wrong with 
something like kerberos.  As for server logging a client out, the auth 
mechanism would need a token that can be revoked by the server, since 
one cannot rely on client co-operation in such a matter.  A kerberos 
ticket seems to fit this bill.  then we'd just need a mechanism for a 
client to request revokation (logout).  It is also AFAIK supported on 
all server platforms, unlike any auth mechanism that requires access to 
plaintext passwords at the server end - these are not always available.

Adrien


On 26/02/2012 3:03 a.m., Julian Reschke wrote:
> On 2012-02-25 14:46, Stephen Farrell wrote:
>> ...
>> Yeah that's a tricky one. While one might like to
>> see "one or more" in both places that might not be
>> practical.
>>
>> In the proposal above the goal is that httpbis pick one
>> or more but recognising the reality that we might not get
>> a new proposal that httpbis will accept and that folks
>> will really implement and deploy.
>>
>> So:
>> Goal = one or more
>> Reluctant recognition of reality = zero or more
>>
>> With this plan if httpbis in fact select zero new proposals
>> that would represent a failure for all concerned. The "zero
>> or more" term is absolutely not intended to provide a way to
>> just punt on the question.
>>
>> Such a failure at the point where httpbis was re-chartering
>> to work on a HTTP/2.0 selection with no better security than
>> we now have is probably better evaluated as a whole - I
>> guess the question for the IETF/IESG at that point would
>> be whether the Internet would be better with or without
>> such a beast, or better waiting a while until the security
>> thing did get fixed.
>>
>> I can imagine an argument might ensue about that;-)
>> ...
>
> If we just need a new authentication scheme, nothing stops people from 
> working on that right now. I don't see how that should affect HTTP/2.0.
>
> If the "right" way to do security needs changes in the HTTP/1.1 
> authentication framework, then we should fix/augment/tune HTTP/1.1. 
> It's not going to go away anytime soon.
>
> Best regards, Julian
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Sunday, 26 February 2012 01:54:35 UTC