Proposal: ClaimOP -- what does it buy?

[Boris Erdmann]

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