[OpenID] canonical Identifier URL, without using delegated authentication

[Peter Williams]

Let's test an edge case of the following "Note" in the specification:

		"The End User is NOT REQUIRED to prefix their Identifier URL with "http://" or postfix it with a trailing slash. Consumers MUST canonicalize the Identifier URL, following redirects, and note the final URL. The final, canonicalized URL is the End User's Identifier. " [http://openid.net/specs/openid-authentication-1_1.html]

This seems to imply that if the Consumer gets a series of 302 HTTP redirects it must follow the location headers in the response(s) till it receives a 200 response which also delivers an HTML resource (with at least markup for the openid.server link value).

Ok. Lets now pick a silly (but legal) edge case of this rule. Lets make the "Identifier URL" typed into the Login field [s3.2]:

https://login.rapmlsstg.com/IdpSsoHandler2.aspx?Target=https%3a%2f%2fsso.rapmlsstg.com%3a12030%2fidp%2fstartSSO.ping%3fPartnerSpId%3drapattoni:stg:customer%26IdpAdapterId=STGIdp%26TargetResource%3dhttps%3a%2f%2peteraccount.rapdata.com/&Contract=2

Ugh! You might say. But, such a convoluted value is really NOT beyond the realm of possibility for machine-based logon . We have all seen what Microsoft Word conversion to HTML did to the use of HTML markup, making it unreadable by humans!

Now, if we follow the Important Note in the spec, the Consumer shall apparently follow the redirects caused by that URL's resolution. As the resource at the URL happens to cause (for authorized users) an IDP-initiated SAML flow (via, say, the REDIRECT binding), a series of redirects will occur eventually landing on a site for the URL peteraccount.rapdata.com <http://www.peteraccount.crsdata.com>  etc (if the DNS registrations and SAML trust relations all hold up, at evaluation time).

>From what I can determine, once https delivers the HTML document (according to and satisfying the Consumer's SSL key management policy) the "final URL" is https://peteraccount.rapdata.com/ . This  string, furthermore, is the "final, canonicalized URL" ( in the absence of an openid.delegated link field value in the HTML document delivered over https). This is thus the "End User's Identifier".

------------

Lets continue the thought experiment:-

Lets say the that openid.server link value is https://login.rapmlsstg.com/sp/SsoHandler.aspx. We can note that this URL has little formal relationship to the End User's Identifier https://peteraccount.rapdata.com/ 

Nevertheless, the consumer can now expect to find an OP Provider listener at that link value URL. If this is true, the consumer agent and provider agent then engage in the "OpenID Authentication Protocol".

In the course of completing the protocol, the provider agent will normally be required to perform BY MEANS BEYOND THE SCOPE OF OPENID AUTH SPEC, user authentication - before it supplies the "cryptographic proof" that a user controls the End User's Identifier. After following some series of locally-defined redirects to a form-login page, users might perform this by completing the action of typing in a correct username/password combination.

Is there any flaw in my understanding, in any of the above? 

Are the example's "complying"?