Financial Cryptography

Identity on the move I - Stefan Brands on user-centric identity management

Stefan Brands has moved over to the podcasting world, with an interview on user-centric identity management. Here's my notes from listening (my comments injected in parenthesies, my errors everywhere):

Stefan relates cash payments as ways to transfer information, Hayekian style, for user-centric transactions. This time, instead of doing an application like digital cash, he is concentrating on an engine to wrap the data for user-controlled privacy.

Consider the large-scale distributed system of medical data management. Specialists across domain boundaries have only their own information on you. How do we allow the doctor to get access to the information in other domains? (Here's a canonical example were we assume a priori that such access is a good thing.)

Classically, would we put it all in a central database and shove some access control on it? This we don't do, because the access control doesn't work well enough - hackers and insiders get widespread access. This was the Passport approach.

The second approach is the federated identity management approach of Liberty Alliance. Here, we hook up all the silos of data together through a centralised party - could be a hospital. The doctor contacts the centralised party and asks for access to the info on the patient. What it gets is the access keys, and can then get the data it needs from the various sources.

The ability to move the data has to be facilitated by a central party - which means the party now knows what you are up to. (Insurance of course wants to know who is visiting which doctor...) It's similar to the credit card model with users, merchants and VISA in the middle. The centre might not know what you are "purchasing" but it does see the amount and the merchant. Does this give the user payment privacy? No, not like cash.

My Doctor typically knows me, and a merchant might as well - but should there be a central party that also knows me? The central party would also know all the clients of a doctor - breaching the patient-doctor autonomy, something that doctors in Quebec rejected when the provice tried to roll out a PKI.

There are economy, privacy and security rights, and they are all interlinked. You think you are disclosing just the pertinent information for the local decision, but this can easily jump to a wider scope. When competitive intelligence comes into play, lots of parties want to know all of these details. Governments are included on both sides, where for example different provinces or states are paranoid about handing their data over to centralised federal parties as this will result in loss of autonomy in dealing with own citizens.

A centralised approach also cannot cope with dynamic queries, it has no flexibility.

The engine of Credentica is the third approach. Model 3 is a crediential system in its purest form, and is closer to how people and society functioned before the computer age. When the relying party wants richer information, the user is asked for the information. The relying party - the doctor - just wants to get the data, and it wants it from a source that it trusts. What it does not care about is how it gets there.

We can put together a device - already available - that holds credentials. Instead of saying, here is my identity, and expecting a centralised party or silo to deal with it, the user provides the credentials and gets the data herself. The user carries a token - in effect a key of some form - that allows the patient and doctor together to get the data.

The default scenario is a user with a smart card or PDA holding her credentials. It can hold the data itself - as a copy of the data held at a service provider. This data can also be accessed directly from the service provider by the user.

A relying party such as principle doctor relies directly on the user. But now the question is, can the user be trusted with the integrity of the information, such as with prescriptions. In this case, the relying party has to go to the source of that prescription, and the user now becomes the person in the middle.

Simple digital signatures aren't good enough, as this information is private and substitutable. How do we stop the user substituting in a prescription? The same applies to credit and employment questions. How does the asker know the information really applies to Alice the users?

Which brings us to the crypto engine Credentica has developed. It allows the source to take data, make assertations, and package that data for the user's token. Some sort of smart card or USB token is needed, but that is implementation details.

Depending on the threat model, the protection is variable (???). Account information for example could be wrapped by the security engine. The relying party could contact the source to verify the information.

Now, what we want to do is give the user the same capability to answer the same questions that the source knows authoritively. Yet, relying party does not trust the user as much as the source. On this "cryptographically certified data" the engine can answer questions like "are you over 18?" We can do this by revealing the birthdate, as certified by some provider, but this reveals more information than needed.

The engine allows that question to be asked and answered - are you over 18? The statement returned is self-certifying, it can reveal its own identity.

Correlation is still an issue over handles. Imagine a question of male versus female. Normally, Alice reveals she is female, but she is also generally revealing data that is matchable to other events. If every piece of data is doled out with these identifiers, this has terrible privacy implications. (At this point the interview was running out of time, so we did not hear how the engine deals with correlation and identifier matching.)

What are the business opportunities? Health data is a big area, and European and Canadian agencies are pushing more and more towards rejecting the panopticon approach. Credentica would likely partner with others in such a complicated supply chain; the engine is literally a component in the vehicle.

Interview. Stefan's blog.

Posted by iang at February 27, 2006 12:56 PM | TrackBack