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

Tue Mar 24 16:43:39 UTC 2009

Just to be clear, this was more of a thought experiment; the new XRD 
spec is clearly the right long term way to go <taps foot impatiently>.  
(This might, possibly, be a somewhat useful short term transitional hack 
in moving from XRDS to XRD_new, but I'm not even going to advocate for 
that.)

John Bradley wrote:
> John Panzer is correct that a site could dynamically generate a XRDS 
> based on the user part of the URI authority segment.  Lots of things 
> are possible but that doesn't necessarily make them good ideas:)
>
> I don't want to start a philosophical debate over the equivalence or 
> lack there of between http://jbradley@ve7jtb.com vs 
> mailto:jbradley at ve7jtb.com.
>
> But some (W3C) will say treating them as equivalent jeopardizes the 
> integrity of the web and perhaps the space time continuum it self.  
> Again not my argument:)
>
> In the new XRD spec and specifically LRDD 
> http://tools.ietf.org/html/draft-hammer-discovery-02 and site meta 
> http://tools.ietf.org/html/draft-nottingham-site-meta-01 there will be 
> a way to use a mailto: URI directly in discovery if individual 
> protocols decide they want to.
>
> We are sidestepping the philosophical questions of equivalence and 
> cross scheme authority.  If a client lib (openID ) performs LEDD on 
> http://ve7jtb.com and finds a template for the mailto: scheme that 
> translates it into a https:// URI the protocol would be free to use 
> the discovered XRD from our point of view.
>
> A number of Google and Yahoo people are contributing to the new 
> specs.  They are not done yet but Will Norris all ready has sample 
> code for testing.  The specs will be done ASAP but there are still 
> signing and other trust model issues that need to be finalized.  
> People should have a look at the above specs if they haven't already.  
> You will be seeing more of them in the future.
>
> Regards
> John Bradley
>
>
> On 24-Mar-09, at 5:06 AM, general-request at openid.net wrote:
>
>> Date: Mon, 23 Mar 2009 22:33:03 -0700
>> From: Andrew Arnott <andrewarnott at gmail.com>
>> Subject: Re: [OpenID] Directed Identity vs. "what the user typed"
>> To: John Panzer <jpanzer at acm.org>
>> Cc: Martin Atkins <mart at degeneration.co.uk>, general at openid.net
>> Message-ID:
>>     <216e54900903232233l2366388bgaef244cfc89214c9 at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> 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://openid.net/pipermail/general/attachments/20090323/405b4ad9/attachment-0001.htm> 
>>
>