What is the demo about?
Using an online movie streaming service as an example, we demonstrate how IBM Identity Mixer allows users to prove facts about themselves — without revealing any personal information. Namely, the users can prove to the movie streaming service that they have the sufficient age and a valid subscription to watch a selected movie in a privacy-preserving manner. In particular, neither the exact date of birth nor any other information from the ID card, nor any information from the subscription is revealed to the movie service. Yet the movie service can rest assured that the user is old enough and that she is a paying customer, and she can therefore watch the movie.
What is the Credential Wallet?
The Credential Wallet is an online service that helps users to manage their credentials and to deploy them in privacy-preserving authentication.
What is the Movie Streaming Service?
The fictional Movie Service is an online video streaming service that uses a subscription-based business model and that applies age restrictions (for example, 12+) for watching movies. For making sure that users indeed have a valid subscription and that they are indeed old enough to watch a particular movie, it employs Identity Mixer technology. By doing so, it does not (need to) collect any sensitive personal data of its users, which means there is no such data to protect. The Movie Service trusts the fictional eGovernment for correctly certifying users' date of birth.
What is the eGovernment?
The eGovernment is a fictional government that certifies users' personal data such as their name and date of birth in the form of identity cards (ID cards). It does so, by using Identity Mixer technology, which allows users to use these ID cards in a highly privacy-preserving manner.
What happens behind the scenes when a user wants to watch a movie?
Assuming that a user has obtained an ID card from the eGovernment and that she owns a valid subscription from the Movie Service, the sequence of actions for watching a movie is depicted in the figure below and described in the following.
What are the system requirements to run the demo?
What happens if I get a credential issued that I already have?
For the sake of simplicity, in the demo we allow users to have at most one credential of each type. In particular, you can have at most one ID card and at most one subscription. When a user requests a new credential, the existing credential of this type will be replaced by a new one. If this was not a demo, however, users would be able to have multiple credentials of the same type.
What should I do if I experience problems with the demo or I find a bug?
We would appreciate if you could give us feedback so that we can fix the issue (the more details, the better of course).
How is this better than OpenID, SAML, Facebook Connect,...?
There are indeed many single sign-on (SSO) solutions out there that let users manage their identities across different websites. All SSO solutions built on traditional cryptography have one downside in common, however: the SSO provider (aka identity provider, OpenID provider, or simply Facebook) is involved every single time you log in to a website. The SSO provider can therefore track your online browsing behavior, because it learns which website you log in to at which time. With Identity Mixer technology, such tracking is simply impossible, because credential issuers (such as the eGovernment) are not involved in the authentication process. Note that, depending on the setup, the Credential Wallet may still be able to track you. For more details, see the next question.
Wait a minute...but can't the online Credential Wallet in the demo track me as well? Can I run the Credential Wallet locally?
To make it as easy as possible for users to experience the benefits of Identity Mixer technology, we consciously chose to host the Credential Wallet in an IBM computing cloud for demo purposes. This way, you only need a web browser to run the demo, but it comes with the same privacy-disadvantages that traditional online identity providers have (see previous question). However, the good news is that the Credential Wallet can actually run anywhere, including on your own home server, or locally on your Mac, PC, or smartphone. In fact, for real-world deployments, we envision the credential wallet to be hosted as an App on your smartphone, which is entirely controlled by yourself. In such a smartphone-based wallet setting, only your smartphone and the service provider are involved in the authentication transaction, and your privacy is optimally preserved.
But if you run the user client locally, then how is it better than standard client certificates?
Client certificates contain the signature of a trusted Certificate Authority (CA) on the user's public key. When authenticating, the user must send his certificate to the service provider and prove that he knows the corresponding private key. The user's public key thereby follows him as a unique identifier, a sort of supercookie, throughout his online transactions. Also, any attributes and identity information included in the certificate must be revealed to the service provider, because he needs it to verify the CA's signature. In contrast, different usages of an Identity Mixer credential are unlinkable, and they only reveal those attributes that were explicitly requested by the service provider.
Does the service provider learn the username I use with the Credential Wallet?
No. This username is only used to log in to the Credential Wallet, so that it can look up you digital credentials (such as your ID card or your subscription). From your digital credentials, the Credential Wallet then generates a cryptographic token, which is then sent (via your browser) to the service provider (see Demo Overview for more details). It is impossible for the service provider to link this token to your previous tokens, and it only reveals those properties (or attributes) whose disclosure you explicitly consented to.
Can't the service provider track me anyway through my IP address, cookies, or browser fingerprints?
What is the trust model here, which entities have to trust each other?
Service providers need to trust credential issuers for certifying only correct data in their issued credentials.
For example, the Movie Service needs to trust the eGovernment for certifying only the correct date of birth in its issued credentials (aka certificates).
However, every service provider explicitly specifies which issuers it trusts for which credential types.
For example, the Movie Service could specify that it trusts government A for ID cards, but not government B.
In our demo, users also need to trust the online Credential Wallet for not misusing their digital credentials. However, as mentioned in a previous question, in real-world deployments, users would host their own credential wallets, and then this trust requirement becomes irrelevant. Instead, in the case of smartphone-based credential wallets, users would have to trust the vendor of their wallet App. By publishing the source code of the App, however, the vendor could prove that he is not misusing the user's credentials.
Why do you use CAPTCHAs from Google? What does Google learn?
We use CAPTCHAs to protect our website from spam and abuse. In particular, we use CAPTCHAs for creating an account with the credential wallet and whenever a credential is about to be issued. Because of this, depending on whether you are automatically logged in to your Google account, Google may learn that you created an account with our wallet and that you filled it with credentials. However, solving CAPTCHAs is not required for watching movies at our movie service, so Google does not learn about your movie streaming behavior.
Won't anonymity lead to abuse?
It is true that absolute and unconditional user anonymity in online authentication transactions may lead to abuse of the used services. Therefore, the Identity Mixer technology offers the option to add accountability to otherwise anonymous transactions, so as to hold misbehaving users accountable for their actions. This is enabled through a feature called verifiable encryption that allows a user to verifiably and selectively encrypt pseudonyms or attribute values from her credentials such that they can only be decrypted by a designated trusted third party under previously well defined conditions. Note, however, that this feature is not part of the demo.
How can I use Identity Mixer technology as an end-user?
First of all, there needs to be a service provider who supports the Identity Mixer technology and accepts Identity Mixer credentials (such as the ID cards or subscriptions in the demo) from trusted issuers. Additionally, you need access to a credential wallet. Because the online Credential Wallet that is used in the demo has certain downsides in terms of privacy protection, we are currently working on a smartphone-based solution that is both secure and optimally protects your privacy. If you would like to learn more about online credential wallets or smartphone-based wallets, please contact us.
I am a service provider (such as the Movie Service) or an issuer (such as the eGovernment). How can I make use of Identity Mixer technology?
You can download the source code of all the back-end services that we use in the demo from our Github repository free of charge and integrate Identity Mixer technology into your infrastructure manually. Because it is rather time consuming to do so, we are currently working on a solution that allows you to use the IBM Bluemix cloud platform for deploying the Identity Mixer technology much more easily - we expect it to be available in spring 2015. If you would like to learn more about the Github way or the Bluemix way, please contact us.
What sort of extra capabilities will users get from Bluemix they can't get from the Github code? Is it free on Github and you will pay for it on Bluemix?
Plug n play, ease of use. Using Bluemix users will be presented with a simple dashboard which they can customised based on the needs. For example, if they want to require date of birth and nationality they simply choose this from a pull down menu and the Identity Mixer code is generated. When using the code available for free from GitHub, the setup and integration into an application this needs to be programmed manually by a crypto-savy developer.
Who do we expect to use Identity Mixer in the Bluemix Cloud? Who is our target audience? Do we expect individuals to download it as well?
Identity Mixer BlueMix is an experimental web service for web service developers and app designers. It’s available for them to add to their services and apps to offer users more privacy protection, while also relieving themselves of storing and protecting the personal data of users. End users can use our hosted wallet (on bluemix) or download the client code from github and run the wallet themselves. Eventually a mobile app will be available for users for manage their credentials in an electronic wallet.
Would IBM own the credentials which contain the personal information or would it be a government agency?
The credentials are owned by the users themselves just as it is the case with traditional credentials such as driver licences, credit cards, or identity cards. We envision that users store their credentials on their mobile phones in the future. However, users could also host their credentials in their own cloud or any cloud for that matter, such as IBM BlueMix. For the demo, we chose the latter so that users can test the technology without installing of any software.
What about a mobile app?
Yes, we should have something by the end of 2015 which can be used as the credential wallet, but currently modern smartphone browsers can also support the wallet.
What is the status of Identity Mixer anyway?
Identity Mixer is based on the Camenisch-Lysyanskaya credential system published in 2001 and a number of other cryptographic protocols which all have been proved secure and published at the top scientific conferences in the area of cryptography. The first prototype of Identity Mixer was implemented in 2004 and has evolved and improved substantially since then. It has been trialled and piloted in a number of EU projects and also other research groups have built their own prototypes and pilots with Identity Mixer. The latest pilots were conducted in the ABC4Trust project where Greek students and Swedish pupils were given Identity Mixer smart cards with which they could anonymously authenticate to online resources.
Who created this demo?
We are a team of cryptography and privacy researchers and software engineers from IBM.
How can I contact you?
The Identity Mixer Demo, consisting of the technology overview page, the Credential Wallet, the eGovernment, and the Movie Service, is solely intended to exhibit the privacy-preserving functionality of Identity Mixer technology. With this goal in mind, we apply the IBM Online Privacy Statement as a basis, and augment it as stated in the following.
Collection of Personal Information
Whenever it is necessary to enter data into input fields (for example, to issue an ID card in the eGovernment), we explicitly ask users not to use their actual personal information such as their real name or date of birth. To facilitate this, we pre-fill input fields presented to users with example data whenever possible.
For manually creating accounts at the Credential Wallet, we strongly advise users not to use usernames or passwords that are used as authentication information with other parties.