Ask the experts

We all use electronic services increasingly often in our daily lives. To do so, we have no choice but to provide a range of personal information for authorization and billing purposes, or as part of the terms and conditions of service providers.

Dispensing all this personal data erodes our privacy and puts us at risk that criminals could abuse this information.

The Internet is like the lu­nar sur­face—it nev­er for­gets a foot­print. With Iden­ti­ty Mix­er, we can turn it into a san­dy beach that reg­u­lar­ly wash­es every­thing away.

—Jan Camenisch, Cryptographer and Co-Inventor of Identity Mixer

IBM Identity Mixer is a cryptographic protocol suite for privacy-preserving authentication and transfer of certified attributes. It allows user authentication without divulging any personal data. Thus, no personal data is collected that needs to be protected, managed, and treated according to complex legal regulations. Nevertheless, service providers can rest assured that their access restrictions are fully satisfied.

Identity Mixer allows users to minimize the personal data they have to reveal in such transactions. For instance, if electronic identity (eID) cards were realized with Identity Mixer, then teenagers possessing such eID cards could log onto a teenage chat room just proving that they are indeed 12–15 years of age without revealing any other information stored on the card such as their name or address.

When Identity Mixer was first developed, IBM scientists made it available in Github, where it remains today. However, it can be quite cumbersome to use, even for more experienced developers.

If your per­son­al data is nev­er col­lect­ed, it can­not be sto­len.

—Maria Dubovitskaya, Cryptographer

But in the meantime, IBM scientists have changed this by making Identity Mixer available in the IBM Bluemix cloud. Developers can now simply copy and paste the code into their apps to become privacy-friendly in minutes.

In addition, we will have a mobile app, similar to the iOS wallet, available soon to help users manage all of their keys.

Jan Camenisch

Jan Camenisch

IBM Research scientist

Maria Dubovitskaya

Maria Dubovitskaya

IBM Research scientist



What it does & how it works

IBM Identity Mixer is a cryptographic protocol suite for privacy-preserving authentication and transfer of certified attributes.

What it does

IBM Identity Mixer is a cryptographic protocol suite for privacy-preserving authentication and transfer of certified attributes.

To understand what Identity Mixer does, it helps to take a closer look at traditional identity management solutions. Roughly, they can be divided in two categories. The first category requires an online issuer (sometimes also known as identity provider) that is actively involved each time the user authenticates to a verifier (also known as relying party).

The issuer can certify only those attributes that the verifier explicitly requires, which is good for privacy, but the issuer becomes a privacy bottleneck in the system that can track all its users’ transactions. Examples of solutions following this approach include OpenID, Facebook Connect, and the Security Assertion Markup Language (SAML).

Identity mixer authentication step 1

The second category are solutions where, in a preceding step, the user obtains from the issuer a credential from which she can later derive, without further help from the issuer, the tokens required to authenticate to verifiers. While avoiding the above problem of an omniscient issuer, the drawback is that, using classical cryptography, users can be tracked across different verifiers through their public keys and/or certificates, and that usually the user must reveal her full identity with all of her attributes at each authentication. Example technologies in this category include X.509 client certificates as well as some existing government eID solutions.

Identity Mixer authentication process

Identity Mixer is a superior solution that offers the best of both worlds: Issuers do not have to be involved during authentication, but at the same time, users can selectively disclose only those attributes that are required by the verifier and can do so without being linkable across their transactions.

Identity Mixer authentication process

How it works

Identity Mixer works in a similar way as client certificates in a classical public-key infrastructure (PKI), but with two important differences:

  • Flexible public keys: Rather than being bound to a single public key, users can have many independent public keys, called pseudonyms, for the same secret key, so that they can use a different pseudonym for each verifier or even for each session.
  • Flexible credentials: The credentials that certify the user's attributes can be transformed into valid tokens for any of the user's pseudonyms that contain only a subset of the attributes in the original credential. The transformed token remains verifiable under the issuer's public verification key.

Classical digital signatures cannot provide this sort of flexibility. Identity Mixer relies on the Camenisch–Lysyanskaya (CL) signature scheme that is specifically designed to have efficient zero-knowledge proofs, which are cryptographic mechanisms to prove that one knows a valid signature with certain properties, without having to reveal the signature itself.

