Voting starts in March for the Drupal Association Board election.
In current Drupal OpenID implementation Claimed ID are normalized and Claimed ID unique fragment (if provider uses it) is stripped. This is ok for normalization, but fragment is stripped also from Claimed ID which is going to be saved to the Autmap table and this is is violation of OpenID 2.0 specs, because we should store Claimed ID including the hash/fragment.
It is true that during normalization should be stripped:
... If the URL contains a fragment part, it MUST be stripped off together with the fragment delimiter character "#".
And is also true that the fragment must not be used for purpose of verifying discovered Information
11.2. Verifying Discovered Information
If the Claimed Identifier in the assertion is a URL and contains a fragment, the fragment part and the fragment delimiter character "#" MUST NOT be used for the purposes of verifying the discovered information.
But the fragment is very important! And identifiers MUST be stored including the fragment:
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.
11.5.1. Identifier Recycling
OpenID Providers with large user bases can use fragments to recycle URL Identifiers if it is so desired. When reassigning a URL Identifier to a new end user OPs should generate a new, unique fragment part.
The full URL with the fragment part constitutes the Claimed Identifier in positive assertions, therefore Relying Parties will distinguish between the current and previous owners of the fragment-less URL.
This mechanism allows the (presumably short, memorable) recycled URL Identifiers without the fragment to be used by end users at login time and by Relying Parties for display purposes.
This issue relays also onbecause claimed id entered by user (without fragment) and claimed id returned by provider (with fragment) could be different.
Additionally this issue is slightly related tobecause without following the redirects from http to https etc. some providers fails later to send correct claimed id including the unique fragment.
PASSED: [[SimpleTest]]: [MySQL] 29,460 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 29,394 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 29,398 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 31,576 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch openid_claimed_id_fragments_1076366-3.patch. View