Allen, Simply passing the old identifier as an attribute is not enough on it's own, for account migration. The RP will need to confirm the OP is actually authoritative in some way. We would need to add a service to the old XRDS to say that the new endpoint is authoritative for openID Connect and have the RP do an extra discovery step, or something similar.
That is the one advantage of AB in that it doesn't mess with the identifiers or there meaning, everything including delegation continues to work. On the other hand we need to figure out migration to deal with all of the non https: URI that are in use now. We know they are not secure. Coming up with a secure way for a user to easily migrate from one ID at a RP to another is something we will need to deal with at some point. Regards John B. On 2010-05-25, at 9:09 PM, Allen Tom wrote: > Hi Martin, > > Regarding your first point, OAuth2 is not compatible with Oauth 1.0a at any > level - yet they still managed to keep the brand name. They should just call > it Oauth-WRAP, but I digress. > > The Hybrid protocol is intended for the case where both the OP and RP want > to exchange the data available via OpenID (The identifier + AX) along with > an Oauth credential to the RP to access APIs on the OP. > > This implies that both the OP and RP are both investing in Oauth > infrastructure, which they'd continue to be able to use in Connect. The only > real tricky issue is migration. The OpenID 2.0 identifier still needs to be > passed from the OP to the RP in Connect. A potential solution would be to > pass the legacy OpenID 2.0 identifier(s) as an additional attribute in the > User Info JSON object. This shouldn't be too big of a deal. > > Allen > > > On 5/25/10 5:48 PM, "Martin Atkins" <[email protected]> wrote: > > >> "OpenID Connect" isn't actually compatible with OpenID at anything but >> the highest conceptual level. >> >>> Renaming the OpenID Connect WG to be the OpenID Hybrid v2 WG could possibly >>> clarify the goals of the WG, and reduce confusion within the community. >>> Afterall - Hybrid is intended for the case where the user's IdP is also the >>> SP, so the Connect proposal is really a revised Hybrid proposal, rather than >>> a proposal for OpenID v.Next >>> >> >> I think this would only make sense if the resulting protocol were >> functionally equivalent to OpenID. That is to say that I can implement >> it against my existing OpenID infrastructure without doing data >> migrations, changing my UI, etc. >> >> I think the most important deviation in OpenID Connect is that the >> identifier is no longer expected to be human-readable; while I >> completely agree that this is the right design if we're starting over >> from a clean slate, that's a breaking change for most existing consumer >> implementations that link to the identifier as the user's "home page" or >> "profile page". >> >> I still think this thing should be branded with a stronger OAuth >> connotation than an OpenID connotation, since it's far closer to OAuth >> than it is to OpenID. I didn't really like the OpenID Connect name, but >> at least it made it sound like this was something new and different; >> calling it OpenID/OAuth Hybrid makes it sound a lot more like a >> different implementation of the same thing than the radical rethink that >> OpenID Connect actually represents. >> >> That's my two cents, at least. >> >> >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
