Ev's identity map ignores what we say

Ev Williams wrote a good blog post on identity yesterday, that I suggest you go and read. The odd thing is that he leaves out the publicly articulated thoughts that we use blogs, Twitter and other services to publish as an expression of our identity. Before I get to that, though, I'd like to connect his facets back to the open specs that represent these aspects.

Authentication

Ev mentions OpenID here, and is essentially correct that it is not helpful on its own. It was designed to verify URLs for blog comments. If all you do is use OpenID, you just replace logging into your site with logging into another, adding extra confusion without much benefit. However, once you have a URL for someone, you can then discover further information about them, by examining that URL and its links. Microformats can encode this directly in the webpage, or you can use related links to discover API endpoints for more.

The distinction between Authorization and Authentication is elided by Ev, and in practice OAuth has been winning out over OpenID as it is explicitly an Authorization APi that had Authentication as a side effect. The new OpenID Connect proposals try to remedy both these failing by using OAuth and by standardizing on how to list other endpoints.

Representation

Here Ev is looking for what is commonly called profile information. We have some mature standards for this - vCard is widely used by email clients, and is currently going through another standardization round to add modern features. The hCard microformat gives a simple way to embed profiles in web pages. Also, the rel="me" part of XFN makes it straightforward to link web pages together that represent different aspects fo your public representation. This is supported by Facebook, Twitter and Google, but sadly not by about.me whom Ev praises.

If you want a general data format for profile data, Portable Contacts is what you need.

Communication

Ev's emphasis on email addresses here illustrates the problem with them; they are primarily write-only; though we persist in using them for log-in IDs, they are not readily discoverable. The WebFinger spec gives a way round this - a way to go from an email to endpoints for other readable identity standards. Other communication standards have piggy-backed on email address, such as Jabber and Wave.

Personalization

This hints at the glaring gap in Ev's model, the expression of personal taste and preference. This is commonly done by reviewing, and we have the hReview microformat to express that, but it can also be useful just to track a history of media played or places visited to derive preferences over time. Here Activity Streams are an obvious fit, and it would be good to map such proprietary formats as Amazon purchases, Last.fm scrobbles, iTunes played songs and so on into a common format to derive this.

One model we can use for this is tagging - associating keywords with things. Many feed specs have tagging built in, and the rel="tag" microformat is a way of indicating these publicly.

Reputation

As Ev says, this is problematic, and also often highly contextual; I may trust someone's advice on restaurants without listening to them about which programming language to use. Reputation and trust are subtle, deeply human and very hard to model. The best answer here may be to rely on the power of faces and following; if we attach the face of someone we know to their public statements, we can decide for ourselves how much weight to give them.

Which brings me back to my opening point. When we decide who to pay attention to online, we tend to rely on what they say; if you get an @ reply on twitter, clicking on that person's name to see their most recent comments is hugely useful in deciding how much attention to pay to them. Similarly, the history of public blog posts, or their reviews of movies, music, books or restaurants arre other reasons we may follow them, and our identity is most strongly formed from the stories we tell and retell about ourselves. Feeds, whether in Atom, RSS or hAtom, and Activity Streams give rich representation of our thought, opinions and actions.

Whom we choose to associate with or follow is also an expression of our identity, and a useful signal when deciding how much attention to pay to someone, and XFN and Portable Contacts are both usefule in discovering these connections.

Dare Obasanjo also responded to Ev's Identity post, and added in payment as well as the friends as missed aspects. I'd love to discuss this further with both Ev and Dare at the Internet Identity Workshop next month, which is where many of the specs mentioned above were conceived and agreed. Maybe Ev can bring some others from Twitter with him too; their past contributions to OAuth were highly useful and there is plenty more to get our teeth into, as Ev's post shows.

Standards are the links of the Social Web

Mike Arrington wrote a plea for better social software on Sunday:

The online social landscape today sort of feels to me like search did in 1999. It’s a mess, but we don’t complain much about it because we don’t know there’s a better way.

