Twitter can has OAuth?

Twitter / Twitter API: Call for OAuth private beta participants ...

Twitter API lead Alex Payne announced today that Twitter is now accepting applications to its OAuth private beta, making good on the promises he made on the Twitter API mailing list and had repeated on the January 8 Citizen Garden podcast (transcript by stilist).

It’s worth pointing out that this has been a long time coming and is welcome news, especially following Alex’s announcement to limit Twitter API requests to 20000/hr per IP.

But it’s important to keep in mind that, in light of the recent security breaches, OAuth in and of itself does not, and will not, prevent phishing.

It does, however, provide a way for Twitter to better track the use of its API, and to enable higher quality of service for trusted (paying?) applications and to surface them through a Facebook-like application directory. It also means that Twitter users will have finer grained control over which applications have ongoing access to their accounts — and will be able to disable applications without changing their password.

I’m on the beta list, so I’m looking forward to seeing what their current UI looks like — and what lessons we can extract for other services going from zero OAuth to a completeld delegated authentication model.

Lightweight access PINs: a modest proposal for enabling OpenID in desktop and mobile apps

While the news that Google is now an OpenID Provider was generally welcomed, a common chorus decrying their support (along with others large OPs like Yahoo, Microsoft and others) at best as half-hearted, at worst as ruining OpenID has revealed a significant barrier to such large providers becoming relying parties (even beyond usability).

Eric Sachs (Google Security Team) writes:

One other question that a lot of people asked yesterday is when a large provider like Google will become a relying party. There is one big problem that stands in the way of doing that, but fortunately it is more of a technology problem than a usability issue. That problem is that rich-client apps (desktop apps and mobile apps) are hard-coded to ask a user for their username and password. As an example, all Google rich-client apps would break if we supported federated login for our consumer users, and in fact they do break for the large number of our enterprise E-mail outsourcing customers who run their own identity provider, and for which Google is a relying party today. This problem with rich-client apps also affects other sites like Plaxo who are already relying parties.

Fortunately there is a solution, and it was developed specifically because Ma.gnolia ran into this problem when it became an OpenID relying party. The result, nine months in the making, was OAuth. Eric even recognizes this:

We need standard open-source components on as many platforms as possible to enable those rich-client apps to support OAuth. That includes a lot more platforms then just Windows and Mac. The harder part is mobile devices (Blackberry, Symbian, Windows Mobile, iPhone, and yes even Android), and other Internet connected devices like Tivos, Apple TVs, Playstations, etc. that have rich-client apps that ask users for their passwords to access services like Youtube, Google photos, etc. If we build these components, they will be useful not only to Google, but also to any other relying parties which have rich-client apps or exposes APIs, and it will also help enterprise SaaS vendors like Salesforce.

iPhone Sync CodeAs I’ve been thinking about this problem, I’ve come to see as an intermediate approach to full-on delegated authorization a simpler, perhaps more familiar approach that would be relatively easy to implement given common interface patterns today. For comparison, Pownce’s iPhone app originally used out-of-band browser-based authentication, leading to a swarm of user criticism resulting in a compromised solution that required embedding a web browser in the app. Less than ideal.

In my proposal, rather than ask for a user’s password, an easier-to-remember OP-issued numerical PIN would be used to authenticate requests. Better is that this approach is already supported in OAuth, it’s just not widely used yet (though is similar to how Flickr authorizes mobile clients).

The basic concept is that you’d have one password (or other strong authentication method) for your primary OpenID account and you’d have one (or more) PINs that you would use to access your account remotely — perhaps in limited risk scenarios or where (again) the full browser-based OAuth flow is not possible or warranted.

Although I initially opposed FriendFeed’s use of Remote Keys, I now think that there’s some merit to this approach, as long as the underlying mechanism uses standard OAuth calls.

There are plenty of holes in this approach, but insomuch as it enables an existing pattern to be phased out gently, I think it offers at least the foundation of an idea that could be useful. It also could be used as a counter-balance to some of the current thinking on federated login flows with OAuth.

