Local Identity Namespace?

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

While I was at OSCON, I had the opportunity to attend an interesting Identity oriented BOF along with Stephe Walli and Dave Gynn, where notable identity resources such as Steve Gillmor, Doc Searls and Kaliya Hamlin were holding forth on issues around federation, interop, privacy and so forth. Great conversation, lots of interesting ideas, and I look forward to seeing what these smart folks – along with others like Kim Cameron – can do with a problem that’s hideously complex.

But in the meantime, I’m looking for a solution to a similarly vexing but presumably easier to solve problem; the issue of local identity. No, I don’t mean that in the Active Directory / LDAP sense, as in the ability to access locally networked resources – I mean local as in “my machine.” The problem there is simple and probably something everyone’s experienced: there’s no single notion of an individual at the local level.

In other words, we have different views of a contact from application to application, with little if any way to connect those identities together in any meaningful fashion. For example, let’s take the first individual cited above: Stephe Walli. I have his IM, which is stored in GAIM, I have his email and phone information, which is stored in Evolution (which, incidentally, can do nothing with that phone information), and I have his blog, which is stored in Bloglines. Apart from the lightweight GAIM Evolution syncing that I’ve never gotten to work, Stephe Walli does not exist as an individual on my machine. He exists as a set of completely separate channels that I’m forced to manage myself. Thus when I write Stephe Walli in my blog authoring environment, it’s just another piece of text, and to link to him I’m forced to hunt down his URL and apply it manually. For this entry, then, I was forced to do six Google searches (Bloglines is down at the moment) and six cut and pastes. That seems dumb, given that the majority of these people are known entities to me.

Microsoft has clearly perceived this problem, because the integration of presence and IM into Outlook has been around for a long while now – long enough that I had it when I last ran Windows/Outlook as my primary environment. The difficulty is that it is – or at least was when I last ran it – aimed at Microsoft managed identities. Thus it was great at managing MSN Messenger identities, but did nothing for my AIM contacts (let alone Jabber), which perhaps not coincidentally form the bulk of my buddylist. If you’re on a relatively homogenous infrastructure, Microsoft is probably your best bet to solve this problem; check out Don Box’s experiences with Office Communicator here. I don’t believe that homogeneity’s going to be a popular approach for a large customer segment, however, given all the conversations I’ve had in the past with Wall St broker-dealers that are using AIM, Communicator or other non-MS IM systems. Thus it would seem there’s an opportunity for an application independent, non-vendor centric approach.

The question in my mind is this: is it worthwhile to try and establish some form of centralized identity repository, such that an individual on your local machine becomes not simply another meaningless string of text but a meaningful namespace? Something that other applications – be they blog, IM, email, office productivity, or otherwise could access via a standardized API much as they might access spellcheck? The basic topology might look something like the Evolution Data Server in GNOME, but with more robust capabilities and an API that applications could ask not to check spelling, but to perform a lookup against a library of known identity namespaces.

I won’t speak for the rest of you, but I’m sick of wasting effort linking to the same people over and over; there has to be a programmatic way of addressing this, and in such a fashion as to solve other problems at the same time. This is all the more relevant if Asterisk takes off the way that I think it could, because then that voice contact information that is mere data within the confines of an addressbook becomes actionable.

