Scott Kveton

I’ve been struggling with the relevance of Data Portability for the last few months now. The ideas around Data Portability have been a work-in-progress for several years; the technologies and communities building them are mature in every way. In this post, I want to try to explain my reasons for leaving the Data Portability project and why I think the Open Web is significantly more important.

I know when I was first introduced to Data Portability I was skeptical but when the ensuing media circus flooded the blogosphere, I had no choice but to jump right in. Many of the people developing the open protocols co-opted by the Data Portability project have hinted (both publicly and privately) at leaving. Others have just outright left.

I don’t have a problem with Data Portability as a whole as much as I do with its leader, Chris Saad. The lack of clarity of vision, the delusions of grandeur and blatant pandering are so frustrating to someone such as myself that has worked so hard to actually do something in this space. I know I’m not alone here, but this week, I reached a tipping point.

First of all, a little history.

David Recordon and I made a point of inviting Chris Saad out to the Social Graph FooCamp in February 2008 as Data Portability was really starting to take the main stage. On the last day, at the eleventh hour, Saad led a talk on Data Portability that got rather heated. Chris Messina, Joseph Smarr, Jeremy Keith, Tantek and many, many others were there saying the same thing: we’re already having these discussions, why do we have to do it now at dataportability.org? We left Sebastopol that afternoon hoping to have Chris Saad really carry on the conversation with the wider audience he had brought to the table. Instead, we continued to hear more calls of “come join the conversation on dataportability.org” coupled with empty press releases instead of real leadership.

At the Data Sharing Workshop where Marc Canter put it all into context for me (and then he prodded me again yesterday). Data Portability is about APML riding along with the rest of the well-known and established Open Web protocols.

Marc and I have had our differences in the past, but on this we both agree.

I’ve always been in the Chris Messina Don’t-stab-babies-in-the-face camp with respect to data portability. Lower-case data portability embodies many of the same ideals around the Open Web. Many small open building blocks, loosely joined helping to enable data exchange and control for users. How can you not like that?!

My reasons are particularly personal for not wanting to participate in Data Portability anymore. I’ve spent close to the last two years chairing the OpenID Foundation board. I’ve seen a fantastic community coalesce out of nothing to create a technology that has been widely adopted. When Data Portability pulled OpenID into its technology stack, I was actually really excited. However, with the expectations set by the media around Data Portability and the lack of follow-through has the potential to negatively impact all of the hard work by these existing communities have done.

My tipping point about this came earlier this week when Jive Software joined the Data Portability group. I love the folks at Jive, have known them for years and always wish them well. However, its a bummer that even folks from my hometown can be misled by this DP media hoopla. When I read Sam Lawrence say:

In the meantime, we’re interested in working with the Data Portability group to help contribute to these standards as well as new ones as well. Hopefully, the organization is now at a point in its evolution to proceed with formal and elected leadership, a standards body, voting process and the rest of the stuff that makes organizations successful.

I realized even Jive had been fooled by the hype around Data Portability. DP is not about creating new technology:

Some things that The DataPortability Project is not:

• We are not a group focused on creating new technologies. DataPortability intends to work with tools that already exist today.
• The group is primarily focused on consumer facing technologies and not those aimed at corporate internal use.

Chris was quoted in Jive’s press release. He knew about this announcement. And yet, as he did with the “Data Availability” release that MySpace did, he opted to “take-all-comers” instead of stay focused on the specific mission of the Data Portabililty project.

More importantly, its not where the discussions about these protocols are happening. They are already happening on openid.net, oauth.net, microformats.org and many, many others. I’m excited to see people talking about OpenID within the Data Portability project, but I feel like they are actually taking away from the existing communities and misleading the new members of the Data Portability community.

I put the blame for this type of messaging and lack of clarity squarely on the back of Chris Saad. I’m actually really amazed at the quality of people that have joined the Data Portability community. They are well-spoken, understand the meaning of collaborative discussion and are very passionate about the project itself. But Chris hasn’t shown the ability to stick to the goals and mission of his organization and community. In fact, the DP community does a better job of staying on point than Chris does.

David Recordon is on the right track; how do you support the Open Web? To me, the Open Web is what this is all about. The Open Web is the key to the centralized me or citizen-centric web we hear so many people talking about. Without interoperable formats and protocols, all of this stuff will be a pipe dream.

Instead of just complaining, I’m going to continue focusing my efforts where I think I can make the most impact. I’m going to continue working hard to promote and enable the OpenID community, I’m going to continue to encourage and engage in discussions with projects like OAuth, microformats, DiSo and others and I encourage everyone to join me in doing the same.

One of my favorite discussions of day 1 at the OpenIDDevCamp was around what you could do with an OpenID end-point. About 15 people showed up to whiteboard and talk first at high-level and then drilling down into the details.

Now, a bunch of folks have been talking about this idea of moving to URL’s as identifiers in recent weeks (even me). The idea is simple; your OpenID is an unique end-point that can act to describe for sites where you get specific services from. For example, if I prove that I’m scott.kveton.com then a website could feasibly query that URI and ask “hey scott.kveton.com, you just logged into my site, can I have your friends list?” or “where can I find your calendar?”

We did our best to try to keep the discussion simple first and then drive into the details of the existing technology. Some basic service types we might want to describe included personal contact information, address book (aka social network or friends list), bookmark service, calendar, photo service or instant messaging. Defining them opaquely we get “my photo service is provided by Flickr” or “I use Google for my calendar”. That’s the easy part.

We had two problems to contend with after we’ve described the types of services we want to expose: privacy and ability to query in or out-of-band. How much information do I want public? How can I share it if I want it to be private for only a few people? Since OpenID works within the browser (consider this “in-band”), what if I want a service (like my photo or calendar service) to update something of mine with my permission when I’m not in front of the computer?

When talking about privacy, it looks like we have the components we need already. In the case of the public data, we can accomplish this with microformats or XRDS right at the OpenID URL. My contact information in hCard, my friends in XFN, etc. Using XRDS you could share where you get specific service types. If you want to lock this up a bit, you can use Attribute Exchange. It allows you to share only what you want to who you want. Ideally you’d be using the same URI’s for both in this scenario.

To deal with the in/out-of-band data problem the idea was floated to leverage OpenID + AX for in-band and OAuth + AX for out-of-band. If I’m logging into a site via OpenID with my browser, I could use Attribute Exchange (AX) to move my private (and public if I want) data. If the web service wants to update something for me or my OpenID provider wants to update something on a service, it can use OAuth which ideally would be automatically setup when the user logs in for the first time to the service.

In the future, we could even consider having an XRDS entry to describe how to add or remove entries into my list of services I use. Now you could have a web service ask you if you’d like to use them as your default photo service or calendar. Very cool stuff.

Now, we have the pieces described for what we want to do. The best part is we’ve been able to turn our OpenID end-point into the choke point for our public and private data. I can see all kinds of applications for other types of information you might want to land there as well (can you say your lifestream?). Looks for some folks (maybe those attending OpenIDDevCamp?) will implement these features in the near future. Let’s get some code out there and start playin’ with it!! Yeah! :-)