Welcoming Facebook to the OpenID Foundation

Facebook logoThe day after Facebook’s 5th birthday, I join David Recordon and the rest of the board of the OpenID Foundation in welcoming Facebook as our newest member, in rapid succession to Paypal just a few weeks ago. The significance of both of these companies investing in and becoming part of the OpenID family can not be understated.

I’m particularly excited that Facebook has joined after the conversation that Dave Morin and I had last Friday during our Jelly Talk. Dave and I were in vehement agreement about a lot of things, and tantamount was the need for the user experience of OpenID authentication to improve.

The crux of the issue is that with OpenID, choice is baked in, which is a good thing for the marketplace and ultimately a good thing for users. The problem is how this choice manifests itself in interfaces.

Facebook Connect is simple because there is no choice: you click a button. Of course, that button only works for the growing subset of the web who have Facebook accounts and want to share their Facebook identity with the web site displaying the button, but that’s why their experience trumps that of OpenID’s. If you take away user choice, everything becomes simple.

But I believe that we can do better than that, and that we can arrive at a satisfying user experience for OpenID that doesn’t necessarily have to dispense with choice. And from the sound of our conversation on Friday, and with Facebook’s membership in the OpenID Foundation, I believe that we now have a mandate to confront this challenge head-on, as a top priority.

To that end, Facebook will be hosting the second User Experience Summit for OpenID on February 10th. The goal is to convene some of the best designers that leading internet companies can muster, and bring them together to develop a series of guidelines, best practices, iterations, and interfaces for making OpenID not just suck less, but become a great experience (in same vein as the hybrid OpenID/OAuth flow that we saw from Plaxo and Google last week, and in line with Luke Shepard’s proposals for an OpenID popup).

Although Facebook has not announced any plans for implementing OpenID specificly, their commitment to help improve the user experience suggests to me that it’s only a matter of time before all of the major social networks, in some way, support OpenID. If there were any lingering doubts about the competition between Facebook Connect and OpenID, hopefully the outcome of a successful collaboration will put them to rest.

Inaugural Jelly! Talk this Friday: OpenID vs Facebook Connect

Jelly TalksThis Friday, I’ll be joined by Dave Morin (my good friend from Facebook) at the first ever Jelly! Talk at Joe and Brian’s loft in San Francisco.

If you’re not familiar with Jelly, you should be. I call it the “gateway drug to coworking” — but it really has its own culture and identity independent of coworking, though both movements are rather complementary. Amit Gupta got Jelly started at House 2.0 in New York City back in 2006 (about two months after I initially expressed my desire to create a coworking space in San Francisco). Since then, like coworking, it’s grown into a self-sustaining movement.

Jelly! Talks is an interesting expansion on the concept — where Jellies distributed throughout the world can tune in to hear interesting and relevant talks and interact with speakers, similar to what the 37 Signals guys do with their “Live” show.

This first show I’ll be talking with Dave Morin about the relationship between OpenID and Facebook Connect — and where the two technologies are headed. This should be a pretty interesting conversation, since I’ve long tried to convince the folks at Facebook to adopt OpenID and other elements of the Open Stack (hey, they’ve got hcard already!).

Apparently the event is physically booked up, but you’ll still be to tune in remotely this Friday at 11am PST.

(Tip: The next Jelly! Talk will feature Guy Kawasaki).

What PayPal’s member in the OpenID Foundation could mean

PayPal logoBrian Kissel announced this morning that PayPal has joined the board of the OpenID Foundation as our sixth corporate member, with Andrew Nash, Sr., Director of Information Risk Management and a longstanding advocate for OpenID, as their representative.

That PayPal has joined is certainly good news, and helps to diversify the types of companies sitting on the OpenID Foundation board (PayPal joins Google, IBM, Microsoft, VeriSign and Yahoo!). It also provides a useful opportunity to think about how OpenID could be useful (if not essential) for financial transactions on the web.

For one thing, PayPal already relies on email addresses for identification, and one of the things that I’m strongly advocating for in OpenID 2.1 is the use of email-style identifiers in OpenID flows.

