On 05/25/2010 06:09 PM, Allen Tom wrote:
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.
OAuth 2.0 is conceptually compatible with 1.0a but changes the wire
protocol and introduces some new capabilities. I can imagine a
relatively straightforward approach for migrating existing OAuth 1.0a
infrastructure to a dual-stack 1.0a/2.0 implementation and then
eventually a 2.0-only implementation.
OpenID Connect changes are a lot more pronounced:
* The thing I want the user to enter is no longer an OpenID identifier
but rather a provider domain.
* The thing that comes back is no longer a URL for a human-readable
page but rather the URL for a machine-readable resource that may or may
not link to a human-readable page.
* None of the identifier data I already have for users will be valid
in Connect, so I must implement yet another "migrate your account" flow
in addition to the flow I already had to allow a user to attach an
OpenID identifier to a username/password-based account.
If the resulting spec has an upgrade path built into it then I'm
slightly less concerned, but it still feels a little weird to call it
"OpenID/OAuth Hybrid" when the result is not conceptually compatible
with OpenID and requires pretty significant changes to deployed
infrastructure.
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
