Got a question? Here you find answers

Demo Overview · Running the Demo · Security and Privacy · Using Identity Mixer · Contact Details · Privacy Policy

Demo Overview

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.

  1. The user requests the desired movie from the Movie Service.
  2. The Movie Service responds with its access policy for this particular movie. For example, the policy may state that it is required to have a valid Movie Service subscription and to be at least twelve years of age according to the eGovernment. This policy is sent via the user's browser to the user's Credential Wallet.
  3. The user is presented with a human-readable form of the access policy and allows the Credential Wallet to proceed by authenticating with its username and password.
  4. Upon successful authentication, the Credential Wallet generates a cryptographic token that merely reveals that the access policy is fulfilled, without revealing any other information than that.
  5. The generated token is sent via the user's browser to the Movie Service.
  6. The Movie Service verifies whether the cryptographic token is valid, and whether it indeed fulfills the access policy that was originally provided to the user. By doing so, the Movie Service does not learn anything except the fact that the policy is fulfilled. In particular, it does not learn the exact date of birth of the user whose ID card was taken as basis for generating the token, except that the user's date of birth is at least twelve years in the past. Also, it does not learn anything about the subscription that was taken as basis for generating the token, except the fact that it is not expired yet (which means it is currently valid). Also, to verify the token, the Movie Service does not have to contact the issuer of the ID card (which is the eGovernment), which means the eGovernment neither learns that the user just used her ID card nor that it was used to watch a movie.
  7. Upon successful verification of the token, the user can watch the requested movie.

Back to Top

Running the Demo

What are the system requirements to run the demo?

All you need, is a web browser with Javascript enabled. There is no software installation of any kind (such as browser plugins or add-ons) necessary. We successfully tested the demo on the most recent versions of Chrome, Safari, Firefox, and Internet Explorer. However, keep in mind that this is just a demo, and not thoroughly tested production code. If you experience problems, please contact us and we will do our best in fixing the issues. In general, the demo also works on mobile devices running Android or iOS, but because of a bug that prevents popup windows from being closed programmatically on iOS v.8.0 - 8.1, the users running these versions of iOS are requested to close the pop-up window manually. This bug, however, was fixed in v.8.1.1 of iOS, so the demo works fine on the latest iOS. Enabling cookies is not necessary, but recommended. Please see our Privacy Policy for more details on the cookies we use.

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).

Back to Top

Security and Privacy

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?

Indeed, Identity Mixer technology alone cannot provide full privacy. You have to take additional measures to prevent your identity from leaking in other ways. For example, if you want to stay completely anonymous, you have to use a freshly created credential wallet account every time you watch a movie, set your browser security settings to refuse cookies and you should use Tor to hide your IP address and 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.

Back to Top

Using Identity Mixer

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.

Back to Top

Contact Details

Who created this demo?

We are a team of cryptography and privacy researchers and software engineers from IBM.

How can I contact you?

You can send us an email. You can also follow us on Twitter.

Back to Top

Privacy Policy

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.

Be aware that because we make use of Google's reCAPTCHA technology to distinguish humans from bots, Google will learn that you used our Identity Mixer demo. We refer to Google's Privacy Policy for more details.

Information Security

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.

Cookies

We currently make use of cookies only for the following two reasons: (1) to establish user sessions in the Credential Wallet so as to prevent users from having to enter their username and password every time they use their wallet account, and (2) to prevent users from having to acknowledge in the Credential Wallet's login popup that they understood the demo's privacy guarantees every time they intent to watch a movie. We do not make use of cookies for any other purpose in the demo.

Back to Top