<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi John - <br>
<br>
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.<br>
<br>
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 <a class="moz-txt-link-freetext" href="https://me.yahoo.com/a/">https://me.yahoo.com/a/</a><random
string>) than to to their Flickr Photos url.<br>
<br>
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:<br>
<br>
<a class="moz-txt-link-freetext" href="http://openid.yahoo.com/">http://openid.yahoo.com/</a><br>
Click Get Started<br>
Type in your password<br>
and take a look at the identifiers at the bottom of the screen.<br>
<br>
Unfortunately, this doesn't seem to work on GetSatisfaction. :/<br>
Allen<br>
<br>
<br>
<br>
John Bradley wrote:
<blockquote cite="mid:51D44F1F-986A-4AB2-A55D-6BA556402DB8@wingaa.com"
type="cite">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 moz-do-not-send="true"
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-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span
class="Apple-style-span" style="font-family: monospace;">Date: Mon, 22
Jun 2009 11:44:03 -0400<br>
From: George Fletcher <<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>><br>
Cc: "<a moz-do-not-send="true" href="mailto:general@openid.net">general@openid.net</a>"
<<a moz-do-not-send="true" href="mailto:general@openid.net">general@openid.net</a>><br>
Message-ID: <<a moz-do-not-send="true"
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>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
general mailing list
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
</pre>
</blockquote>
<br>
</body>
</html>