[OpenID] canonical Identifier URL, without using delegated authentication

Sun Jul 8 21:56:25 UTC 2007

For 6 and 7, as long as the Provider maintains the OpenID Authentication
request through the login redirects then it shouldn't be a problem.  It
just needs to maintain the state so once the user logs in they can
proceed, allow the OpenID request, and then have the Provider redirect
them back to the RP.

--David

From: Peter Williams [mailto:pwilliams at rapattoni.com] 
Sent: Sunday, July 08, 2007 2:53 PM
To: Recordon, David; general at openid.net
Subject: RE: [OpenID] canonical Identifier URL,without using delegated
authentication

The only amendment Id make concerns 6 and 7.

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

6) the sp/SsoHandler.aspx redirects the browser with 302 responses one
or more times, to some remote login-site where the user authenticates
however they need to, or is already authenticated.

7) after user authentication, the login site redirects the browser one
or more times back to sp/SsoHandler.aspx, whereupon the user allows the
transaction at their Provider which responds to the RP.

If we can agree that this is generally consistent with the intent and
model of OpenID, I'll go and build it. It would be merely an extension
of the OpenID experiment we already performed, with folks at
www.scardsoft.com.

FYI: 

The redirects on the front and back ends provide me with great added
value. They will allow me resolve such as XRIs without using a proxy
architecture. An XRI form of Claimed Identity
(https://mls.com/=Peter.Williams) can now be resolved as a side effect
of OP provider discovery. Similarly, a protocol of "trusted redirects"
can secure the discovery process itself, automatically deliver
name-federation-based name resolution, and optionally automatically use
pseudonyms to enforce privacy firewalls during a discovery run that the
discovery subsystem recognizes as crossing security domain boundaries.

-----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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070708/abea4a9d/attachment-0001.htm>