Given that PayPal already assumes that you are your email address, things become more interesting when a company like PayPal starts to assume that you are your OpenID (regardless of the format). With discovery, your OpenID could be useful not just as an indicator of your data resources across the web (essential in cloud computing), but could also be useful for pointing to your financial resources. Compare these two XRDS-Simple entries (the latter is fictional):

<!-- Portable Contacts Delegation -->

    http://portablecontacts.net/spec/1.0
    http://pulse.plaxo.com/pulse/pdata/contacts


<!-- Payment Gateway Delegation -->

    http://portablepayments.net/spec/1.0
    http://paypal.com/payment/

From this simple addition to your discovery profile, third parties would be able to request authorization to payment, without necessarily having to ask you every time who your provider is. And of course no payment would be disbursed without your explicit authorization, but the point is — sellers would be able to offer a much more seamless payment experience by supporting OpenID and discovery.

The pieces are more or less in place here, and with PayPal on board, I think that we’re starting to see how OpenID can be used to smooth the on-boarding process for any number of routine tasks — from specifying where you store your photos to pointing to the service(s) that you use for payment.

I commonly use the metaphor of credit cards for OpenID. One thing that makes credit cards convenient is that the 16-digit unique ID on each card is embedded in the magnetic strip, meaning that it’s trivial for consumers to just swipe their cards rather than typing in their account number. OpenID and discovery, combined, provides a similar kind of experience for the web. I think we need to keep this in mind as we move the state of the art forward, and think about what can be accomplished once people not only have durable identity on the web — but can use those identifiers to access other forms of real-world value (and can secure them however they see fit).

TheSocialWeb.tv #25: “An ‘Open’ Letter to the Obama Administration”

http://www.viddler.com/player/95214990/

Last Friday, Joseph, John and I recorded episode #25 of TheSocialWeb.tv.

Besides shout outs to 97bottles.com and Janrain for their stats on third-party account login usage, we discussed how the Obama administration might better make use of or leverage elements of the Open Stack — specifically OpenID.

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.

Farewell W, aloha Obama! (or, Announcing PublicSentiment.net!)

Public SentimentOn the eve of President Obama’s inauguration, I’m happy to announce a new side project that Brynn, Michael, and I have been working on for the past three weeks called Public Sentiment.

At its base, it’s simply a site for polling opinions, designed to capture what people are thinking about a certain topic at a given time. The concept actually arose out of an informal study that Brynn and I did last November immediately after the election. At the time, the media portrayed a rather unidimensional view of public opinion — very black and white with little nuance (or should I say, red and blue?). We decided to take matters into our own hands and commissioned a study on Mechanical Turk to get long-form responses about what people thought about the outcome of the election — making sure to document who, if anyone, they voted for.

The results were illuminating and much more textured than one might expect. So we decided that we’d take a similar approach as President Bush left office and President-elect Obama was sworn in.

While we were in Hawaii over the holidays, we actually started working on the project and came up with the Aloha Obama and Farewell W names and figured that it would be interesting to build a site around this content… to really get a sense for what people think — right now — and to provide a public record of those sentiments (hence “Public Sentiment”).

There are two ways to contribute content: in short form, via Twitter or using our site’s Twitter-like posting feature, or our “extended letter” format (since not everyone can say everything that they care to in 140 characters or less). You can create either an aloha, a farewell or both. To post by Twitter, simply post a message to @barackobama and use the hashtag #aloha (or use “aloha” in the text of your message) or send a message to @georgewbush and use the hashtag #farewell (or just include the word “farewell” in your Tweet).

Here are two live examples (the first from Twitter, the latter, Mechanical Turk):

@barackobama I'm so happy with ... - Public Sentiment

Thank you for preventing a ... - Public Sentiment

It’s also worth pointing out that we basically paid about three dollars to populate the first hundred posts from Mechanical Turk users — basically to prime the pump and make sure that we had some good data to start with. Since people were paid $0.02 to complete this particular survey, we figured that it would model the behavior we were looking for from folks on the open web, thereby decreasing any incidence of incendiary behavior. I mean, I’m sure there are lots of emotions that people are feeling out there, but the hope was to catch some of the more subtle feelings — not just the vitriolic.

