Category Archives: identity

Ascription

Thinking about badges and how people reveal their membership in things…


Millitary service ribbons have a rank ordering.

Blog authors announce their affiliation with various vendors, standards, etc.

Boy scouts can wear one of these to reveal their religion, except for Unitarians.

Pins are very popular in the Soviet Union. People collect them.
This power adaptor claims to be very conformant.

Standardizing Social Networks

Standard bar code for a relationshipIf I had a EAN.UCC Company Prefix of my very own (only $750 dollars!) then I could assign all my relationship partners a unique GSRN or Global Service Relationship Number (pdf). This would be very useful when I need to quickly retrieve the details of any given relationship. In some cases I might want to hand out multiple GSRN to the same person, since our relationship is framed in different modalities; friend/coworker, wife/mother/helpmate. I could then mark up all my correspondence so it might be quickly associated with other aspects of the relationship. Membership cards! Better yet jewelry with RFID chips embedded. Then when they drop by the house I could dynamically customize their visit to my home.

Bar codes? Not just for tangible items anymore! Label the intangible. This is going to be big!

Could your phone number be identity?

Interesting post on identity, phone numbers, etc. over at the most excellent Telepocalypse.

It includes the delightful paragraph that I will have to work into a blog posting some day:

Now, the following is so vital, I’m going to put it in large red bold. It’s the only large red bold ever posted on Telepocalypse, and I promise not to do it again unless something even larger, redder and bolder is being said. Which isn’t likely.

What comes next? Well this (emphasis removed):

What’s the core purpose of a telco? A telco joins the physical world to the virtual world.

My first thought after reading that was: “Hm: so Orange isn’t really a color or a fruit, it’s just the peel.” (Orange is a telecom company in Europe).

It’s hard when talking about the architecture of the net to decide what to emphasis. I, for example, tend to emphasis the how exchange becomes standardized and that leads to consolidation of power in the hands of middlemen. Other people emphasis empowering the ends; or advancing the client; or toolkits for distributed apps; or distributed data models.

Martin’s bold red words insist that we take note of another thing. The telcom industry has a lot of control over the border crossings.

The first time I ever say the “cloud” drawing was in a phone company document. You know the cloud drawing right? It shows mom on the phone, and the butcher on another phone. Little lines run from their phones over little telephone polls and then disappear into a fluffy cloud. Sometimes that cloud is labeled “the phone company.” These days the drawing shows mom’s browser on one side and eBay’s servers on the other side; and the cloud is labeled the net.

The cloud drawing implicitly says – “Don’t worry your pretty head about what’s inside this ball of fog. We will take care of it.”

Martian’s bold red word? Yeah the phone companies lost control of the cloud; now all they have is the rine. Of course, controlling the border can be a very profitable place to be.

Collectively the telecom industry is a fascinating beast. Historically the industry was very granular; each major player existed inside a safe geographic bubble where they had captured the regulator. Set aside how that empowered them to frustrate progress for so long that now that the damn has burst all hell broken loose. The granular structure created a set of peers who didn’t threaten each other. Those peers could then work collaboratively to look for joint gains. One of the forums for that was the International Telecommunications Union. The ITU of the old gorillas in the standards setting world.

When big disruptive change washes over an industry they can existing players can only fight back with the muscles they already have. Martin is arguing that if the telecom industry knew what they were doing they would be using their standardization muscles to get a handle on the identity standard – possibly by evolving the phone number.

It’s an interesting thought. They industry has fought so hard to avoid number portability. A fight that is all about defending the old obsolete granularity of the industry. Now just maybe they need to turn around and strive to make the numbers even more pliable.

Consider this concrete example. I’ve been forwarding a VOIP number to assorted phones; and I give it out as my “mobile” number. This causes a bit of trouble when I call from one or another cell phone – the guy on the other end doesn’t know it’s me because I can’t annotate my outgoing phone calls with my “mobile number” persona. (Well at least not until I absorb even more of the functions the phone company provides.) This trick as tree advantages. I can use a real phone for more calls. I can avoid cell minute costs on some calls. I can grab the cheapest mobile service and switching carriers when ever the sign up incentives of the last carrier run out.

