<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">George,<div><br></div><div>The combination of directed identity is still a real interop issue because it is not well explained in openID 2.0.</div><div><br></div><div>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.</div><div><br></div><div>If delegation was done the openid.identity must match the LocalID in the XRD.</div><div><br></div><div>If the RP doesn't do this step anyone with a Yahoo account can log into any openID that is delegated to Yahoo.</div><div><br></div><div>Yahoo is following the spec as intended. </div><div><br></div><div>There is an OSIS test for RPs to check if they are vulnerable to this.</div><div><br></div><div>If the second discovery verifies then 1 can still be used safely as the users identifier.</div><div><br></div><div>I had to sit Johnny Bufu down to explain it to me what they intended when they wrote 2.0.</div><div><br></div><div>I couldn't extract the logic from the spec itself for the delegating to a directed identity flow.</div><div><br></div><div>John B.</div><div><br><div><div>On 22-Jun-09, at 11:45 AM, <a href="mailto:general-request@openid.net">general-request@openid.net</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="font-family: monospace; ">Date: Mon, 22 Jun 2009 11:44:03 -0400<br>From: George Fletcher <<a href="mailto:gffletch@aol.com">gffletch@aol.com</a>><br>Subject: Re: [OpenID] Delegation leading to new accounts on websites<br>To: Andrew Arnott <<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>><br>Cc: "<a href="mailto:general@openid.net">general@openid.net</a>" <<a href="mailto:general@openid.net">general@openid.net</a>><br>Message-ID: <<a href="mailto:4A3FA6C3.9060305@aol.com">4A3FA6C3.9060305@aol.com</a>><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>Isn't one of the underlying issues the fact that there are really 3<span class="Apple-converted-space"> </span><br>identifiers in this scenario?<br>1. the identifier entered by the user (claimed_id or i-name)<br>2. the discovered/resolved identifier ("local_id" or "i-number")<br>3. the identifier returned by the OP<br><br>In the case of OpenID 2.0 protocol flow, the RP has to remember #1 and<span class="Apple-converted-space"> </span><br>send #2 as the openid.identity parameter. If the OP does NOT return<span class="Apple-converted-space"> </span><br>openid.identity == #2, then the OP has chosen to do directed identity<span class="Apple-converted-space"> </span><br>regardless of the request and the RP must throw out #1 and take #3 as<span class="Apple-converted-space"> </span><br>the user's identifier.<br><br>This causes some weird user experience issues, but this is what we ran<span class="Apple-converted-space"> </span><br>into when implementing OpenID 2.0 Relying Party support.<br><br>Thanks,<br>George<br></span></span></blockquote></div><br></div></body></html>