The big bang opportunity in the Identity space is clearly around seamless management of my external identities and personas, but let’s be honest: it’s not like our ability to manage them just in the context of a single machine is much better.


  1. I think it is all related. The identities you think of as local are external identities to someone else. Somehow they all need to be connected. Easier said then done though. If you try to centralize all this info like Passport then trust and privacy become concerns. For whatever reason, I think users feel better just registering over and over again rather than trusting one service or source to manage identity. I keep thinking of something that would let you claim your identity. Sort of like how you take all your email addresses and forward them to one that you actaully use. Granted it is an incomplete thought.

  2. Jaime: from what i remember, and from Wikipedia, i think LDAP was intended to solve a slightly different problem. i'm really talking strictly about a local machine, not about networked identity of any kind. something that could be stored locally, without being explicitly shared outside the boundaries of a single machine. agreed on the priority to scalability, relibility and security.

    Random Blogger: i think there may be potential for federating these identities externally, but my ambitions are limited: i'm really talking strictly on a machine level. the linking of identities offers some potentially huge new features, but also introduces – as you note – a ton of complexity.

  3. Stephen, that issue was the basis for LDAP and, ironically, it was Microsoft who started doing partial implementations of LDAP in their email client to hurt interoperability and to promote their proprietary protocols.
    LDAP is not only for networked resources, LDAP was built to be the method of storing preciselly that kind of information, it would be up to the client to get the relevant information from it.
    When Microsoft discovered what everyone else was saying for years, that the domain model wasn’t the way to go, they had a chance to make technology more usefull to everyone, instead, they built a protocol LDAP-alike (Active Directory) with the single purpose (IMO, of course) to hurt interoperability.
    It is my oppinion that the absence of an scalable and reliable information storage mechanism in MS’s offer is now taking it’s toll in their offer in Identity Management but, instead of turning back, they’re trying to limit the scope of what IdM is supposed to do.
    The issue remains, if you work in an 100 people organization and, each personne has 100 contacts, that would be a deployment of 10000 entries. It wouldn’t even be considered a “project” where I come from but, it would be a big AD Deployment.
    Every time you pick “enhanced multimedia features” over scalability, reliability and security, you’re hurting your own future, this being just another example of it.

  4. Jaime: agreed. the nature of the data itself may lend itself well to an LDAP repository, so if that's the chosen format for a local store, i'm all for it. my argument more was that this should be a local effort, rather than an attempt at a once and future multi-server directory effort.

    James: why does a machine level effort preclude loosely coupled web services? i'm merely saying that *starting* with web services is not the way to go, b/c the problems of managing, protecting and securing data beyond the context of a single machine while not insurmountable, are a challenge. hence the current situation with identity.

    i'm also not saying i don't want Microsoft to provide it; i'm saying i personally would find Microsoft's solution less than ideal because it assumes homogeneity, for certain customers it'll be a great answer.

    then there's the IM systems question. many of the IM clients, as you note, do maintain their lists server-side, but clients like GAIM also do local aliasing. i see no reason why a local store could not be synced with a remote store at runtime.

    as for the phone problem, while that's not one i'm trying to solve here, it would seem to me it's a perfect candidate for syncing your master local store with remote devices via something like Funambol.

    in the end, all i'm talking about is empowering a local store with information, then serving that information up via a standardized API to whatever application wants to make use of it: Evolution, GAIM, Skype, or even remote web services. i don't see this as integrated innovation, just an acknowledgement that the multiple independent identity repository/contact database implementations we've seen to date is not a great idea.

    it's basically Identity as a service, on a local scale. would i love to see a remote web service with this information? sure. i just don't see that as realistic at the moment and i'm tired of waiting.

  5. there is, I think, two diffferent things. One is the nature of the data. Another completelly different thing is where the Data is stored.
    The nature of the data is perfectably suited to store in an LDAP infrastructure.
    That isn’t the same has to say you can put your information outside your “control”, you could still have it in your windows PC.
    Just take a look at the number of different databases and storage schemes you have in a fresh install of Windows XP. You have the registry, you have the DB to support the find utility, you have your contacts DB inside Outlook, just to name a few I remember (and I’m not a windows user).
    you could replace all of it with a small LDAP database, have a single access to all your Storage schemes, in one move get rid off the stupid limit on the number of register keys (a former bug in Win95, at least) and provide a platform for ALL ISVs to use and to make the user experience a lot more pleasent.
    this platform has to be made by the OS vendor since, it is supposed that ISVs know that there is such a feature available to ALL users and that provides a richer user experience and eases the development effort. Now, if Microsoft wanted to make the best product possible, they wouldn’t have killed the idea, while tey are more interested in cross selling and taking advantage of the monopoly to hurt 3rd party integration, this will never happen.

  6. on a machine level? and here was me thinking this is a world of loosely-coupled web-based services.

    seriously Stephen there do seem to be some contradictions in your request. you want something that will run on Linux or Windows or any other OS, and integrate with any service. but you dont want Microsoft to provide it. Perhaps on the google deskbar? and how does this help me when i am on the road just using my phone?

    the IM systems you talk to all use server-based models, which makes them powerful.

    i am thinking of things like i-names.

    or Skype- which cross correlates with your outlook inbox, for example. of the AOL service that pulls data, again, from outlook.

    you will be calling for an end to end web services stack and single identity namespace next. reductio

    i, for one, would be happy to have a blog client that offered autocomplete for the identities/blogs i regularly link to. solve that specific problem and i am happy/

    you want a local identity Hula?

    all in all it sounds like you want Microsoft style “integrated innovation” from your loosely coupled components. this might be a long wait, or perhaps i am missing the point

  7. I also don’t see any problem with having this feature and loosely coupled Web Services. It’s the worderfullness about standards, you define a common ground but the implementation is left to you.
    Stephen, all your points are already adressed by LDAP, you add LDAP support in your applications (game, evolution, Outlook, and whatever) and, have all your contacts data in a singular place.
    So, you travel a lot and don’t want to move around your PC all the time? Just host your contacts branch of your local LDAP server in an ISP and put a referall in your local LDAP. Never travel and you use only 1 PC? Just store all that information locally. Work in a company and get a new PC every year? Just store everything in your corporate LDAP server.
    The entire infrastructure is already created, you just need to have an personal LDAP server ALWAYS present so ISVs can use it in an integrated way.

Leave a Reply

Your email address will not be published. Required fields are marked *