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

Tue Mar 24 15:12:13 UTC 2009

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2486 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090324/83396525/attachment-0002.bin>