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

Tue Mar 24 17:11:51 UTC 2009

I give you the clever idea part.

It is just that we have enough interop issues with the existing spec.
I can see all sorts of unanticipated behaviors with RPs if an OP tried  
this.

I feel so conservative,  I must be getting old:)

John Bradley
On 24-Mar-09, at 9:43 AM, John Panzer wrote:

> 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 at 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090324/02e2bd58/attachment-0002.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/02e2bd58/attachment-0002.bin>