A credential in Identity Mixer is a CL signature by the issuer on the user's secret key and on the attribute values. To transform a credential into a presentation token, the user creates a zero-knowledge proof showing that he knows a valid CL signature on the disclosed attribute values and on the same user secret that also underlies his pseudonym.

To create an inspectable token, the user encrypts an identifying credential attribute under the public key of the inspector, so that only the inspector can decrypt it. Of course, this is not a standard encryption scheme, because otherwise a cheating user could easily circumvent it by encrypting gibberish or encrypting someone else's identity. Rather, Identity Mixer uses  verifiable encryption, which allows the user to prove that the encrypted attribute value is the same as in his certified credential, without revealing the value. The verifier can check this proof and thereby be convinced that inspection will point to the correct user if he ever needs to inspect the token.

Revocation of Privacy-ABCs can be performed in several ways. The easiest is to avoid revocation altogether by issuing short-lived credentials that the user must refresh on a regular basis. While easy to implement, this approach has the disadvantage that it involves the issuer more often, which we actually wanted to avoid.

Another approach is to use dynamic accumulators. These are essentially special cryptographic hash functions so that the issuer, or a dedicated revocation authority, can publish the hash of the serial numbers (called revocation handles in Privacy-ABCs) of all valid or revoked credentials, depending whether a white-list or black-list approach is taken. The user must then prove in zero knowledge that the revocation handle of his credential is (or is not) included in the published hash.

A third revocation technique is by means of set membership proofs. Here, the issuer signs the intervals that are bounded by the revoked revocation handles. The user proves that his revocation handle is strictly within one of those intervals.


Extended features

Identity Mixer is a full-fledged privacy-preserving attribute-based credential (Privacy-ABC) system that offers many features beyond data-minimizing authentication.

Extended features

Identity Mixer is a full-fledged privacy-preserving attribute-based credential (Privacy-ABC) system that offers many features beyond data-minimizing authentication. We summarize the most important features below; a more extensive overview can be found in the documentation.

  • Attribute predicates: Rather than revealing the full value of an attribute, the derived token can merely show that the attribute is within a certain range. For example, if the attribute encodes the user’s birth date, then the token can show that the user is over eighteen, without disclosing the exact birth date.
  • Multi-credential tokens: A single token can disclose information from multiple credentials at the same time. Beyond revealing attributes from those credentials, it can show that different attributes have the same value, without disclosing the exact value, or it can provide guarantees that all credentials were issued to the same user.
  • Revocation: When attribute values change, or when a credential has been compromised, the credential can be revoked so that it can no longer be used to create tokens. Note that revocation is slightly more complicated than in a traditional PKI, because Privacy-ABC tokens do not reveal a unique credential identifier such as a serial number. Rather, the token shows that the underlying credential has not been revoked, without revealing its identifier.
  • Inspection: In some situations, absolute anonymity can lead to abuses for which nobody can be held accountable. In such cases, it can be useful to introduce a separate trusted entity called an inspector who can lift the anonymity of tokens if needed. At the moment that a token is created, the user is informed of who the inspector is, which information the inspector can recover, and under which circumstances the token will be inspected. The verifier cannot inspect tokens by himself. Tokens remain anonymous to the verifier until he can convince the inspector that the agreed-upon circumstances have been met.
  • Scope-exclusive pseudonyms: Some applications, for example online opinion polls, do not require users to be identifiable, but do need to make sure that each user can create only a single account, or can use the service only once. Scope-exclusive pseudonyms are a special kind of pseudonyms that are uniquely determined by the user’s secret key and a given scope, e.g., the URL of the service. Pseudonyms for different scopes remain unlinkable.
  • Advanced issuance: It is possible to issue credentials on attribute values that remain hidden from the issuer. These attributes can be chosen freely by the user, can be assigned a random value that the user cannot control, or can be carried over from existing credentials. In the latter case, the user shows during issuance that he possesses a valid credential, possibly from a different issuer, that includes the same attribute value as will be embedded in the new credential, but without revealing that value to the issuer.

IBM Research announces breakthrough in protecting personal data using the Cloud

On Data Privacy Day 2015, IBM announced an innovative cloud-based technology for developers to help consumers better protect their personal data online such as their date of birth, home address and credit card numbers. As cybersecurity threats and identity theft continue to threaten both consumers and businesses, IBM scientists have been developing a clever cryptographic algorithm which enables transactions to occur without unwillingly sharing any personal data.


