Proposal: ClaimOP -- what does it buy?

[Dick Hardt]

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

On 15-May-07, at 8:43 AM, Boris Erdmann wrote:

> This post continues "Proposal: ClaimOP -- an in-band OP identity
> system" and "Proposition: possible anti-phishing solution".
>
> So what does ClaimOP provide?
>
> It provides browsers with
>
> a) a sure way to detect an OPs looping-in login (LIL) page
> b) sure access to the credential data of a LIL page
> c) enough information to validate an OP's compliance to ClaimOP.
>
>
> What do we get from that?
>
> By means of discovery/YADIS the openid identifier (and as such the
> credential data) carry in-band information about where the credentials
> are allowed to go to. Browsers can easily check the realms of
>
> * the LIL page
> * the form action attribute
> * the discovered openid.server / openid.provider
> (* a yet to be discussed "openid.cred_destination" as part of
> discovery -- if we like that)
>
> to match certain criteria. In consequence a user could never post a
> password to a destination that is not authorized for a specific
> OpenID.
>
>
> Are there issues?
>
> As can easily be seen, ClaimOP shifts a phisher's task from faking
> (RP, OP) to faking identifiers: A malicious OP could fully comply to
> ClaimOP -- but to trick a user into delivering a certain identifier's
> password it has to provide an openid.identifier that
>
> a) is under the realm of the malicious OP
> b) looks similar enough to the users original openid
>
> So a browser has to provide methods to make such fakes visible to
> users. But I think that this is solvable task, since it shifts a users
> focus to a well known and often verified string of characters. Two
> things come to mind:
>
> a) Browsers could always display some kind of "visual hash" next to an
> identifier -- easy to remember and identify. Users would easily
> recognize a change of that. (That needs to be specified)
> b) Browsers could remember OpenIDs. Each first time a new openid has
> to be verified by letting a user retype their id. Faked ids would be
> instantly detected.
>
> -- Boris
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>