In this rather long post, I'd like to discuss the practical difficulty of securely collecting and combining attributes from different contexts when one starts using a system based on attribute based credentials. How do you determine that two separate contexts really belong to the same person? How do you ensure that a few people colluding cannot create a supercredential combining their individual attributes.
Conceptually, your identity is a set of attributes describing certain properties about yourself. This set is dynamic, and depends on the context in which you are known. Being a husband, friend, colleague, etc. means different things to different people. So instead of having one identity you have many partial identities, that may not and often should not be linked.
Attribute based credentials are used to implement this concept in the digital world. They store attributes about a person, without fully identifying that person. Moreover, they can be used many times by the same person without being linkable (either to that person, which is sometimes called untraceability, or among the different uses themselves). Attribute based credentials are a perfect means to achieve the necessary context separation required in privacy friendly identity management. They allow a person to be anonymous.
Certain attributes of a person belong together within one context. In this case, they may be stored together in a single credential (issued by one credential issuer). Sometimes attributes that belong together are stored in different credentials, however. In that case, their relationship is represented by the fact that the private key used to prove ownership of both credentials is the same.
This relationship among credentials (and their attributes) is important. Although it is up to the user to decide whether to show a certain subset of his attributes, the relying party needs to be sure that the set of attributes revealed in fact correspond to one and the same person. For example, the sale of soft drugs in the Netherlands is going to be restricted to Dutch citizens that are over 18 years old. It should not be possible for a French adult and a Dutch minor to obtain soft drugs.
Ideally, the architecture of the credential system should guarantee this property as an invariant: if a set of attributes are shown to belong together, then they all describe the same person. The question is: can this be guaranteed, and how?
It is helpful to discuss what could go wrong. Consider a system of attribute based credentials based on smart cards. Each smart card belongs to a single individual. All credentials belonging to the owner are stored securely on the card. A credential containing the identity of the owner may be stored on the card as well. Now suppose that I can add a credential to my card by first authenticating to a credential issuer using for example an existing username password, after which the issuer uploads the credential to the card securely. If such procedure is allowed, I could also sign in first and then present someone else's card to store the issued credential on. Now my credential is connected to the credentials already present on that card.
To prevent this from happening, the act of authenticating to the credential issuer should be done with credentials already present on the card. The aforementioned identity credential could be used for this, for example. In other words, the authentication procedure should be bound to the card to which the credentials are going to be issued.
But the issue is more subtle that this. I already mentioned people have many partial identities, that are not necessarily connected, and often should not be linkable. If the credentials associated with each of these identities are all stored on a single card, the card needs to separate these identities internally.
This can be done by associating a different private key with each partial identity. But then the solution above for binding the authentication to the card needs to be refined. In fact, instead of binding the authentication to the card, the authentication needs to be bound to a particular private key on the smart card, and the credential should be issued to this particular private key. This way all credentials bound to a single private key are in fact connected and belong to one and the same person.
The procedure outlined above appears to be secure, but has a severe limitation. Existing on-line accounts or existing information about your partial identity cannot easily be linked to your smart card. According to the procedure above, this can only be done if this information can somehow be related to credentials already stored on the card. This is often not the case.
We somehow need to be allow the inclusion of already existing user profiles, like your social network account, or your Amazon.com account, etc. One way to do this is by creating a new context with a separate private key for each external profile that cannot be linked to an existing context managed by the smart card. So your Facebook account becomes a separate context.
New, empty, accounts can of course be done associated with any context a user likes. When signing up, the account credential can be linked to the private key corresponding to that particular context.
But this is a bit strange. If I already have a Facebook account, I cannot link it to one of my contexts on my card. But if I create a new Facebook account (that does not contain any information), I can bind it to whatever context I like, and then start to fill my Facebook account with arbitrary data (for example, the data I already have stored in an existing account that I could not link to this context). This appears to be caused by the fact that Facebook is in a way a very unreliable credential issuer (it is basically me saying whatever I like about myself). It is however unclear yet how this all plays out with other existing online services, when connecting them to attribute based credentials stored on smart cards.
More discussion on these and related topics is certainly necessary, and I would welcome your contribution in the comment section below.
[…] it is feasible to provide privacy friendly identity management, for example by using attribute based credentials (ABCs). We are currently demonstrating their applicability in practice, even on smart cards, in the IRMA […]