Hi Adrien, On Sun, Feb 26, 2012 at 02:54:01PM +1300, Adrien de Croy wrote: > > 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. I am personally concerned with the risk that new auth schemes continue to mix messages and transport. I don't think we need to define these new schemes, we just need to ensure the new protocol offers provision for doing the things right. I'd like to ensure we never get a new NTLM-like design error which forces every implementation to break the HTTP model to try to be compatible. Also, (that's not directly related to auth) it would be nice if we could have a random session ID in messages that browsers would send to help the whole intermediary chain select the appropriate server. A simple hash on this session ID would make load balancing much easier and much more reliable than any other algorithm right now and would definitely help when challenge based auth schemes are needed. (...) > 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. It is comparable to what is already done with cookies in most applications (ie I have nothing against this). We just have to keep in mind that auth methods will change with time. Many applications right now expect two-factor auth and/or some complex UI adaptations to protect against malware. That's why I think that our work on supporting auth should mainly ensure we offer the solid blocks for building new auth schemes and don't necessarily need to define these schemes ourselves. Regards, Willy _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf