On the OpenID attribute exchange protocol

Image via WikipediaThe process for new attribute creation (a 5 point list, proposed by D. Hardt) is broken. It assumes central control (or at least some barrier for me) over what can be postulated about me. My position on this is explained in The Profile Problem.

I would rather not see the openID initiative which is applauded for its decentralizing effects on Identity, become a centralized point for attribute definitions.

Luckily, (apart from the openID attribute namespace) anyone can define attributes as they see fit. But when everyone starts defining attributes, how do we make sure this still results in a usable system of exchange (where usable means no centralization of any kind is needed to take off).

Off course the openID namespace attributes will mostly be identifying attributes, which are attributes whose values are supposed to be unique for one person. However the non-identifying remainder of the set all possible attributes is much larger and possibly much more interesting in the lives of most people. So this is where most of the action will take place, between common folk.

Let's suppose that everyone gets his own namespace (or comparable mechanism) for creating whatever attributes to describe him or her self; This way, no central authority on 'official attributes' stands in the way of full self expression of the individuals describing themselves.

In order to exchange attributes meaningfully, the two parties must agree on the semantics (they must agree that the attributes, although maybe called differently by both parties, actually are one and the same thing). But if attributes can be dreamed up by anyone, how do we do that?

Basically there are two options. The first is that both parties decide that their attributes to be exchanged both conform to an externally known (official) attribute definition. The other option is to create an ad-hoc attribute just for the pairing of the two personally defined attributes, and use that as the underlying definition to agree upon. A new attribute definition will be instantiated, specifically for this one-on-one mapping. Both parties designate their attributes to be one of that kind.

It would not be unreasonable to expect well defined attribute collections for general use to
appear soon. If both parties designate their (personally defined) attributes as a known external uri, semantic matching is automatic. If not, human intervention is needed to decide, but that's nothing too dramatic. A simple instant message "Hey, your sending me this http://..../foobar property, it has value 14. What is it?" If an understanding is reached, both parties will have semantic agreement, and both attributes will be defined as being of a (newly created) special attribute which is defined purely for this one-on-one purpose.

The key point here is that all attributes that I create are in my private namespace, and that semantic matching occurs on a different layer, between each of the 2 identities involved.

In the end, each person would still have his own idiosyncratic world view defined by the attributes he makes up. These describe himself as well as other people he knows. Hidden from view are the mappings based on semantic agreements (the underlying attributes) via well known or ad-hoc attributes.

The result is decentralized attribute collections (they are personal, but allow for consensus via intermediate maps or via plain old human consensus).

Let's fast forward from here.

I can imagine that certain groups of people (say, project team members) might want to share some pretty interesting attribute sets, which are not 'standard' by any other means. The support of this kind of creativity is essential.

Quick creation of special-purpose attribute sets, and proposing those sets to others is where protocol thought should be focussed now. If I can quickly create, send out, and receive values of, self-defined attribute sets, all in a fully decentralized way, then we finally have a reason to ditch Lotus Notes forever (for which I should win the Nobel Peace Prize).

DataPortability - bad name for a real problem

It's about you

The recurring theme in social web data is that the data concerned is about an individual (ie. you). Anything that describes (a part of) you or your actions or preferences or you name it, qualifies to be part of your 'profile'. It doesn't matter if you typed it in yourself, or if it is generated by some system. (As long as something pertains to you, represents you, it should be under your control. I'm taking an extremely user- or identity-centric approach here).

Currently almost any data describing you is not under your control. See The Profile Problem of which the Scoble vs Facebook case is an example (not the latest, methinks).

Let me be clear: I totally agree with the problems that DataPortability tries to solve. Only the name of the project is misleading to say the least.

The name Data Portability (and some of the things I've read on their website and forum) gives me the feeling that they want to be able to extract and import 'user data' from and into various existing social-web applications, just like Scoble did. That's a nice problem to solve, but it all depends on what level of abstraction the standards are formulated.

Let's do a thought experiment, Imagine a less-than-world-wide web where pre-existing publication platforms were hosting content, each in its own proprietary way. At some point the need for inter-operability (linking) and re-usability of this content becomes apparent.

Thanks to Tim Berners-Lee, and lucky for us, we don't have this situation on the current world-wide (webpage) web. We're not porting documents from one web-server implementation to the other, and we don't need or want standards to do so. Instead we have the HTML standard for the document format, the HTTP protocol for accessing and creation, and the URL for addressing.

These are key components. But on the social web, we do have this situation.

The problem isn't then that we can't port or migrate data (we really shouldn't be wanting to go that way), the problem lies deeper in that there aren't any standards for representing, addressing and manipulating this type of content.

Similar to the standards that make the world-wide web so successful, I sincerely hope that the DataPorters want to come up with a similar addressing standard for identities and for individual attributes. Already OpenID covers the part of the solution.

Once identities and specific attributes are uniquely addressable, data at these addresses should be in a standard document format (like HTML documents which resides at url addresses, 'attribute documents' should reside at attribute-url's). I would like to have an addressable document in a standard document format for each of the attributes that are part of my self-representation. (Unlike web-pages, these attribute-documents shouldn't be automatically world-readable, the documents themselves should include disclosure settings, and part of the access protocol should be the decision to disclose or not, depending on the 'requesting party'.)

It follows then that we also need a protocol for sending messages to create, retrieve, update, remove and share (disclose) these attribute-documents (defined by their unique addresses); HTTP does this for viewable documents and we should have something similar for identity-centric attribute documents.

Once the standards are there at the right level of abstraction (the attribute level imho), the rest is easy. You could implement a Facebook in no time, and it would be inter-operable with any other such system (no need to shovel data to and fro).

Conclusion

It seems to me that trying to make current proprietary social-web applications inter-operable after the fact, by devising a standard at the application level, is a waste of effort. Too bad we have existing applications without standards, but this still leaves us with the need for low-level standards for the identity-attribute domain. Once we have that, data portability is a non-issue.