Hi Nico,
let me also point to the TLS Inner/Application draft here:
http://tools.ietf.org/wg/tls/draft-funk-tls-inner-application-extension-02.txt
It also tries to accomplish the goals mentioned below.
Ciao
Hannes
Nicolas Williams wrote:
On Sun, Mar 26, 2006 at 02:12:18AM -0600, Eliot Lear wrote:
Robert Yates wrote:
1. Eliot's dad wants to remember one userid and password for the web.
He also wants to use the same mechanism for IMAP a/o POP, SMTP to his
MSA, and calendaring. As a stretch goal he may want to use the same
mechanism to authenticate through on 802.1x, but I would admit that this
could prove challenging.
There was a BoF at Paris, but insufficient bodies to do the proposed
work then, for a Generally Useful Authentication Mechanism (GUAM)
framework so that we could end up with a suite of mechanisms for EAP,
SASL and the GSS-API.
There is now an I-D (draft-salowey-guam-mech-00.txt) for GUAM. And more
work will follow.
This combined with some additional HTTP authentication using the GSS-API
(beyond what Negotiate can do) and the new SASL/GSS-API bridge
(draft-josefsson-sasl-gs2-00.txt), improvements in digest mechanisms,
and applying GUAM principles to any remaining populate mechanisms should
go a long way to meeting this requirement.
Coroporate networks tend to use lots of these protocols and plenty of
browser-based applications too. Which is why I would insist on any
solutions in this problem space at the very least not preclude being
extended to work in non-browser contexts. But I think such a
requirement wouldn't be difficult to meet.
Nico
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
