Proposal for a Conceptual Open Stack

I maintained a blog about open identity protocols - this is a mirror of the original post, now only available in the Wayback Machine

Last summer, John McCrea and Joseph Smarr put together a diagram of the “open stack”. The image showed up in numerous talks throughout last year, culminating in an Open Stack Meetup in December. Last week, Marc Canter sent an email asking for thoughts on crafting a new revision to the “open stack” graphic. I’d like to propose a new stack based on the underlying concepts rather than the specific, possibly obsolete technology.

Here’s the open stack graphic from summer 2008:

The Original Open Stack

Here’s the problem: how do I read this? If I’m an average businessperson or developer who has never read a spec, how do I know what these terms mean? Some of the ideas are in there … ID, Auth, Contacts … but others don’t make any sense. XRDS-Simple? My eyes start to glaze over - that doesn’t seem all that simple. I have to lean over to my friend and ask him what all these things mean.

Technology changes.

The technologies involved here change rapidly. In just the past six months, we’ve added draft specs for PortableContacts, ActivityStreams, OpenID / OAuth Hybrid, and OpenID User Experience. These are all draft specs, which means they will change (some more than others) in the near future. Other specs, like XRDS-Simple, are actively being deprecated in favor of newer versions, like LRDD. And the work is far from done - there will likely be even more specs developed and revved before the whole thing really starts to gel.

Do we really want every version of this graphic to be out of date shortly after it’s released? Or do we want something that is compelling, demonstrates the vision, and gets people thinking about how to do it themselves? We should use the underlying concepts to communicate ideas instead of specific technologies.

The “Real” Open Stack .. of papers.

For an example of a different approach, I looked at the messaging around Facebook Connect. A developer who’s deciding whether to implement Connect will see the three main benefits: Identity, Friends, and Feed. Sure, it’s much more complicated under the covers, and sure there are some pieces that aren’t covered (lots, actually), but those are the main points that everyone should think about. They will go home and think: “How can I fit each of these pieces into my own website?”

The Facebook Connect value stack.

The “open stack” embodies a similar set of concepts, but they aren’t entirely the same. for example, to participate with a many-to-many decentralized web made up of open standards, Discovery becomes a really important element. Someone who views the diagram should be able to tell what’s going on without having to look up a bunch of terms or be involved with the community. They should also be able to immediately understand most of the terms, and apply them to their own use cases.

Here’s my proposed conceptual open stack:

A conceptual open stack.

Let’s stack it up, with the highest-level concepts on top and the foundations for those concepts on the bottom. Thus we have:

• Streams. Read recent activities that people are doing around the web. Can be implemented with Atom, RSS, or the newer ActivityStreams.
• Friends. Get information about people you are connected to. Alternately, this could be called Contacts, although I think that word tends to turn people off since they think it means contact information (which it doesn’t always). Can be implemented with PortableContacts, the OpenSocial “People and Friends” API.
• Identity. How does someone prove they are who they say they are? This one is solidly covered by OpenID.
• Profile. All the information that goes along with an identity - name, profile picture, birthday, whatever. There are a bunch of ways of getting this, and it hasn’t really settled yet. The most popular now are OpenID Simple Registration and OpenID Attribute Exchange. Another possibility is to use the OpenSocial “People and Friends” API with the OpenID-OAuth hybrid (although to my knowledge nobody has implemented this yet).
• Authorization. Allow someone to have access to private data. Alternately, this could be called Privacy. The open standard for authorization is clearly OAuth.
• Discovery. In a decentralized system, we need a way to figure out where everything is. As we get more and more providers and consumers, a smooth discovery process becomes ever more important. It has hopped around, from simple link tags in OpenID 1.1, to XRDS-Simple in OpenID 2.0. Now Eran Hammer-Lahav is working on a Link-based discovery mechanism, which will hopefully replace the other forms of discovery going forward.

As you can see, the world of the open stack is constantly changing, but the underlying concepts are maturing. We should ask people to think about how they can apply the concepts to their own business or project, rather than asking them to check off a bunch of arcane technology names.

I’m sure that lots of people have thoughts on this. Let me hear ‘em!