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.<br>
<br>Chris Messina, David Recordon, and Joseph Smarr:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
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.</blockquote>
<div><br></div>Allen Tom:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
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.</blockquote>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<br></blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
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.</blockquote>
<div><br></div><div>Eran Hammer-Lahav (with a +1 from Chuck Mortimore):</div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
I approach this from the opposite direction.</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
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.</blockquote>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
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.</blockquote>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
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.</blockquote>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
My guess is that an OAuth identity layer will not be a good thing for OpenID adoption. OAuth providers will get it for free.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>--David </div>