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 <[email protected]> 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 <[email protected]> wrote: > >> +1 Allen/John > >> > >> On Fri, May 28, 2010 at 11:35 AM, Allen Tom <[email protected]> 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" <[email protected]> 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 > >>> [email protected] > >>> http://lists.openid.net/mailman/listinfo/openid-general > >> > >> > > > > > > > > -- > > Nat Sakimura (=nat) > > http://www.sakimura.org/en/ > > http://twitter.com/_nat_en > > _______________________________________________ > > general mailing list > > [email protected] > > http://lists.openid.net/mailman/listinfo/openid-general > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
