IRMA versus Frau Mustermann, take 2: the advantages of attribute based credentials over a more centralised approach.

In a previous blog post I discussed the difference in security and flexibility between attribute based credentials (used in our IRMA project) and the German eID system. Now I will discuss the additional privacy protection offered by attributed based credentials, compared to a more centralised approach where attributes are stored on one or more central servers.

The centralised approach is necessary if one wants to support additional attributes that the card (like the German eID card) does not support. In this approach, the smart card merely functions as a secure authentication token for the central attribute server, to unlock the user attributes that are stored there. The centralised approach corresponds to the traditional, network-based, systems for identity management, like OpenID, Liberty, and Shibboleth. We have discussed the security, privacy and usability problems of such systems extensively elsewhere.

In general, a smart card containing the attributes themselves can be used in off-line scenarios (like vending machines, access to remote locations, or access to off-line machines, devices and installations), whereas the centralised approach can only be used on-line. But we focus on the privacy aspects here. The main privacy problem with network-based identity management is that the attribute provider sees all services a user does business with. The user may not be known by name, but only through a pseudonym (using the restricted identification feature of the German eID for instance). But even in this case a pseudonymous user profile can be collected.

For several use cases the privacy protection offered by using attribute based credentials (ABCs) is significant. Let's make this explicit by considering a few examples.

• Online sale of event tickets. The ticket is uploaded to the smart card as an attribute, that is later shown at the entrance gate of the event. If the payment method does not reveal the identity of the buyer, the online seller cannot compile a profile of all the tickets a particular person bought. In a centralised approach, the online seller is the attribute provider, where the online tickets are stored in the account of the user until they are redeemed at the entrance gate of the event.
• Voting. An attribute encodes the right to vote. In a centralised approach this will allow the attribute provider to record all people that actually voted (but of course not what they voted). In this case, one-shot uses of restricted identification do help to protect privacy, as the central server only has a list of pseudonyms that are allowed to vote. The question does remain however how the server obtains this list, as the pseudonyms can only be generated by the card (and if not, the privacy protection is broken)...
• Delegation. An attribute can encode the fact that someone delegated some rights to me, for example to collect a medicine, or to act financially. Central registration of these delegated rights reveal two things: the fact that I am related to the person delegating, and the fact that some rights are delegated. These rights (if they are for instance health related) can be sensitive personal information.
• Subscriptions and other long-term entitlements. An attribute can encode these rights, like ownership of a public transport passes. In the ABC approach, no travel patterns can be compiled, whereas this is clearly possible in the centralised approach.

To be fair, the centralised approach also has few advantages. For example, the centralised approach allows one to revoke an attribute immediately, without the need of maintaining and verifying revocation list, or having short-lived attributes. But restricting the card to contain only a fixed set of attributes appears to be rather limited in terms of privacy protection.