Caspar Bowden, Chief Privacy Advisor of Microsoft was giving an introduction of U-Prove, a technology they recently bought from dutch cryptographer Dr Stefan Brands who now works with Kim Cameron. He explains how it fits into Microsoft’s identity strategy and how it fits into Cardspace.
What are the laws of identity?
These are more principles than laws. If you break one, bad things might happen to your system.
- User control and consent
- Minimal disclosure for a defined use
- Justifiable parties
- Directional identity
- Pluralism of operators and technologies
- Human integration
- Consistent experience across contexts
He mentioned some points like point 5, where it’s unlikely that you will have at some point a global unique identity system. You cannot really designa universally applicable identity system. They instead talk about a metasystem, a system of systems. You provide ways to exchange information between those systems but this exchange needs to be done by the user.
The Metasystem Architecture
The basic idea is to create some sort of identity bus which connects all those systems together. This layer e.g. translates information between those systems.
The user interface for this bus is the Identity Selector. There the user can choose which persona they want to use for a particular use.
Self-issued vs. Managed Cards (CardSpace)
He explained a bit what information cards are and that Cardspace is the Microsoft implementation of it. He also mentioned CardSpace 2.0 but couldn’t give any information on it ;-)
The basic idea of information cards is that you have a client program which holds information cards. You can store as many cards about yourself as you wish. These are the self-issues cards. These cards can then be given to sites which want to get information about you.
The goal is to provide an alternative to username/accounts by using PKI inside those cards. That way by giving a card the website knows that you are the user you claim to be and you know that the website is what it’s supposed to be and not e.g. a phishing site. If it does not match you get a big red warning message.
Managed Cards OTOH are issued by e.g. banks, stores, governments etc. These cards can be used in auditing or non-auditing mode.
The detailed process is like followed:
- Client would like to access a ressource
- RP provides identity requirements: format, claims & issuer of security token
- Client shows which if known IPs can satisfy requirements
- User selects an IP
- Request to choosen IP for security token
- IP generates secrity token based on RP’s reqs
- Token is released to RP. RP reads claims and allows access
The problem is an intense communication with your identity provider when you choose that it creates a separate token for every set of claims.
1.0: centralized like Passport (problem: one party is too powerful)
2.0: SAML or OpenID like (central parties are all-powerful, problem: Phishing)
3.0: smart client-side crypto. Multi-party security and privacy
Example of a problem: If you need to know whether I am over 18, you don’t really need to know my exact age. This can be done with CardSpace but the penalty is that much communication with the IdentityProvider.
Stefan Brauns was working on this problem and developed techniques to solve these problems. The goal here is to provide minimal disclosure tokens (to fulfil law #2).
Minimal disclosure tokens
Usually you can put as many attributes into a token as you want. You also need to sign those tokens but the problem is that a RP sees then all those attributes. What you want is though to only show those needed for the RP.
Moreover those attributes can get out of date and you have to renew those regularly.
What would be great would be a way to „grey out“ (cryptographically) certain attributes for a particular RP in a way they cannot retrieve them in anyway. This is what U-Prove can do.
For instance an institution knows your name, your birthdate, your loyalty card status etc.
Another Identity Provider knows where you live.
Now if an RP wants to know if you are from WA and that you are over 21. This can be done by cryptographically blinding the fields not needed and you can also put in a cryptographically prove that this person is over 21.
The good thing here is that you can put quite a lot of attributes into a token which you then can blind out as you need it. That means that you are more independant of an Identity Provider which is actually a good thing given all those laws around data retention. The drawback is still though that those attributes might become out of date and the more you put in the earlier this will happen.
In this case you want to authenticate somebody without revealing their identity. You can do this by asking the identity provider if you are a gold card customer and the IP can prove it without giving out your name etc.
Unlinkable data sharing
This technology can also be used to share data but without linking data sets together.
Privacy Friendly Revocation
This is a very new technique. Imagine Alice Smith with an address and a gold customer status.
You have a sitaution where an IP gives out such credentials. Now if you want to revoke those credentials you have to go to every RP and tell them to delete it. This is not very privacy friendly though because you have to go to an RP but the RP does not really know much about you. So that way you could also damage people’s reputation.
This techniques now can help here. The RP will then not know which person’s credentials have been revoked.
So you revoke a credential and the RP will not accept it anymore (I didn’t understand how this works though but that’s maybe true for most of the underlying technology ;) ).
Integration into Windows
The described techniques will be integrated into Windows CardSpace and into the Windows Communication Foundation in .NET.
One problem here is though that these techniques are patented and it looks like patents more hinder innovation. Hence making things open is hard. They are working on it though to spread adoption.
For Open Source it was mentioned though to look into the Higgins Project.
Disclaimer: I am not security/identity/privacy expert so there are errors in here quite likely. If you encounter one pleas e add a comment and I will correct it!