[OpenID] Directed Identity vs. "what the user typed"

[Peter Williams]

For reference, Ping identity have done the following for a year or more and contributed the method to a standards group

For user typed input of peter at rapattoni.com<mailto:peter at rapattoni.com>, the RP get metadata (not xrds format, but SAMl2 format) via backchannel GET from saml2.rapattoni.com. If that fails, from Rapattoni.com. The results in a SSO endpoint (a service URL), and the IDP entity name (a naming URL). The relying party then redirects the user, not to Rapattoni.com, but to the SSO endpoint, which could be anywhere.

One difference between the proposal here and what they do is that the dynamically sign the metadata. One might dynamically sign the XRDS, of course. The Ping solution optionally uses strong names to detect the authenticity of the signed metadata, based on the semantics of the https URL scheme applied to the locator used for retrieving metadata.


If one were to be using the SAML account linking modes, the user typed input of peter at rapattoni.com<mailto:peter at rapattoni.com> could be dynamically linked at the RP to the asserted subject name (a persistent pseudonym claimed identifier in openid terminology) upon receiving the assertion. If the RP maintains state to retain the user typed input (as in openid delegation state management), such account linking could be automatic - and be private to the browser and RP.


From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Andrew Arnott
Sent: Monday, March 23, 2009 10:10 PM
To: John Panzer
Cc: Martin Atkins; general at openid.net
Subject: Re: [OpenID] Directed Identity vs. "what the user typed"

The user part is never sent to the OP, regardless of the RP's implementation.  Discovery is performed with an HTTP GET on either user at domain.com<mailto:user at domain.com> or domain.com<http://domain.com>.  Discovery results in the OP endpoint URI and an identifier_select claimed identifier.  The RP then redirects the user, not to domain.com<http://domain.com>, but to the OP endpoint, which could be anywhere, and certainly does NOT include the user@ portion because the redirect is determined by the OP's advertised OP endpoint via their XRDS document.

So the OP never sees user1@ or user2 at .  The RP has no way to correlate user1@ to a user account or a claimed identifier on the OP, and the RP never sees user2@ because the claimed identifier is not in the form of an email address. :)

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire

On Mon, Mar 23, 2009 at 6:26 PM, John Panzer <jpanzer at acm.org<mailto:jpanzer at acm.org>> wrote:
On Mon, Mar 23, 2009 at 11:06 AM, SitG Admin
<sysadmin at shadowsinthegarden.com<mailto:sysadmin at shadowsinthegarden.com>> wrote:
>> Of course, a user can also enter some other email address in the same
>> domain and have it quietly switch on him when he logs in.
Stupid question:  Seems to me that the OP can deal with this, assuming
that it does get the "user" part of the "user at domain.com<mailto:user at domain.com>" URL.
According to the HTTP spec, it should, and at least JSP frameworks
were able to pick up on this last time I checked.  (It's equivalent to
HTTP Basic auth, but without sending a password, which gives you an
empty password.)  This could be used for pre-filling forms, or for
selecting the "right" identity from a set already pre-authenticated at
the OP, or just for warning the user "you said X, about to change that
to Y, click OK to continue".
_______________________________________________
general mailing list
general at openid.net<mailto: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/20090324/b257ead5/attachment-0002.htm>