- From: Adrien de Croy <adrien@qbik.com>
- Date: Thu, 01 Mar 2012 09:09:56 +1300
- To: Henrik Nordström <henrik@henriknordstrom.net>
- CC: Julian Reschke <julian.reschke@gmx.de>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, mnot@mnot.net, iesg@ietf.org, ietf-http-wg@w3.org, IETF-Discussion <ietf@ietf.org>
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
Received on Wednesday, 29 February 2012 20:10:24 UTC