I Reveal My Attributes

by Bart Jacobs

This page explains the basic ideas, notions, scenarios and architecture for the IRMA project. It covers the following topics.

IRMA_card1. What is IRMA about?
2. Why using attributes instead of identities?
3. How do I obtain and use attributes?
4. What is under the hood of IRMA?
5. Why are smart cards used for IRMA?
6. What is the architecture behind IRMA?
7. Who organises and runs IRMA?
8. Can I participate or contribute?

1. What is IRMA about?

When you buy a bottle of whiskey you need to prove that you are over 18 (or 21) years of age. You don’t need to reveal who you are. Just this personal property, or attribute, of being “over 18” is enough to authorise the transaction.

IRMA is the name of a project for doing just this: revealing selected attributes about yourself in order to carry out transactions, either online (on the web), or offline, like in a shop. In a typical transaction you reveal a few attributes about yourself. Useful attributes are:

  • I’m a student (or senior citizen)
  • I’m over 12 (or 16, or 18, or 21, or 65)
  • I’m under 12 (or …)
  • My nationality is …
  • I’m an inhabitant of the city of …
  • My gender is male / female
  • My bank account number is …
  • My address is …
  • My name is …
  • My social security number is …
  • My email address is …
  • My loyalty status for company X is bronze / silver / gold / …
  • I have a valid second class train pass
  • etc., etc.

Some of these attributes, like your bank or social security number, can be used to identify you, but other attributes are not uniquely identifying: they apply to other people too.

Attributes provide a way to reveal certain aspects of yourself, namely precisely those aspects which are relevant or required to carry out a transaction. It is easy to think of scenarios where attributes as listed above are useful:

  • when you buy a certain type of game/video/book online, you need to reveal that you possess the attribute “over 16”, or “over 18”.
  • if you wish to participate in an online chat-box for minors, you need to show the attribute “under 15” (say);
  • if you wish to get a cheaper haircut, show the “student” attribute, and for cheaper public transport you show that you are a “senior citizen”;
  • if you buy an item in a webshop you need to reveal your bank account and address attributes, and possibly also your loyalty/member attribute.

To summarise: IRMA is about attribute-based identity management.


2. Why attributes instead of identities?

Basically, attributes protect and empower you.

Via a fixed identity, like a social security number or a passport number, people can be recognised in many situations and their actions can be linked. This has many advantages, for instance in public services. But it can also lead to serious damages and stress when this single identity is abused, in what is called identity fraud. It is one
of the most serious perils in our modern societies.

If you use non-identifying attributes for a transaction, your identity is not involved. Hence it cannot be abused afterwards.

Using attributes instead of identities has other advantages besides reducing the risk of identity fraud:

  • it is privacy-friendly, because it supports data minimalisation: only the attributes relevant/necessary for a transaction need to be revealed;
  • it prevents linking different transactions, and thus hidden/implicit profiling;
  • it is flexible, and allows usage in many situations, not only in private life but also in professional contexts; for instances, via attributes one can make roles or access rights explicit;
  • it keeps you in control!

In many digitalisation projects of the past decades one sees that attributes from daily life have been replaced by fixed digital identities. An example is smart card based e-ticketing in public transport. Traditionally, having a (anonymous, untraceable) paper ticket was enough to get on a bus or train. These days one implicitly reveals one’s identity by using a (uniquely numbered) smart card. Via such cards individual movements can be traced and stored for many years — with all associated advantages and disadvantages. Attribute-based identity management (re)introduces more protection and flexibility in such contexts.


3. How do I obtain and use attributes?

Your attributes are stored on a personal smart card, called your IRMA card. You will need such a card in order to be able to use attributes. The IRMA card is strictly personal: it contains your picture on the outside and requires a PIN that only you (should) know.

(Other attribute-carriers than smart cards, like mobile phones, are in principle possible, but they provide less protection than smart cards, see the discussion below. At this stage, only smart cards are used for IRMA.)

Attributes that hold for you can be downloaded to your card. Typically this is done via the web, but it is also possible to do this in a face-to-face scenario. An organisation that provides attributes is called an Attribute Issuer, or simply an Issuer. There may be several issuers of attributes, such as:

  • national and local (government) authorities
  • banks / insurance companies / …
  • internet service providers / telecom operators / …
  • the Facebook’s / Google’s / Apple’s of this world
  • (web)shops with a larger customer base
  • marketeers
  • etc.