So there you have it!

We’d love feedback, thoughts or ideas. This will also be just our first survey of the sort. I imagine as Obama starts to execute on his promises, we’ll do follow up surveys to see what people have to actually say about the things going on in the news.

As an aside, it was also my first Django project, and I have to acknowledge that I was spoiled by all the help that Michael Richardson provided here (mostly late night sessions of me asking questions and then patching my bugs). I actually designed the whole site in Keynote first and then built a prototype locally in PHP. Michael then recreated it in Python and Django and had me work on the theme layer. Turned out to be a lot of fun — and a good learning experience!

Lastly, props to David Lanham for letting use his awesome icons. You’ll see them throughout the site.

Perception and reality in the land of OpenID

OpenID LogoA couple related posts caught my attention recently about OpenID. As I’m now a board member of the OpenID Foundation, I feel some responsibility for helping to inform folks about OpenID: what it is, how it’s used, why I believe that it has so much potential — and at same time, address what it isn’t, won’t or can’t be, and what the scope of the OpenID solution stack is.

The first is a post by Nick O’Neill from the Social Times blog: “OpenID Organizes the Organizers While Facebook and Google Start Letting Users Login“. It was posted on December 29th.

He begins his criticism with a slight error:

Over the weekend the OpenID Foundation announced that they are having its first election of community board members.

In fact, over that particular weekend, the OIDF announced the results of its election, not the kick off.

But his broader sentiment deserves a response:

[…while] Facebook and Google have launched their own identity services that enable users to instantly log in to any site with third-party accounts[, … the] group seems to still be in the process of organizing though. … I think the group is over planning and under executing.

Josh Catone from SitePoint picked up his point, suggesting that “OpenID Needs to Start Getting Real“. He writes:

What the OpenID Foundation needs to do is start “getting real.” Getting real is a business philosophy from 37signals, a successful web application software company based in Chicago. Though there’s a lot more to their idea, one of the main themes essentially boils down to this: stop screwing around with all the stuff that doesn’t matter and just wastes time (like politics and meetings), and start doing the stuff that needs to get done (like building your app). Don’t worry about the details until people are already using what you’re selling.

I agree with O’Neill that so far the OpenID Foundation seems to be spending too much time on organizational stuff, and not enough time on actually doing what needs to get done. In a chapter of their book “Getting Real,” 37signals talks about how meetings can kill productivity. “Every minute you avoid spending in a meeting is a minute you can get real work done instead,” they write. From my admittedly outsider’s vantage point, it appears that the people behind OpenID are getting too caught up in the organizational stuff, getting too lost in the details, and not spending enough time on execution.

My perspective, of course, is that of an outsider. I’m not privy to what’s going on behind closed doors, so to speak. So my perception of what’s really going on could be off. But at this point in the game, public perception is what it’s all about.

And therein lies the heart of the problem. Perception is reality in the land of OpenID and will shape the thinking of developers, users and those who make up the OpenID and user-centered identity communities unless we initiate a campaign to earnestly counter those perceptions.

Nevermind that for OpenID to succeed, it must be developed with the involvement of many different groups, each with slightly different ideas, objectives and release cycles. Unlike Facebook Connect, OpenID is essentially consensus technology. To advance, it must secure and maintain the buy-in and adoption of many parties on every forward step. But let’s ignore that for a moment, because that’s an issue for us to overcome.

Jim Louderback (veteran of PC Mag) recounted his miserable experience trying to sign in to Disqus with his OpenID in a post titled “I can haz OpenID?“. Apparently, he can not, since he abandoned his comment and resorted to posting it to Twitter instead. The problem apparently had to do with Clickpass, but that’s besides the point, as the experience left a serious impression (emphasis mine):

And that gets me back to OpenID. I love the idea of having one set of identification credentials that I can use around the web. If it all works right, it’ll be awesome, birds will sing and the swallows will return to wherever they’ve disappeared from. But it won’t all work right, not all the time. We’re talking software here, and the internet, and the egos of childish web developers. Occasional (or more often) fail is guaranteed.

