<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Yes if the RP supports http: tag discovery.<div><br></div><div>Some openID 2.0 RP may only support XRDS, or at least discover it first.</div><div>The user may only be able to edit there XRDS. eg someone migrating from a iName.</div><div><br></div><div>We should support both HTML and XRDS versions of rel='me'</div><div><br></div><div>In general this will be used for bulk moving people, but should be useful otherwise for people migrating accounts.</div><div><br></div><div>John B.</div><div><div><div>On 2010-05-29, at 8:36 PM, David Recordon wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Could use rel-me to point from the old claimed id to the new user identifier.<div><br></div><div>So Connect's user info API includes an "openid2_url" 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 <link rel='me' href='<a href="https://profiles.server.com/i1b8qklb12kb93">https://profiles.server.com/i1b8qklb12kb93</a>' />.</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"><<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>></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'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'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>
> So, who is going to draft the spec?<br>
><br>
> As I have stated earlier, I would like to generalize it a little bit more than<br>
> just openid2/connect.<br>
><br>
> This would be very useful to solve "the openid2 provider shutting down<br>
> problem" as well.<br>
><br>
> =nat<br>
><br>
> On Sat, May 29, 2010 at 2:51 PM, David Recordon <<a href="mailto:recordond@gmail.com">recordond@gmail.com</a>> wrote:<br>
>> +1 Allen/John<br>
>><br>
>> On Fri, May 28, 2010 at 11:35 AM, Allen Tom <<a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>> wrote:<br>
>>><br>
>>> Hi Nat -<br>
>>><br>
>>> The high level strawman proposal that John Bradley and I briefly discussed<br>
>>> was:<br>
>>><br>
>>> 1) return the user's OpenID 2.0 identifier as an attribute in the Connect<br>
>>> assertion (along with the new Connect ID)<br>
>>><br>
>>> 2) Update the OpenID 2.0 discovery document for the identifier to list the<br>
>>> to OpenID Connect endpoint as a "connect/openid2" migration service.<br>
>>> Connect<br>
>>> RPs are supposed to perform OpenID 2.0 discovery on the OpenID 2.0<br>
>>> identifier to make sure that the Connect OP is also authorative for the<br>
>>> OpenID 2.0 identifier<br>
>>><br>
>>> Implementing #1 and #2 will allow an existing OpenID 2.0 RP that already<br>
>>> has<br>
>>> OpenID 2.0 users to migrate their existing users to Connect without<br>
>>> requiring users to auth twice during the migration process.<br>
>>><br>
>>> Does anyone see a problem with this approach?<br>
>>><br>
>>> Allen<br>
>>><br>
>>><br>
>>> On 5/27/10 7:06 PM, "Nat Sakimura" <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>> wrote:<br>
>>><br>
>>>><br>
>>>><br>
>>>> My suggestion here is to include both the old and new identifier in a<br>
>>>> signed assertion,<br>
>>>> with a sunset set for the old identifier. It could be either OpenID<br>
>>>> assertion or XRDS.<br>
>>>> If it is in the OpenID assertion, it is done.<br>
>>>><br>
>>>> If it got the old identifier as an attribute of the identity that the<br>
>>>> new identifier points to,<br>
>>>> RP can then do the Discovery on the old known<br>
>>>> identifier and get back the XRDS which includes both the old and new<br>
>>>> identifier.<br>
>>>><br>
>>>> What do you think?<br>
>>><br>
>>> _______________________________________________<br>
>>> general mailing list<br>
>>> <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
>>> <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> Nat Sakimura (=nat)<br>
> <a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br>
> <a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a><br>
> _______________________________________________<br>
> general mailing list<br>
> <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
> <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>
</blockquote></div><br></div></body></html>