If I wish to obtain certain attributes from such an Issuer I first have to authenticate (prove who I am) to this Issuer. Subsequently, this Issuer can look up in its own database which attributes it knows about me, and I can choose from the available attributes which ones to download to my card. Via an intuitive (web)interface this choice can be expressed by clicking and/or dragging.

This authentication (proof of identity) is very important. Others who rely on the downloaded attributes later on trust the Issuer in two ways:

  • the Issuer knows for sure to whom it is issuing attributes the
  • Issuer only provides attributes which actually hold (are true) for the person requesting them.

Once your IRMA card contains a collection of attributes, you can start using them in various transactions. In such transactions the “other side” may ask (or require) you to reveal certain attributes, and then verifies them via some cryptographic calculations. The “other side” thus relies on your attributes and is therefor often called the Relying Party.

There is an important difference between Issuers and Relying Parties. Issuers make a claim about a cardholder and can be held responsible for the correctness & validity of the claim. Relying Parties rely on these claims. Cryptographically, Issuers perform much more sensitive operations, involving private keys, that should ideally be performed in secure hardware modules (HSMs). Relying Parties perform only public key operations, for checking. Because of these differences, it is expected that there will be more Relying Parties than Issuers. In principle, anyone offering some product, service or access — either online or offline — can be a Relying Party.

The Relying Party must clearly display to you, as cardholder, which attributes it expects to check. You then explicitly agree to reveal these attributes, and to allow the Relying Party to check them cryptographically, by typing in your PIN. The main role of the PIN is to prove ownership of the card.

In principle it is also possible to reveal attributes without a PIN, but this offers less protection (but maybe a bit more convenience). For instance, when using your IRMA card for access to (low security) buidings this verification may be done without PIN.

Attributes may expire after some time, or become no longer true (for instance “under 18” may not hold at some stage). Therefor attributes implicitly contain a validity date. Hence you may have to refresh or renew your attributes from time to time. You simply do this by returning to the original Issuer and downloading new/fresh attributes.

This process of downloading and revealing your attributes becomes a new activity in what may be called “personal identity management”. It is a bit similar to maintaining and using personal contacts, or apps.


4. What is under the hood of IRMA?

This part briefly explains the technology involved in IRMA and explains why IRMA is both privacy-friendly and secure. It is necessarily a bit more technical. IRMA is based on non-trivial cryptography for attribute-based credentials. These credentials are
data items that contain a provable claim. There are two similar technologies that will be considered here:

  • Idemix, developed by Jan Camenisch and Anna Lysyanskaya at IBM Zurich. (link)
  • U-Prove, originally developed by Stefan Brands, and now available via Microsoft. (link)

Both Idemix and U-Prove are so-called open technologies, which can be used free of charge. IBM and Microsoft both offer implementations of these frameworks. At the Radboud University Nijmegen very efficient smart card implementations have been developed (by Pim Vullers), both for Idemix and for U-Prove.

In both Idemix and U-Prove several attributes are combined in one credential. The technique allows selective disclosure of attributes, whereby only a selection of the attributes in a credential are revealed. For instance, on a smart card one may have a single credential that combines your:

  • nationality
  • date of birth
  • place of birth

Such a credential may for instance be issued by the authorities. You can decide, per transaction, to reveal any subset of these attributes.

Issueing attributes/credentials involves a so-called blind digital signature. As a result, after issueing the Issuer can no longer recognise the data credential it has just signed and issued. Hence the Issuer cannot trace the card (owner) and see which attribute is used where.

A Relying Party performs some cryptographic operations on a credential offered by a smart card and can obtain certainty about two things:

  • the content/claim of the shown attribute (like “over 18”)
  • the integrity and origin of the attribute, via a digital signature

With Idemix each showing of attributes/credentials also involves a form of blinding. Thus, different disclosures of the same attribute, even to the same Relying Party, cannot be linked. In U-Prove unlinkability requires more work (via multiple instances).

Credentials are cryptographically bound to a card via the private key of the card that is embedded in the credential. Such a private key is stored in a secure, hardware-protected manner in the card. As a result, credentials cannot be transferred from one card to another. Hence I cannot give my “over 18” attribute to my little nephew.

(Of course, I could give my whole card plus PIN to my nephew, but that is not wise: offline he cannot use the card, because of the picture on the outside, and online I run the risk that he does all kinds of (other) undesirable things for which I can be held responsible; this is like handing over your credit card to minor.)

The operations of downloading and revealing a credential/attribute are cryptographically non-trivial and involve many computation steps. Since a smart card has only limited computing resources, these operations take somewhere between 1 and 3 seconds in total. Future generation smart cards and/or faster implementations may reduce these transaction times.


