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

[Andrew Arnott]

Hi John,
Your idea for a dynamic XRDS at the OP that manages to pass a parameter to
the OP endpoint is very interesting.  It sounds like it might work. :)

If the OP were to send an assertion that included a user component in the
claimed identifier that was actually significant, I would fear that most RPs
would ignore it and thereby allow identity spoofing.  Perhaps OpenID 2.1 can
clarify this.
--
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


2009/3/23 John Panzer <jpanzer at acm.org>

> On Mon, Mar 23, 2009 at 10:10 PM, Andrew Arnott <andrewarnott at gmail.com>
> wrote:
> > 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 or domain.com.
>
> Not clear on whether OpenID normalization requires stripping the user@
> part, but notionally user at domain.com/ is a valid URI and could be used
> for discovery.
>
> Discovery results in the OP endpoint URI and
> > an identifier_select claimed identifier.  The RP then redirects the user,
> > not to 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.
>
> The XRDS document could be generated dynamically based on the $USER
> variable, thus incorporating the data as an argument to the OP
> endpoint.  This would of course rule out a static XRDS file.
>
> > 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. :)
>
> What stops the OP from sending back a URI http://user2@example.org/?
>
> I am not advocating for any of this, just pushing the boundaries a bit.
>
>
> >
> > On Mon, Mar 23, 2009 at 6:26 PM, John Panzer <jpanzer at acm.org> wrote:
> >>
> >> On Mon, Mar 23, 2009 at 11:06 AM, SitG Admin
> >> <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" 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
> >> http://openid.net/mailman/listinfo/general
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090323/405b4ad9/attachment-0002.htm>