[OpenID] canonical Identifier URL, without using delegated authentication

[Recordon, David]

Hey Peter,
I think I'm following you...

1) The End User provides
https://login.rapmlsstg.com/IdpSsoHandler2.aspx?Target=https%3a%2f%2fsso
.rapmlsstg.com%3a12030%2fidp%2fstartSSO.ping%3fPartnerSpId%3drapattoni:s
tg:customer%26IdpAdapterId=STGIdp%26TargetResource%3dhttps%3a%2f%2petera
ccount.rapdata.com/&Contract=2 to the RP.
2) The RP fetches the Claimed Identifier which has a series of 302
Redirects (to a logged out user-agent...the RP) which end at
https://peteraccount.rapdata.com/.
3) https://peteraccount.rapdata.com/ is now the canonicalized Claimed
Identifier.
4) The RP performs discovery on the Claimed Identifier resulting in an
HTML-Based Discovery openid.server tag with the value of
https://login.rapmlsstg.com/sp/SsoHandler.aspx.
5) The RP redirects the user to
https://login.rapmlsstg.com/sp/SsoHandler.aspx with the appropriate
OpenID Authentication request.
6) The user authenticates however they need to, or is already
authenticated.
7) The user allows the transaction at their Provider which responds to
the RP.

--David

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Peter Williams
Sent: Friday, July 06, 2007 11:39 PM
To: general at openid.net
Subject: [OpenID] canonical Identifier URL,without using delegated
authentication

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:s
tg:customer%26IdpAdapterId=STGIdp%26TargetResource%3dhttps%3a%2f%2petera
ccount.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"?

 

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general