[OpenID] Finally the Shit has hit the fan!

[John Bradley]

Thanks John,

People seem to be a bit on the edgy side these days.

Between Connect, xAuth, and v.Next.

People aught to remember that openID 2.0 is itself a amalgamation of technologies from LID, SXIP, XRDS and others that I have probably forgotten.

Examining and incorporating new ideas is something that is not new to openID.

That is not to say that everything gets adopted ether.

xAuth is a solution that a group of people have come up with for a problem.   

We need to engage and understand, not ridicule.

I certainly have concerns about potential issues with xAuth,  but I have taken them up with Meebo and others working on xAuth.

It is still early days for xAuth.  

I can't predict if it will be a technology that openID will embrace.

The same is true for Connect, or whatever it will be called at the end of the day.

I would rather work with those companies who are primarily concerned with providing OAuth protected API like facebook inside the OIDF, than tell them to go develop there ideas elsewhere.

Once we decide that "We" know best and have the one true way, we will be no better than other protocols that we have mocked in the past.

I am going to continue to help people develop there ideas so that we can determine the ones with merit.

In fairness to Eran, my initial reaction was quite negative as well,  fortunately I took the time to discuss xAuth with the proposers before deciding the sky was falling.

Regards

John B.


On 2010-06-07, at 5:15 PM, John Panzer wrote:

> It's not a centralized component[1].
> 
> I'm disappointed in Eran's post and wrote a response yesterday:
> 
> http://www.abstractioneer.org/2010/06/xauth-is-lot-like-democracy.html
> 
> Unfortunately, FUD sells and Eran's post is being retweeted and cited pretty widely.  If you're going to agree with his objections, please read the rebuttals as well, and explain why you think they're not sufficient.
> 
> -John
> 
> [1] There is nuance here which I'm ignoring in order to get a clear message across.  The initial implementation has a single centralized piece, a DNS entry, but no centralized services or data storage at all.  The end game is a fully decentralized system, but you need a path to get there.  Go read the details at http://www.abstractioneer.org/2010/06/xauth-is-lot-like-democracy.html or at http://googlecode.blogspot.com/2010/04/using-xauth-to-simplify-social-web.html.
> 
> On Mon, Jun 7, 2010 at 7:40 AM, SitG Admin <sysadmin at shadowsinthegarden.com> wrote:
> >http://hueniverse.com/2010/06/xauth-a-terrible-horrible-no-good-very-bad-idea/
> 
> Well, his points against it are quite valid. Having a centralized component to a decentralized architecture, especially one that all parties must *rely* upon, would violate the essential spirit of the idea.
> 
> (That said, if any of them *want* to do it, they may do so unofficially, with neither the involvement nor sanction of the community. Then, when the inevitable user backlash arrives - or, as you put it, "the shit hits the fan" - they alone suffer the reputation hit and loss to market share, compounded by having done so against the recommendations of the majority of the OpenID movement itself.)
> 
> I realize that you're in favor of the centralized component, but please do try to understand why this philosophy is diametrically opposed by OpenID.
> 
> -Shade
> 
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
> 
> 
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100607/cb7b91cd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100607/cb7b91cd/attachment-0001.bin>