Everything is decentralized, and no one is working to centralize stuff. I’ve got photos on Flickr, Posterous and Facebook (and even a few on MySpace), reviews on Yelp (but movie reviews on Flixster), location on Foursquare, Loopt and Gowalla, status updates on Facebook and Twitter, and videos on YouTube. Etc. I’ve got dozens of social graphs on dozens of sites, and trying to remember which friends puts his or her pictures on which site is a huge challenge.

What enabled Google to solve the search problem was a common standard for expressing pages and the links between them, so that they could index the webpages and derive a metric for which ones were more important. They didn't do this by replacing the web with a structured database that they curated, they worked with the standards in use to make sense of it.

To solve the social conundrum we need the equivalent - agreed standards in widespread use so that we can generalize across sites. Fortunately, we have these. We have OpenID and OAuth for delegated login; we have XFN, other microformats and Portable Contacts for public and private people connections; we have Feeds and Activity Streams for translating social actions between sites.

This enabling social infrastructure means that we'll be able to have a new generation of sites that enhance our web experience through social filtering without our connections being centralised in a single company's database.

Once we get used to the experience of being able to delegate login, personal connections and activity updates, we'll look askance at developers who insist we create yet another profile and invite all our friends by email to experience their site; it'll be like a website without links.

My twittered notes on the Leweb Social panel

Platform Love: Getting Along - Panel

Panelists:


• David Glazer - Director of Engineering, Google
  
• Jeff Hansen - General Manager, Services Strategy/Live Mesh, Microsoft Corporation
  
• Dave Morin -Senior Platform Manager, Facebook

  
• David Recordon - Open Platforms Tech Lead , SixApart
  
• Max Engel, Head of Data Availability Initiative, MySpace

Moderator: Marc Canter - CEO, Broadband Mechanics

Watching the 3 Davids, Max, Marc and Jeff talk social at LeWeb
says Marc Canter 'open is the new black' - and asks about the Open Stack
says @daveman692 google, yahoo, microsoft all building on the open stack - won't FaceBook become the underdog when openness wins?
Canter suggets OpenID will be the brand that ties the Open stack together
max of MySpace "what we're doing with these standards is moving the web forward - when the web hits a roadblock it routes round it"
max of MySpace:"90% of our users think of themselves as URLs so OpenID is a natural fit for us"
Dave Glazer: the goal is to let users do anything they want to, with others, anywhere on the web. OpenID lets you log in anywhere
Dave Glazer: openSocial solves a different bit of the puzzle - JS APIs to run the same app in different social contexts REST APIs web to web
says @daveman692 the web is designed to be distributed, and the Open Stack fits this model
Jeff of Microsoft: live mesh is built on symmetric sync - supports Open Stack, OpenID shipping, OAuth looks good, support PortableContacts
Jeff of Microsfot: we're evaluating the OpenSocial gadget container
Marc canter "we're putting all our balls into ev williams vice"
Jeff: we offer lots of languages. Marc: lots of ways to put our balls in your vice
Max: we support OpenID, Oauth, OpenSocial but you can too
Marc: anything good for the Open Web is good for Google
Marc Canter wants a URL for each Gmail? DG: each one does have that, but only you can see it
Dave Glazer: there are 3 classes of information: Public, Private and Complicated - users should never be surprised by who can see what
says @davemorin facebook wants people to have a social context wherever they go
says @davemorin FaceBook had to create a Dynamic Privacy model for FB Connect @daveman692 calls shenanigans - LJ had those in 1999
asks @daveman692 of @davemorin why are you giving microsoft access to all our email addresses wihtout asking permission?
Max of MySpace - we've shown that security and openness work together by using OAuth, and can revoke them from in MySpace
Dave Glazer: need to separate the technical levers from the social customs. technology can't stop people putting your bizcard on the web
says @techcrunch "call bullshit on facebook" - broke integration with google. FB don't want an open stack, they may be forced into it
says @tommorris how can MS be on the panel after the debacle of Office OOXML which wasn't open or XML?
says @dave500hats could we get contacts with certain features eg tennis fans?
Dave Glazer: there's an open spec process to define new attributes in the spec - if you want to add one go and propose it