In any case; Martin’s post is an it’s an interesting view of the identity problem from the point of view of just one industry. It suffers a bit from failing to admit how many other industries are similarly waking up to the value of their “relationship asset.”

Notation 3

Stefano brought N3, or Notation 3, to my attention – it’s a good thing!

I hate XML. It’s a mess. Wrong on so many levels. But getting the industry to switch is now nearly impossible. XML has played almost all the cards you can to make a standard sticky and lock-in users. For example it’s extreme complexity. Just like that of the Window’s API. That makes people extremely reluctant to abandon their sunk costs after learning it.

That said I keep hoping that something better will emerge.

One possibility is that something will emerge that provides overwhelmingly improved UI. Making users smile can be a powerful force for change. So cool UI might be the lever. Things like SVG and Lazslo are examples of folks making a run for this exit. On a lesser scale the evolution of HTML/Javascript just keeps on hill climbing.

A less plausible possibility is that we will all rendezvous around one standard from for storing our documents, our data. This idea has been a fantasy of the ivory tower crowd since beginning of time. There has been a cool up and coming normal form at every stage of my life. I still have some stacks of punch cards. I wrote programs to convert IDL databases into suites of prolog assertions. I can’t count the number of times I’ve forced some data structure to lie down in a relational database or a flat file that sort/awk/perl would swallow.

After a while one becomes inured to hearing the same tune, the old enthusiasm returned again new clothes. You wish them the very best of luck because of course you remember how hopeful one once was that this could all come together. As a result I’ve have been treating the Semantic Web work with a kind of bemused old fart’s detachment.

But! Step past all the self indulgent ivory tower talk of one world data model. Skip the seminar on how soon we will compute the answer to everything. You don’t need to know from reification, or Mereological Ontological.

This stuff is actually useful.

Look at this:

:dirkx foaf:based_near  [
            a geo:Point;
             geo:lat "52.1563666666667";
             geo:long "4.48888333333333" ].

That tells us where something named here as :dirkx is lives. That’s it! No wasted tokens. Easy to parse. That’s why I like N3. Easy for humans, easy for computers. XML is neither.

    <foaf:based_near>
       <geo:Point rdf:nodeID="leiden">
         <geo:lat>52.1563666666667</geo:lat>
         <geo:long>4.48888333333333</geo:long>
	</geo:Point>
    </foaf:based_near>

XML is good if your getting paid by the byte.

I’d love to see XML displaced by something more practical. Something that lowers the barriers to entry so that you don’t need a few meg of code just to fool around. I believe that XML’s complexity is good for large players and bad for small players. I want to see the small players having fun – and frustrating the large players.

N3 is neat, but what about RDF?

RDF is just fine. You need to clear way all the overly serious ivory tower presentation. get past all that righteous marshmallow fluff and down at the core you find a nutritious center of practical and simple useful good stuff. How nice! It’s going to drive the marshmallow men in their tower crazy if this thing takes off!

When I look at RDF I notice two critical things. It is much easier to stack up new standards in RDF than it is in XML. Look the example above. It’s using a standard called geo and one called foaf. Click on those links to see how straight forward they are.

In XML if you want to define a new standard it takes extremely talented labor. Only a handful of people can both understand XML Schema and think in practical terms about real world problems. In RDF any fool can do it; which means that anybody with some data to move can get on board without having to go thru some gauntlet of heavy industry standardization.

The second thing I notice about RDF is actually a blind spot.

Above I mentioned two ways that XML might get displaced. One on the supply side (data normal form) and one on the demand side (presentation). There is a third – data exchange. Exchange is where the powerful network effects are – always! RDF is better for data exchange than XML. It’s easier, it’s simpler, and it is far better for layering, mixing, and creating new standards.

This trio, and the standards around them, are key to making anything happen in the net.

  • Supply: writers, data, storage, normal forms, etc.
  • Demand: readers, presentations, ui, etc.
  • Exchange: messaging, subscriptions, polling, push, etc.

The RDF folks think that the demand side is where the leverage is. That’s wrong. Content is not king! Exchange is king. In the world of ends, the middle rules.

