Migration - (te) openid.identity support? (by Nov)

[Nat Sakimura]

OpenID 2.0 has 2 identifier, openid.claimed_id & openid.identity. For historically reasons, some libraries/RPs are using openid.identity as user identifier, unfortunately.

Does this migration spec have plan to returning openid.identity? or just ignore such buggy libraries/RPs?

The biggest issue would be Y! inc & Y! Japan’s case. They have fragment component only in openid.claimed_id.

[Nat Sakimura]

Mike proposed wontfix in the list.

[Nat Sakimura]

Add text to the implementer's consideration.

There are OpenID 2.0 libraries that uses openid.identity instead of openid.claimed_id to link to the user account at the RP. This is a bug as openid.identity may be recycled. There are not many OpenID 2.0 providers who uses different string as openid.identity and openid.claimed_id however. Yahoo! and Yahoo! Japan seems to be the only large scale providers that falls under this category. In their case, by stripping out the fragment from the openid.claimed_id, you can get openid.identity. Those implementations who are using these buggy OpenID 2.0 libraries, they can adopt this strategy to link Yahoo! and Yahoo! Japan users to their local account.

[Edmund Jay]

fixes #956 - Migration - (te) openid.identity support? (by Nov)

→ <<cset ddae2048be74>>