Consider these three sign in boxes for comparison:

  1. Traditional Password
    traditional password
  2. Lightweight PIN access
    pin-access
  3. Full OAuth
    Full OAuth

Thoughts welcome.

OAuth for the iPhone: Pownce.app

Pownce OAuth flow Step 1

If you’re one of the lucky folks that’s been able to upgrade your iPhone (and activate it) to the 2.0 firmware, I encourage you to give the Pownce application a try, if only to see a real world example of OAuth in action (that link will open in iTunes).

Here’s how it goes in pictures:

Pownce OAuth flow Step 1 Pownce OAuth flow Step 2 Pownce OAuth flow Step 3 Pownce OAuth flow Step 4/Final

And the actual flow:

  1. Launch the Pownce app. You’ll be prompted to login in at Pownce.com
  2. Pownce.app launches Pownce.com via an initial OAuth request; here you signin to your Pownce account using your username or password (if Pownce supported OpenID, you could signin with OpenID as well).
  3. Once successfully signed in to your account, you can grant the Pownce iPhone app permission to access your account.
  4. Once you click Okay, which is basically a pownce:// protocol link that will fire up Pownce.app to complete the transaction.

There are three important aspects of this:

  • First, you’re not entering your username and password into the Pownce application — you’re only entering it into the website. This might not seem like a great distinction, but if a non-Pownce developed iPhone application wanted to access or post to your Pownce account, this flow could be reused, and you’d never need to expose your credentials to that third party app;
  • Second, it creates room for the adoption of OpenID — or something other single sign-on solution — to be implemented at Pownce later on, since OAuth doesn’t specify how you do authentication.
  • Third, if the iPhone is lost or stolen, the owner of the phone could visit Pownce.com and disable access to their account via the Pownce iPhone app — and not need to change their password and disrupt all the other services or applications that might already have been granted access.

Personally, as I’ve fired up an increasing number of native apps on the iPhone 2.0 software, I’ve been increasingly frustrated and annoyed at how many of them want my username and password, and how few of them support this kind of delegated authorization flow.

If you consider that there are already a few Twitter-based applications available, and none of them support OAuth (Twitter still has yet to implement OAuth), in order to even test these apps out, you have to give away your credentials over and over again. Worse, you can guarantee that a third-party will destroy your credentials once you’ve handed them over, even if you uninstall the application.

These are a few reasons to consider OAuth for iPhone application development and authorization. Better yet, Jon Crosby’s Objective-C library can even give you a head start!

Hat tip to Colin Devroe for the suggestion. Cross-posted to the OAuth blog.

Feature request: OAuth in WordPress

Twitter / photomatt: @factoryjoe I would like OA...

In the past couple days, there’s been a bit of a dust-up about some changes coming to WordPress in 2.6 — namely disabling ATOM and XML-RPC APIs by default.

The argument is that this will make WordPress more secure out of the box — but the question is at what cost? And, is there a better solution to this problem rather than disabling features and functionality (even if only a small subset of users currently make use of these APIs) if the changes end up being short-sighted?

This topic hit the wp-xmlrpc mailing list where the conversation quickly devolved into spattering about SSL and other security related topics.

Allan Odgaard (creator TextMate, as far as I can tell!) even proposed inventing another authorization protocol.

Sigh.

There are a number of reasons why WordPress should adopt OAuth — and not just because we’re going to require it for DiSo.

Heck, Stephen Paul Weber already got OAuth + AtomPub working for WordPress, and has completed a basic OAuth plugin for WordPress. The pieces are nearly in place, not to mention the fact that OAuth will pretty much be essential if WordPress is going to adopt OpenID at some point down the road. It’s also going to be quite useful if folks want to post from, say, a Google Gadget or OpenSocial application (or similar) to a WordPress blog if the XML-RPC APIs are going to be off by default (given Google’s wholesale embrace of OAuth).

Now, fortunately, folks within Automattic are supportive of OAuth, including Matt and Lloyd.

There are plenty of benefits to going down this path, not to mention the ability to scope third party applications to certain permissions — like letting Facebook see your private posts but not edit or create new ones — or authorizing desktop applications to post new entries or upload photos or videos without having to remember your username and password (instead you’d type in your blog address — and it would discover the authorization endpoints using XRDS-SimpleEran has more on discovery: Magic, People vs. Machines).