Scare Crow Model of Identity

User identity on the Internet; it’s just a strawman.

[After encountering the witch’s flying monkeys.]

Tinman: What happened to you?

Scarecrow: They tore my legs off and threw ’em over there. Then they took my chest out and threw it over there.

Tinman: Well, that’s you all over

Poor scarecrow, he lacks a brain.

Wicked witches? Some of them are trying to enslave the flying monkeys. Aggregate those bits of straw.

Social Physics

In my morning mail (Thank’s Karim!) a pointer to Social Physics yet another assault on the tough problem of how to manage the identity, persona, privacy problem. This assault distinguishes it’s self by attempting to push the problem to the edges of the network and thus reduce the role of the middlemen. A fine design goal as far as it goes. People who strive for that are often running blind to both power-law nature of what emerges on top of these platforms and the value that middlemen bring to the party.

Blindness to the power-law can be fatal; or more typically it just limits your scale. I see signs that they suffer from it in their somewhat gassy introductory manifesto. It’s on the front page. It insists on framing the problem into the well worn 20th century dialectics where big is bad and small is good, and middlemen are ways suspect. For example: “Who has 687,389 trusted friends? Nobody.” This just misses the point so widely it makes my head spin. Most of the economy runs thru entities of that kind – governments, the credit card firms, etc. etc. So lots of entities have millions of of trust relationships. To fail to take this to heart only assures that we encourage the emergence of two solutions; one for each class. That’s a horse race I’d rather we avoided.

There is a lot to like here. Particularly for the engineer of software/network-systems/standards. A commitment to severing the desires and needs of the small player in the persona/relationship market. They have pulled a lot of fun technology cards out of the deck: P2P, Jung’s data model, etc. They are not naive about what it takes to get the bandwagon to pick up speed – particularly when doing a bottom up standards play.

I’m going to enjoy taking a closer look.

Privacy Column Fodder

Feature comparison charts  showing N competing product offerings vs. M features are called column fodder in the sales and marketing liturature. Sales men like to offer them up to their customers in the hope that the customer will then turn around and use them to show his purchasing department that he carefully weighted the alternatives and picked the most cost effective product. The devil is in the details; so it’s a huge advantage if you can get the customer to use your template to do the analysis.

That disclaimer now made. I will fall victim to just that scam and recommend this one for it’s list of things to think about when working on a privacy policy.

It’s a good starting point for thinking about how hard this stuff is. For example consider the feature: “Requires member consent if info is shared w/3rd parties.”  All the vendors shown get a check mark for that. But I very much doubt that the term “3rd party” means the same thing for each of them. For example are a firm’s partners a “3rd party.” Contrast that to AT&T Broadband old policy that allowed release to 3rd parties; but then third parties turned out to be a huge group of people; include all their subscribers.”

Reputation and Privacy

Joe’s privacy erodes when two or more parties conspire to merge their model of him together. To frustrate this we have a design principle: avoid handing out a unique identifier. If the library and the video store both index their records by my national id number then the only barrier to merging those records are current law and rapidly evaporating technological inconvenience.

For example I have a number of standing queries at Google. This morning one of these reported that a member of my family seems to have an account at an a certain site; clicking thru revealed a list of the content they had viewed at that site. In this case the unique identifier in my query was their name. Somedays these problems seem a little hopeless.

My idea that groups could empower their members by a letter of introduction scheme to create anonymous persona is one attempt to tackle this problem. Key, in my thinking about that idea, was that the persona would be bootstrapped by the reputation of the group and the user/member of that group.

The letter of anonymous introduction is means of narrowing the model of a user. Creating only a fragment of reputation that can then be used to gain rights in some other community; say the world of open systems.

It’s interesting to note that user model isn’t exactly the same thing as reputation; it’s only a kind of model. Is it the kind of model that creates rights?

Generally reputation accumulates for a persona based on a history of transactions involving that persona. The video store records are an example of just that kind of transaction records. Statistical summaries of those records – stating derived facts are less revealing. So if we know that the 20% of the videos weren’t returned on time we know something different than what we know compared to knowing that 82% of the movies rented were rated PG.

