Facebook has announced that they are about to release vanity URLs.

What most people don’t realize is that this move, while interesting, is not really about vanity URLs at all – it’s actually about addressable identity.

One of Twitter’s key advantages in the race for dominance over internet identity is their growing namespace of what I call Addressable Identities.

What are they I hear you ask? An example of an Addressable Identity is being able to write ‘@chrissaad‘ and have the system and users understand that it is a direct and concrete reference to me. This form of addressing is particularly interesting because it is easy to write in a sentence or micro-blog.

With Vanity URLs, Facebook will encourage users to specify a tidy/tiny/compact identity identifier by which friends/followers/others can reference/point to each other. This is a big step towards keeping up with Twitter as one of the web’s only providers of modern addressable identities (email is an old, less compact version of this).

It will be interesting to see how this unfolds and how we consolidate these namespaces when using 3rd party services.

It might ultimately have to end up like good old email:

chrissaad@twitter.com, chrissaad@facebook.com etc.

Ideally though, we should be able to use our own/personal email address and have it resolve to an OpenID for true, federated and open addressable identity.

That, however, is still some way away.

Proposal: OpenID Connect

December 8, 2008

OpenID needs to be as simple as Facebook Connect if it has any chance of competing. The problem is User Experience. It’s a nightmare.

My proposal:

  1. All Email providers and OpenID Consumers (particularly Gmail, Hotmail and Yahoo Mail) implement: http://eaut.org/
  2. Until we have critical mass with step 1, a 3rd party, community controled “Email to OpenID mapping service” should be provided. Vidoop runs a related service at http://emailtoid.net/. It’s quite good but it should be donated to the OpenID foundation for independent control.
  3. OpenID Connect login prompts ask for your email address on 3rd party sites.
  4. When you hit ‘connect’ it generates a popup much like the FB Connect popup.
  5. The contents of the popup is either:
    • The password screen of the OpenID provider as resolved via EAUT OR
    • The password screen of the OpenID provider as resolved via the community EmailtoID service OR
    • A prompt from the EmailToID service that walks you through creating a new OpenID or mapping an exiting OpenID to this email address.Here’s the important part: In all cases, the screens MUST conform to a strict UX Design Guideline set forth by the OpenID Foundation to ensure the process is as simple as Facebook Connect.Only providers that confirm to this OpenID Connect UX standard (as certified by the OpenID Foundation?) may have their OpenIDs validated in this popup. This is a harsh rule but it ensures a smooth UX for all involved.
  6. This initial Email to OpenID mapping through a 3rd party service is painful since most email providers and OpenID consumers do not use EAUT yet.
  7. This can be overcome if we get a series of OpenID Consumers and OpenID Providers involved as launch partners. A major email provider (Gmail, Hotmail and/or Yahoo) would also be be helpful but not a blocker.

Potential Concerns:

  1. How do we deter phishing? Does this work-flow make phishing worse because of the predictable UX? Does it matter? Is there a way to ensure a distributed karma system is included in the work flow?
  2. This only solves the login problem and does not go into the issue of connecting to, accessing and manipulating data as the full data portability vision describes. This is a conversation for another thread.


  • If you provide OpenID but do not consume it you need to be named and shamed. There should be a 2 month grace period, then The OpenID Foundation, the DataPortability Project and everyone else who is interested should participate.
  • “OpenID Connect” should be a new brand with a fresh batch of announcements with strict implementation guidelines (not just around UX but also around things like consumption).

To summarize, my proposal world:

  1. Allow users to use their email address for OpenID
  2. Standardize the User Experience for OpenID
  3. Provide a stop gap while Email providers catch up with Email to OpenID mapping.

Get involved:

I’d love to do mockups for this – but I’m busy. Anyone interested in learning from the Facebook Connect UX and drafting OpenID Connect Mockups from which we can draw the strict UX guidelines I mentioned?

Could this work?

Is Data Portability Safe?

November 20, 2008

‘What about privacy and security’ is a question that comes up regularly when discussing Data Portability. I’d like to address some of the reasons why Data Portability is actually good for privacy.

More safe than today.

Data Portability is not about putting more personal data in the cloud. We’re dealing with data that’s already out there. The goal is to provide the ability to give access to your data to applications you trust.

Using proper protocols and formats to move the data such as oAuth and OpenID is safer than allowing sites to scrape your mail account by giving it your username and password. They are safer because you are not giving your username and password away and because the access is scoped. Scoped access mean that you can grant specific and precise access to only the data you want to share with the requesting application (e.g. just your address book) as apposed to giving them complete access to your entire gmail account (address book, email, account history, google searches etc).

Federated Karma – Market Forces made Explicit

It may be possible to build a distributed trust or Karma system that sites and services can expose on Authorization Screens so that users can make informed decisions before trusting an application.