Anyway, WordPress and OAuth are natural complements, and with popular support and momentum behind the protocol, it’s tragic to see needless reinvention when so many modern applications have the same problem of delegated authorization.

I see this is a tremendous opportunity for both WordPress and OAuth and am looking forward to discussing this opportunity — at least consideration for WordPress 2.7 — and tonight’s meetup — for which I’m now late! Doh!

The OpenID mobile experience, part II

In January, I wrote about the “OpenID mobile experience” lamenting that it sucked and asking for positive examples of identity providers who got it right. Well, I didn’t get a whole lot of examples, but Ian McKellar (Songbird) did get inspired to hack something together called Twauth, which serves as the foundation for a flow that I’m going to articulate now.

The foundation of Ian’s idea is this:

My initial approach was to offer an OpenID URL for phone numbers and use an SMS message containing a one-time password to verify that the person attempting to log in had access to that mobile phone. Unfortunately there’s no free web service for sending SMSes, so did the next best thing and built it on top of Twitter.

Extending this, I have two variations of this proposal, that could work today. I will be using Brightkite as the example service, since they currently do not support OpenID but should and are at least interested. So, given that, here’s a proposal for how they could make it happen.

Single-site mobile sign-in with OpenID

The first approach requires no change to the OpenID protocol, but actually leaves out OpenID altogether beyond the initial association, which may or may not be a good idea, security-wise. Regardless, no one says you can’t do what I’m about to propose, so here we go.

I already have an account with Brightkite, and use a traditional username and password to sign in. Let’s assume that Brightkite adds support for OpenID, and allows creating new accounts with OpenIDs or allows existing members to associate an OpenID with their account — by verifying against the identity provider — not just adding a URL to their account (as Beanstalk used to do!).

Let’s also assume that you’ve associated a phone number with your account. (Now, while you could arguably just use your phone number for this flow, the point is to associate an OpenID with your account and then use it to sign in later.)

So, once you’ve associated your OpenID and your phone number your account:

  1. Visit the mobile Brightkite site.
  2. If it’s not provided on the homepage, click “Sign in with OpenID” (remember, this doesn’t exist today).
  3. Enter your OpenID and hit “Login”.
  4. Since you’re on the mobile site, we’ll assume that you’re indicating to Brightkite that you want to use a mobile-friendly flow to authenticate. Since, Brightkite has already associated a verified phone number with your OpenID, they simply send an SMS to that number with a key (probably 5 numerical digits).
  5. Once you receive the SMS from Brightkite, you return to the login flow and enter the key.
  6. If you provide the correct key, Brightkite should log you in successfully, since you’ve proven that you have control of the phone that’s associated with the OpenID you provided.

The key to this flow is that you have verified both your phone number and your OpenID, and so essentially you’re transitively substituting an OpenID URL for your phone number. Is this OpenID? Well, insomuch as you can use your OpenID identifier to sign in on both the desktop (where the full roundtrip happens) and on your mobile device, I think it’s at least compatible in the interim.

So why not just use your phone number to sign in? Well, you could, but as I’ll describe in the next flow, there might be a way for OpenID providers to do a better job with the mobile experience, and so starting here and training people to use their OpenID URL as opposed to a phone number to sign in to websites (and mobile experiences) seems like a good idea.

Roundtrip mobile sign-in with OpenID

Now, this entire flow is OAuth territory, but for the sake of discussion, I’m going to talk about the conceptual flow of OpenID. I recommend that anyone who wants to implement this flow actually look into using OAuth to support this mobile flow.

