TYPO3 Core

OpenID servers return several identifiers that can be used for user authentication. According to the speciciation openid.claimed_id is authoritative for authentication if it is set. openid.identity can be used but openid.claimed_id is more authoritative.

Usually those two identifiers are the same. But some OpenID servers (namely UNINETT AS server) provide different values for these identifiers. In such cases preferred value is in the openid.claimed_id as defined by the specification. However the code in the OpenID service fails to properly test that because of wrong priorities during checks.

Excerpts from the specification:

---------------------------------------------
Claimed Identifier: An Identifier that the end user claims to own; the overall aim of the protocol is verifying this claim. The Claimed Identifier is either:

• The Identifier obtained by normalizing the User-Supplied Identifier, if it was an URL.
• The CanonicalID, if it was an XRI.

OP-Local Identifier: An alternate Identifier for an end user that is local to a particular OP and thus not necessarily under the end user's control.
---------------------------------------------

Section "Positive assertions" (http://openid.net/specs/openid-authentication-2_0.html#positive_assertions):

---------------------------------------------
Positive assertions are indirect responses with the following fields:
...
openid.claimed_id

Value: (optional) The Claimed Identifier. "openid.claimed_id" and "openid.identity" SHALL be either both present or both absent.

Note: The end user MAY choose to use an OP-Local Identifier as a Claimed Identifier.

Note: If neither Identifier is present in the assertion, it is not about an identifier, and will contain other information in its payload, using extensions.

openid.identity

Value: (optional) The OP-Local Identifier

Note: OpenID Providers MAY assist the end user in selecting the Claimed and OP-Local Identifiers about which the assertion is made. The openid.identity field MAY be omitted if an extension is in use that makes the response meaningful without it (see openid.claimed_id above).
---------------------------------------------

Document “Open ID 2.0 to OpenID Connect Migration” (http://openid.net/specs/openid-connect-migration-1_0.html#ImplementationConsiderations) makes a note in the “Implementation consideration section”:

---------------------------------------------
There are OpenID 2.0 libraries that use 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. However, there are not many OpenID 2.0 Providers that use different values for openid.identity and openid.claimed_id. Yahoo! and Yahoo! Japan seem to be the only large scale providers that fall under this category. In their case, by stripping out the fragment from the openid.claimed_id, you can get openid.identity. For implementations that are using these buggy OpenID 2.0 libraries, they can adopt this strategy to link Yahoo! and Yahoo! Japan users to their local accounts.
---------------------------------------------

Section 11.5 (https://openid.net/specs/openid-authentication-2_0.html#identifying) of the specification says:
---------------------------------------------
11.5. Identifying the end user

The Claimed Identifier in a successful authentication response SHOULD be used by the Relying Party as a key for local storage of information about the user. The Claimed Identifier MAY be used as a user-visible Identifier. When displaying URL Identifiers, the fragment MAY be omitted.
---------------------------------------------

So all references say that we should use claimed id, not identity.

To follow the specification, fix the issue and preserve the compatibility with any other existing implementation, we should swap checks inside the OpenID service.