[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).