In this flow, we start with the similar presumptions except that instead of storing the mobile number with Brightkite, we’re going to store it with the OpenID provider.

  1. As before, we start by visiting the mobile Brightkite site.
  2. If it’s not provided on the homepage, we click “Sign in with OpenID”.
  3. Enter your OpenID and hit “Login”.
  4. This time however, we’re going to bounce over your OpenID provider where one of three things could happen:
    1. If your OpenID provider has a pre-defined mobile flow, or if you’re using directed identity (as Yahoo does) you’ll have to use the standard sign in procedure. This is how things are today.
    2. If your identity provider recognizes both your OpenID URL and the relying party URL as a mobile site (i.brightkite.com), it should immediately issue a token (like a five-digit numerical value) to Brightkite and send it (via SMS) to your mobile device. If you can provide that same token to Brightkite, Brightkite should successfully sign you in since you’ve proven that your identity provider knows that you’re trying to authenticate. In this flow, you wouldn’t see your identity provider; instead you would likely receive a text message that said “Someone is trying to sign in to Brightkite.com as you. To confirm this request, use this token: [12345].”
    3. A slight variation to the previous step would be for the relying party (Brightkite) to indicate that it’s requesting a mobile flow in its original request, if available. This could be as simple as appending “?mobile=true” as a parameter hint to help the OpenID provider use a mobile-friendly authentication dance, rather than trying to recognize the relying party as a mobile site.
  5. As before, once you receive the SMS from Brightkite, you return to the login flow and enter the key.
  6. If you provide the correct key, Brightkite should log you in successfully, since you’ve proven that you have control of your OpenID identity.

The major benefit to this approach is that you’re actually authenticating against your OpenID provider. Additionally 1) you never necessarily need to reveal your phone number to the relying party (say, if we weren’t talking about Brightkite) and 2) should you change your mobile number, you would only need to change it on the side of your identity provider, rather than on every site that offer a mobile version of their site, to continue to be able to authenticate with your OpenID URL.

Bonus: Twauth v0.2: using Twitter direct messages

Finally, should a service or identity provider not wish to send (or pay for) SMS’, the alternative would be to allow someone to associate their Twitter account, via the Twitter API, to their existing account (e.g. their Brightkite account) and then to receive direct messages with the private tokens. The problem with this approach is that it uses Twitter, which may not be reliable, and that it also exposes tokens, via the Twitter API, to any other third-party services that can read your direct messages (basically any other Twitter app that asks for your Twitter account credentials).

Still, for testing purposes, Twitter could be a useful intermediary.

Thoughts/counter-proposals/arguments?

I’m joining Vidoop to work on DiSo full time

Twitter / Scott Kveton: w00t! @factoryjoe and @willnorris joining Vidoop ... :-) http://twurl.cc/18g

Well, Twitter, along with Marshall and his post on ReadWriteWeb, beat me to it, but I’m pretty excited to announce that, yes, I am joining Vidoop, along with Will Norris, to work full time on the DiSo (distributed social) Project.

For quite some time I’ve wanted to get the chance to get back to focusing on the work that I started with Flock — and that I’ve continued, more or less, with my involvement and advocacy of projects like microformats, OpenID and OAuth. These projects don’t accidentally relate to people using technology to behave socially: they exist to make it easier, and better, for people to use the web (and related technologies) to connect with one another safely, confidently, and without the need to to sign up with any particular network just to talk to their friends and people that they care about.

The reality is that people have long been able to connect to one another using technology — what was the first telegraph transmission if not the earliest poke heard round the world? The problem that we have today is that, with the proliferation of fairly large, non-interoperable social networks, it’s not as easy as email or telephones have been to connect to people, and so, the next generation of social networks are invariably going to need to make the process of connecting over the divides easier, safer and with less friction if people really are going to, as expected, continue to increase their use of the web for communication and social interaction.

So what is the DiSo Project?

DISO-PROJECTThe DiSo Project has humble roots. Basically Steve Ivy and I started hacking on a plugin that I’d written that added hcards to your contact list or blogroll. It was really stupidly simple, but when we combined it with Will Norris’ OpenID plugin, we realized that we were on to something — since contact lists were already represented as URLs, we now had a way to verify whether the person who ostensibly owned one of those URLs was leaving a comment, or signing in, and we could thereby add new features, expose private content or any number of other interesting social networking-like thing!

This lead me to start “sketching” ideas for WordPress plugins that would be useful in a distributed social network, and eventually Steve came up with the name, registered the domain, and we were off!