Cycling to new layers of freedom

Dave Winer used the public beta of Google Friend Connect to reflect on tech industry cycles:

A new generation of young techies comes along, takes a look at the current stack, finds it too daunting (rightly so) and decides to start over from scratch. They find that they can make things happen that the previous generation couldn't cause they were so mired in the complexity of the systems they had built. The new systems become popular with "power users" -- people who yearn to overcome the limits of the previous generation. It's exhilirating! [...]
The trick in each cycle is to fight complexity, so the growth can keep going. But you can't keep it out, engineers like complexity, not just because it provides them job security, also because they really just like it. But once the stack gets too arcane, the next generation throws their hands up and says "We're not going to deal with that mess."

Now, I may be a few years behind Dave, but I think he is throwing the baby out with the bathwater, or the stack out with the cycle here. Back when I started out, to get my computer to generate sound, I had to make my own D to A converter to attach to the parallel port, and for non-character graphics, my hardware hacker friends swapped the character generator ROM for RAM, and I had to code in assembler to swap the display data in time.

Now my son thinks nothing of mixing 10 polyphonic Midi tracks in an afternoon or editing hi-def video (and yes, it's on an OS I helped to make capable of that).

Dave's revolutionary impulsiveness has a germ of truth, but what really happens is that successful technologies become invisible infrastructure for the next things that build on them.

I no longer need to write assembler, heck I no longer need to write C code. Dave's very URL - scripting.com - shows how we have built up layers of utility to work upon.

HTTP, HTML, JSON, Atom and Javascript are infrastructure now. Our deepest role as developers is to build the invisible infrastructure for the next generation to take for granted, so they imagine new abstractions atop that. Dave did it with feeds.

What we're doing with the Open Stack — OpenID, OAuth, PortableContacts and OpenSocial— is part of this evolutionary cycle too. We're combining building blocks into a simplified whole that makes sense to people who want their websites to become social.

It comes down to what you can take for granted as the baseline to build the next exciting cycle on.

OpenSocial’s birthday today

OpenSocial Reach chart
Originally uploaded by Kevin Marks

Just over a year ago, we launched OpenSocial to the web, with a few example applications and a lot of potential. Now, a year on, over 600 million social network users can use OpenSocial applications in their preferred social network sites.
Then, applications had to be embedded in sites as gadgets, which makes the social context clear for users, but means developers have to write some Javascript, and can only run code when the user is looking at the site.
With OpenSocial 0.8 rolling out, the REST APIs mean that developers can integrate with social sites using server-side code directly, potentially delegating user registration, profiles and friend relationships to an already-trusted social site, and feeding activity updates back into them.
To do this, we are building an Open Stack, based on OpenID, XRDS-Simple, OAuth, PortableContacts and OpenSocial. By composing open standards in this way, we can make each one more valuable. The advantages of OpenID over email login in itself are not that obvious to users, but if the OpenID can be used to bring in your profile and contacts data - with your permission via OAuth - suddenly the added value is clear to users and developers alike. This connection was one of the exciting discussions at the Internet Identity Workshop this week - here's a video of myself, Steve Gillmor, David Recordon and Cliff Gerrish talking about it.

Missing the point of OpenID

I'm puzzled by Dare's post on OpenID, as he is wilfully misunderstanding its advantages at each stage, and I know he's smarter than that. He gets it right that OpenID is a way to confirm that a user owns a URL, without the rigmarole required to do so for an email address. 

However, the then uses his unmemorable Facebook URL http://www.facebook.com/p/Dare_Obasanjo/500050028 as an example, rather than any of the memorable ones he actually uses and people refer to, such as http://www.25hoursaday.com/weblog/ or http://carnage4life.spaces.live.com/ or http://twitter.com/Carnage4Life

DeWitt Clinton did an excellent job of clearing up some of Dare's other innaccuracies, but he then rhetorically exaggerated thus:

URLs make fantastic identifiers — for the 0.1% of the web population that understands that they “are” a URL. Fortunately, the other 99.9% of the world (our parents, for example) already understand that they have an email address.

This is missing the huge population of the online world (our children, for example) who consider email a messy noisy way to talk to old people, or to sign up to services when forced to, but are happy using their MySpace or Bebo or Hi5 or LiveJournal or Blogger or Twitter URLs to refer to themselves.
As I said in URLs are People Too:

The underlying thing that is wrong with an email address is that it's 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.

Where I see OpenID providing a key advantage is in it's coupling with URL-based endpoints that provide more information and save the user time. The OpenID to PortableContacts connection as demonstrated by janrain can add your friends (with permission) from an OpenID login directly via OAuth.
This makes the OpenID login instantly more useful than an email one, and by connecting to an OpenSocial endpoint too, you can couple activities you take on the wider web with the site you trust to be a custodian of your profile and friends data, so your friends can discover what you are doing elsewhere, and come and join you.

I'm looking forward to talking through these issues at Internet Identity World next week in Mountain View.

An API is a bespoke suit, a standard is a t-shirt

Brad is calling for APIs, and even the NYT is proposing one, but there is a problem with APIs that goes beyond Dave's concern about availability.

When a site designs an API, what they usually do is take their internal data model and expose every nook and cranny in it in great detail. Obviously, this fits their view of the world, or they wouldn't have built it that way, so they want to share this with everyone. In one way this is like the form-fitting lycra that weekend cyclists are so enamoured of, but working with such APIs is like being a bespoke tailor - you have to measure them carefully, and cut your code exactly right to fit in with their shapes, and the effort is the same for every site you have to deal with (you get more skilled at it over time, but it is a craft nonetheless).

Conversely, when a site adopts a standard format for expressing their data, or how to interact with it, you can put your code together once, try it out on some conformance tests, and be sure it will work across a wide range of different sites - it's like designing a t-shirt for threadless instead.

Putting together such standards, like HTML5, OpenID, OAuth or OpenSocial or, for Dave's example of reviews, hReview, takes more thought and reflection than just replicating your own internal data structures, but the payoff is that implementations can interoperate without knowing of each others' existence, let alone having to have a business relationship.

I had this experience at work recently, when the developers of the Korean Social network idtail visited. I was expecting to talk to them about implementing OpenSocial on their site, but they said they had already implemented an OpenSocial container and apps using OpenID login, and built their own developer site for Korean OpenSocial developers from reading the specification docs.

I'm looking forward to more 'aha' moments like that this week at I/O.

URLs are people too

There is an assumption buried in the collective mind of developers that is hard to remove, and it is that people are best represented by email addresses. Go to almost any website to sign-up, and you are prompted for an email address and password. Signing up usually involves digging out the site's reply from your spam folder and clicking on a link to get confirmed, then giving it a password. Sometimes you get to pick a username too, from whatever stock of namespace is left at the site.

Elizabeth Churchill and Ben Gross looked into this and found out that people find it easier to remember passwords than usernames, because they use the same passwords everywhere, and they end up with multiple different email accounts to handle the problem of having handed them to to all these sites and getting spammed by them.

Meanwhile, over here in the blog world, we've been using blog URLs to refer to people for years, and social network sites have proliferated URLs that are people. I have several that refer to me, my events, my music, my twitters and my photographs linked from the sidebar here. We even have XFN's rel="me" to connect them together, and OpenID to allow them to be used as logins elsewhere, instead of emails.

The underlying thing that is wrong with an email address is that it's 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.

So, developers, remember that URLs are people too.

Update: This tension between email-as-identifier and email-as-way-to-be-spammed is what makes Scoble's attempt to extract 5,000 people's emails from Facebook for his own use less defensible than it appears at first. Dare Obasanjo recognises the tensions, but strangely dismisses the OpenSocial attempt to abstract out this kind of data into a common API.