Users could rate services and the ratings would be normalized and made available via trusted Karma aggregation services.

This would provide an explicit meta layer of market sentiment at the point of permitting a data portability transaction.

This solution is far better than the Facebook Protection Fee solution.

Privacy is the wrong word

The real issue should not be labeled Privacy. Privacy is an idea but it’s not actionable. It can not be converted into ‘functionality’. We should be discussing ‘access controls’, ‘portable permission metadata’ and ‘universal privacy models’. These ideas combined allow us to define and implement privacy preferences in concrete terms.

Hyper Transparency

Privacy advocates can never and should never come to peace with it, but it’s clear that traditional ideas of privacy are changing.

Remember that It was once thought unconscionable to share you photos, daily activities, location, relationship status and other personal information for the world to see. Now it’s standard practice for young people around the world.

What taboos of personal privacy will fade next? It’s quite possible the question asked by future generations of Internet users will ask not why their data is available for everyone to see, but rather why it isn’t.

“I think therefore I am”.

Maybe now it’s

“I tweet therefore I am”.

The web-wide social network

November 19, 2008

Ross Dawson has an excellent summary of a Gartner presentation on the Distributed Social Web by David Cearley. A web where each participant is their own central node on a web-wide social network.

It is the only natural conclusion of the vision of Data Portability.

It will be made possible by a series of futurists, technologists, philanthropists and engineers developing core building blocks like OpenID, oAuth, APML, PortableContacts, XMPP, RSS/ATOM, OPML, Microformats and more.

It will be commercialized by a series of entrepreneurial start ups with stars in their eyes running in and around the feet of the giants who are each fighting each other to keep up. Startups like JS-Kit.

It will be fueled by traditional and not so traditional media companies, steered by young, idealistic intrapraneurs, who are willing to take a bet in order to stake their claim on the next generation of social networking and human communication.

It will be monetized by a recognition that one can’t monetize word-of-mouth. Instead Attention will emerge as the ultimate way to measure, discover and interact with participants. See Faraday Media.

It will be popularized by bloggers, smart IT journalists and conference organizers who understand the importance of open over closed.

We have already started to see a preview of the world to come via the early attempts at rudimentary aggregators and proprietary data portability implementations. This is just the beginning of the beginning.

For a more details around the emerging trends, check out Ross’ post.

Using email as OpenID

August 22, 2008

One of the most common comments/questions I get while talking about data portability is ‘The OpenID User Experience sucks – how do we make it more user friendly?’.

The problem is two fold. First, users do not understand why they need to provide a URI to log in. Second, users get confused by bouncing around to a 3rd party site.

I’ve given a lot of thought to this problem.

The only answer I’ve had so far is that while the OpenID user experience is difficult to explain to users who expect an email address and password log in, the data portability value proposition may help justify the added cognitive load for users and vendors.

It’s probably true – but it’s not a good enough answer.

More recently I’ve been thinking about another potential solution.

I believe the 3rd party site bounce is actually becoming common place. Passport, Facebook, Google use it and, as such, users are becoming more comfortable with it.

The question of using a URI as a ‘username’ however, is a more difficult pattern to explain to users at a login screen.

Mapping email addresses to OpenIDs

The purists among us will argue that identity should not be tied to messaging. That is, uniquely identifying people by email address is a bad idea. It encourages spam and other unhealthy activity.

Putting that aside for a moment, however, imagine this.

Rather than asking for a user’s OpenID, ask them for their email address:


Now imagine the application refactoring the address on the fly to something like this:


The point here is that we take everything before the @ and place it after a slash. Remove the @ and put HTTP:// at the start and you end up with a well formed URI.

Now imagine that Gmail provided OpenID functionality for each email account in this way.

There are a number of challenges to pulling this off. Not the least of which is getting major email providers to support OpenID, and get existing OpenID consumers to refactor email addresses (if provided) on the fly.

It’s certainly worth thinking about though.

Chris Messina has posted a fantastic post on his blog about DataPortability. It is a real pleasure to read his thoughtful and well articulated questions, concerns and compliments about the project.

I am going to try to answer or comment on many of his comments below by quoting big chunks and including my ideas.

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.

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.

I do understand the concerns about names and the underlying meaning they convey. I do think, however, that the ship has sailed on the branding of the movement. We can call it Data Availability, Data Connectivity, Data Streaming, Data Accessibility or we can call it what everyone is already calling it – Data Portability. I think the nuance of meaning is probably one that only affects the technologists closest to the issue; not the broader audience we are trying to reach.

Also, we have long defined ‘portability’ as the ability to port the data or port the context in which the data is used. That is, use data from one application from within the context of another application.

Is it a perfect name? Probably not.

Is it worth diluting the conversation to stop and rename it? probably not.

