Sunday, May 4, 2008

On the OpenID attribute exchange protocol

OpenIDImage 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).

Friday, May 2, 2008

How (not) to make friends

Social Networks world wideImage by Chewbacka via FlickrRegarding the social web and linking of 'friends', the currently available implementations such as Facebook etc. take the following approach:

First you identify who is your 'friend' (within the same network or application), this in turn determines which attributes they are allowed to see. Other classes of relationships like 'acquaintance', 'co-worker' 'school-mate' 'best friend' are now being proposed on the Data Portability forums to manage this.

This not only smells like bad design, but it appears to me to be an inversion of what happens in reality.

It is not the appointing of a 'friend' class to someone which determines who can see which of your attributes. It's the other way around: by allowing different identities to see different subsets of your attributes (gradually and over time), you define your relationship with these other identities. In other words, someone might become a friend after you decide he may see some of your attributes.

You don't have to decide on the relationship type upfront if you could granularly disclose attributes to various other identities (and maybe have the favor returned to you).

Off course people don't want to be bothered continuously with such fine-grained control over their individual attributes. As usual, software programs can ease the burden and help with common tasks.

Not many people currently craft their HTML documents and HTTP requests by hand to publish or read on the world-wide web. Still, inter-operability of all the different software is possible, thanks to the underlying standards. Sadly, we don't have these for identities and their attributes yet.

Thursday, May 1, 2008

Notification for feed consumers

The rss feed for this site has been changed to

Please update your rss clients.
Creative Commons LicenseExcept where otherwise noted, content on this site is licensed under a Creative Commons Attribution 3.0 License