[fc-discuss] Financial Cryptography Update: Identity on the move I - Stefan Brands on user-centric identity management

[iang@iang.org]

 Financial Cryptography Update: Identity on the move I - Stefan Brands on user-centric identity management 

                           February 27, 2006


------------------------------------------------------------------------

https://www.financialcryptography.com/mt/archives/000665.html



------------------------------------------------------------------------

_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):_

http://www.connectedtosource.net/thestoryofdigitalidentity/2006/2/15/th
estoryofdigitalidentity.html

http://www.idcorner.org/?p=138

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.

http://www.connectedtosource.net/thestoryofdigitalidentity/2006/2/15/th
estoryofdigitalidentity.html

http://www.idcorner.org/?p=138


-- 
Powered by Movable Type
Version 2.64
http://www.movabletype.org/