[OpenID] Problems with delegation and directed identity OPs

[Andrew Arnott]

Incidentally, I just tried delegated identity against
openid.live-int.com(Microsoft's Live OpenID) and Yahoo!'s anonymous
identifier.  Microsoft's
didn't work either.  But Yahoo!'s did.  (Well done again, Yahoo!)

Microsoft and Google both still have time to fix it, seeing as they both
state to be in beta phase.  I hope they fix it before they release.

On Fri, Nov 7, 2008 at 7:40 PM, Andrew Arnott <andrewarnott at gmail.com>wrote:

> So I whipped up a delegated claimed identifier for Google.  And guess
> what?! Google's OP is buggy.
>
> This is my delegated OpenID page that delegates to Google's OP:
> http://nerdbank.org/RP/rpgoogle.html
>
> It's magic contents are:
> <link rel="openid2.provider" href="https://www.google.com/accounts/o8/ud
> "/>
> <link rel="openid2.local_id" href="
> https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU
> "/>
>
> This works just like any other delegated thing.  Since Google provides
> pair-wise unique identifiers, I had to first log in to nerdbank.org/RPusing google directly, find out what identifier Google assigned for me at
> that RP, and then stick that into the above local_id field.  Then this
> delegated page will *only* work against that RP.
>
> Or at least that's what should happen.  In actuality Google changes the
> claimed_id though it shouldn't.  This is what it asserts:
>
> ClaimedIdentifier:
> https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU
> ProviderLocalIdentifier:
> https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU
> ProviderEndpoint: https://www.google.com/accounts/o8/ud
> OpenID version: 2.0
>
> And this is what was discovered at the delegated identity page:
>
> ClaimedIdentifier: http://nerdbank.org/RP/rpgoogle.html
> ProviderLocalIdentifier:
> https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU
> ProviderEndpoint: https://www.google.com/accounts/o8/ud
> OpenID version: 2.0
>
> The ClaimedIdentifier has been tampered with.  This Google's OP should note
> that the auth request was with its local_id but a 3rd party claimed_id and
> preserve the claimed_id so that delegation works.  They don't, and
> delegation breaks.
>
> So you see, it's not that they use directed identity that breaks
> delegation.  It's that their OP doesn't preserve the openid.claimed_id
> parameter.  I'm not sure if this is a strict contradiction to the spec, but
> it breaks scenarios, which stinks.
>
> I'll send this over to the Google folks and see what they have to say.
>
>
> On Fri, Nov 7, 2008 at 7:17 PM, Andrew Arnott <andrewarnott at gmail.com>wrote:
>
>> From the spec:
>>
>> Value: (optional) The Claimed Identifier.
>>
>> "openid.claimed_id" and "openid.identity" SHALL be either both present or
>> both absent. If neither value is present, the assertion is not about an
>> identifier, and will contain other information in its payload, using
>> extensions (Extensions).
>> So you can't include one without the other.  And having neither doesn't
>> provide any authentication at all.  Delegation *should* work, if you had
>> an openid identity page with a openid2.local_id tag that was exactly the
>> opaque RP-specific identifier that Google would assign the RP that you are
>> trying to log into.  That would mean you'd need a separate delegate page for
>> every single RP you log into... but it's theoretically possible.  It would
>> just be a maintenance nightmare. It would be interesting to test just to see
>> if Google actually implemented the spec correctly to handle *non*-directed
>> identity scenarios.
>>
>>
>> On Fri, Nov 7, 2008 at 5:40 PM, Breno de Medeiros <breno at google.com>wrote:
>>
>>> On Fri, Nov 7, 2008 at 4:48 PM, Allen Tom <atom at yahoo-inc.com> wrote:
>>> > Deron Meranda wrote:
>>> >> Of course, from an OP usability perspective, it's not exactly straight
>>> >> forward for somebody to determine their actual Yahoo identity(-ies),
>>> >> although it is possible.
>>> >>
>>> > We definitely can improve the usability, but you can list your Yahoo
>>> > OpenID identifiers by going to http://openid.yahoo.com and clicking on
>>> > the "OpenID Home link" at the top of the page.
>>> >
>>> >> And, just from curiosity, why are the randomly generated URIs
>>> >> (both Google and Yahoo!) so long?
>>> > :)
>>> >
>>> >> So, the current Google situation makes it almost impossible to use
>>> delegation!
>>> >>
>>> >>
>>> > Hmm, it does appear that it's impossible for someone to delegate their
>>> > OpenID to Google.
>>>
>>> The OpenID spec says that the op_local is an optional field. I think
>>> in practice libraries set identity=claimed_id in this case. I assume
>>> it is then unspecified how the OP validates that the user is
>>> authorized over that URL. That changes nothing from the RP
>>> perspective, because it always has to depend on the OP to make that
>>> judgment.
>>>
>>> Bottom line: The fact that the op_local technique is not available for
>>> usage with the Google OP does not mean that it cannot support
>>> delegation.
>>>
>>> >
>>> > Allen
>>> >
>>> >
>>> > _______________________________________________
>>> > general mailing list
>>> > general at openid.net
>>> > http://openid.net/mailman/listinfo/general
>>> >
>>>
>>>
>>>
>>> --
>>> --Breno
>>>
>>> +1 (650) 214-1007 desk
>>> +1 (408) 212-0135 (Grand Central)
>>> MTV-41-3 : 383-A
>>> PST (GMT-8) / PDT(GMT-7)
>>> _______________________________________________
>>> 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/20081107/6c73ea26/attachment-0001.htm>