Eran, Just to let you know: OpenID Foundation has been working on the identity layer on top of OAuth for several months already. The draft spec of the Artifact Binding WG is 90% same as the Connect proposal. If OAuth2.0 defines a "Request in a file" or "Mobile Web App" kind of flow, it will be 95% the same. Admittedly, it lacks the Discovery portion of the Connect proposal, but that is to be dealt with v.Next Discovery led by Allen Tom.
Just have a look: https://openid4.us/specs/ab/ Regards, Nat On Wed, May 26, 2010 at 5:22 PM, Eran Hammer-Lahav <[email protected]> wrote: > Discussing the name is a distraction. The issue is whether the OpenID > foundation wants to be where identity work is done, or where the OpenID > protocol (and nothing else) is done. Again, the question is very simple: > OAuth is going to have an identity layer (that's a done deal) - do you want > to work on it here under the OpenID foundation or not? > > Everything else (like naming, migration path from OpenID 2.0 to OAuth 2.0 > identity) is stuff for the WG to figure out. > > This is a fundamental question far beyond all this geek talk: what is the > purpose of this community? Where are its boundaries? Is this the hub of web > identity work, or just one tiny piece of it? > > I'm happy with any answer. > > It would be helpful if people would voice clear opinions on this rather than > going in circles (i.e., start with "I'm for/against doing this work here, and > this is why..."). > > EHL > >> -----Original Message----- >> From: [email protected] [mailto:openid-specs- >> [email protected]] On Behalf Of Martin Atkins >> Sent: Tuesday, May 25, 2010 5:49 PM >> To: [email protected] >> Subject: Re: OpenID Hybrid v2 Proposal (formerly known OpenID Connect) >> >> 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. >> >> >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
