Modeling Reality (II)

Ah, the beauty of models. A good model can capture the essence of a system, a phenomenon, anything: it allows you to easily manipulate things, make predictions, transport the knowledge you already have of a domain to a new one. It’s just great, and as we will disclose more things about Oslo I am sure you’ll have chance to experience this thing first hand. For the time being, let me dig a bit on a model factory we know very well: the identity metasystem.

Back in November, during my EU tour, I had a great discussion with a policy maker: this person has an amazing understanding of the identity metasystem, a deep knowledge of the eID landscape, made all the right questions, he was just a pleasure to converse with. At a certain point he described how they were currently dealing with the problem of transporting in application form a very complex scenario, already tamed from the analytic & regulatory perspective. That prompted me to express a thought about how the identity metasystem could have helped there, and I was surprised by how well received that thought was: he told me he never heard things explained from that point of view, so I thought there could be some value in repeating that here.

One of the powers of the identity metasystem, and its architectural backbone WS-*, is that it gives you the tools for describing the relevant aspects of existing relationships: who is affiliated with whom, what are the information an entity needs for making business with somebody, what the constraints are, and so on. Sometimes those relationships are totally natural and are there as a given (like the relationship between a country’s administration and the citizens, between the tax department and registered companies , etc); some other time they have to be figured out as part of the natural business negotiation process (what firms are allowed to offer retirement plans and in which conditions, what are the official suppliers of some goods for a national team in this edition of the Olympics, etc). What is important is that establishing those things should be the bigger part of the job; once the relationships and the rules are defined, I should be able to take advantage of them also in the online world just by describing them. That’s what the identity metasystem allows us to do: if I’d have to re-create the entire net of relationship with passwords, for example, I’d be forced to re-establish relationships (by setting a pwd)  that are already up & running in the offline realm; and I’d have to explicitly plan for every possible interaction, instead of obtaining those as emerging properties of a well designed system.

All right, that’s all pretty abstract: luckily I have an example of real world transaction that IMHO is just perfect for getting my point across. I used it just this morning while chatting with Caleb & Charles for a channel9 clip (should come out soon), and apparently it worked pretty well.

Here there’s my example. Let’s consider the procedure that an Italian citizen needs to follow when applying for a US visa. Among the many things that one needs to do, there is a tax that the applicant needs to pay; a proof of the payment of that taxt (the receipt) must be presented at the visa interview. How do you pay this tax? There is one bank, Banca Nazionale del Lavoro (BNL), which has been enabled for collecting those taxes and emitting suitable receipts. So, how does it work?

1. you walk in any branch of BNL


2. you show some proof that you’re Italian citizen and your name is what you claim it is (that typically means showing your passport); you also give 85EU, or whatever the due is nowadays


3. if your passport is good and your money are OK, you get a BNL-certified receipt that declares you paid the due tax


4. you go to the consular office of competence and you show the receipt, along with all the other credentials you are supposed to present; that moves you to the next step of the procedure, but for the sake of our example we can stop here

Now, that’s a very interesting scenario. There are at least 4 independent entities here: the citizen, the country, BNL and the consulate. There is clearly a relationship of trust between BNL and the country; and between the consulate and BNL (that’s simplifying, I know); there is also a relationship of “membership” (for lack of a better word) between the citizen and the country. The information that needs to be exchanged at every step is well defined, and so is the protocol and the expected formats: name & citizenship from the passport, currency values on the notes, certification fields & numbers on the receipt. All those things have been decided for solid business reasons, for historical reasons, whatever: the bottom line is that they have good reasons for being how they are.

Imagine now to have to re-create such a system in the online world, but having only passwords technology available. That’s a mess, just think of the fact that BNL needs to give this service to ALL italian citizents that require it, not just its own customers. There is no way that you can just describe the system and have everything up & running: you need to introduce all sorts of artifacts for reproducing even the simplest things, you’ll likely have dependencies that are not in the business model but are induced by technology limitations (say duplicating users in the stores of entities that do not have a direct relationship with the user). But IMHO what’s worse is that you need to think much harder about the system. One thing is defining a handful of rules & constraints, putting things in motion and looking where things go: your rules protect you from unwanted situations, without the need of imagining all possible ways in which you may land in a state you want to avoid. A completely different thing is implementing the behavior of a system without having the chance of codifying the underlying rules it should comply with: nothing happens automatically, everything needs to be explicitly implemented and the possibility of inconsistencies is always creeping on your project.

Now imagine how to describe our scenario with the familiar tools of the user centered identity management.

• You can give the subject a managed card that expresses his relationship with his government


• BNL can declare in its policy what is needed for this particular transaction: a token signed by the government key containing name, proof of citizenship (and money; but this is controversial ’cause it may be an application level play)


• The consulate can declare in its policy what is needed for this particular transaction: a token signed by BNL containing proof of payment

That’s pretty much it! As you can see, I am not defining explicitly any interaction. The right path across the various actors naturally arises from the various policies & cards in the moment in which the subject (citizen) lands on the RP (consulate) pages. The system is much easier to define, much easier to control (every node takes care of the things of its own competence, without having to carry the burden of others), much easier to evolve (if tomorrow another bank will be entitled to collect that tax, it’s just a matter of changing few lines in the policy. It is a model that comes alive, a representation that not only describes the system it is poised to depict but it actually acts (or enable to act). IMHO THIS is the real essence of the expression “projecting your identity online”. That’s really what happens 🙂 but your identity is not the only thing that must be projected, it’s the ecosystem in which it makes sense that must be available online as well. For the record, this is one of the case in which having a less expressive system would just not be enough for reaping the full benefits of modeling.