"We must hang together, or most assuredly we shall hang separately."
- Commonly attributed to Benjamin Franklin, 1776. However, attributed earlier to Richard Penn. Interesting story: Penn went to England in the summer of 1775, having been entrusted with the Olive Branch Petition to King George III. Quote: > Lord Dartmouth received the original from Penn on September 1st, but the > King would not see him On being pressed for a reply, Lord Dartmouth said: > "As His Majesty did not receive the petition on the throne, no answer will > be given." As a result of this action, and the cold shoulder given to the > petition, the way was cleared for the Declaration of Independence in > 1776,.........and the Revolution went on to its successful conclusion. - http://www.rain.org/~karpeles/olifrm.html On Wed, May 26, 2010 at 12:46 PM, Dick Hardt <[email protected]> wrote: > The Connect problem space (as I understand it, I am having to guess as > there are no requirements in the charter) is a subset of the v.Next work. > > The discovery in Connect is a duplication of the v.Next discover work. > > Now that the v.Next work is moving along, why can't we all work together on > one spec? If a simple version is needed sooner, why can't we do that work > together? > > You have effectively forked the OpenID process David because you were > frustrated with the pace of v.Next and because you don't care about some of > the use cases. > > A healthy community cares about the needs of all the members, not just the > needs of a few individuals. Are you saying that you don't care about the > needs of other members of the community? > > Since you are building on top of OAuth, are not working with the other WGs, > and have decided you don't care about a number of use cases that are > important to many members of the community, I have suggested you do it > outside the OpenID community. > > If the community is not working how you would like it to work, you can > either be part of the solution to resolve the issues, or you can be part of > the problem. Right now I see you as being part of the problem. I'd like you > to be part of the solution. > > -- Dick > > > On 2010-05-26, at 11:07 AM, David Recordon wrote: > > I'm obviously +1 for this work occurring inside the OpenID Foundation. But > as Eran said, there's momentum pushing this work forward, and whether this > happens within the OIDF is not a gating factor. Since I posted the OpenID > Connect proposal we've evolved and simplified it, an engineer at Six Apart > built a prototype client and server, and we've received some really positive > feedback from both potential clients and servers in a range of industries. > > I want this work to occur within the OpenID Foundation, but am tired of a > small number of people trying to stop us from even creating a Working Group. > > I'm also supportive of the v.Next work moving forward so that there's > actually a technical proposal which can be understood, compared, and ideally > combined where it makes sense. > > The risk to the OpenID brand and Foundation is clear to me if this work > happens elsewhere; the risk of moving the Connect Work Group forward within > the Foundation remains quite unclear to me. > > --David > > > On Wed, May 26, 2010 at 8:48 AM, Brian Kissel <[email protected]> wrote: > >> +1 for having the work done inside the OpenID Foundation. >> >> Cheers, >> >> Brian >> ___________ >> >> Brian Kissel >> CEO - JanRain, Inc. >> [email protected] >> Mobile: 503.342.2668 | Fax: 503.296.5502 >> 519 SW 3rd Ave. Suite 600 Portland, OR 97204 >> >> Increase registrations, engage users, and grow your brand with RPX. Learn >> more at www.rpxnow.com >> >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Eran >> Hammer-Lahav >> Sent: Wednesday, May 26, 2010 1:22 AM >> To: [email protected] >> Subject: RE: OpenID Hybrid v2 Proposal (formerly known OpenID Connect) >> >> 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 >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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
