Proposal: ClaimOP -- what does it buy?

Boris Erdmann boris.erdmann at googlemail.com
Tue May 15 16:57:32 UTC 2007


Well,

two reasons:

a)

I outlined before (http://openid.net/pipermail/specs/2007-May/001643.html and
http://openid.net/pipermail/security/2007-May/000365.html) that the
current specification(s) allow for (corner?) cases where the browser
would have a hard time tracking the protocol flow from the start (at
the RP). This would either lead to an implied reduction of variability
or - due to complexity - to breakable browser implementations (imo).

That's why I made the proposition
(http://openid.net/pipermail/specs/2007-May/001640.html) in the first
place -- to discuss if the whole thing can be broken down to the
situation at the OP site, which can be perfectly controlled.

My approach makes OpenID not part of the problem ("openid is broken,
it can be phished") but part of the solution. I hope one can see the
idea behind my proposal.

b)

One of the cool things about OpenID is, that it works w/o me telling
my browser who I am. I can go anywhere on the planet, and don't have
to take my browser with me, but never the less OpenID works. That's
cool. My idea adds to that.

I don't like the idea of tying OpenID security to the fact, that it
would be safe if only I had my preconfigured browser at hand. My idea
doesn't necessarily need that. And I believe, that this is something
that would make OpenID unique compared to some other solutions.

That is not to say, that an Identity Manager is a bad thing in itself
-- but tying security to it, I think, is.

-- Boris


On 5/15/07, Dick Hardt <dick at sxip.com> wrote:
> If we work with the assumption that we can add code to the browser,
> then why not let the user configure the browser with their OP(s)?
>
> That puts the browser in the position of sending the user to the OP
> rather then the RP.
>
> -- Dick



More information about the specs mailing list