Demo: Teenage chat scenario

This demo offers a safe chat environment for minors where they can interact anonymously without the danger of being exposed to overage predators. The users’ credentials are stored and managed in a browser plugin installed on the local machine. The demo features the issuance of new credentials, the selection of credentials to be presented, and the presentation itself. The presentation policies can be modified to see the effect on the presentation.

The demo is not available for download, unfortunately, but you can watch a screencast on the link below.

Download screencast [avi | 9.75 MB]


This series of screenshots shows the scenario of a teenager authenticating to a teenage chat room as in the screencast above.

Kids' Chat screenshot 1

Kids' Chat screenshot 2

Kids' Chat screenshot 3

Kids' Chat screenshot 4

Kids' Chat screenshot 5

Kids' Chat screenshot 6

Kids' Chat screenshot 7

Kids' Chat screenshot 8

Kids' Chat screenshot 9

Demo: Movie streaming service

This demo shows how Identity Mixer can be used to check subscription credentials and enforce age restrictions for a movie streaming service. The demo lets you create a personal credential wallet, obtain a subscription credential from the movie service and an age credential from a virtual government, and then to use these to stream a movie of your choice.

All entities in this demo, including the user agent, run “in the cloud” on the IBM Bluemix platform. This allows the demo to be run conveniently from any web browser, without the need to install any software.

In an actual deployment, managing the users’ credentials in the cloud can make sense to ease portability across multiple user devices. Users must have the freedom, however, to select a cloud host that they trust to properly protect their credentials and to not spy on their transactions. Managing Privacy-ABCs in the cloud still offers advantages compared to a traditional online identity provider, as the cloud host does not need to be trusted by the verifier.

This demo shows a movie streaming service that uses Identity Mixer to ensure that viewers have the appropriate age to watch the selected material. Users can obtain a movie streaming subscription from a movie streaming service and an identity card from an eGovernment and store both credentials in a personal credential wallet. Later, using their credential wallet, users prove in a privacy-preserving manner to the movie streaming service that they are entitled to watch the selected content.


An open-source reference implementation of IBM Identity Mixer is freely available for commercial and non-commercial use. The Privacy-ABC Engine language framework acts as an abstraction layer on top of the cryptographic routines of IBM Identity Mixer and Microsoft U-Prove, allowing application developers to use the technology without needing to understand the cryptographic details. It is available from GitHub under an Apache 2.0 license. The core cryptographic routines are published separately under a proprietary license that allows commercial as well as non-commercial use.

Instructions on how to build the ABCE development environment are available on Github, as well as documentation on how to integrate Privacy-ABCs in existing applications using helper classes that encapsulate the most common operations for each of the entities.

We suggest that you first read the high-level concepts and features of Privacy-ABCs to get a better understanding of what the technology is capable of. To integrate the open-source implementation into your own projects, read the fully-documented programming interfaces (APIs) and XML protocol specifications to that you can create your own policies. For more information on the inner workings of the Privacy-ABC Engine, please refer to the architecture documentation and the description of the cryptographic architecture.

Download presentation "IBM Identity Mixer Authentication without Identification"

EU projects

IBM Identity Mixer was tested, piloted, improved, and considerably extended throughout our participation in a number of European research consortia.

We have enjoyed and continue to enjoy working with many different partners from many different disciplines in all these projects.

Thanks a lot to all of you!

AU2EU logo


Authentication and Authorisation for Entrusted Unions

FutureID logo

Future ID

Shaping the Future of Electronic Identity

ABC4Trust logo


Attribute-based Credentials for Trust

FI-WARE  logo


Future Internet Ware

PrimeLife  logo


Pervasive and Trusted Network and Infrastructure

Prime logo


Privacy and Identity Management for Europe


Meet the Identity Mixer team


Identity Mixer team

We have also had the pleasure to work with many previous team members:

Björn Assmann
Endre Bangerter
Patrik Bichsel
Carl Binding
Marco Bove

Victor Shoup
Els Van Herreweghen
Greg Zaverucha
Roger Zimmermann


Overview articles

Applications of Identity Mixer

Technical foundations of Identity Mixer

Note: Not all of the following have been implemented in the code that can be downloaded.