OpenID Hybrid v2 Proposal (formerly known OpenID Connect)

Martin Atkins mart at degeneration.co.uk
Wed May 26 02:31:41 UTC 2010


On 05/25/2010 07:09 PM, Allen Tom wrote:
>
>
>
> On 5/25/10 6:25 PM, "Martin Atkins"<mart at degeneration.co.uk>  wrote:
>
>>
>>
>> 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.
>
> I am a little biased towards my own service, but I don't think this is an
> issue for Yahoo.
>

My concerns were largely from the point of view of an RP; for an OP, 
it's easy to imagine running both stacks side-by-side.

>
>> 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.
>>
>
> At least for existing implementers of OpenID Hybrid, the OpenID Connect
> proposal implements exactly the same features, and shares exactly the same
> data. The only difference is that the user's identifier might be different
> (or it might be the same)
>

Given that the identifier URI is part of the user interface in OpenID 
2.0, both in terms of what the user is invited to enter in the 
non-directed case and in terms of what is used to represent the user in 
UI for other users, this change touches a lot more of an implementer's 
stack than, say, switching to bearer tokens for OAuth does.

With that said, I don't feel strongly enough about this for the amount 
of time we've both invested in this discussion so far, so I'm happy to 
drop it. This whole thread is a textbook case of bikeshedding; let's get 
some work done and then worry about what it's called when we know what 
we're naming.





More information about the specs mailing list