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

Mike Jones Michael.Jones at microsoft.com
Fri Jul 4 17:05:34 UTC 2014

I would prefer that the OpenID 2.0 identifiers used with OpenID Connect all have an “openid2” prefix so that it’s syntactically clear that they’re there for transition purposes.  So for instance, I think “openid_id” is a misleading name.  “openid2_id” would be better.  Etc.

                                                            -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
Sent: Thursday, July 03, 2014 7:31 PM
To: openid-specs-ab at lists.openid.net
Subject: [Openid-specs-ab] New version of the Migration spec, and HTML version of it


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 guide.

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<http://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 openid2_realm.

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 resource.

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/4ef1555b/attachment.html>

More information about the Openid-specs-ab mailing list