Since then, Stephen Paul Weber has jumped in and released additional plugins for OAuth, XRDS-Simple, actionstreams and profile import, and this was when the project was just a side project.

What’s this mean?

Working full time on this means that Will and I should be able to make much more progress, much more quickly, and to work with other projects and representatives from efforts like Drupal, BuddyPress and MovableType to get interop happening (eventually) between each project’s implementation.

Will and I will eventually be setting up an office in San Francisco, likely a shared office space (hybrid coworking), so if you’re a small company looking for a space in the city, let’s talk.

Meanwhile, if you want to know more about DiSo in particular, you should probably just check out the interview I did with myself about DiSo to get caught up to speed.

. . .

I’ll probably post more details later on, but for now I’m stoked to have the opportunity to work with a really talented and energized group of folks to work on the social layer of the open web.

Thoughts on DataPortability

Introduction

Over the last several days I’ve started and abandoned four drafts of this post. Usually it doesn’t take me this long to write out my thoughts, or to go through so many different approaches, but I wanted to express myself as clearly as I could given the amount and overlapping texture of what I wanted to say. I ended up gutting a lot, and tried to focus on some basics, making as few assumptions about the reader (you) as possible.

The reality is that I’m eyeballs-deep in this stuff, and realized that in earlier drafts, I had included a lot of subtext that just wasn’t helping me get my message across and that really only made sense to other folks similarly in the thick of it.

So I got rid of the subterfuge and divided this up into four sections, inspired by a conversation I had with Brynn.

I encourage and invite feedback, but I would prefer to discuss the substance of what I’m arguing, rather than focusing on tit-for-tat squabbly disagreements.

  1. What is data portability?
  2. How does DataPortability (DP) relate to OpenID?
  3. Are there risks associated with DataPortability?
  4. What’s good about DataPortability?

What is data portability?

Contrary to what some folks have argued, I think that the semantics and meaning of the phrase “data portability” are important. To me data portability denotes the act of moving data from one place to another, and that the data should, therefore, be thought of like a physical thing, with physical properties.

Let me draw an analogy here to illustrate the problem with this model.

Take an iPod. With an iPod, you literally copy files from one device to another — for example, from your laptop to your iPod. This is, on the one hand, a limitation imposed by a lack of connectivity and restrictions in copyright law, but on the other, is actually by design. This scenario is not altogether unmanageable unless you have dozens of iPods that you want to sync up with your music, especially if you don’t typically think to connect your iPod every time you add new music, create new playlists or otherwise change your music library.

Now take an always-connected player, like Pandora Mobile, where the model works by federating continuous access from a central source — to consuming devices that play back music. Ignoring the restrictions that make it impossible for Pandora to let you listen to what you want on demand, the point is that, rather than making numerous copies across many unaffiliated and disconnected devices, Pandora affords a consistent experience and uniform access by streaming live data to any device that is authorized (and is online).

The former model (the iPod) is what you might call the “desktop model of data portability”. Certainly you can copy your data and take it with you, but it doesn’t reflect a model where always-on connectivity is assumed, which is the situation with online social networks. The offline model works well for physical devices that don’t require an internet connection to function — but it is a model that fails for services like Pandora, that requires connectivity, and whose value derives from ready access to up-to-date and current information, streamed and accessible from anywhere (well, except in Canada).

It’s nuance, but it’s critical to conceptualizing the value and import of this shift, and it’s nuance which I think is often left out of the explanation of “DataPortability” (whose official definition is the option to share or move your personal data between trusted applications and vendors (emphasis added)). In my mind, when the arena of application is the open, always-on, hyper-connected web, constructing best practices using an offline model of data is fraught with fundamental problems and distractions and is ultimately destined to fail, since the phrase is immediately obsolete, unable to capture in its essence contemporary developments in the cloud concept of computing (which consists of follow-your-nose URIs and URLs rather than discreet harddrives), and in the move towards push-based subscription models that are real-time and addressable.

