[OpenID] Migrating User Identifier URL re: Connect
Nat Sakimura
identifier for the user.
The RP will get the old identifier only through the request to the new
identifier.
It is done pretty cleanly though there are some downsides. Namely:
1) User is now bound to the authentication service.
2) Current RP will be screwed up because there is no strong link
between the current and new identifiers.
Among the two, 1) is relatively benign. Most of the current OpenID 2.0
providers are like that.
(Though I would still want to seek more user centric way of doing things.)
In contrast, 2) is a disaster for the current RPs.
What the RPs needs to do then is to authenticate the user that has
come in with connect proposal
with the good old OpenID 2.0 again to make the identity linking, which
in general is not a very
good user experience.
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?
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
_______________________________________________
general mailing list
gen...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
George Fletcher
If it's possible to discover the new identifier from the old one, then RPs can just go through their DB and do the mapping out-of-band (meaning the user doesn't have to be present). This can easy migration efforts from a deployment perspective.
Thanks,
George
Allen Tom
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" <saki...@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?
_______________________________________________
Peter Watkins
> If it's possible to discover the new identifier from the old one, then
> RPs can just go through their DB and do the mapping out-of-band (meaning
> the user doesn't have to be present). This can easy migration efforts
> from a deployment perspective.
I would *love* to see that. We offer OpenID RP for login largely because
we offer relatively few authentication-required features, so our general
users (unlike, say, Facebook users) rarely need to log in. OpenID allows
our customers to use their existing accounts at OpenID OPs instead of
creating new accounts whose passwords they're sure to forget.
It would not be at all unusual for one of our customers to go a year between
logins. So I don't want a migration protocol that relies on the OP running
both 2.0 code and Connect code, and can only migrate during a login event
-- surely at some point OPs will choose to shut down their 2.0 services, and
any of our customers who haven't migrated to new identifiers by that time
will have orphaned, unusable OpenID 2.0 accounts.
The strawman proposal from Allen & John requires OPs to run 2.0-compatible
discovery services in order to migrate to Connect identifiers, and that part
makes me nervous. Our users don't see themselves as logging in as
https://www.google.com/accounts/o8/biglonguglyreallylongstring and won't
(shouldn't!) understand that their Connect identifier is different. They
see themselves as logging in with their regular Google accounts, and I don't
want that perception to change if/when we switch the backend crypto stuff
to Connect. Once their OP shuts down 2.0 discovery and only sends Connect
info, our users would wonder why we forgot who they were -- and we wouldn't
have any idea that we'd seen any one of them before if they hadn't logged
in recently. :-(
-Peter
Nat Sakimura
=nat via iPad
Nat Sakimura
iPad typing is not always as easy as it should be ...
=nat
--
Nat Sakimura
"openid2/connect" migration but "oldid/newid" migration service. That
way, we can use it even for openid2 idp to openid2 idp migration or
connect idp to connect idp migration.
=nat
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
David Recordon
Nat Sakimura
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
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
Peter Watkins
> 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.
If you're going to formalize identity migration, please consider extending
it to handle "identity linkage". Users might want to tell an RP to treat
two different identities as identical for a number of reasons, including
migration. For instance, I might want to link a Yahoo and Google identity
if I feared that one of those companies might shut down operation in my
country, or if I planned to travel to some country where one of those OPs
was likely to be unreachable. If I primarily use Google and find myself
blocked by some Great Firewall, it won't help me to have a strict "migration"
path, but it would be great if I could link my Google identity before I
leave, at least for the RP sites I care most about.
-Peter
SitG Admin
>if I feared that one of those companies might shut down operation in my
>country, or if I planned to travel to some country where one of those OPs
>was likely to be unreachable.
It sounds like there are two similar use-cases here: one where the
user wants resilience (in case either of their providers shuts down),
and one where the user needs to have another OP *temporarily* be
counted as a legitimate alternative.
In the first case, if they can anticipate which OP is in imminent
danger of going down (or being compromised), they will want to make
sure that the old account cannot remove the new account; however,
they *do* want to make sure that the new account cannot be prevented
from removing the *old* account. (Single login would mean a
compromised OP could keep the backdoor open forever; MultiAuth would
mean a compromised OP could lock the user out of their account
indefinitely.)
In the second case, the user will not want that secondary OP
continuing to work after their vacation, due to the lockout and
backdoor issues described above.
Keeping track of which OP has what authority, and under what
circumstances, could get complicated. (For humans. The code is easy.)
-Shade
John Bradley
The Connect RP needs to keep supporting openID 2.0 discovery, but they are likely going to anyway to continue to support openID 2.0 users who are not migrating.
John B.
John Bradley
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.
David Recordon
John Bradley
You want some sort of automatic account linking hint for a RP so that if it supports that it can add other claimed_id to your account?
That is probably doable.
I don't know that we can require RP to support account linking.
I suspect with connect they will probably wan't to have access to more of your social graph, so will be encouraged to support it.
John B.
John Bradley
Peter Watkins
> RPs can and do link multiple ID to a single account.
But only with custom code. Put this in the spec and it's likely
to be included in popular code libraries (even if it's not a
requirement), which will make it easier for RPs to add linking,
and likely make the linking more secure.
> You want some sort of automatic account linking hint for a RP so that if it supports that it can add other claimed_id to your account?
I don't know what you mean by automatic. There's a privacy angle to
linking, so this ought to be an action that is requested by the
end user.
> That is probably doable.
>
> I don't know that we can require RP to support account linking.
I don't think you should. Spec how it MAY be done and let implementors
decide whether to support it or not. While I'd love to see this, I don't
think it's important enough to make it more difficult to comply with
the spec.
> I suspect with connect they will probably wan't to have access to more of your social graph, so will be encouraged to support it.
> On 2010-05-29, at 2:54 PM, Peter Watkins wrote:
> > If you're going to formalize identity migration, please consider extending
> > it to handle "identity linkage". Users might want to tell an RP to treat
> > two different identities as identical for a number of reasons, including
> > migration.
_______________________________________________
Nat
can provide the migration information.
To make the new OP capable of making an authoritative assertion is
much more tricky but it could be done. One way of doing it is for the
old OP to sign the old user identifier / new op identifier pair by its
private key and new op including it in the assertion so that the
receiving RP can verify that the migration info is authoritative. This
would allow the old OP shutting down almost immediately as well.
=nat @ Tokyo via iPhone