OpenID Hybrid v2 Proposal (formerly known OpenID Connect)

[Martin Atkins]

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.