[Openid-specs-ab] New version of the Migration spec, and HTML version of it

Nat Sakimura sakimura at gmail.com
Fri Jul 4 02:31:15 UTC 2014


I have pushed a new version of OpenID 2.0 to Connect Migration spec draft.

Fixed some errors and added the difference between this spec and Google's

You can find the HTML version here:

While we have discussed it a bit in the WG call and the people who were
calling in agreed to align some of the variable names with Google's, I have
not applied them yet to allow more people to chime in. One of the thing
that I noticed after the call is that during the call, while we said that
these OpenID 2.0 related claims will go away soon, it actually may not.
OpenID 2.0 OP could go away soon, but IdPs may need to keep those claims
for a longer time to allow RPs' users to fully migrate. So, using claim
names like "openid_id" for OpenID 2.0 identifier may be misleading.

I am not particularly attached to eitherway, but I have kept the difference
for the time being to call out the discussion around it.

The Appendix C lists these differences/discussion points, and I am copying
it here as well:

Appendix C.  Difference to Google’s migration guide as of June 3, 2014

In this appendix, the differences between this spec and the Google’s
migration guide as of June 3, 2014 is expalined. The differences are
categorized in accordance with the section number of this specification.
Google's migration guide is available at
https://developers.google.com/accounts/docs/OpenID#openid-connect . These
differences should be discussed and determined whether it should be aligned
with the Google's guide before finalizing this specification.

*3. Requesting the OpenID 2.0 Identifier and Connect iss/sub pair together*

Google uses openid.realm instead. Since OpenID Connect uses param_name
style instead of param.name, as well as the name openid.realm may mislead
the user that it is a Connect parameter proper, it has been changed to

Google uses the existence of openid.realm parameter to switch the behavior
at the Connect OP. New scope value openid2 has been introduced in this spec
to make it more explicit and semantically in-line that it is asking for a

*4. Verification of the Relying Party by the OP*

Google does not perform RP verification.

*5. Returning OpenID 2.0 Identifier*

Google uses openid_id instead of openid2_id . It was changed to openid2_id
 because openid_id may cause confusion among people that it is the Connect
identifier. Since this spec allows providing openid2_id even after the
OpenID 2.0 OP has been taken down, this claim may persists much longer than
the OpenID 2.0 OP. Thus, the chance of confusion should be minimized.

Google does not take care of XRI while this standard does.

*6. Verification of the authority*

Google does not perform authority verification.

Otherwise, I feel that we are in a pretty good shape, so that as soon as we
settle on these issues, we can go to the implementer's draft vote.


Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140704/83e61a43/attachment.html>

More information about the Openid-specs-ab mailing list