So if you ask me what is “data portability”, I’ll concede that it’s a symbol for starting a conversation about what’s wrong with the state of social networks. Beyond that, I think there’s a great danger that, as a result of framing the current opportunity around “data portability”, the story that will get picked up and retold will be the about copying data between social networks, rather than the more compelling, more future-facing, and frankly more likely situation of data streaming from trusted brokered sources to downstream authorized consumers. But, I guess “copying” and “moving” data is easier to grasp conceptually, and so that’s what I think a lot of people will think when they hear the phrase. In any case, it gets the conversation started, and from there, where it goes, is anyone’s guess.

How does DataPortability (DP) relate to OpenID?

OpenID, along with OAuth, microformats, RSS, OPML, RDF, APML and XMPP are all open and non-proprietary technologies — formats and protocols — that grace the DataPortability homepage. How they ended up on the homepage, or what selection criteria is used to pick them, is beyond me (for example, I would have added ATOM to the list). So the best way that I can describe the relationship between any of these technologies and DataPortability is that, at some point, the powers that be within the group decided to throw a logo on their homepage and add it to their “social software stack”.

To reiterate (and I won’t speak for the OpenID Foundation since I’m unfamiliar with any conversations that they might have had with DP), no one necessarily asked if it would be okay to put the OAuth or microformats logos on the homepage of DP, or to include those technologies in the DP stack. They just did it. It wasn’t like DP had been around for awhile with a mandate to develop best practices for the future of social networks, and groups like the microformats community petitioned or was nominated to be included. They simply were. There was no process, as far as I’m aware, as to what was included, and what was not.

So while OpenID and the other technologies may be part of the technologies recommended by DP, it should be known that there really is no official relationship between these efforts and DP (though it is true that many members of each group coordinate, meet and discuss related topics, for example, at tomorrow’s Internet Identity Workshop, and at events like the Data Sharing Summit).

Beyond that, it should be noted that OpenID, OAuth, microformats et al have been in development for the last several years, and have been building up momentum and communities all on their own, without and prior to the existence of the DP initiative. In fact, the DP project really only got its start last November with an idea presented by Josh Patterson and Josh Lewis called WRFS, or the “Web Relational File System”. At the time, the WRFS was intended to serve as a “reference design” for describing how data portability should work and this was to serve as the foundation of the DP recommendations.

In January, after ongoing discussions, Josh decided that it would be best to spin WRFS off into its own project and started a separate mailing list, leaving DP to focus exclusively on evangelizing existing technologies and communities and, in the oft-repeated words of Chris Saad, to invent nothing new (a mantra inherited from the OAuth and microformats efforts).

Are there risks associated with DataPortability?

If you accept that DP is primarily a symbol for starting the conversation about transforming social networks from walled gardens into interoperating, seamful web services, then no, not really. If you believe or buy into the hype, or blindly follow the forthcoming “technical specifications“, I see significant risks that need to addressed.

First, DP does not speak for the community as a whole, for any specific social network (except, perhaps, MySpace), or for any individuals except those who publicly align themselves with the group. On too many occasions to feel comfortable about, I’ve seen or read members of the DP project claim authority far beyond any reasonable mandate, which to me have read like attempts to seize control and influence that not only isn’t justified, but that shouldn’t be ascribed to any individual or organization. I worry that this hubris (conceivably a result of proximity to certain A-Listers) is leading them to take more credit than they’re due, and in consequence, folks interested but previously uninitiated with any of the core technologies will be lead to believe that the DataPortability group is responsible and in control of those technologies. Furthermore, if it is the case that people are mislead, I have little faith that folks from the DP project will prevent themselves from speaking on behalf of (or pseudo-knowledgeably about) those technologies, leading to confusion and potential damage.

Second, I have a great deal of concern about the experiences and priorities that are playing into the group’s approach to privacy, security, publicity and disclosure. These are concerns that I would have with any effort that aims to bridge different social or commercial contexts where norms and expectations have already been established, and where there exists few examples (apart from Beacon) of how people actually respond to semi-automatic social network cross-fertilization. Not that privacy isn’t a hot topic on the DP mailing lists, it’s just that statements like this one reflects fishtailing in the definition and approach to privacy from a leader of the group, and that I worry could skid wildly out of control if clarity on how to achieve these dictims isn’t developed very soon:

