There is one other thing I would add to auth:
Ability for a challenger to identify itself, and for a response to
target a challenger.
Currently with chained proxies, it's not possible to reliably pass
challenges and creds back to the client. A proxy looking at a request
would need to maintain state to know if it challenged the client or not.
Adding a parameter to the challenge and response which identifies the
challenger would allow for this.
In fact it would then allow proxy and server auth to use the same
mechanism and headers.
Adrien
On 1/03/2012 8:19 a.m., Henrik Nordström wrote:
tis 2012-02-21 klockan 19:50 +0100 skrev Julian Reschke:
Well, we have an existing authentication framework. It would be
interesting to find out what's missing from it.
My take is better secure authentication schemes (not plaintext password
based) which is cleanly specified to a level that implementations
actually interop properly, and the ability for site owners (and proxies)
to influence how the login process is presented to users in a safe
manner that do not collide with preceived https security or makes a mess
for matchine<->machine communication not involving humans.
The existing HTTP auth framework works in general very well for
machine<->machine.
This said I have used HTTP Digest authentication quite successfully (but
with a number of interop workarounds) with non-tech users using the
default login box, only providing a good error response message seen if
the user cacels of fails the login.
Regards
Henrik
--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf