If it is the same RP and the RP authenticates itself, then the old OP
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
On 2010/05/30, at 9:32, 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
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
