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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf