Tag: identity

RIP @factoryjoe

Twitter / Mr Messina: Oh, and in case you missed ...

Sometime last week, after two Manhattans, I decided to change my Twitter username from @factoryjoe to @chrismessina. In the scheme of things, not a big deal (yeah, okay, so I broke a couple thousand hyperlinks…). And yet, I can’t but feel like I’ve shed a skin or changed identities… at least to a specific audience.

I started using Twitter in 2006 as “factoryjoe”. Of course, this is the nick that I use everywhere —from Flickr to my personal homepage — so that choice was obvious. I essentially own factoryjoe on the web — people even occasionally call me “Joe” when we meet, such is their familiarity with my online persona. But that’s not my actual name.

When I talk in front of people and I introduce myself as “Chris Messina”, the disconnect between my real name and my online persona becomes distracting. And, over time, my motivations for having a separate online identity have waned.

But first, I suppose, I should provide some background.

Where did “factoryjoe” come from?

Every so often I’m asked where “factoryjoe” came from: “Kind of like ‘Joe the Plumber?’” “Kind of,” I say. “But not really.”

Growing up, I drew comic books for fun. In fact, for most of my formative years, it seemed pretty clear that I’d pursue a career in art. I worked in pastels, watercolor, pen and ink; I preferred pen and ink above all the others though, taking lessons from Rob Liefeld, Todd McFarlane, Jim Lee and others as Image Comics came on to the scene. It was a fond dream of mine to someday pen my own sequential art.
1984 PosterIn high school, I read Nineteen Eighty-Four and became enamored with the character of Winston Smith, Orwell’s “everyman” character. In Winston Smith, I found a confederate, struggling to assert his individual humanity against the massive, dehumanizing forces of groupthink and oligarchy. Similarly, I identified with Vonnegut’s Harrison Bergeron and his struggle against homogeneity and mediocrity. The contours of “factoryjoe” began to emerge against the backdrop of the metropolitan “FactoryCity”, where industrialism was proven a sham and one’s conspicuous pursuit of passion ruled over the shallow pursuit of material consumption.

Factory City

Factory Joe was the anonymous shell in which I could plant my aspirations and designs for the future. He served as a metaphorical vessel through which I could mold a broader narrative.

So… changing your Twitter username?

In every superhero’s journey, there comes a time when the mask grows bigger than its owner. Is it the mask that provides the wearer with his power, or is it something integral to the individual?

I once believed that I needed to have a deep separation between myself and my online persona — that they should be distinct; that I should distrust the web. Over time I’ve realized a great deal power by closing the gap between who I am offline and who I am online. I suppose this is the power of transparency, developed through consistency and demonstrated integrity.

@factoryjoe was, therefore, my first go at creating an online identity for myself. A kind of “home away from home” that I could experiment with before this whole social web thing caught on.

As it happened, this was fine when I had a small group of friends who used similar aliases for themselves, but more recently — inspired by Facebook’s allergy to pseudonyms and non-human friendly usernames — it seems that not only owning your own identity is in vogue, but using your real name is an act of assertiveness, inventiveness or establishment. Heck, if you’re willing to share your real name with 150+ million compatriots on Facebook, is there really that much to be gained from obfuscating your actual name on the open web anymore (that’s rhetorical)?

So, back to Future of Web Apps… following my workshop with Dave, I took a step back to think about how it must appear for me to be working on the social web and identity technologies while maintaining this dichotomy between my offline and online personas — in name only. C’mon, when people have feedback and I’m talking on stage — who do I want them addressing? — my assumed identity … or me? The friction that I invented is just no longer necessary.

So factoryjoe isn’t going away — not entirely at least. It’s a useful vessel to inhabit and I’ll continue to do so. But on Twitter, Facebook, and on my homepage, I’ll use my real name. There is simply no longer a good reason to differentiate between who I am online, and who I am off, if ever there was.

. . .

Postscript: I’m now @chrismessina on Twitter. If we were friends before — no need to make any changes — Twitter took care of that already. @factoryjoe‘s been retired, but now that I got it back from Recordon (he was just jealous, since he has the worst username ever), who knows, maybe he’ll return someday. We’ll see!

Responding to criticisms about OpenID: convenience, security and personal agency

Twitter / Chris Drackett: openID should be dead... its over-rated.

Chris Dracket responded to one of my tweets the other day, saying that “OpenID should be dead… it’s way over-rated”. I’ve of course heard plenty of criticisms of OpenID, but hadn’t really heard that it was “overrated” (which implies that people have a higher opinion of OpenID than it merits).

Intrigued, I replied, asking him to elaborate, which he did via email:

I don’t know if overrated is the right word.. but I just don’t see OpenID ever catching on.. I think the main reason is that its too complex / scary of an idea for the normal user to understand and accept.

In my opinion the only way to make OpenID seem safe (for people who are worried about privacy online) is if the user has full control over the OpenID provider. While this is possible for people like you and me, my mom is never going to get to this point, and if she wants to use OpenID she is going to have to trust her sensitive data to AOL, MS, Google, etc. I think that people see giving this much “power” to a single provider as scary.

Lastly I think that OpenID is too complex to properly explain to someone and get them to use it. People understand usernames and passwords right away, and even OAuth, but OpenID in itself I think is too hard to grasp. I dunno, just a quick opinion.. I think there is a reason that we don’t have a single key on our key rings that opens our house, car, office and mailbox, not that that is a perfect/accurate analogy, but its close to how some people I’ve talked to think OpenID works.

Rather than respond privately, I asked whether it’d be okay if I posted his follow-up and replied on my blog. He obliged.

To summarize my interpretation of his points: OpenID is too complex and scary, potentially too insecure, and too confined to the hands of a few companies.

The summary of my rebuttals:

Convenience

OpenID should not be judged by today’s technological environment alone, but rather should be considered in the context of the migration to “cloud computing”, where people no longer access files on their local harddrive, but increasingly need to access data stored by web services.

All early technologies face criticism based on current trends and dominant behaviors, and OpenID is no different. At one time, people didn’t grok sending email between different services (in fact, you couldn’t). At one time, people didn’t grok IMing their AOL buddies using Google Talk (in fact, you couldn’t). At one time, you had one computer and your browser stored all of your passwords on the client-side (this is basically where we are today) and at one time, people accessed their photos, videos, and documents locally on their desktop (as is still the case for most people).

Cloud computing represents a shift in how people access and share data. Already, people rely less and less on physical media to store data and more and more on internet-based web services.

As a consequence, people will need a mechanism for referencing their data and services as convenient as the c: prompt. An OpenID, therefore, should become the referent people use to indicate where their data is “stored”.

An OpenID is not just about identification and blog comments; nor is it about reducing the number of passwords you have (that’s a by-product of user-centered design). Consider:

  • if I ask you where your photos are, you could say Flickr, and then prove it, because Flickr supports OpenID.
  • if I ask you where friends are, you might say MySpace, and then prove it, because MySpace will support OpenID.
  • if you host your own blog or website, you will be able to provide your address and then prove it, because you are OpenID-enabled.

The long-term benefit of OpenID is being able to refer to all the facets of your online identity and data sources with one handy — ideally memorable — web-friendly identifier. Rather than relying on my email addresses alone to identify myself, I would use my OpenIDs, and link to all the things that represent me online: from my resume to my photos to my current projects to my friends, web services and so on.

The big picture of cloud computing points to OpenIDs simplifying how people access, share and connect data to people and services.

Security

I’ve heard many people complain that if your OpenID gets hacked, then you’re screwed. They claim that it’s like putting all your eggs in one basket.

But that’s really no different than your email account getting hacked. Since your email address is used to reset your password, any or all of your accounts could have their passwords reset and changed; worse, the password and the account email address could be changed, locking you out completely.

At minimum, OpenID is no worse than the status quo.

At best, combined with OAuth, third-parties never need your account password, defeating the password anti-pattern and providing a more secure way to share your data.

Furthermore, because securing your OpenID is outside of the purview of the spec, you can choose an OpenID provider (or set up your own) with a level of security that fits your needs. So while many OpenID providers currently stick with the traditional username and password combo, others offer more sophisticated approaches, from client-side certificates and hardware keys to biometrics and image-based password shields (as in the case of my employer, Vidoop).

One added benefit of OpenID is the ability to audit and manage access to your account, just as you do with a credit card account. This means that you have a record of every time someone (hopefully you!) signs in to one of your accounts with your OpenID, as well as how frequently sign-ins occur, from which IP addresses and on what devices. From a security perspective, this is a major advantage over basic usernames and passwords, as collecting this information from each service provider would prove inconvenient and time-consuming, if even possible.

Given this benefit, it’s worth considering that identity technologies
are being pushed on the government. If you’re worried about putting all your eggs in one basket, would you think differently if the government owned that basket?

OpenID won’t force anyone to change their current behavior, certainly not right away. But wouldn’t it be better to have the option to choose an alternative way to secure your accounts if you wanted it? OpenID starts with the status quo and, coupled with OAuth, provides an opportunity to make things better.

We’re not going to make online computing more secure overnight, but it seems like a prudent place to start.

Personal agency for web citizens

Looking over the landscape of existing social software applications, I see very few (if any) that could not be enhanced by OpenID support.

OpenID is a cornerstone technology of the emerging social web, and adds value anywhere users have profiles, accounts or need access to remote data.

Historically, we’ve seen similar attempts at providing a universal login account. Microsoft even got the name right with “Passport”, but screwed up the network model. Any identity system, if it’s going to succeed on the open web, needs to be designed with user choice at its core, in order to facilitate marketplace competition. A single-origin federated identity network will always fail on the internet (as Joseph Smarr and John McCrea like to say of Facebook Connect: We’ve seen this movie before).

As such, selecting an identity provider should not be relegated to a default choice. Where you come from (what I call provenance) has meaning.

For example, if you connect to a service using your Facebook account, the relying party can presume that the profile information that Facebook supplies will be authentic, since Facebook works hard to ferret out fake accounts from its network (unlike MySpace). Similarly, signing in with a Google Account provides a verified email address.

Just like the issuing country of your passport may say something about you to the immigration official reviewing your documents, the OpenID provider that you use may also say something about you to the relying party that you’re signing in to. It is therefore critical that people make an informed choice about who provides (and protects) their identity online, and that the enabling technologies are built with the option for individuals to vouch for themselves.

In the network model where anyone can host their own independent OpenID (just like anyone can set up their own email server), competition may thrive. Where competition thrives, an ecosystem may arise, developed under the rubric of market dynamics and Darwinian survivalism. And in this model, the individual is at the center, rather than the services he or she uses.

This the citizen-centric model of the web, and each of us are sovereign citizens of the web. Since I define and host my own identity, I do not need to worry about services like Pownce being sold or I Want Sandy users left wanting. I have choice, I have bargaining power, and I have agency, and this is critical to the viability of the social web at scale.

Final words

OpenID is not overrated, it’s just early. We’re just getting started with writing the rules of social software on the web, and we’ve got a lot of bad habits to correct.

As cloud computing goes mainstream (evidenced in part by the growing popularity of Netbooks this holiday season!), we’re going to need a consumer-facing technology and brand like OpenID to help unify this new, more virtualized world, in order to make it universally accessible.

Fortunately, as we stack more and more technologies and services on our OpenIDs, we can independently innovate the security layer, developing increasingly sophisticated solutions as necessary to make sure that only the right people have access to our accounts and our data.

It is with with these changes that we must evaluate OpenID — not as a technology for 2008’s problems — but as a formative building block for 2009 and the future of the social web.

Announcing Emailtoid: mapping email addresses to OpenIDs

EmailtoidThe other night at Beer and Blog in Portland, fellow Vidooper Michael T Richardson announced and launched a new service that I’m both excited and a little apprehensive about.

The service is called Emailtoid, and while I prefer to pronounce is “email-toyed”, others might pronounce it “email two eye-dee”. And depending on your pronunciation, you might realize that this service is about using an email address as an ID — specifically an OpenID.

This is not a new idea, and it’s one that been debated and discussed in the OpenID community an awful lot, which culminated in a rough outline of how it might work by Brad Fitzpatrick following the Social Graph FOO Camp this past spring, and that David Fuelling turned into an early draft spec.

Well, we looked at this work and this discussion and felt that sooner or later, in spite of all the benefits of using actual URLs for identity, that someone needed to take a lead and actually build out this concept so we have something real to banter about.

The pragmatic reality is that many people are comfortable using email addresses as their identity online for signing up to new services; furthermore, many, many more people have email addresses who don’t also have URLs or homepages that they call their own (or can readily identify). And forcing people to learn yet another form of identifier for the web to satisfy the design of a protocol for arguably marginal value with a lesser user experience also doesn’t make sense. Put another way: the limitations of the technology should not be forced on end users, especially when it doesn’t need to be. And that’s why Emailtoid is a necessary experiment towards advancing identity on the web.

How it works

Emailtoid is a very simple service, and in fact is designed for obsolescence. It’s meant as a fallback for now, enabling relying parties to accept email addresses as identifiers without requiring the generation of a new local password and without requiring the address owner to give up or reveal their existing email credentials (otherwise known as the “password anti-pattern“).

Enter your email - Emailtoid

The flow works like this:

  1. Users enter either an OpenID or email address into a typical OpenID input field. For the purpose of this flow, we’ll presume an email address is used.
  2. The relying party splits email addresses at the ‘@’ symbol into the username and the domain, generating a directed identity request to the email domain. If an XRDS, YADIS or XRDS-Simple document is discovered at the domain, the typical OpenID flow is invoked.
  3. If no discovery document is found, the service falls back to Emailtoid (sending a request like http://emailtoid.net/mapper?email=jane@example.com), where users verify that they own the supplied email addresses by providing their one-time access token that Emailtoid mailed to them.
  4. At this point, users may optionally associate an existing OpenID with their email address, or use the OpenID auto-generated by Emailtoid. Emailtoid is not intended to serve as a full-featured OpenID provider, and we encourage using an OpenID from a third-party OpenID provider.
  5. In the case where users supply and verify their own OpenID, Emailtoid will create a 302 HTTP redirect removing Emailtoid from future interactions completely.

Should an email provider supply a discovery document after an Emailtoid mapping has been made, the new mapping will take precedence.

Opportunities and issues

The drive behind Emailtoid, again, is to reduce the friction of OpenID by reusing familiar identifiers (i.e. email addresses). Clearly the challenges of achieving OpenID adoption are not simply technological, and to a great degree rely on how the user experience needs to become more streamlined and deliver on the promise of greater security and convenience.

Therefore, if a service advertises that they support signing in with an email address, they must keep that promise.

Unfortunately, until all email providers do some kind of local resolution and OpenID authentication, we will need a centralized mapper such as Emailtoid to provide the fallback mapping. And therein lies the rub, defeating some of the distributed design of OpenID.

If anything, Emailtoid is intended to drive forward a conversation about the experience of OpenID, and about how we can make the protocol compatible with, or complementary to, existing and well-known means of identifying oneself on the web. Is it a final solution? Probably not — but it’s up, it’s running, it works and it forces us now to look critically at the question of emails as OpenIDs, now that we can actually experience the flow, and the feeling, of entering an email address into an OpenID box without ever having to enter, or create, another unnecessary password.

It’s high time we moved to URL-based identifiers

Ugh, I had promised not to read TechMeme anymore, and I’ve actually kept to my promise since then… until today. And as soon as I finish this post, I’m back on the wagon, but for now, it’s useful to point to the ongoing Scoble debacle for context and for backstory.

In a nutshell, Robert Scoble has friends on Facebook. These friends all have contact information and for whatever reason, he wants to dump that data into Outlook, his address book of choice. The problem is that Facebook makes it nearly impossible to do this in an automated fashion because, as a technical barrier, email addresses are provided as opaque images, not as easily-parseable text. So Scoble worked with the heretofore “trustworthy” Plaxo crew (way to blow it guys! Joseph, how could you?!) to write a scraper that would OCR the email addresses out of the images and dump them into his address book. Well, this got him banned from the service.

The controversy seems to over whether Scoble had the right to extract his friends’ email addresses from Facebook. Compounding the matter is the fact that these email addresses were not ones that Robert had contributed himself to Facebook, but that his contacts had provided. Allen Stern summed up the issue pretty well: My Social Network Data Is Not Yours To Steal or Borrow. And as Dare pointed out, Scoble was wrong, Facebook was right.

Okay, that’s all well and fine.

You’ll note that this is the same fundamental design flaw of FOAF, the RDF format for storing contact information that preceded the purposely distinct microformats and :

The bigger issue impeding Plaxo’s public support of FOAF (and presumably the main issue that similar services are also mulling) is privacy: FOAF files make all information public and accessible by all, including the contents of the user’s address book (via foaf:knows).

Now, the concern today and the concern back in 2004 was the exposure of identifiers (email addresses) that can also be used to contact someone! By conflating contact information with unique identifiers, service providers got themselves in the untenable situation of not being able to share the list of identifiers externally or publicly without also revealing a mechanism that could be easily abused or spammed.

I won’t go into the benefits of using email for identifiers, because they do exist, but I do want to put forth a proposal that’s both long time in coming and long overdue, and frankly Kevin Marks and Scott Kveton have said it just as well as I could: URLs are people too. Kevin writes:

The underlying thing that is wrong with an email address is that its affordance is backwards — it enables people who have it to send things to you, but there’s no reliable way to know that a message is from you. Conversely, URLs have the opposite default affordance — people can go look at them and see what you have said about yourself, and computers can go and visit them and discover other ways to interact with what you have published, or ask you permission for more.

This is clearly the design advantage of OpenID. And it’s also clearly the direction that we need to go in for developing out distributed social networking applications. It’s also why OAuth is important to the mix, so that when you arrive at a public URL identifier-slash-OpenID, you can ask for access to certain things (like sending the person a message), and the owner of that identifier can decide whether to grant you that privilege or not. It no longer matters if the Scobles of the world leak my URL-based identifiers: they’re useless without the specific permissions that I grant on a per instance basis.

As well, I can give services permission to share the URL-based identifiers of my friends (on a per-instance basis) without the threat of betraying their confidence since their public URLs don’t reveal their sensitive contact information (unless they choose to publish it themselves or provide access to it). This allows me the dual benefit of being able to show up at any random web service and find my friends while not sharing information they haven’t given me permission to pass on to untrusted third parties.

So screen scrape factoryjoe.com all you want. I even have a starter hcard waiting for you, with all the contact information I care to publicly expose. Anything more than that? Well, you’re going to have to ask more politely to get it. You’ve got my URL, now, tell me, what else do you really need?

My OpenID Shitlist, Hitlist and Wishlist for 2008

OpenID hitlist

Update: I’ve posted an update to these lists, giving props to Yahoo, Google, PBWiki and Drupal for embracing OpenID.

I believe in the power of community to drive change, and I believe that peer pressure can be a great motivator. I also believe that shaming can be an equally powerful motivator, if used lovingly and when an “out” is provided.

In this case, that “out” is adding support for consuming OpenIDs, not just being an identity provider.

With that in mind, I thought I’d throw out my OpenID Shitlist, Hitlist and Wishlist with the hope that a little sunlight might cause the previously planted seeds to finally sprout. Since OpenID 2.0 is now out, these folks really have very little excuse not to get on board and make this happen (limited developer resources notwithstanding).

So, without further ado:

My Shitlist

Last February, at the Future of Web Apps in London, there was an orgy of OpenID announcements.

The point of my Shitlist is to publicly shame folks who have previously promised (or strongly indicated an intent) to adopt and add support for OpenID but who have failed, thus far, to do so. I invite them to redeem themselves by making good on their promises. I won’t hold it against them, but hey, it’s their word on the line.

  • Digg.com. I’d consider myself personal friends with the Digg folks. I like Daniel, Kevin and Owen. I think they do great work and that Digg is one of the most influential synaptic centers of the net. But Digg tops my shitlist because of a very important 10 seconds of speech that Kevin offered on stage, and which was covered by Om and TechCrunch. He said, and I quote: And then we also want to announce today, uh, support for OpenID. So we will be, uh, rolling out OpenID here in the next few months. That’s gunna be cool. Listen to it yourself. Did this ever happen? Nu uh. Still waiting. Hmmph!
  • NetVibes. NetVibes remains one of the more innovative, more “open source like” rich internet desktops out there. Tariq‘s a friend. But, like Digg, when you make promises (scroll down to Tariq Krim) to do something and months and months later you haven’t made good on your word, well, you end up in my shitlist.
  • Last.fm. Now, I’m going out on a limb here. I have a strong recollection that Last.fm was the third company to promise OpenID support at FOWA, but for the life of me, I can hardly find a reference (besides this: “So what was the buzz at this years FOWA London? Two things resonated to me more than anything in the conference. OpenID and attention data. All of the key players from digg to Netvibes, Last.FM to Arrington touched on, commented or made announcements in these arenas.” — hat tip to JP), and in the recording of their session, they make nary a mention. Now, I’m pretty sure they said something about it, but I don’t have proof. Last.fm needs OpenID regardless, so if someone can backup or discredit my memory, I’m happy to move them to a more appropriate list.
  • PBWiki. I’m a fan of PBWiki, the hosted wiki service. They’re a good friend to the BarCamp and Twitter communities and are my first choice when I need a wiki and don’t want the hassle of setting up and maintaining my own. The oldest email I could find when I first approached David, Nathan and Ramit with a request to support OpenID was July 30, 2006. I’ve badgered them consistently since then, receiving various assurances that they’d work on it. And without directly calling bullshit, I do wonder why their own Auth API hasn’t been made to be OpenID compliant when there have been so many other significant improvements made. I know that nerds aren’t their top priority (nor their biggest money-makers by a long shot) but maybe we can hack it in at the next SHDH?
  • MyBlogLog. I suppose things change when you get absorbed by a massive corporation that requires a consistent terms of service. Or else it seems plausible that the early indications of support for OpenID might have blossomed into full fledged support. Alas, it was not to be.
  • Technorati. In October of 2006, Technorati announced support for blog claiming with OpenID. They also became an OpenID provider. So technically, they don’t deserve a full shaming. However, it’s lame that they allow you to claim your blog if it’s an OpenID, but for reasons that confound me, don’t let you actually sign in to Technorati using the same OpenID. This seems ludicrous to me and frankly, I expect more from Technorati. (And can I point out that it’s a bad sign that when I search your blog for OpenID using your search engine, nothing comes up? Huzzah!)
  • Wikipedia. Well, everyone loves Wikipedia right (that’s an uncorroborated generalization)? Well, they still belong on my shitlist. Wikipedia said they’d support it in a Google Video as early as June of 2006. They might be able to define the protocol, but they certainly don’t support it. (Reprieve: open source to the rescue! Evan Prodromou wrote the OpenID extension for Mediawiki. Now Wikipedia simply needs to adopt it!)

Hitlist

With the shitlist out of the way, I can get on to those folks who haven’t necessary made promises before, but are ripe candidates to be lobbied to add support for OpenID.

  • Satisfaction. Satisfaction has long since planned on offering OpenID (and more recently OAuth) and they tell me that it’s coming soon. With co-founders (and my friends!) Thor and Amy recently getting into a new startup they’ve named Tesla Jane, I think I can be patient for a while longer. 😉
  • Twitter. If you’re aware of the backstory of OAuth, you’ll know that it was my advocacy of OpenID for Twitter that revealed the need for a delegated authentication protocol that was compatible with OpenID. And, now that OAuth has gone 1.0 (and while we’re waiting for Twitter to roll out support for the final spec) it’d be great to also see movement on the OpenID front. I know you’ll get right on that. Heh.
  • Drupal. Bonus points go to Drupal and James Walker for rolling in support for OpenID into core for Drupal 6.0, and maybe we have to wait for the upgrade, but it’s too bad that there isn’t support on the drupal.org website. Should be an easy fix, and with the brilliant way the community devoured my recent feedback, I hope that this request is met with equal enthusiasm!
  • Plazes. Well, I’m with Tara and am pretty disappointed with where Plazes is today. Felix and Stefan are great, but the new Plazer sucks. It’s like they took a bunch of VC and lost focus. Then again, maybe I’m projecting. Anyway, it’d mean something to me if they went ahead and added support for OpenID. Better late than never.
  • Pownce. Pownce has been rocking the portable social network stuff, along with sister-site Digg (yes, the same Digg on my shitlist). The logical next step is for them to provide OpenID consumption to make the circle of portability complete!
  • Ning. Well, they already have NingID, but I really question the wisdom of proprietary authentication schemes at this point. I mean, if they’re all about niche-social-networks, wouldn’t consuming OpenIDs make so much sense to further reduce barriers to outsides coming in to play?
  • LinkedIN. These guys have been doing some great work widely adopting microformats and becoming more social-network-like. People seem to use LinkedIN as an identity aggregation point; shouldn’t they also be able to prove that they own a certain LinkedIN profile elsewhere and then verify their accounts elsewhere by logging in to LinkedIN with their other OpenIDs?
  • Slideshare. Given that Slideshare probably has the greatest collection of OpenID related presentations on the net, it’s kind of a shame that you can’t login to the site using the protocol. I know Rashmi and Jon have their hands full, but it’d be sweet to see them add support.
  • TripIt. TripIt’s awesome. Tara and I did a day of consulting with them and have been constant users ever since. What’d be great is if you could use your OpenID to login between Dopplr and TripIt — it might sound insane to them — but they really are complementary services. Tying my identity between them would save me such a hassle of having to go back and forth between them — and they’d both win!
  • Blip, Viddler, YouTube et al. This might be a pipe dream, but I do think that we could win over Blip and Viddler. YouTube, not so much. But if we lobbied each independent and got one to go, the others might follow…
  • WordPress.com. So WordPress is a funny one. They serve as an OpenID provider but don’t currently consume. If you want to enable OpenID consumption, you have to run your own blog (as I do) and use Will Norris‘ excellent plugin. This isn’t necessarily a problem, but with Drupal 6.0 getting support and Blogger offering limited consumption of OpenIDs, I would have hoped that WordPress would have made the move first.
  • Pandora. Finally, and this one might just be a vanity request, but I think it’d be cool if Pandora supported OpenID, if only because it would make OpenID seem cooler.

Wishlist

So, with the more likely candidates out of the way, I’d like to turn my attention to what would be big wins for OpenID, but that are an order of magnitude harder to win over, not so much because of technology issues but because of the complexities of terms of service and other business-level issues. In any case, if we see support from these folks for OpenID in 2008, we know we’re making serious ground.

  • Facebook. I asked the question on Twitter whether people would use Facebook as their OpenID provider if they could. The overwhelming response was no. Still, of anyone, Facebook could, if they actually rebuilt people’s trust and extended the reach of their strong privacy controls with best practice OpenID support, I think it’d be a net positive thing to see Facebook official adopt OpenID. There are already two Facebook apps that enable it, so clearly someone’s interested!
  • Yahoo and its various properties: Flickr, Delicious, Upcoming. I know they’re interested, but it will take more than interest and developer intentions to make this one happen. If Yahoo gets on board, game over man, cat’s in the bag.
  • Google. With their enthusiasm for OAuth and the recognition of the problem of widespread password scraping, I think Google is realizing that their avoidance of OpenID is not paying off. With Blogger toying with support for OpenID, I think (hope!) that’s it’s only a matter of time.
  • Microsoft. Well, Bill already promised. And they’ve even shipped code, even if it’s kind of a weird approach. Like most brushes with the embrace of openness, Microsoft is probably at war with itself once again, on the one hand having elements within that want to do the right thing and on the other, for some reason, being heavily influence by holdouts from the evil empire. We’ll see what comes of this, but I’m not holding my breath, even if InfoCard is the right interface metaphor for OpenID.
  • Mozilla. I don’t know if you noticed, but Mozilla has quite a few properties strewn about. Practically every week there’s a new property launched to promote some new campaign, not to mention all the myriad community sites that crop up (i.e. UserStyles.org, thankfully an OpenID consumer!). In leiu of a top-down single sign-on solution, why not just support OpenID and get it over with and enable portable reputation within the Mozilla universe? And — once you do that — maybe start looking at integrating support into Firefox, as I asked earlier this year?
  • Trac/SVN. With OAuth, support for OpenID on the command line becomes much more feasible, even if there’s little support today. Imagine being able to use your OpenID credentials to login to any SVN repository. Being able to federate whitelists of identifiers would make cross-collaboration much more facile and I think would be a boon to independent open source development.
  • MySpace, Hi-5, Bebo, Orkut et al. I mean, we now know that is basically an overhyped widget distribution platform, but that doesn’t mean that it won’t turn into something more. Eventually the limits of siloed identities are going to run up against the cross-pollinating design of OpenSocial and logging in to Bebo with your MySpace account is not only going to make sense, but will be expected, just like I can send email from my Gmail account to Hotmail and Yahoo email users. OpenID 2.0, with directed identity, is perfectly suited to handle this particular use case and I’d love to see the early OpenSocial partners get on board sooner than later.
  • Adobe. Not even sure why this one’s in the list, but so long as I’m thinking big, it’d be sweet to see support not only on Adobe’s site for OpenID, but also in Flash apps (which I think would possibly require OAuth). Adobe has Adobe IDs already, and, as I suggested before, proprietary protocols for identity on the web make less and less sense.
  • TechCrunch. This one’s for fun. I know Mike’s a fan of big ideas and making things better, so it seems strange that, given his use of WordPress, he hasn’t demanded support for OpenID commenting yet. Perhaps we can dream.

Now that I’ve got those lists out of the way, I wanted to give summary props to folks who have already gone ahead and implemented OpenID (this is not an exhaustive list; check out the OpenID Directory for more):

Make sure to stop by these folks’ sites and try out their support for OpenID. Heck, they’ve pioneered the way forward, might as well both give them some patronage and see what user experience lessons can be had from their implementations.

And, this is by no means a finished list. It’s just a start. If you’ve got your own Shitlist, Hotlist and Wishlists, please do share them. Not only have I probably missed some folks (Amazon anyone?), but there are probably services and sites more dear to your hearts that should be embracing citizen-centric web protocols that I don’t even know about yet.

So, let me know what you think and if you want to start doing some lobbying, the best place to start is with the OpenID site itself.

Data portability and thinking ahead to 2008

So-called data portability and data ownership is a hot topic of late, and with good reason: with all the talk of the opening of social networking sites and the loss of presumed privacy, there’s been a commensurate acknowledgment that the value is not in the portability of widgets (via OpenSocial et al) but instead, (as Tim O’Reilly eloquently put it) it’s the data, stupid!

Now, Doc’s call for action is well timed, as we near the close of 2007 and set our sights on 2008.

Earlier this year, ZDNet predicted that 2007 would be the year of OpenID, and for all intents and purposes, it has been, if only in that it put the concept of non-siloed user accounts on the map. We have a long way to go, to be sure, but with OpenID 2.0 around the corner, it’s only a matter of time before building user prisons goes out of fashion and building OpenID-based citizen-centric services becomes the norm.

Inspired by the fact that even Mitchell Baker of Mozilla is talking about Firefox’s role in the issue of data ownership (In 2008 … We find new ways to give people greater control over their online lives — access to data, control of data…), this is going to be issue that most defines 2008 — or at least the early part of the year. And frankly, we’re already off to a good start. So here are the things that I think fit into this picture and what needs to happen to push progress on this central issue:

  • Economic incentives and VRM: Doc is right to phrase the debate in terms of VRM. When it comes down to it, nothing’s going to change unless 1) customers refuse to play along anymore and demand change and 2) there’s increased economic benefit to companies that give back control to their customers versus those companies that continue to either restrict or abuse/sell out their customers’ data. Currently, this is a consumer rights battle, but since it’s being fought largely in Silicon Valley where the issues are understood technically while valuations are tied to the attractiveness a platform has to advertisers, consumers are at a great disadvantage since they can’t make a compelling economic case. And given that the government and most bureaucracy is fulled up with stakeholders who are hungry for more and more accurate and technologically-distilled demographic data, it’s unlikely that we could force the issue through the legal system, as has been approximated in places like Germany and the UK.
  • Reframing of privacy and access permissions: I’ve harped on this for awhile, but historic notions of privacy have been out-moded by modern realities. Those who do expect complete and utter control need to take a look at the up and coming generation and realize that, while it’s true that they, on a whole, don’t appreciate the value and sacredness of their privacy, and that they’re certainly more willing to exchange it for access to services or to simply dispense with it altogether and face the consequences later (eavesdroppers be damned!), their apathy indicates the uphill struggle we face in credibly making our case.

    Times have changed. Privacy and our notions of it must adapt too. And that starts by developing the language to discuss these matters in a way that’s obvious and salient to those who are concerned about these issues. Simply demanding the protection of one’s privacy is now a hollow and unrealistic demand; now we should be talking about access, about permissions, about provenance, about review and about federation and delegation. It’s not until we deepen our understanding of the facets of identity, and of personal data and of personal profiles, tastestreams and newsfeeds that can begin to make headway on exploring the economic aspects of customer data and who should control it, have access to it,

  • Data portability and open/non-proprietary web standards and protocols: Since this is an area I’ve been involved in and am passionate about, I have some specific thoughts on this. For one thing, the technologies that I obsess over have data portability at their center: OpenID for identification and “hanging” data, microformats for marking it up, and OAuth for provisioning controlled access to said data… The development, adoption and implementation of this breed of technologies is paramount to demonstrating both the potential and need for a re-orientation of the way web services are built and deployed today. Without the deployment of these technologies and their cousins, we risk web-wide lock-in to vender-specific solutions like Facebook’s FBML or Google’s , greatly inhibiting the potential for market growth and innovation. And it’s not so much that these technologies are necessarily bad in and of themselves, but that they represent a grave shift away from the slower but less commercially-driven development of open and public-domained web standards. Consider me the frog in the luke warm water recognizing that things are starting to get warm in here.
  • Citizen-centric web services: The result of progress in these three topics is what I’m calling the “citizen-centric web”, where a citizen is anyone who inhabits the web, in some form or another. Citizen-centric web services, are, of course, services provided to those inhabitants. This notion is what I think is, and should, going to drive much of thinking in 2008 about how to build better citizen-centric web services, where individuals identify themselves to services, rather than recreating themselves and their so-called social-graph; where they can push and pull their data at their whim and fancy, and where such data is essentially “leased” out to various service providers on an as-needed basis, rather than on a once-and-for-all status using OAuth tokens and proxied delegation to trusted data providers; where citizens control not only who can contact them, but are able to express, in portable terms, a list of people or companies who cannot contact them or pitch ads to them, anywhere; where citizens are able to audit a comprehensive list of profile and behavior data that any company has on file about them and to be able to correct, edit or revoke that data; where “permission” has a universal, citizen-positive definition; where companies have to agree to a Creative Commons-style Terms of Access and Stewardship before being able to even look at a customer’s personal data; and that, perhaps most import to making all this happen, sound business models are developed that actually work with this new orientation, rather than in spite of it.

So, in grandiose terms I suppose, these are the issues that I’m pondering as 2008 approaches and as I ready myself for the challenges and battles that lie ahead. I think we’re making considerable progress on the technology side of things, though there’s always more to do. I think we need to make more progress on the language, economic, business and framing fronts, though. But, we’re making progress, and thankfully we’re having these conversations now and developing real solutions that will result in a more citizen-centric reality in the not too distant future.

If you’re interested in discussing these topics in depth, make it to the Internet Identity Workshop next week, where these topics are going to be front and center in what should be a pretty excellent meeting of the minds on these and related topics.