5. Why are smart cards used for IRMA?

The security of IRMA depends on the protection of each User’s private key. This private key should remain under the exclusive control of the User: it determines his/her collection of attributes, and binds them together. On a modern smart card such a private key can be adequately protected. Cards are designed in such a way that the private key will never leave the card or be visible via hidden channels, through various hardware and software protection mechanisms.

Such high level of protection can not be guaranteed when the private key resides in the memory of a PC, tablet, smart phone, or other personal computing device, since such devices are too “open”. New, possibly malicious, software can be installed that obtains easy access to the private key. Malware is a serious problem for usage of such devices for secure, trusted services. Because of their closed character, malware is not a problem for smart cards.

It could be possible to embed a private IRMA key (plus IRMA software) in the SIM of a mobile phone, but such a set-up requires the cooperation of the mobile operator. Alternatively, the private key could be stored in a separate smart card (secure element) in a smart phone. Using a smart phone for very personal identity management may seem attractive, but also has disadvantages:

  • Mobile/smart phones are often lost or stolen
  • People often change their phone, moving to a next model
  • Many people use a phone that is provided by their employer; using such a phone for your personal attributes can be problematic, for instance when you loose your job, or change employer.

Thus, running IRMA with mobile phones as attribute carriers may seem attractive because it does not require a new separate card and provides an easy interface, but at the same time management and protection of (private) keys is quite problematic.

The main disadvantage of smart cards is that one needs a separate device as interface, for instance a smart card reader for your PC. Increasingly, however, smart phones contain NFC readers that can be used as interfaces to the smart card.

Also, people may find it cumbersome to have to use a separate smart card. Actually, this extra effort is an advantage, from the viewpoint of psychology of security. The extra, physical effort of taking your IRMA card from your wallet and holding it close to your smart phone or card reader makes you aware that you are performing a security sensitive operation. This is a bit like getting your bank card or (ordinary) keys from your pocket: usually it brings you into a more security sensitive state, aware of the fact that you are doing something special.

As an aside, one can also imagine online storage of one’s attributes in a personal vault. Then one still needs a very strong form of authentication to secure access to the vault, for which a smart card is an obvious solution. Also, such a vault precludes off-line use of IRMA.

All in all smart cards remain the most obvious technology to realise IRMA. They will be used in the IRMA pilot project, in order to get the technology up and running. Of course, other (secure) realisations may be possible in the future.


6. What is the architecture behind IRMA?

The most distinguishing aspect of the architecture behind IRMA is its decentralised character: your attributes are stored with you, on your smart card, and not with some “identity broker” with a mediating role. When you wish to prove to a shop keeper that you are over 18, you can do so directly, without going through some central infrastructure that
can keep track of:

  • what your attributes are
  • who you are showing them to.

In this way IRMA provides optimal privay protection.

The whole IRMA scheme does require a governance structure that sets the rules, responsabilities, and accountabilities for the various players involved (Issuers, Relying Parties, Users, etc).

Another key characteristic of IRMA is that the technology is open, and not monopolised by a single party. This open character is essential for the required high levels of trust and participation. It is an enabler for new forms of business and innovation: IRMA provides the common infrastructure on top of which new (commercial) services can be developed.


7. Who organises and runs IRMA?

Currently IRMA is a cooperation project primarily between:

Several other parties have expressed interest, but are not actively participating yet.

The intention is to organise a pilot project in the academic year of 2012/2013, involving some 100 students of the Kerckhoffs computer security master (jointly in Eindhoven, Twente and Nijmegen). In this pilot phase the emphasis is on getting the core technology up and running, in a version with limited features.

If succesful, the intention is to involve more parties, extend the user-base and the features, and ultimately to transfer the technology, infrastructure and experience to an independent foundation that can run the scheme.

Important organisational issues that need to be addressed are the precise requirements, both technical and legal, that Issuers and Relying Parties need to satisfy in order to participate.


8. Can I participate or contribute?

If you represent an organisation that:

  • wishes to explore the role of Issuer and/or Relying Party within the IRMA setting;
  • is capable and willing to contribute to the further development and roll-out of the technology;
  • is ready to contribute financially to such efforts, for instance, by funding additional smart cards and card readers;
  • supports the open character of this project,

then please get in touch via:


and describe how you foresee your contribution.

