OpenID Hybrid v2 Proposal (formerly known OpenID Connect)

[Martin Atkins]

On 05/25/2010 01:56 PM, Allen Tom wrote:
> Hi All,
>
> A better way to look at OpenID Connect is to just think of it as revised
> version of the OpenID Hybrid. The purpose of the Hybrid WG was to find a way
> to combine OpenID Authentication with the approval of an Oauth access token
> into a single request/response.
>

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