Could use rel-me to point from the old claimed id to the new user identifier.<div><br></div><div>So Connect&#39;s user info API includes an &quot;openid2_url&quot; parameter with the value of <a href="http://profiles.server.com/daveman692">http://profiles.server.com/daveman692</a> and a Connect user identifier of <a href="https://profiles.server.com/i1b8qklb12kb93">https://profiles.server.com/i1b8qklb12kb93</a>.</div>
<div><br></div><div>RP fetches <a href="http://profiles.server.com/daveman692">http://profiles.server.com/daveman692</a> and looks for &lt;link rel=&#39;me&#39; href=&#39;<a href="https://profiles.server.com/i1b8qklb12kb93">https://profiles.server.com/i1b8qklb12kb93</a>&#39; /&gt;.</div>
<div><br></div><div>--David<br><div><br><br><div class="gmail_quote">On Sat, May 29, 2010 at 5:32 PM, John Bradley <span dir="ltr">&lt;<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
To do that with openID 2.0 we would need to create a new attribute to communicate the old claimed_id.<br>
<br>
There is no reason that would&#39;t work.<br>
<br>
Two things are required:<br>
<br>
1 a old claimed_id attribute.  (In connect the profile page could be used for that, but it might be better to be more specific)<br>
2 a discovery document at the old claimed_id that has a service or link  pointing to the new claimed_id.<br>
<br>
That won&#39;t work for some services using PPID like identifiers,  however the solution for them is to not change the claimed_id if migrating to Connect.<br>
<br>
John B.<br>
<div><div></div><div class="h5">On 2010-05-29, at 4:48 AM, Nat Sakimura wrote:<br>
<br>
&gt; So, who is going to draft the spec?<br>
&gt;<br>
&gt; As I have stated earlier, I would like to generalize it a little bit more than<br>
&gt; just openid2/connect.<br>
&gt;<br>
&gt; This would be very useful to solve &quot;the openid2 provider shutting down<br>
&gt; problem&quot; as well.<br>
&gt;<br>
&gt; =nat<br>
&gt;<br>
&gt; On Sat, May 29, 2010 at 2:51 PM, David Recordon &lt;<a href="mailto:recordond@gmail.com">recordond@gmail.com</a>&gt; wrote:<br>
&gt;&gt; +1 Allen/John<br>
&gt;&gt;<br>
&gt;&gt; On Fri, May 28, 2010 at 11:35 AM, Allen Tom &lt;<a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hi Nat -<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The high level strawman proposal that John Bradley and I briefly discussed<br>
&gt;&gt;&gt; was:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 1) return the user&#39;s OpenID 2.0 identifier as an attribute in the Connect<br>
&gt;&gt;&gt; assertion (along with the new Connect ID)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 2) Update the OpenID 2.0 discovery document for the identifier to list the<br>
&gt;&gt;&gt; to OpenID Connect endpoint as a &quot;connect/openid2&quot; migration service.<br>
&gt;&gt;&gt; Connect<br>
&gt;&gt;&gt; RPs are supposed to perform OpenID 2.0 discovery on the OpenID 2.0<br>
&gt;&gt;&gt; identifier to make sure that the Connect OP is also authorative for the<br>
&gt;&gt;&gt; OpenID 2.0 identifier<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Implementing #1 and #2 will allow an existing OpenID 2.0 RP that already<br>
&gt;&gt;&gt; has<br>
&gt;&gt;&gt; OpenID 2.0 users to migrate their existing users to Connect without<br>
&gt;&gt;&gt; requiring users to auth twice during the migration process.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Does anyone see a problem with this approach?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Allen<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On 5/27/10 7:06 PM, &quot;Nat Sakimura&quot; &lt;<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; My suggestion here is to include both the old and new identifier in a<br>
&gt;&gt;&gt;&gt; signed assertion,<br>
&gt;&gt;&gt;&gt; with a sunset set for the old identifier. It could be either OpenID<br>
&gt;&gt;&gt;&gt; assertion or XRDS.<br>
&gt;&gt;&gt;&gt; If it is in the OpenID assertion, it is done.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; If it got the old identifier as an attribute of the identity that the<br>
&gt;&gt;&gt;&gt; new identifier points to,<br>
&gt;&gt;&gt;&gt; RP can then do the Discovery on the old known<br>
&gt;&gt;&gt;&gt; identifier and get back the XRDS which includes both the old and new<br>
&gt;&gt;&gt;&gt; identifier.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; What do you think?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; general mailing list<br>
&gt;&gt;&gt; <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
&gt;&gt;&gt; <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Nat Sakimura (=nat)<br>
&gt; <a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br>
&gt; <a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a><br>
&gt; _______________________________________________<br>
&gt; general mailing list<br>
&gt; <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
&gt; <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
<br>
</div></div></blockquote></div><br></div></div>