Attribute based credentials (ABCs) allow users to prove properties about themselves without disclosing any additional information, and without being traceable. ABCs therefore implement privacy friendly identity management. Within the IRMA project of the Privacy & Identity Lab we are busy making ABCs practical by implementing them on a smart card. This allows them to be used, for instance, in national electronic identity card schemes. We are currently studying how to implement some recent ideas on how to improve ABCs in terms of functionality, securty and privacy.
So far we have not paid much attention to issuers.
Issuers may be liable for the use of the information in the credentials they issue. Therefore they may want to restrict which relying parties are allowed to use their credentials, and for what purpose. A simple directory of all issuer public keys maintained by the scheme authority clearly does not suffice.
How do you deal with organisational changes at the issuer? Issuers may change their name, or several issuers may merge into a single, larger organisation. It is also possible that an organisations splits, with one part issuing some credentials, and the other issuing some other credentials. How do the users and the relying parties that depend on the credentials issued by this issuer learn from this change? What do you do with previously issued credentials still carried by users?
The trustworthiness of the overall system highly depends on the quality of the credentials issued by the issuer. Currently, there is nothing preventing relying parties to accept credentials from arbitrary issuers, even if they are not in the central issuer public key repository maintained by the scheme authority. How do you prevent rogue issuers, i.e. issuers that join the system under a name that looks like an important one (e.g. a health insurer) and that the start issuing credentials that are accepted by careless doctors.
The current IRMA implementation requires relying parties to know about each and every issuer from which they accept a credential. This quickly becomes unmanageable. Suppose doctors issue prescriptions as credentials to patients. Then whenever a new doctor sets up practice, all pharmacies need to know about this doctors issuing key. Is there a way to add a level of indirection such that some relevant and competent authority keeps a database of current doctors, such that
What risks does a hierarchy like this introduce?
IRMA relies on so called relying-party certificates to enforce an access control policy on the attributes stored on an IRMA card. Relying parties can only access the attributes permitted by the relying party certificate issued to them by the scheme authority. What if several relying parties pool their certificates and try to get more attributes than they are each entitled to on their own? For example by querying the card several times as if there is a new session every time. The only thing that prevents this currently is the user paying attention.
This system of relying arty certificates is very paternalistic. There is no room for the users to make their own decisions. Moreover, it heavily relies on the fact that the scheme authority (issuing these credentials) is trusted. It would be good to also allow users themselves to add policies on cards restricting access to attributes automatically. One could define classes of relying parties that the card can recognise, and allow users to tell their cards never to release a certain attribute to a certain class. E.g. never release your name to a "shop". I like this idea, because it adds another layer of defence. And users need not define these policies all by themselves. Any organisation (consumer organisations, civil liberties groups) can provide sample policies that users can upload to their card directly, or first tweak a bit.
What do you do when the something big (e.g. crypto) breaks, i.e. how do you inform people and how do you migrate?
Which components need to be trusted, and with what. If some of these components are compromised, how easy is it to recover from that (i.e. let other components take over). In other words, think about trust agility (similar to how to overcome compromises in the web CA hierarchy) and how ideas from Convergence or certificate pinning can be applied in this context.
It would be good if users could choose and even build their own smart card using the open source hardware and software available. Currently this is not (really) possible because the smart card also enforces certain security policies to protect against a malicious user (to prevent copying or pooling of credentials). How to make this possible (i.e. enforce these security properties in another way)
In the current IRMA design the scheme authority is trusted for way too much. Can we make it publicly auditable? For example can we really make sure that all RP certificates (with attribute access permissions) it issues need to be put on a public bullitin board so that everyone can keep the scheme authority in check? (It seems the scheme authority can always issue certs 'on the side'). Can we distribute the scheme authority over several independent organisations, and monitor it's behaviour?
Most of the ideas discussed above are not limited to IRMA but apply to Attribute Based Credentials in general (like Idemix, uProve, and their implementation in projects like ABC4TRUST). For related musings on ABCs, see here.
(These ideas were born out of discussions with many people. In particular I would like to thank the people attending the TA3M meeting at the Rietveld Academy Amsterdam on May 19, 2014.)