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