22 thoughts on “I Reveal My Attributes

  1. I’ve been working and still have friends at (Honeywell) Bull, a company with a division having over 20 years experience and is still active in smart card applications, and I also have a friend (ex-IBM) who’s been and now as a freelance expert still is active in the technical aspects of electronic voting. One of these parties of both of them could be interested in and for your project.
    Before I’m going to make them aware of IRMA I’ve one question:
    When you have all your personal information as listed under ‘1 What is IRMA about?’ on the card how will it be arranged (technically and organizationally) that a Relying party only has entrance to, for instance, my address and bank account number, and NOT to other information such as my BSN number?

    • A relying party will need a certificate in order to authenticate itself to the card. This certificate will also contain a policy which describes which information the relying party is allowed to retrieve from the card. The card will deny all requests not matching with this policy.

  2. Attributes are all fine and a BIG step in the right direction when it comes to protecting your personal identification information, but how do I know as a “future” user of IRMA that the local liquor store only gets my “Over 18” attribute.

    It might be possible for the liquor store to have software installed which pulls all attributes from the card to form a more comprehensive image of my person. Date of birth might be an attribute which I have on my card for certain purposes but not for the liquor store.

    Is this safeguarded in any way? Does the liquor store have to obtain a certificate of key from the TTP (you) which guarantees only this specific attribute can be read? (PKI structure or anything…)

    Don’t get me wrong I really like the idea of the IRMA card, but I’m also a bit paranoid.

    • This is a great question. A verifier should not learn more information than absolutely necessary when you show your IRMA card. There are several techniques to achieve this. Currently, we are setting up a designated organisation, the so-called Scheme manager. This entity grants access to verifiers for certain attributes to query and the same organisation creates certificates that cards can check. Although it is possible and later it is certainly required, in the current stage of the project we do not employ technical restrictions on what verifiers can query from the card.

      • I would argue that this should be a key part of the solution. If a card owner cannot verify which attributes will be checked when he/she enters his/her pin, that defies the whole idea of attributes right? If you cannot see which attributes are checked, you might as well be giving out your social security number every time you go to the liquor store. I’m also missing some information on the hardware of the Relying Parties. Can this hardware be hacked? If so, does this mean that every user can have his/her information forwarded to an unknown third party every time he/she visits the infected Relying Party?

        I feel bad for criticising a good new concept of smart card use, but I felt like these questions are quite essential when you create a new concept like this.

        • There are two questions. The first one is related to the previous comment. Let me rephrase my answer. A verifier before letting it request attributes from IRMA cards receives a public-key certificate. This certificate shows that the verifier is legitimate and it also describes which attributes this verifier is eligible to query from cards. When a card obtains a request, it first checks the certificate and extracts the public key and the attribute rights of this particular verifier. So, when the verifier sends a request, the card already knows whether the attributes in the request may or may not be queried. Moreover, the information sent by the card is secured by a channel bound to the public key of the verifier. This provides assurance that indeed the intended verifier receives the disclosed attributes.
          Your second question is related to hacking a relying party’s terminal. This may be of course possible and it is independent of the IRMA technology. However, the benefit of using the IRMA technology over other authentication and authorisation methods has a lot to do with data minimisation. In many cases, e.g. when buying a bottle of whisky, authorisation to a service is not identifying, so the amount of data that a hacker or an unknown third party can gain is not very valuable as the information cannot be linked to people.

          • Hi Gergely,

            That sounds reasonable. The only trust you have to put in as a user is that the certificate authority only hands out certificates to a Relying Party with minimum attribute eligibility.

  3. I realise “With Idemix each showing of attributes/credentials also involves a form of blinding. Thus, different disclosures of the same attribute, even to the same Relying Party, cannot be linked.” that this is safeguarded between requests, however, this is I believe not the case when multiple attributes can be read with a single request.

    • Thank you for the question, it is an important issue that you point out. Idemix provides unlinkable showing actions. This means that if you show attributes from your card several times, a verifier will not be able to tell whether these instances came from the same or different cards. It does not matter if they included the presentation of only one or multiple attributes.

  4. I wonder about three things.

    A. Do I as a cardholder have to approve the request from or answer to a relying party? Similar to the way a android app needs to be approved.

    B. How do you prevent a relying party to just ask everything they can think of? So it doesn’t become the next: I need a foto copy of your ID. Currently most organizations aren’t allowed to ask for a foto copy, but they just do because they can. The hands of the dutch privacy body are tied. Not handing over the requested info will result in me not getting anywhere or anything.

    C. In a discussion on this subject on a other site the Belgium eID was mentioned. I wonder how irma is similar or different?

    • Hi Jose,

      I’ve tried to answer your questions below, let us know if you have any additional questions.

      re A: yes, you do, but you can choose as a user whether you want to do this (i.e. it is optional). The approval is implicit; you can enforce (as user) that you have to enter the PIN of the card before data is revealed.

      re B: Every relying party will have a certificate on their verification device; this certificate is card verifiable and contains a digitally signed statement from the issuer or scheme authority which attributes a relying party is allowed to request. What is revealed to which relying party is, of course, a policy decision. Common practice in identity federations is to use the principal of “minimal disclosure”, which means that only those attributes that are absolutely necessary to render a service a revealed to a relying party. IRMA can enforce the same principle, but this is a policy rather than a technical matter.

      re C: as far as I know, the Belgian eID is a “classic” PKI smart card with X.509 certificates for legally binding digital signatures and authentication. Because of the nature of PKI technology, such a card does not offer the same privacy guarantees as IRMA; users are inherently traceable based on their certificate.

  5. Two questions:

    1. What is the difference between a Relying Party and a Verifier?

    2. Can an Issuer also be a Relying Party?


    • Short answers to these clarifying questions:
      1. A verifier is a relying party, because it relies on the validity of the issuers’ claims formulated in attributes. For instance, if the ‘over 18’ attribute is signed by a specific government organisation, then any verifier who believes that the credential owner is over 18 relies on the issuer (besides the technology). Verifiers are most often service providers; therefore, the notions of ‘verifier’, ‘relying party’ and ‘service provider’ are often used interchangeably.
      2. When the ‘service’ is credential issuance, an issuer can also be a relying party. The issuer first verifies some of the already existing attributes, and then it issues a new attribute-based credential. In this case the issuer is also a relying party.

  6. Above at “3. How do I obtain and use attributes?” it reads:
    “This authentication (proof of identity) is very important. Others who rely on the downloaded attributes later on trust the Issuer in two ways:
    * the Issuer knows for sure to whom it is issueing attributes the
    * Issuer only provides attributes which actually hold (are true) for
    * the person requesting them.”

    but I guess it should read:
    “This authentication (proof of identity) is very important. Others who rely on the downloaded attributes later on trust the Issuer in two ways:
    * the Issuer knows for sure to whom it is issueing attributes
    * the Issuer only provides attributes which actually hold (are true) for the person requesting them.”

    • Thank you for the correction. We adapted the text accordingly.

      On a similar note: the issuer in fact does not necessarily know the identity of a user. An attribute-based credential can also be issued based on verifying attributes from other credentials already on the card. This is a very important aspect in terms of privacy. For instance, a shop in a city could issue a loyalty credential, but only to local residents. The shop does not need to know the identity of a returning customer, but it can get convinced that its policy (loyalty cards only to local residents) is satisfied.

      If you are interested in these topics, you can find further discussion on the page Scientific and popular publications (especially, Credential Design in Attribute-Based Identity Management and The ABCs of ABCs: an analysis of attribute-based credentials in the light of data protection, privacy and identity)

  7. Above at “3. How do I obtain and use attributes?” it reads “Attributes may expire after some time, or become no longer true (for instance “under 18″ may not hold at some stage). Therefor attributes implicitly contain a validity date.”

    Does this mean that if a verifier are allowed to request the “under 18″ attribute then the verifier also get the validity date for that attribute? If that is the case then isn’t that the same thing as giving the verifier the birthdate of the cardholder, i.e. the validity date of the attribute “under 18″ must be the same date as when the cardholder turns 18 years old?

    • Dear Hans,

      1. The IRMA project is an open-source research project. This has (at least) two consequences. First, anyone who is interested to try and experiment with this technology can do that by downloading the necessary files and install them on MULTOS smart cards and issuing/verification devices. Please visit the Resources/Downloads sections. Second, since it is a research project, we constantly develop the ideas and the technology. There are new use cases, cryptographic methods, devices and implementations in the context of IRMA. Therefore, the project is not restricted by borders, albeit our pilots are currently carried out in the Netherlands.

      2. The ABC4Trust and the IRMA projects are separate. However, the underlying cryptographic technology is essentially the same. But because in the two projects the infrastructures developed on top of this core technique (attribute-based credentials) are very different, the resulting user experience, implementations and policies are quite far apart.

      Researchers of ABC4Trust and IRMA have a similar goal in mind; namely, a secure and privacy-friendly digital society and they keep contact with each other.

  8. I read that all source code developed within the IRMA project is open source. Are all of this source code licensed under GNU general public license, version 3?

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.