[OpenID] Problems with delegation and directed identity OPs
Andrew Arnott
andrewarnott at gmail.com
Sat Nov 8 22:19:47 UTC 2008
Reverting back to OpenID 1.1 style of delegation would break unsolicited
assertions when the OP is asserting a delegated Identifier. I thought of
another scenario or two that would break as well but I can't think of them
at the moment...
On Sat, Nov 8, 2008 at 12:05 AM, Martin Atkins <mart at degeneration.co.uk>wrote:
>
> This seems similar to what happened with clavid.com. When I tested their
> OP, they would accept OpenID 2.0 requests but always respond with 1.1
> responses. (They may have since fixed this.)
>
> The upshot of this was that the OpenID 1.1 responses didn't include
> openid.claimed_id because that argument didn't exist in OpenID 1.1, so
> things broke.
>
> There is scope for a careless OP to break delegation by failing to pass
> through openid.claimed_id as given. This was a concern I had when we added
> that argument in OpenID 2.0; in 1.1, it was the RP's responsibility to
> figure out how to maintain that state, and so some RPs did it by adding
> stuff to openid.return_to in the request and others maintained state at the
> RP server, but either way it was opaque to the OP and passed through
> correctly unless the OP did something really bizarre.
>
> I wonder if it would be a good idea to revert to the previous approaches
> for maintaining the delegation state at the RP, since clearly a faulty OP
> can break delegation with 2.0 as currently specified. I'm concerned that as
> we currently stand some 2.0-compatible libraries will be preserving this
> state in a 1.1-compatible way and thus will work correctly with Google's OP,
> while others will be relying on openid.claimed_id and break. I know that
> Net;:OpenID::Consumer for Perl relies on openid.claimed_id in 2.0 mode, but
> if that differs from everyone else's implementations I would consider making
> it do it the 1.1 way in all cases in order to be resiliant to broken OPs.
>
> Andrew Arnott 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/RP <
>> http://nerdbank.org/RP> using 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<mailto:
>> 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
>> <mailto:breno at google.com>> wrote:
>>
>> On Fri, Nov 7, 2008 at 4:48 PM, Allen Tom <atom at yahoo-inc.com
>> <mailto: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 <mailto: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 <mailto:general at openid.net>
>> http://openid.net/mailman/listinfo/general
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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/20081108/1c26f7f9/attachment-0002.htm>
More information about the general
mailing list