returning clamed_id is a wrong approach

[GoogleCodeExporter]

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

Original issue reported on code.google.com by m...@mail.ru on 18 Sep 2013 at 9:41

[GoogleCodeExporter]

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.

Original comment by mewp...@gmail.com on 18 Sep 2013 at 9:54

• Changed state: Invalid

[GoogleCodeExporter]

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?

Original comment by m...@mail.ru on 18 Sep 2013 at 10:12

[GoogleCodeExporter]

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.

Original comment by mewp...@gmail.com on 19 Sep 2013 at 9:19

[GoogleCodeExporter]

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

Original comment by m...@mail.ru on 19 Sep 2013 at 10:52

[GoogleCodeExporter]

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).

Original comment by mewp...@gmail.com on 19 Sep 2013 at 11:20