It’s even worse than I feared. A few days after my Disqus debacle I was talking with a developer friend of mine who was bemoaning the sorry state of OpenID implementations. It seems that all the big sites have their own flavors, and the OpenID foundation just doesn’t have enough clout to force a single standard across the web.

That’s a bad state of affairs. It guarantees more fail – and also guarantees epic finger-pointing. Who will lose? The users, first, who won’t be nearly as patient nor accommodating as I am. But in the end the whole glorious promise of OpenID will be left in tatters, and we’ll be back to our walled-gardens of identification. And that’s just too bad – because an open, interoperable identity system is actually one of the best ideas I’ve heard in a long time. Too bad no one can get their act together to actually build it right.

And these are the stories that will be told and retold because it’s not the successes that are heralded — it’s the epic failures. As much as I like to rag on Twitter about OAuth, their service is a million times better than it was six months ago during the Summer of the Fail. Twitter ops deserve a lot of credit for making hard decisions about which features should be cut in order to scale the service.

But when it works, people don’t shower Twitter with praise. It’s expected. It’s only when there are problems that people raise their voices — and it’s no different with OpenID. Unfortunately it’s this cacophony of complaints that ends up shaping the negative perceptions of OpenID.

So, when the Japanese chapter of the OpenID Foundation releases figures that show significant and gaining consumer awareness of OpenID in Japan that contradict the outdated and statistically insignificant findings (PDF) that Yahoo presented last year (on which so much criticism was heaped), few seem to notice.

openid-usage

Progress in Japan alone isn’t enough of course. But it does suggest that there is more to the story of OpenID’s overall progress and success in the marketplace. It also suggests that OpenID has yet to succumb to Facebook Connect or that it ever will (or that that’s even the right question).

Still, what all this says to me is that the OpenID Foundation and the community at large have its work cut out for itself.

As more people begin to believe in the promise of OpenID, more people will commit themselves to the success of OpenID, taking ownership of the idea, and promoting it their friends and family (as they did with Firefox). Our opportunity is to make good on the hope that people have for OpenID and effectively channel it to challenge the bruised perception that defines OpenID today. If we succeed, changing perceptions truly will change reality.

Twitter and the Password Anti-Pattern

Twitter / Alex Payne: @factoryjoe Yes, OAuth is ...

I’ve written about the password anti-pattern before, and have, with regards to Twitter, advocated for the adoption of some form of delegated authentication solution for some while.

It’s not as if Twitter or lead developer Alex Payne aren’t aware of the need for such a solution (in fact, it’s not only been publicly recognized (and is Issue #2 in their API issue queue), but the solution will be available as part of a “beta” program shortly). The problem is that it’s taken so long for Twitter’s “password anti-pattern” problem to get the proper attention that it deserves (Twitter acknowledged that they were moving to OAuth last August) that unsuspecting Twitter users have now exposed themselves (i.e. Twitter credentials) to the kind of threat we knew was there all along.

This isn’t the first time either, and it probably won’t be the last, at least until Twitter changes the way third party services access user accounts.

Rather than focus on Twply (which others have done, and whose evidence still lingers), I thought I’d talk about why this is an important problem, what solutions are available, why Twitter hasn’t adopted them and then look at what should happen here.
Continue reading “Twitter and the Password Anti-Pattern”

The results of the OpenID Board election are in!

I'm kind of a big dealI received an SMS from Michael Richardson this morning (around 8am here in Hawaii) congratulating me on my election to the board of the OpenID Foundation. It seems fitting that I should receive first word from him, since, as the Karl Rove of my campaign, he came up with the “kind of a big deal” slogan from Anchorman.

Anyway, I’m thrilled about the outcome of the election and am looking forward to working with Snorri Giorgetti, Nat Sakimura, David Recordon, (each of whom received two year terms along with me) and Eric Sachs, Scott Kveton, and Brian Kissel (who received one year terms).

I’m also pleased that 80% of the 217 foundation members voted in the first-ever OpenID election. We’ve obviously got a lot of work ahead of us, but I’m very confident that we’ll make great strides in 2009.

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.