OpenID spec violation. Extract Authentication data - *search* for OP Identifier element [#579448]

OpenID 2.0 Authentication 7.3.2.2. Extracting Authentication Data:

Once the Relying Party has obtained an XRDS document, it MUST first search the document (following the rules described in [XRI_Resolution_2.0]) for an OP Identifier Element. If none is found, the RP will search for a Claimed Identifier Element.

SO:

First, Drupal should search throught the XRDS document, trying to find whether it contains an OP Identifier element which is a Service element, containing a Type tag with the text content "http://specs.openid.net/auth/2.0/server" and a URI tag (the text content is the OP endpoint URL Drupal must use to do authentication requests).

If Drupal cannot find this OP Identifier element, it should try to find a Claimed Identifier Element which is a Service element, containing a Type tag with the text content http://specs.openid.net/auth/2.0/signon", a URI tag (containing the OP endpoint URL as above) and an optional LocalID tag (an identifier used by the OpenID provider to identify the user).

This issue is brought to you by the OpenID 2.0 Compliance Crusade

Comment	File	Size	Author
#6	openid-xrds-3.patch	19.9 KB	c960657
#6
#5	openid-xrds-2.patch	20.18 KB	c960657
#5
#2	openid-xrds-1.patch	19.77 KB	c960657
#2

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

alex_b CreditAttribution: alex_b commented 12 January 2010 at 19:35

Comment #2

c960657 CreditAttribution: c960657 commented 16 January 2010 at 23:53

Status:

Active

» Needs review

File	Size
openid-xrds-1.patch	19.77 KB

This patch searches for the two different service elements as described in the OpenID spec. It also adds support for the priority attribute for the Service element as described in the XRI spec, section 4.3.3.

In openid_complete() the verification no longer uses $services[0] but loops through all discovered services. Section 11.2 of the spec says:

If the Claimed Identifier was not previously discovered by the Relying Party (the "openid.identity" in the request was "http://specs.openid.net/auth/2.0/identifier_select" or a different Identifier, or if the OP is sending an unsolicited positive assertion), the Relying Party MUST perform discovery on the Claimed Identifier in the response to make sure that the OP is authorized to make assertions about the Claimed Identifier.

I'm not completely sure how this is done. For now I look for service elements with the type either http://specs.openid.net/auth/2.0/signon or http://specs.openid.net/auth/2.0/server.