The thing is that while Privacy is certainly important, in the end these are *social* platforms. By definition they are about sharing. The problem with Facebook Beacon was not that it was sharing, but rather it was sharing the WRONG information in the WRONG way.

Also again, don’t forget, just because data is portable or accessible does NOT mean it is public or ‘open’. This is why I stayed away from the ‘Open Data’ terminology when thinking up DataPortability. Just like a Hard Drive and a PC that runs certain applications, ultimately the applications that USE the data that need to ensure they treat the data with respect – or users will simply stop using them.

[. . .]

You are right that DP should NOT be positioned that Privacy is not important – that is certainly not my intention with my answers. But being important and being a major sticking point is two different things.

Again I tend to think of this as one big Hard Disk. While you provide read/write permissions to folders on a network (for privacy) it is ultimately up to the people and applications you trust to respect your privacy and not just start emailing your word docs to your friends.

So if the second risk is that an unrealistic, naive or incomplete model of privacy [coupled with a lack of effective enforcement mechanisms in the case of fraud or abuse] will be promoted by the DP group, the third risk is that groups or communities that are roped into the DP initiative may open themselves up to a latent social backlash should something go wrong with specific implementations of DataPortability best practices. Specifically, if the final privacy model demands certain approaches to user data, and companies or organizations go along with them by adopting the provided “social technology stack” (i.e. libraries offered that implement the DP data model), the technical implementation may be flawless, but if people’s data starts showing up in places where they didn’t expect it to, they may reject the whole notion of “data portability” and seek to retreat back to the days of “safe” walled gardens of today. And it may be that, because of the emphasis on specific technologies in the DP group’s propaganda, that brands like OpenID and OAuth will become associated with negative experiences, like downloadable .exes in email are today. It’s not a foregone conclusion in my mind that this future is inevitable, but it’s one that the individual groups affected should avoid at all costs, if only because of the significant progress we’ve made to date on our own, and it would be a shame if ignorance or lack of clear communication about the proper methods of adoption and implementation of these technologies lead people to blame the technology means instead of particular instances of its application.

What’s good about DataPortability?

I don’t want to just be a negative creep, so I do think that there is a silver lining to the DP initiative, which I mentioned earlier: it provides a token phrase that we can throw around to tease out some of the more gnarly issues involved in developing future social applications. It is about having a conversation.

While OpenID and OAuth have actual technology and implementations behind them, they also serve as symbols for having conversations about identity and authorization, respectively. Similarly, microformats helps us to think about lightweight semantic markup that we can embed in human-friendly web pages that are also compatible with today’s web browsers, and that additionally make those pages easier for machines to parse. And before these symbols, we had AJAX and Web 2.0, both of which, during their inception, were equally controversial and offensive to the folks who knew the details of the underlying technological innovation behind the terms but who also stood to lose their shamanic positions if simpler language were adopted as the conversations migrated into the mainstream.

Now, is there a risk that we might lose some of the nuance and sophistication with which we data junkies and user-centric identity advocates communicate if we adopt a less precise term to describe the present trends towards interoperable social networks? Absolutely. But this also means that, as the phrase “data portability” makes its way into common conversation, people can begin to think about their social networking activities and what they take for granted (“Wait, you mean that I wouldn’t have to sign up for a new account on my friend’s social network just to send them a photo? Really?”), and to realize that the way things are today not only aren’t the way that they have to be, but that there is a better way for social applications to be designed, architected and presented, that give the enthusiasts and customers of these services greater choice and greater latitude to actually pick services that — what else? — serve them best!

So just as Firefox gave rise to a generation of web developers that take web standards much more seriously, and have in turn recognized and capitalized on the power of having a “rectangle” that actually behaves in a way that they expect (meaning that it fully complies with the standards as they’ve been defined), I think the next evolution of the social web is going to be one where we take certain things, like identity, like portable contact lists, like better and more consistent permissioning systems as givens, and as a result, will lead to much more interesting, more compelling, and, perhaps even more lucrative, uses of the open social web.