Drug-Resistant Tuberculosis, Federation and Fresh Tokens

This morning I was reading Newsweek (before you get any ideas: I subscribed to BOTH Newsweek and Time) and the interesting account they made about the history of a person. Much is being written on the subject, just browse your favourite news website for the details: however the summary is that this person was traveling through Europe while having a drug-resistant form of tuberculosis, raising worries about the spread of the disease. Health officials tried to locate him and minimize his chances of infecting others (apparently the infection is much more likely to occur when you spend a long time with the subject, like in an airplane cabin). When they finally managed to talk to him he was in Rome: since there was no way for him to travel in “normal” ways back to US without endangering also the pilot, the guy was advised to hire a private jet or go to an Italian hospital. 

NOW there’s the part of the story that is relevant to identity. This person didn’t go to stay in an Italian hospital, nor he hired a private jet: he boarded a commercial flight and simply flew home. How did he do that? According to Newsweek, his name was promptly included in the no-fly list; however the man flew from the EU to Montreal, and apparently Canada was not alerted about the situation. Once entered in Canada  he rented a car and drove into the US, managing to go through the border after few routine questions. The article I read is available in electronic form here.

This story uncovers one drawback of relying on physical documents, or in general on an ID that can be used offline thanks to “claim buffering”. If the passport would have been represented by a managed card, that is to say “expressed” as a security token, that would not have happened.

In the offline world a document contains a number of statements about the subject: such statements can be shown to anybody, and they are supposed to be valid for the entire duration of the intended validity period. That’s a pretty big act of faith from the identity provider that issues the document: it assumes that the eligibility conditions will hold for the entire validity period. As we have seen above, that may not always be the case. The protagonist of the story above must have used the passport for leaving EU and entering  Canada: there was nothing in the passport itself that betrayed the no-fly status of its bearer, and the “backend” communication between checkpoints didn’t work fast enough for preventing the security breach. Below there’s a little picture that summarizes part of the scenario, and the countries are a generic “blue green country”.

If the passport is a document that entitles you to travel, as soon as the issuing agency believes you should not be allowed to travel the document should immediately cease to be valid. This is exactly what happens in the model based on identity providers. If the passport would have been a managed card, the subject would have been forced to get the corresponding token from the issuing authority itself before being able to use it with any relying party (like an officer at the airport). If the issuing authority would determine that the request comes from somebody in the no-fly list, it would simply refuse to send back a token; the subject would then be unable to comply to the request of the officer, the digital equivalent of ripping the passport apart before being able to show it. In the case of an auditing STS, that is to say an STS in which all requests for a token must declare also for which relying party the token is being requested, there are even more possibilities: if a no-fly subject would ask to an US STS to get the passport in form of token contextually to a checkpoint in Rome, the STS should be able not only to refuse to issue the token but it could also alert the RP (the Rome checkpoint, in our example) of a potential sanitary emergency at their airport. Before I get a storm of comments about privacy: naturally the auditing policy should be ALWAYS clearly advertised, so that the user will always be in control of how his/her data are distributed and to whom, and take informed decisions about if he/she does or does not want to use the system at all. Also, I am not making any judgement call about if such system should or should not be adopted: here I am simply pointing out the technical possibilities offered by the system. 🙂

P.S.: Who is familiar with enterprise SSO may have seen in this some echo of the paradigmatic example that shows why federation is a good thing, as opposed to duplicate accounts across multiple stores. That is the typical case of the employee that, after having left his company, can still access a partner website because they use duplicated user stores and the news are slow to spread from one backend to the other. In a federated environment that does not happen, since the authentication is always performed in the home realm and everything works on trust from that moment on. That works beautifully, but it still requires some amount of synchronization between the company and the partner. With CardSpace the partner could in theory just decide to accept managed cards from that company, without any explicit negotiation (apart from acquiring the public key used for signing the tokens). At that point the choice of using the company managed card will magically appear in the options presented to the subject. Now that’s one of the meanings of the term “user centered federation” 🙂

P.P.S.: the fact that the guy wears a hat is not a reference to Garrett, it was simply a quick way to make the pic recognizable in the no-fly DB-)