[OpenID] Delegation leading to new accounts on websites

Tue Jun 23 16:21:48 UTC 2009

We know from the old Bufu rule that the RP is responsible for testing that

"(identity claim == subscriber.OP.XRD[localID]) is element of user.XRD[localIDset]" ,

through an act of RP-discovery.

The RP is ALSO responsible for testing that yahoo.com has authority to make cross-realm claims (release a authoritative identity claim for the realm of homepw.org, which is outside the asserting parties OP-identifier realm of yahoo.com).

But how do I as RP test that Yahoo is so authorized?

Put in activeDirectory terms that a million Windows MCSEs can understand, how do I test that any one of 10 different UPNs in 10 different domains (peter at rapattoni.com<mailto:peter at rapattoni.com>, peter at homepw.com<mailto:peter at homepw.com>, ...) is "rapnt.com/pwilliams"?

Some synonym service has to be attesting to the cross-realm OP-identifier-bridging - and it cannot be the OP itself. under my RP obligations, I have to be able to authenticate the synonym service, and determine its authoritive for some synonym mesh.

In the delegation case, checking for LocalID intersections in the delegated-XRD and OP-XRD is not sufficient. One must discover the XRD for the OP identifier underlying the rapattoni.com or homepw.org domains that yahoo MAY provide as identity claims. I must ensure OP identifier underlying the claim's domain links back to OP identifier for the assertion domain - myopenid.com L authorizing the act of outsourcing (and the cross-domain assertion power).

All we have done of course is obligate the RP to discover/create now a "chain" of XRDs, much like one has chains of authority certs in SSL! But then, what is an XRDS, but a chain of XRD elements?  And, in the XRI resolution case, chain formation is done for you, where the particular chaining "route" is discovered in the delegation flow according to the user-controlled priorities and redirects/referalls - user-centric trust fabrics. If the user's vanity-XRD is being servered by an actual XRI server (in walled garden mode), that user gets a synonym-management service, of course. It _overlays_ the user-centric trust fabric of "who is authoritive", even when cooperating with OP identifiers that are perhaps formally registered in the public XRI space.

________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of Allen Tom [atom at yahoo-inc.com]
Sent: Monday, June 22, 2009 10:48 PM
To: John Bradley; general at openid.net; t_edwards at btinternet.com; Andrew Arnott
Subject: Re: [OpenID] Delegation leading to new accounts on websites

Hi John -

Your description accurately describes how the Yahoo OP is implemented, and it is the RP's responsibility to keep track of the user's URL that was delegated to the OP.

One possible possible issue is that Flickr itself delegates to Yahoo, so users are probably better off delegating to their default machine generated Yahoo OpenID (of the form https://me.yahoo.com/a/<random string>) than to to their Flickr Photos url.

Tom - can you try delegating your personal URL to your default Yahoo OpenID? This will eliminate the extra round trip to Flickr, which is probably causing your problem.  The easiest way to find out what your Yahoo OpenID is to go here:

http://openid.yahoo.com/
Click Get Started
Type in your password
and take a look at the identifiers at the bottom of the screen.

Unfortunately, this doesn't seem to work on GetSatisfaction. :/
Allen

John Bradley wrote:
George,

The combination of directed identity is still a real interop issue because it is not well explained in openID 2.0.

When the claimed_id (less fragment)  or the identity are different in the response from the request the RP must rediscover the openid.claimed_id.

If delegation was done the openid.identity must match the LocalID in the XRD.

If the RP doesn't do this step anyone with a Yahoo account can log into any openID that is delegated to Yahoo.

Yahoo is following the spec as intended.

There is an OSIS test for RPs to check if they are vulnerable to this.

If the second discovery verifies then 1 can still be used safely as the users identifier.

I had to sit Johnny Bufu down to explain it to me what they intended when they wrote 2.0.

I couldn't extract the logic from the spec itself for the delegating to a directed identity flow.

John B.

On 22-Jun-09, at 11:45 AM, general-request at openid.net<mailto:general-request at openid.net> wrote:

Date: Mon, 22 Jun 2009 11:44:03 -0400
From: George Fletcher <gffletch at aol.com<mailto:gffletch at aol.com>>
Subject: Re: [OpenID] Delegation leading to new accounts on websites
To: Andrew Arnott <andrewarnott at gmail.com<mailto:andrewarnott at gmail.com>>
Cc: "general at openid.net<mailto:general at openid.net>" <general at openid.net<mailto:general at openid.net>>
Message-ID: <4A3FA6C3.9060305 at aol.com<mailto:4A3FA6C3.9060305 at aol.com>>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Isn't one of the underlying issues the fact that there are really 3
identifiers in this scenario?
1. the identifier entered by the user (claimed_id or i-name)
2. the discovered/resolved identifier ("local_id" or "i-number")
3. the identifier returned by the OP

In the case of OpenID 2.0 protocol flow, the RP has to remember #1 and
send #2 as the openid.identity parameter. If the OP does NOT return
openid.identity == #2, then the OP has chosen to do directed identity
regardless of the request and the RP must throw out #1 and take #3 as
the user's identifier.

This causes some weird user experience issues, but this is what we ran
into when implementing OpenID 2.0 Relying Party support.

Thanks,
George

________________________________

_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general