Can the community live with it? I would argue they could. So we should probably move on.

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”.

I’m curious if, besides Atom, there are any other standards that community members would suggest as an addition to the list. Are there any on there that don’t belong there? Having discussed this topic for a long time now, I think that most people agree that each of those technologies listed have a place in the conversation. The final ‘stack’ however will be determined by the Technical Best Practice documents.

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.

Agreed – this is a fact I constantly repeat to everyone I speak to – particularly in public forums and on podcasts. I don’t think, however, anyone can deny that the DataPortability project has accelerated the momentum and helped to propel the conversation into the mainstream. It is gratifying that many of the participants in each of these standards groups (particularly the groups that don’t have as much visibility as OpenID, Microformats or oAuth) are now participating in the DataPortability project as a way to promote their work to a broader audience.

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).

This is actually not quite accurate. The DataPortability project was running in parallel to the work on WRFS. We invited the two Josh’s to bring their WRFS work into the DataPortability project and as it matured we spun it out again.

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.

This is certainly where it starts – but I think it’s clear that the group has far more potential than that.

… 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.

This is also true – The DataPortability project speaks for itself and for the people who participate. There are thousands of people and vendors both large and small who have publicly supported the group and, by extension, given it some level of authority to consult on and develop best practices for the community.

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.

Open standards are developed as building blocks. The DataPortability project is building something from them. If some of the standards groups would -for some reason – like their standard to be excluded from our recommendations then we would be happy to oblige.

Also, there are a lot of people from all over the world looking at, refining and experimenting with the best practices being developed. I think most would agree that ‘something could go wrong’ is not enough reason not to try working through the challenges to come up with something worthwhile.

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.

Agreed. I have often used the example that DataPortability can and will do for open standards what Web 2.0 and AJAX did for CSS, Javascript and XML.

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.

I obviously agree completely here.

It is clear with Chris’ great post, that the data portability conversation, and the DataPortability project has unearthed a fantastic set of questions and opportunities.

The Data Portability narrative, and the resulting questions that it posses, are precisely the tools that will encourage end users, developers, vendors and media to further investigating popular standards like OpenID and Microfomats, and dig deeper into more nascent standards like RDF, XRDS and APML.

The resulting acceleration in just six months has been phenomenal – I look forward to the next six months.

I’ve written more on this subject in my “Internal note of thanks” post.

In the last couple of weeks there have been a number of very positive steps forward for Data Portability in general and the DataPortability Project specifically.

These include wins by the OpenID Foundation, the IC report, the DataPortability Report and others.

A couple of trends, though, are causing me a little concern and may require a slight course correction before they spin out of control and fragment, rather than standardize, the ecosystem.

1. Tightly coupled OpenID Implementations

On Plaxo right now there is a ‘Sign in with YahooID’ button. This is effectively an OpenID login mechanism, except to remove the user experience complexity of OpenID, Plaxo has worked with Yahoo to make it easier by creating a direct relationship.

This seems antithetical to the promise of OpenID and could ultimately create another mess of tightly coupled vendor relationships that defeat the purpose of a single sign-on identity that any provider can provide and consume.

A more long term solution must be to improve the generic OpenID user experience or devise an education campaign to help users learn the new login process.

2. Google’s Social Graph API

While revealing an enormous usefulness in the existing XFN and FOAF data out on the web, Google’s Social Graph API also reveals a weakness in current XFN and FOAF implementations. Many users are not aware when XFN data is included around URLs they enter, much less when the URLs are marked as rel=me.

For example when Twitter asked me for my homepage, I didn’t understand that I was asserting a semantic link from Twitter to my blog that Google would later document and carve into stone as part of its implicit global social network in the sky.

As it stands, there is a real concern for user backlash as these APIs start being implemented and users find themselves presented with eerily accurate information about themselves magically appearing on websites without their ‘consent’.

Some sort of best practice text and/or iconography is required around fields that will be marked up with XFN – particularly if rel=me will be used to that users can make informed decisions about the type of data they provide and how it might be used. Perhaps even an opt out checkbox is appropriate.

This is probably a job for the Microformat community to dig into and solve. They should probably solve it quickly though.

3. OpenSocial++

As OpenSocial implementations role out, it’s becoming clear that there is no such thing as a pure OpenSocial container. Each container includes proprietary APIs and extensions that widget developers may choose to use.

Presumably these exist to differentiate each network and encourage developers to write enhanced apps for the environment.

The problem, though, is that developers need to write defensively for each custom API leading us to a place similar to browser compatibility hell. App developers will need to write and test their apps across every Container and will either have to hard code support for special APIs or keep their apps generic and ordinary.

Is this sustainable? Is there a better way?

If OpenSocial is going to be the Write Once, Deploy Many model for widgets, then the OpenSocial team at Google need to find a way to address this concern quickly.