> From: Nicolas Williams [mailto:[EMAIL PROTECTED]
> Hmmm, I'm not sure this is right, but what is right is that > the way to use SAML in HTTP is not as easily abstracted from > the application as an authentication layer in the HTTP > protocol would, and I'm not sure that DIX is any different > from SAML in this sense. Remember that each standards venue has its own constraints. SAML was one of the very first major OASIS specs. At the time SAML 1.0 started there were no browser providers at the table. The proposals made were limited to what was possible. Much has happened since, SAML is generally considered to be a successful protocol in certain areas. It is important enough to be on the list of 'no-brainer' infrastructure that other proposals in the area have to support. The blog pain point has appeared. Phishing is rife. The browser providers have a major interest in locking down the inbound and outbound authentication processes. I think that we certainly do need to have a zero footprint solution. We should be aware that we have the opportunity to go further here and make proposals that do depend on browser changes, particularly in the area of proposals that support the concept of secure chrome.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
