On 2-Jun-06, at 8:01 AM, Sam Hartman wrote:
I think we view the requirements somewhat differently or at least view what requirements need to be solved when somewhat differently.
Yes, that may well be the case. We're coming at this from a different angle than you.
I'm OK with a solution that supports situations where I have a single alegidly unique identifier today
I'm not sure if you're saying this but... DIX does not impose any specific number of identifiers on a user. They can have as many as they choose to have, from 0 to infinity.
but that can transition to more complex forms of identity claims in the future. You seem to want sets of identity claims today.
I find the 'claim' term to be a bit ambiguous, so try to avoid it. I'm not
sure how claims relate to identifiers in your comment above. The DIX protocol draft specifies how the an attribute value assertion can be moved between parties... and the assertion draft shows how those attribute value assertions could actually be third party attested attribute value assertions. The benefits are that websites that use common property names will get more data of better quality and users won't have to deal with tedious user registration forms.... And... if we can move around third party assertions (Beth>21) then we have a safer more productive internet.
I'm much more interested in reusing existing security technology and am not interested in working on entirely new protocols.
Well, we are too. Hence the reuse of SAML/HTML/HTTP/HMAC, etc. We're just bringing the bits together in such a way that the barrier to adoption (the really big problem) can be as low as possible.
(And I do see this as a security problem which may also be a difference in how we come at this.)
Yes, we're coming at this from a slightly different angle... not that security isn't important, but we feel that we can provide real value with just enough security... and show a roadmap of how people can move up to more security when they need it.
I consider requirements related to binding things together at multiple levels (4.4 in my draft) really critical to forward progress on phishing. A lot of people disagree with me. One on one I have been able to convince people that I'm right, but the text in the current section 4.4 clearly does not stand on its own and needs significant revision.
I agree with you.
Finally, I think it critical that whatever solution we have here needs to work both with non-web HTTP applications (atompub, caldav, webdav, deltav) and with non-HTTP applications. I'd hate to see people pushed towards HTTP as a substrate to get better identity management.
I agree too. I think the DIX messages could be mapped onto other protocols, or pushed down into the stack. Our approach though has been to try to avoid changing any code and any user behaviour. Not easy.
Needless to say my vision of the solution space is different because I view these requirements differently.
Yes.
I am working on a specific solution proposal to demonstrate that what I want to do can be accomplished with incremental changes to existing technology.
I'm looking forward to reading that. I hope you get buy in for solving the
secure user authentication problem. John _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
