Privacy (P2ABC)

What it is

This GE allows authentication while preserving much privacy. For example, it is possible to prove to the authenticating party that you have a valid credential without revealing it. Or that the name on the credential is the same as the name on your passport, again without revealing the name on the passport. The GEri consists of three RESTful services:

Why get it

If you run a service that is open only to authenticated users, but where you don't need a user's full identity every time they access your service or your resources, this GE may be for you. If you view the increasing number of break-ins and thefts of customer databases from major retailers with growing unease, this GE may be a profitable part of your strategy to curtail the value of such thefts. If you agree that the only way to prevent the misuse of large databases is not to have the data in the first place, but if you still want to make sure that users of your services are properly authenticated, this GE may be for you.


The goal of the Privacy GE is to support Privacy-Preserving Attribute-Based Credentials (P2ABC). These allow people to prove something about themselves (for example that they are older than 18, or that the name on their concert ticket is the same as the name on their passport), but at the same time revealing only the smallest amount of personally identifying information (in this case their actual date of birth or their names or passport numbers).

P2ABC are realised through multi-round protocols that require exchanging many artifacts and requires logic for crypto. In our architecture, we have three actors, realised by three services:

All services have associated UI services. For the issuer and verifier, these configure the services with data that can or should not be in the deployment descriptors. For the user service, the UI service as written is a very rudimentary GUI that exposes all the functions of the user service. It must be emphasised that it is well possible, by writing a suitable UI service, to hide most of the complexities of the user service from the user so that his or her user experience is very much like using ordinary credentials. In fact, once a credential is obtained, no additional authentication step is technically necessary, so using P2ABC may actually be more pleasant to use than ordinary ones.

It should also be emphasised that an end user is not physically required for an interaction. If it is desired to protect data with privacy-preserving credentials when services are talking to each other without any user interaction, all that is needed is to install the user service alongside the service that requests the resources, and provide the user service with the necessary identity information in its configuration. Of course, then the requesting service will have to talk to the user service using the exposed API, and there would have to be one instance of the user service for every user for which the service requests resources. This is due to the single-tenant nature of the user service.


FIWARE Webpage



Privacy Documentation


Privacy Download

Fiware Academy

Privacy Courses


Click on the images to enlarge them.