While the letter of anonymous introduction is an interesting edge case all these distillations from fully fleshed out transaction details into statistically abstractions have some slight element of increasing the privacy of what’s getting revealed about the persona involved.

This is similar to the privacy schemes used in the census data that reveal aggregate statistics for a region but not for a household. It’s a step in the right direction.

All this gets me thinking that there might be a middle ground regarding the unique identifier question. That there might be schemes that allow roughly unique identifiers. In a sense that’s what the anonymous letter of introduction scheme is creating. It a means that allows the creation of a persona that says no more than this is Mr. X of Group Y.

Regulating Hearsay

As outlined in this model one way to look at the identity problem is that information about a user flows out from their activities and then is passed – behind their back so to speak – to third parties that then aggregate models of the user. Those third parties then sell those heuristically built models to fulfill the demand for a better user model.

That process makes users reluctant to reveal information to other parties. They have no assurance that the information they reveal will “go no further”.

At the nub of this problem is the contract, implicit or explicit, that governs that revealing. For example if the user could get a signed non-disclosure agreement each time he reveals some information his confidence that his privacy could be protected would increased. The identity business could help with this.

This is one reason that corporate people often say that technically the identity problem is easy, but the business agreements are very very hard.

Today users contractual deal with the web services they reveal information to are governed by the privacy policies of those sites or the PPA (Privacy Protection Acts) of the relevant industries. The protections afforded are typically very thin. Web sites want to keep their options open. Web sites can’t afford to negotiate a distinct binding agreement with each and every user.

It isn’t practical to assume that one privacy contract/regulation will cover all cases. I want a different one for my home address, my phone number, my library records, my academic records, my performance reviews etc.

Problems of this kind can be solved in only two ways. You can set a very low baseline and then add protections; or you can set a very high base line and then open permissions. In a safe environment you can adopt the first design pattern, in a risky environment you must adopt the second.

This is possibly the hardest transition that must be managed in solving the identity problem. How do we bootstrap a very strict contractual/regulatory center piece and then empower the users and web sites relax that for individual cases.

Consider the FOAF directory service outlined in a previous posting. Could we write a contract we bind the web services to that strictly limits what they can do with the information they glean from the FOAF we helped them find? Would that frustrate any attempt to get the system to grow?

FOAF magic

Often when I encounter tech-savvy folks and I mention that I spend a lot of my time working on the identity problem they mention FOAF. FOAF, or Friend of a Friend, for those unfamiliar is a spec for how to write down a mess of information about a person. It uses XML, well actually the RDF variant of XML. Oh, and it can be used for any entity not just for a person.

FOAF is a nice format to solving various problems about how to reveal information about a person. It doesn’t try to tackle other issues; like privacy and it’s complement: how to broker the data exchanges. It is a pretty good solution to the question: “What might a user model look like.”
Thus if you embrace the magic happens model of this identity business FOAF is an acceptable first draft of what we want the magic to return so the web site can begin to make a better experience for it’s visitors.

If we cheerfully ignore issues of privacy then the magic we are seeking is “just a directory” problem. The web site queries the magic and get’s back a pointer to the user’s FOAF file.

You could thread that needle with web bugs, shared cookies, or redirection bouncing.

For example: Redirection bouncing works as so. The user visits the web site. The web site asks the user’s web browser to redirect to the FOAF directory service. That service then redirects the user’s web browser back to the web site passing a pointer to the user’s FOAF file.

The FOAF directory service has a relationship with site and users. For the web sites it provides the magic. For users it provides the service of making their FOAF easier to find.

There are huge number of issues with a service like this before it becomes useful. Here are a few examples:

  • Achieving scale.
  • Rate limiting the sites.
  • Guarding user privacy.
  • Avoiding incidental revealing to incidental observers.
  • Efficent authentication of sites using the service.
  • Denial of service attacks.
  • Tempering the problem that a browser is not identical to a user.
  • Avoid enabling gossip like consolidation (without permission) of joined user model.
  • Tempering the concentration of power such a hub implies.
  • Enabling distribution, extensibility, and distribution, and compartmentalization of the user model.