[OpenID] Migrating User Identifier URL re: Connect

[John Bradley]

Yes if the RP supports http: tag discovery.

Some openID 2.0 RP may only support XRDS,  or at least discover it first.
The user may only be able to edit there XRDS.  eg someone migrating from a iName.

We should support both HTML and XRDS versions of rel='me'

In general this will be used for bulk moving people, but should be useful otherwise for people migrating accounts.

John B.
On 2010-05-29, at 8:36 PM, David Recordon wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20100529/7e9cbaf6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20100529/7e9cbaf6/attachment.bin>