[OpenID] [LIKELY_SPAM]Re: Problems with delegation and directed identity OPs

Tue Nov 11 04:15:47 UTC 2008

4.2.1.  Relying Parties

...

openid.claimed_id" is not defined by OpenID Authentication 1.1. Relying Parties MAY send the value when making requests, but MUST NOT depend on the value being present in authentication responses. When the OP-Local Identifier ("openid.identity") is different from the Claimed Identifier, the Relying Party MUST keep track of what Claimed Identifier was used to discover the OP-Local Identifier, for example by keeping it in session state. Although the Claimed Identifier will not be present in the response, it MUST be used as the identifier for the user.

"openid.identity" MUST be sent in a authentication request (Responding to Authentication Requests).

1.  Note in the last sentence,  a should be "an" - since folk are back in editing mode.

2.  More importantly, I cannot see how OpenID2 delegation is really that different from OpenID2 delegation - despite all that's been said. In OpenID1, keep the normalized URL, but ask for an assertion about the delegation value. In OpenID2: RP shall keep the claimed id, but ask for an assertion about the localid value.

3.  The only interesting case seems to be when >1 rounds of discovery occur, in response to processing one or more unsolicited assertions. If an unsolicited assertion is indicated, given the RP is retaining the required state for a request that cited a localid != original cliamedid, presumably the handling rule above now refers to the claimed id in the unsolicited assertion ... not that in the stored away during initiation of the current round of discovery/auth. Presumably if a followup round discovery produces (performed as oneMUST) and another localid != claimed id is determined, the first localid storage/state is discarded...and a 2nd/nth round of auth is required? Ad infinitum?

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Peter Williams
Sent: Sunday, November 09, 2008 10:55 AM
To: Andrew Arnott; Martin Atkins
Cc: OpenID List
Subject: Re: [OpenID] [LIKELY_SPAM]Re: Problems with delegation and directed identity OPs

Id recommend an openid.net 1000 word tutorial be written on the openid2 delgation model, adressing clearely how its security model is different to openid1.

I've read and reviewed the openid2 spec several times, and had not realized that fundamental delegation processes had changed (from what I saw in the janrain openid1.1 .net code).

Id realized that names and metadata fields had changed...but not that the security model had changed.

I had no idea that an op maintained identity page (with rdf tags, such as that of myopenid) was anything other than a nicety (that could be entirely eliminated).

________________________________

From: Andrew Arnott <andrewarnott at gmail.com>

Sent: Saturday, November 08, 2008 5:19 PM

To: Martin Atkins <mart at degeneration.co.uk>

Cc: OpenID List <general at openid.net>

Subject: [LIKELY_SPAM]Re: [OpenID] Problems with delegation and directed identity OPs

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<mailto:mart at degeneration.co.uk>> wrote:

This seems similar to what happened with clavid.com<http://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> <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> <mailto: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>

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

       <mailto: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> <mailto: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> <mailto:general at openid.net<mailto:general at openid.net>>

       http://openid.net/mailman/listinfo/general

------------------------------------------------------------------------

_______________________________________________

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/20081110/6ed151f0/attachment-0002.htm>