Issue 72: returning clamed_id is a wrong approach
Status:  Invalid
Owner: ----
Closed:  Sep 2013
Reported by m...@mail.ru, Sep 18, 2013
In some cases there are possible situations when using different claimed-id we would get them resolved to same identity by OP. Thus need to return that identity from OP, not a claimed one
Sep 18, 2013
Project Member #1 mewp...@gmail.com
And in many other situations, using one claimed id can lead to multiple different OP-local identities, so we need to return the claimed id.

Besides, Section 14.2.1 of the specification says:

  Although the Claimed Identifier will not be present in the response, it MUST be used as the identifier for the user. 

And that's the reason LightOpenID returns the claimed id. It won't break the specification, especially since it doesn't really make sense to do so.
Status: Invalid
Sep 18, 2013
#2 m...@mail.ru
hmm, really... Did not notice that...

But what is rationale behind this?

How to deal with, eg, google? it's claimed id is, as I see https://www.google.com/accounts/o8/id

Have all of the users share it? how then we would distinguish among them?
Sep 19, 2013
Project Member #3 mewp...@gmail.com
Firstly, in case of google, the claimed id is NOT https://www.google.com/accounts/o8/id . It's the same as op-local id, by default. https://www.google.com/accounts/o8/id is just a discovery url.

Basically, openid supports two modes, signon -- which you already know, and server, which google uses. The latter lets an user choose his ID after discovery, so the discovery url isn't used as a claimed identifier.

Try to log in with google and see the results.

As for the rationale: the claimed identifier is an url that you have control of. OpenID is a protocol that lets websites determine if you are indeed the owner of that url. The op-local identifier is just something that providers use to identify their user.

The case you've mentioned that multiple claimed identifiers point to one op-local id is perfectly valid - it might simply mean that someone wants to have multiple identities. On the other hand, if someone wants to change a provider, he could simply point his claimed identifier to another provider (and another op-local identifier). In both cases, using the op-local id as a username would be harmful to the user.
Sep 19, 2013
#4 m...@mail.ru
yeah, I did look.

let suppose my website intended to have 1-1 user-to-account relationship. Then same user claims he is `user1`and receives claimed id like this: http://openid.mail.ru/mail/user1 and op local id as http://user1.id.mail.ru. Also, (just for example, not sure about mailru)
he then claims he is `user.1` (by that mail service rules, both these names are mapped to same user, for example) and in that second case his claimed id becomes http://openid.mail.ru/mail/user.1 BUT op local id still unchanged: http://user1.id.mail.ru

So how can I rely on claimed ID?

You can check it with google, it allows such dotted aliases

Best Regards
Sep 19, 2013
Project Member #5 mewp...@gmail.com
Your first problem is assumption that you can and should have 1-1 user-to-account relationship. You should instead think about 1-1 user-to-openid relationship.

When someone logs in with a different claimed id, simply assume that it's a different user.

Besides, if I recall correctly, nothing stops another provider from using, for example, google's op-local identifiers (that's why they're "op-local"). That means that I can create a provider that will return op-local identifiers for mail.ru. That would be a huge security hole if you used that for user names, wouldn't it?

Anyway, this is a bug report, and as you've seen, it's not a bug. If you want a more detailed explanation why the protocol was designed that way, try asking on StackOverflow, or something. LightOpenID will not go against the protocol specification even if I disagree with it (which is not the case).