Federal Federated Identity

A couple of weeks ago I commented on the US’ decision to abandon a centralised authentication system and wondered how a federated model would work. Given I was just musing on Joint and Several Liability (or perhaps, a federated family seeking authentication), I’ve also spent some time thinking about this fragmented or federated model.

I guess some definition setup would help. I see “centralised” in this context as meaning a single authoritative source that confirms you are who you say you are – i.e. establishes your identity, or authenticates you There are purists who will say that we need to be separate out identity establishment, authentication, verification, rights management etc, but for now I think this will do. So, think of this like a big LDAP or directory that says not only who you are but how you relate to the organisation – what you can do, perhaps when and where too. You have to go, actually or logically, to this directory lookup service before you’re allowed to progress.

In a federated model, there’s no single authoritative source. I guess it’s possible to argue that actually there is no authoritative source. Instead, various sources are able to confirm your identity (authenticate you) and grant access to certain services, and yet more services then trust that initial source to allow entry. It’s an attractive model – potentially multiple proof points, no single centralised source etc. The venemous treatment of anything centralised in some organisations, public and private, makes it even more attractive for those.

Both models have their supporters – all the way to the top of the technology tree. Passport was Microsoft’s attempt at a centralised service; Liberty was the (almost open source) response, initially from Sun and now from any vendors. Both can work, both can fail. For a while, they might even have been the same thing as the Passport folks talked about moving to a federated model by bringing in partners and storing data in a variety of places (I think of this as some kind of RAID type storage of authentication information – a potentially globall distributed SAN).

Thinking about it purely in government terms, I see some issues to consider with a federated model. It’s not that they’re going to be impossible to solve, but I do think they’re a challenge.

– Government doesn’t see any one individual the same way. Various numbers are attached to every one of us, whether it’s social security, driving licence, passport, tax, benefit, whatever. There’s still a need then to associate “me” to “me in government department a” and “b” and “c” and all the others. I’m not sure that this can be done anywhere else but in one place or, if it’s done in a fragmented way, the customer experience is not much of an improvement on a silo-based model

– It’s hard to know who to trust. Let’s say that I go to my bank. They know who I am, so why don’t they tell government that I’m ok and let me do transactions with government without any further delay? Why not? Well:

– First, the bank only knows who I am to the bank – not to government (so there’s that whole process in the previous paragraph to go through);

– Second, why should I, as government, trust the bank? After all, the bank has a duty to figure out who I am, but they also have pretty good controls on fraud – regular statements, transfer limits, a global network to use to track funds and, a reserve against which to charge losses. Government doesn’t have all that – who would we send the statement to and what limits would we set?

– Third, What happens if I do trust the bank and I let that person go on to use several more services. The more services they use, the more they get to do. Eventually, maybe you can get a passport because you have used enough services – but there’s still only the original trusted relationship. How do I unwind that trust if it turns out to have been false? Think BCCI for those of you old enough. Or think about all of the phishing scams that are going on targetting banks right now. Who do we trust to be who they say they are in a purely online world?

– Fourth, with identity comes liability. How much is your identity worth? And if someone takes it away, how much more is it worth to get it back? So, if we’re going to federate trust and allow many people to vouch for identity … ummmm … we’re going to need to understand where the risk has moved to at each stage, what controls we have and what measures we take to govern it. The only way out of this is, I think, to actually have no liability – because having it will shut out too many players, because the cost of insurance will be high; or to have a few very large players that allow access to “all” and smaller players who can grant access to only small (low risk) services. Similar debates about liability are going on in the security/spam world now … a world where perhaps we only accept mail from authenticated sources. A federated model might make a lot of sense for email, but I don’t see the same model making sense for distributing government money to people.

We haven’t even got into the whole space of “tokens” yet – whether the ID is assured in a mobile phone, a smart card or whatever, or whether it needs biometric assurance and so on. Those issues are there irrespective of federation or not, but with federation they come into a new space – standards for exchange. Without solid standards that allow the token contents to be passed around, it won’t work. There are many folks out there still signing laws passing the use of digital signatures/certificates. All good stuff, but falling down because of standards and technology incompatibility (as well as horrible user experience).

There are lots of smart people looking at digital identity, e.g. btw.net, here’s Andre Durand (who has a commercial interest in being right), and Mark O’Neil who writes books and more. The hard thing I find is drawing all of these and more together to create a scenario where it will work for government. If anyone has the resource to do it, it’s going to be the US government I guess, but that doesn’t stop it being hard, nor does it make it a cert for success.

The audit folks in the US gave a helpful hint for how they should progress there, “Establish policies for consistency and interoperability among different authentication systems and develop technical standards”. Easy to say, but what to do about it? It does, however, suggest that the federated model in the US will be purely a public sector model initially – meaning that the challenge may be reduced (i.e. no need to figure out how to trust banks or other financial institutions at this stage). But, I’d lay very good money, that persuading government agencies to trust each other will be just as hard. Gotta wish them luck.

Leave a Reply