One of the questions that a variety of people have asked the past few days is why are we working on Connect versus just v.Next? I wanted to provide the community with an answer. It turns out that while there are common themes among the potential working group members, the reasons vary a litle.
Chris Messina, David Recordon, and Joseph Smarr: > The market desires a standardized protocol that incrementally improves upon > popular, established concepts and techniques that is simpler for developers > to implement, provides additional value for site owners and web users, and > is available by the year's end. Allen Tom: > Connect has a well defined scope that standardizes an identity interface > using OAuth – which has already been widely implemented and has already > proven to work by several vendors. Based on adoption, It’s obvious that the > marketplace wants this. Given that there are several widely implemented and > very successful implementations of Identity using Oauth – its pretty > straightforward and almost obvious how to build OpenID Connect by taking the > best practices of what’s already been implemented. > I do think that the community would be better off if we could drop the > Connect branding. Perhaps we can call it OpenID 3.0 Core, and the use cases > that are in the v.Next Proposal that are not in Core can be built on top of > 3.0 Core. Eran Hammer-Lahav (with a +1 from Chuck Mortimore): > I approach this from the opposite direction. I think OAuth needs an identity layer (regardless of OpenID, connect or > not). If you look at *OAuth* use cases such as Sign-in with Twitter, as well > as the ‘immediate’ mode (which is not safe without some form of identity > hint), there is a clear case for that. I don’t care much what the OpenID community decides to do. OAuth needs this > solution, as well as support unregistered clients and signatures. The only > part that is missing is discovery, which we are going to cover as well in a > companion OAuth spec (which is likely to have both light discovery for a > protected resource, and host-meta based discovery for domains). In other > words, OAuth is going to cover this entire proposal. Unless, the OpenID community wants to step up and lead the identity portion > of OAuth. As leading member of the OAuth community, my question is, does the > OpenID community wants to step up and help define this functionality based > on its experience, or does it want to work on a separate identity solution > which may or may not be in line with what OAuth ends up doing. My guess is that an OAuth identity layer will not be a good thing for OpenID > adoption. OAuth providers will get it for free. To Eran's point, this sort of technology is going to be built whether or not the OpenID Foundation leads. At our Board meeting a few months ago we changed our mission to include supporting technologies beyond just OpenID 2.0. This is a perfect opportunity to show that we actually mean it. --David
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
