On 05/25/2010 07:09 PM, Allen Tom wrote:
On 5/25/10 6:25 PM, "Martin Atkins"<[email protected]> 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.
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
