[OpenID] Delegation leading to new accounts on websites

[John Bradley]

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

> Date: Mon, 22 Jun 2009 11:44:03 -0400
> From: George Fletcher <gffletch at aol.com>
> Subject: Re: [OpenID] Delegation leading to new accounts on websites
> To: Andrew Arnott <andrewarnott at gmail.com>
> Cc: "general at openid.net" <general at openid.net>
> Message-ID: <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090622/bc6756e9/attachment.htm>