[dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing

[John Merrells <merrells at sxip.com>]

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
dix at ietf.org
https://www1.ietf.org/mailman/listinfo/dix