irma-explanation.md 33.8 KB
Newer Older
1
2
3
4
5
6
7
8
9
10
11
12
---
layout: page
title: IRMA in detail
header:
  image_fullwidth: header_unsplash_1.jpg
  title: Privacy by Design Foundation
permalink: /irma-explanation/
language: en
translations:
  nl: /irma-uitleg
---

13
14
<a name="top"></a> This page explains the ideas behind the idenity
platform IRMA.  It also explains how the system works and has been
Bart Jacobs's avatar
Bart Jacobs committed
15
16
17
18
19
designed. The following topics will be discussed.

 1. [What is IRMA all about?](#topic)
 2. [Why would you wish to use attributes instead of identities?](#why)
 3. [How do I obtain and use attributes?](#how)
Bart Jacobs's avatar
Bart Jacobs committed
20
21
 4. [How does IRMA differ from other authentication systems?](#architecture)
 5. [How does IRMA work under the hood?](#hood)
22
23
24
25
26
 6. [Which privacy guarantees does IRMA provide, and which not?](#guarantees)
 7. [Which values does the IRMA technology embody?](#values)
 8. [What are attribute-based signatures?](#signature)
 9. [What are IRMA's disadvantages?](#disadvantages)
 10. [How can I participate or contribute?](#contribute)
Bart Jacobs's avatar
Bart Jacobs committed
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

These questions will be addressed one by one below. Elsewhere there
are shorter explanations, for [IRMA app users](/irma-start) and for
[IRMA verifiers](/irma-verifier).


### <a name="topic"></a>1. What is IRMA all about?

In many countries, when you buy a bottle of whiskey, you are obliged
to prove that you are older than 18. You don't have to prove who you
are. Just this personal property, that you are over 18, suffices
for the whiskey purchase. Such personal properties will be called
*attributes*.

IRMA is the name for a system that allows you to do precisely this.
IRMA stands for *I Reveal My Attributes*. IRMA empowers you to
disclose online, via your mobile phone, certain attributes of yourself
("over 18"), but at the same time hide other attributes (like your
name, or phone number). IRMA protects your privacy in this way. This
privacy-protection is intrinsic to the system, which is called
*privacy by design*. In the most recent European data protection
regulation such privacy by design is legally required for new
ICT-systems.

51
Apart from instrinsic privacy-protection, IRMA also protects against
Bart Jacobs's avatar
Bart Jacobs committed
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
identity fraud: if your name and date of birth are not revealed at
all, they cannot be abused.

The list below gives several examples of attributes that may be useful,
for instance for interaction with a webshop, with the government,
with your bank, or at a webforum, etc.

* I'm a student (or a pensioner)
* I'm older than 12 (or 16, or 18, or 21, or 65)
* I'm younger than 12 (or ...)
* My nationality is ...
* My gender is ...
* My bank account number is ...
* My home address is ...
* My given/family name is ...
* My national registration number is ...
* My insurance number is ...
* My email address is ...
* My mobile phone number is ...
* My loyalty card of company X has status bronze / silver / gold
* My rail subscribtion is first / second class
73
74
* etc. etc.

Bart Jacobs's avatar
Bart Jacobs committed
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
Some of these attributes are uniquely identifying, like your bank
account number: it is associated with a single person. But some other
attributes can be used anonymously, without disclosing who is
involved. These non-identifying attributes apply to multiple people.

Attributes form a natural mechanism for revealing certain aspects of
yourself, while at the same time selectively disclosing other aspects.
There are many scenarios where attributes provide precisely the
relevant information that is required for a certain transaction.

* If you wish to join an online chat-box for minors, you have to prove
  that you are younger than 15, for instance. Or if you want to
  participate in an online discussion group of people with a certain
  sensitive disease, this disease itself can be the attribute that
  gives you anonymous access to the group.

* When you wish to buy a violent game/movie/book online, you have to
  prove that you are older than 16, or may even older than 18.

* If you possess the "student" attribute you may be able to get a
  discount at a hairdresser; en if you have the "handicapped"
  attribute of specific kind, you may be entitled to special
  transportation.

* For a purchase online you home address attribute is needed for
  delivery. Discounts may be available via a loyalty attribute of the
  webshop. And possible an age limit attribute is required if the item
  that you purchase is not intended for minors.

In short, IRMA is about attribute-based authentication: it is not
about *who* you are, but *what* you are. This is very natural and
intuitive. When you visit a doctor in a hospital you may wish to know
his/her name for communication, but a much more important attribute is
that the relevant person is a qualified medical doctor indeed. In the
non-digital world we rely very much on context: the person wears a
white coat and receives you in an office in a building that says
"hospital" above it entrance. But in the online world such context
information is often missing (or is easy to fabricate), so that we
have to use attributes like in IRMA for trusted intraction.
114
115
116
117
118
119
120
121
122
123
124
125

Kortom: IRMA gaat over attribuut-gebaseerde authenticatie: u bewijst
niet zozeer *wie* u bent, maar *wat* u bent. Dat is heel natuurlijk
en intuïtief. Als u een arts in het ziekenhuis bezoekt wilt u
diens naam misschien weten voor de communicatie, maar een veel
belangrijker attribuut is dat de betreffende persoon daadwerkelijk
arts is. In de niet-digitale wereld vertrouwen we erg op de context:
de persoon draagt een witte jas en ontvangt u in een werkkamer in een
ziekenhuis. Dat geeft vertrouwen. Maar in de online wereld ontbreekt
een dergelijke context (of is die makkelijk te vervalsen) en moeten we
attributen als in IRMA gebruiken voor betrouwbare omgang.

Bart Jacobs's avatar
Bart Jacobs committed
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186

[To the top](#top)

### <a name="why"></a>2. Why would you wish to use attributes instead of identities?

The short answer is: attributes protect you and empower you.

Via a unique personal number, like a passport number or a national
registration number, people can be recognised in many different
situations and all their actions can be linked. This has many
advantages, for instance in public services. But it can also have
serious disadvantages, especially when this unique personal number is
abused by someone else. This is called identity fraud, and it is one
of the biggest plagues of the digital era.

When you use anonymous attributes, instead of a unique personal
number, for a transaction, then your identity does not play a role and
cannot be stolen. In this sense, attributes protect you.

Usage of attributes, instead of identities, has additional advantages.

* It is privacy-friendly because of *data minimalisation*. Only those
  attributes which are relevant and necessary for a transaction need
  to be disclosed.
* It provides the user, at least with IRMA, real control and
  transparancy about who is requesting to see which attributes.
* It is flexible and can be used in many situations.
* It prevents linking of different transactions, as long as
  non-identifying attributes are being used. Hence it also prevents
  open or surreptitious surrveillance and profiling, and everything
  that is associated with it, such as price-discrimination (the price
  that you have to pay depends on the profile that has been assembled
  about you).

In many digitisation projects of the past decades attributes from
daily life have been replaced by 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, be used for
marketing purposes, and posssibly become public through a computer
hack or through negligence. Anonymous cards, at least in the
Netherlands, do not offer much privacy protection, since when an error
needs to be corrected or when you want to receive any remaining saldo
on the card after its expiration, you need to disclose your
identity. In this way a connection is made between you and and all
your travels, which, you thought, were anonymous.

Attribute-based identity management (re)introduces more protection and
flexibility for users. Additionally, attributes offer some protection
for service providers against possible disadvantages of total
anonymity, because they can demand that participants do reveal some
minimal level of relevant data about themselves, for instance that
they are female, or under 12, in special online discussion groups for
women or for children.

[To the top](#top)

### <a name="how"></a>3. How do I obtain and use attributes?

187
188
189
190
191
192
193
194
In the IRMA identity platform your personal attributes are securely
stored in the IRMA app on your own phone (or tablet) --- and nowhere
else. The app is protected via your own PIN code. This personal PIN
ensures that no-one else can use your attributes in your IRMA app, and
thus steal your identity. Of course, it is important that, in
addition, your phone has its own login pattern or code. But on top of
that, the IRMA app has its own PIN, just like various apps from mobile
banking have their own PIN.
Bart Jacobs's avatar
Bart Jacobs committed
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222

Attributes that hold for you can be downloaded to your IRMA app on
your phone. Typically this is done via the [web](/issuance), but it is
also possible to do this in a face-to-face scenario at a counter. An
organisation that provides attributes is called an *attribute issuer*,
or simply an *issuer*. There may be several issuers of attributes, such
as:

* national or local (government) authorities, for attributes like:
  name, address, date of birth, national citizen numbers, categories
  of income, etc.
* banks and insurance companies, for attributes like: bank and/or
  insurance account numbers, type of insurance, etc.
* internet service providers and telecom operators, for: email
  addresses, phone numbers, IP-addresses
* the Facebook's / Google's / Apple's / Amazon's / Microsoft's of this
  world for login data
* big or small webshops, with loyaly cards and custum numbers, with
    associated status, coupons, etc.
* companies and other organisations, for attributes as a basis for
  fine-grained role-based access management
* hospitals and other healthcare organisations, for regulating access
  via attributes, not only for healthcare professionals, but also for
  patients
* block chain initiatives, for authentication of users and their roles
* military organisations, for all their different ranks and (security)
  compartimentalisations and clearances, and for members of special
  forces whose identifying data are typically not revealed
223
224
* etc.

Bart Jacobs's avatar
Bart Jacobs committed
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
Unfortunately, at this stage, IRMA is not so widely accepted and
supported yet that all these organisations actually issue IRMA
attributes. But some of them seriously look at the possibilities.

If you wish to obtain certain attributes from such an issuer you first
have to authenticate (prove who you are) to this issuer. Subsequently,
this issuer can look up in its own database which attributes it knows
about you, and you can choose from the available attributes which ones
to download to your IRMA app on your phone, digitally signed by the
issuer. Concretely, in order to obtain attributes from your bank,
you have to log into your bank first. This is precisely what happens
with [iDIN](/issuance-idin).

Once your IRMA app contains a collection of attributes, you can start
using them in various transactions. In such transactions the other
side (think of a webshop) may ask you, for instance, what your home
address (attribute) is. After you have explicitly agreed to such a
request, and typed in your PIN code, this attribute is revealed by the
IRMA app to the webshop. By performing some cryptographic checks, the
webshop can verify that the attribute is genuine, has not expired, has
not been manipulated, has been issued by a specific issuer, and also
that it really belongs to you (actually: to your phone). This
requesting party, who wants to see some of your attributes, is called
a *verifier*, or sometimes a *relying party*. There is a special
[verifier page](/irma-verifier) explaining what this role amounts to.

It is built into the IRMA system that these verifiers must make very
clear to you which attributes they request to see.  You, as an IRMA
user, have to explicitly agree to the release of those attributes.  In
this way it is clear and transparant who wants to know what about you.
The IRMA app keeps its own log, so that you can see later which verifier
has requested which attributes (at what time), and what you have
revealed. If there are verifiers who request disproportionally much
information from users, you can file a complaint, based on these logs,
for instance with your (national) data protection authority.

(The Privacy by Design foundation also keeps a minimal log of all your
transactions, in order to enable you to detect possible abuse, see the
[MyIRMA explanation](/irma-start/#myirma). This log gives you no
information about the attributes that have been requested and/or
shown, and can not be used for complaints.)

Attributes in IRMA carry a digital signature of the issuer. Via this
signature the verifier can check the origin and the integrity of
attributes. Attributes have an expiry date, which can also be checked
by the verifier. If attributes have expired, they need to be refreshed
by the user, by returning to the original issuer. This works just like
for passports, identity cards, or driver's licenses: at some stage
they expire, and you need to get it re-issued. Refreshing of IRMA
attributes is much simpler, however, since it can be done online.

276
277
The three pictures below give a schematic overview, first of
downloading attributes at an issuer, and subsequently, of
Bart Jacobs's avatar
Bart Jacobs committed
278
using attributes at two different webshops.
279
<hr>
280
<p align="center"><img src="../images/Transactions_IRMA_voorbereiding_en.png" alt="IRMA uitgever" style="width: 55%; height: 55%"/></p>
281
<hr>
282
<p align="center"><img src="../images/Transactions_IRMA_eerste_gebruik_en.png" alt="IRMA gebruik" style="width: 50%; height: 50%"/></p>
283
<hr>
284
<p align="center"><img src="../images/Transactions_IRMA_enzovoort_en.png" alt="IRMA gebruik" style="width: 50%; height: 50%"/></p>
285
286
<hr>

Bart Jacobs's avatar
Bart Jacobs committed
287
288
289
290
291
292
293
294
This downloading of attributes is a natural form of modern *identity
management*. It allows you to assemble and maintain your own personal
digital passport in your IRMA app. Such personal data management is a
bit like installing and removing apps on your phone or tablet.

[To the top](#top)


Bart Jacobs's avatar
Bart Jacobs committed
295
### <a name="architecture"></a>4. How does IRMA differ from other authentication systems?
Bart Jacobs's avatar
Bart Jacobs committed
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324

IRMA differs in essential ways from other identity management systems,
such as [Facebook
login](https://developers.facebook.com/docs/facebook-login), or
[iDIN](http://www.idin.nl) in the Netherlands. IRMA has a
*decentralised* architecture. Your attributes are stored only locally,
on your phone, and not centrally in the computer systems of some
"identity broker". When you use IRMA to prove to a webshop that you
are older than 18, your IRMA app communicates directly with the
webshop, without intermediary parties. In the IRMA set-up there are,
in principle, no third parties who can monitor and record:

* which attributes you have
* where you use them
* when you use them.

In this manner IRMA offers optimal privacy protection, by design.

To compare: if website X does not use IRMA for user authentication,
but let's say Facebook login, you are re-directed to Facebook when you
wish to login at X. After logging into Facebook, using your Facebook
credentials, Facebook gives website X certain information about
you. In this way Facebook learns where you login at what moment and
uses this information to extend your profile and adapt its
advertisement targeting. In addition, it is not transparant to you
which data about you website X receives from Facebook.

Many identity management systems are organised in such a *centralised*
manner. This is commercially most interesting for the providers of the
Bart Jacobs's avatar
Bart Jacobs committed
325
326
327
328
329
identity management system: they can not only build up and sell
profiles of all users --- who logs in where and when with which data
--- but they can also charge the relying party for each authentication
action, precisely because they are in the middle, and all
communication goes through their systems.
Bart Jacobs's avatar
Bart Jacobs committed
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345

Another clear example is the iDIN authentication system that banks in
the Netherlands have set up. When you authenticate via iDIN, your bank
can see whether you login to a liquor store or to a psychiatric
clinic. The banks [promise](https://www.idin.nl/consumenten) that they
will not use this information for other purposes, for instance, when
they decide whether or not you will get a mortgage. In IRMA's
decentralised architecture such uncomfortable issues do not arise at
all. In addition, relying parties, such as webshops, need to pay the
banks per iDIN authentication session. The prices are a real concern
for them, and have already led to complaints. Again, with IRMA there
are no such artificial costs imposed by the chosen (centralised)
architecture.

The difference between a decentralised (IRMA) and centralised
(non-IRMA) set-up is sketched below.
346
<p align="center"><img src="../images/Transactions_all_lowres_en.png" alt="overzicht" style="width: 100%; height: 100%"/></p>
347

Bart Jacobs's avatar
Bart Jacobs committed
348
It may be clear that in the non-IRMA set-up the issuer of attributes
Bart Jacobs's avatar
Bart Jacobs committed
349
is a *privacy hotspot* who facilitates and sees all
Bart Jacobs's avatar
Bart Jacobs committed
350
351
352
353
354
transactions. Moreover, in the centralised architecture a (malicious)
issuer can completely take over your identity and impersonate you. You
have no way to stop this, or even notice it --- until possibly later
when you are confronted with the consequences. In the decentralised
IRMA set-up you have genuine control over the usage of your own
Bart Jacobs's avatar
Bart Jacobs committed
355
356
357
358
attributes: you directly disclose your own attributes yourself, every
time only after explicit consent, without (unnecessary) interference
of third parties.  This is similar to the way you can disclose your
(physical) passport yourself, without dependence on others.
Bart Jacobs's avatar
Bart Jacobs committed
359
360
361
362
363
364
365
366
367
368

In the IRMA system there are no such *privacy hotspots*. At a
meta-level, IRMA does involve some level of coordination about how
attributes and credentials are organised and which cryptographic
(public) keys are needed at which stage. This coordinating role is
fulfilled by the Privacy by Design foundation. But: the foundation can
not see at all which attributes are used where.

The Privacy by Design foundation does not monopolise IRMA and its
technology. The software is open source and is freely available, for
Bart Jacobs's avatar
Bart Jacobs committed
369
everyone to use. Also other parties can play the coordinating and/or
Bart Jacobs's avatar
Bart Jacobs committed
370
371
372
373
374
375
376
377
378
379
380
381
issuing roles that the foundation is playing at this stage.  In fact,
it would be better if [iDIN](/issuance-idin) or the [BIG
register](/issuance-big) would directly issue IRMA attributes
themselves, instead of the foundation doing so indirectly ---
currently, hopefully temporarily.

Decentralised and centralised identity management systems do not
exclude each other. In fact, they can work well together, for instance
in the case of iDIN providing attributes for IRMA. IRMA can best be
used for applications where privacy plays a (big) role and where
attributes are needed that can not be organised easily in a
centralised manner, for instance because of legal restrictions or lack
Bart Jacobs's avatar
Bart Jacobs committed
382
383
384
385
386
387
388
389
of trust in central storage among users. IRMA can also handle
"temporary" attributes, like an entry ticket for a concert, containing
the name, date and location of the concert. In principle, you can buy
such a ticket online and download it as attribute to your IRMA app. At
the entrance of the concert you can disclose the ticket for
verification, and subsequently delete it from your phone. (Such
tickets are strictly personal non-transferrable, because they are
cryptographically connected to your own personal IRMA app.)
Bart Jacobs's avatar
Bart Jacobs committed
390
391
392
393

A subtle point is wheter IRMA outperforms centralised architectures
since such architectures intrinsically have a single-point-of-failure;
if it goes down all authentication is disabled. In fact, IRMA also
Bart Jacobs's avatar
Bart Jacobs committed
394
395
396
397
398
involves a small central *keyshare* component, as will be explained in
more detail [next](#hood), so that users can inspect and disable their
usage, if needed. This central component plays a role in each
attribute disclosure and issuance. Hence it is a
single-point-of-failure too.
Bart Jacobs's avatar
Bart Jacobs committed
399
400
401
402
403
404


[To the top](#top)


### <a name="hood"></a>5. How does IRMA work under the hood?
405

406
This section overlaps to some extent with the
Bart Jacobs's avatar
Bart Jacobs committed
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
[explanations](/irma-start) for getting started with IRMA, especially
its last part about [registration](/irma-start/#hood).

Technical details of IRMA will be given below, explaining why IRMA
works in a privacy-friendly and secure manner. IRMA is based on
non-trivial cryptography for attribute-based credentials. These
credentials are containers for attributes, equipped with an expiry
date and a digital signature, produced by the issuer.  The underlying
cryptography is based on
[Idemix](http://www.research.ibm.com/labs/zurich/idemix/), which has
been developed since the late nineties at IBM Zürich. The technology
is *open* and has been published in the scientific literature. This
contributes to confidence.

IBM has made its only implementation of Idemix publicly available,
free of charge. The Privacy by Design foundation has developed its
own, different, independent, open source [IRMA
implementation](https://credentials.github.io/). The rights on this
IRMA implementation are jointly in the hands of the foundation and
Radboud University --- where the initial parts of the implementation
were developed.

As mentioned, individual IRMA attributes are combined in a credential.
For instance, you can have a credential containing the following
attributes.

* nationality
* place of birth
* date of birth.

Such a credential may for instance be issued by the (local or
national) authorities. You, as user, can decide, per transaction, to
disclose any subset of these attributes. In the above example, you can
for instance disclose your nationality, without revealing where or
when you were born. This is *selective disclosure* property is the
basis of IRMA's privacy by design.

The party that offers such credentials according to the IRMA protocols
is called an *issuer*. During the issuing process, the issuer puts
a so called *blind* digital signature on the credential. This has
two important consequences.

1. By checking this signature, verifiers can check the origin and
   integrity of the credential. The latter means that they can check
   that no-one has tampered with the (contents of the) credential.
2. By the *blindness* of the signature, issuers do not see the
   ultimate form of the signed credential, and hence can not trace its
   usage, even if the issuer colludes with verifiers. This property is
455
   called *issuer unlinkability*.
Bart Jacobs's avatar
Bart Jacobs committed
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504

The Privacy by Design foundation has freely available open source
[software](https://credentials.github.io/) for issuing credentials.

The party that checks one or more attributes, from one or more
credentials, is called a *verifier* (or sometimes also *relying
party*). Such a verifier checks a number of things:

* whether the attributes are still valid (not expired)?
* is the digital signature valid, so that the origin (authenticity)
  and integrity of the credential is guaranteed?
* do the attributes come from an issuer that the verifier trusts
  sufficiently? For instance, a verifier may trust a name attribute if
  it has been issued by national authorities, but not when it has been
  issued by Google, say.
* when attributes are disclosed from different credentials: do they
  belong to the same person?

The Privacy by Design foundation has freely available open source
[software](https://credentials.github.io/) also for this verifier
role.  It allows a webshop, or other organisation, to verify
attributes from its customers, see the [more detailed
explanations](/irma-verifier) elsewhere. Small webshops may wish to
outsource such attribute verifications to third parties, just like
they often outsource payment processing. This is possible, but is not
ideal for privacy, since these external verifiers see many
attributes. Such a third party may offer IRMA attribute verification
as a commercial service.

Credentials are cryptographically bound to a mobile phone, and to each
other, via a personal secret cryptographic key. This private key is
crucial for the security of the IRMA app; it must be stored securily.
Such secure local storage is difficult on a mobile phone, since the
device may be rooted or hacked. That is why a small but crucial part
of this private key is stored outside the phone on a so-called
*keyshare-server* that is operated by the Privacy by Design
foundation. The IRMA PIN code is checked by the keyshare server, see
the [more detailed explanations](/irma-start/#hood) elsewhere.  Only
when the PIN checks out, will the server participate with its own
small part of the secret personal key, and can attributes be
disclosed. The keyshare sever will not see the attributes themselves,
nor to whom they are disclosed.

This entire secret personal cryptographic key, and thus the
cooperation of the keyshare server, is necessary for each IRMA
operation, such as receiving and disclosing of attributes. As long as
my key stays under my control, my attributes cannot be used by
others. Thus, my attributes cannot be transferred to other user IRMA
users --- unless I somehow also transfer my secret key.
505
506


Bart Jacobs's avatar
Bart Jacobs committed
507
508
[To the top](#top)

509
### <a name="guarantees"></a>6. Which privacy guarantees does IRMA provide, and which not?
Bart Jacobs's avatar
Bart Jacobs committed
510

511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
The following terminology is used for IRMA's privacy guarantees.

* **Issuer unlinkability.** This means that an issuer of attributes
    can not trace the disclosures of these attributes by a user, even
    not when the issuer colludes with a verifier and both parties put
    there data together. Of course, this does not work for identifying
    attributes, like your bank account number, but it does work for
    non-identifying attributes, like your gender.

* **Multi-show unlinkability.** This means that multiple disclosures
    of the same attribute by the same user cannot be linked by a
    verifier. Concretely, if, on a single day, you prove to a webshop
    that you are older than 18, then the webshop cannot find out that
    the same person is behind both disclosures.

These properties are built into the underlying cryptographic system
(Idemix) on which IRMA is based. Nevertheless, it is still possible
that privacy-sensitive information leaks out, for instance the
IP-address involved, or the "fingerprint" of the browser. The above
webshop may conclude, rightly or not, that the same person is involved
because both attribute disclosures come from the same IP-address.

Protection against this is possible, for instance via anonymisation
technologies, such as [Tor](https://www.torproject.org). But such
protection is not built into IRMA.




### <a name="values"></a>7. Which values does the IRMA technology embody?
Bart Jacobs's avatar
Bart Jacobs committed
541

542
543
544
545
546
Authentication requirements, and information flows, reflect the power
relations in society.  In general, the more powerful parties impose
authentication requirements and mechanisms on the less powerful
parties. The Privacy by Design foundation is well aware of these
societally important issues and aims to use value-laden design in
547
548
offering IRMA as a transparant open identity platform for proportional
and contextual authentication that empowers, instead of weakens,
549
550
551
users. This context-dependence is related to [Helen
Nissenbaum](http://www.nyu.edu/projects/nissenbaum/)'s interpretation
of privacy as contextuele integrity.
Bart Jacobs's avatar
Bart Jacobs committed
552
553

IRMA works via freely available open source software. Everyone can
Bart Jacobs's avatar
Bart Jacobs committed
554
555
556
557
558
559
560
561
562
563
inspect and judge how it works. This contributes to confidence, not
only in the proper functioning of the IRMA system, but also in order
to check that there are no hidden backdoors in the system.  Such
transparancy is essential for broad voluntary usage and acceptance of
sensitive ICT-infrastructure, like for authentication. With IRMA there
is no commerical lock-in, and there is no extorted trust. Even if the
foundation somehow goes down, the IRMA software will still be there
and can be maintained and continued by others.

Thus, IRMA is not about plundering or deceiving users, or about
Bart Jacobs's avatar
Bart Jacobs committed
564
surreptitiously steering them commercially or politically, but about
565
encountering them transparantly, with dignity, respecting their
Bart Jacobs's avatar
Bart Jacobs committed
566
autonomy and privacy.
567
568
569
570
571
572
573
574
575

IRMA is based on properties of individuals (attributes) whose source
is explicitly visible, namely in the form of the issuer who commits
itself via digitial signatures to the validity of these attributes.
IRMA is thus about "objective" properties and qualifications of people,
where the objectivity lies in the verifiable origin of attributes.
In this way IRMA distinguishes itself from "subjective" reputation-based
systems, in which qualifications can be manipulated relatively
easilty and their origin is seldomly transparent.
Bart Jacobs's avatar
Bart Jacobs committed
576
577
578
579
580
581
582
583
584
585
586
587

IRMA does not exclude commercial activities surrounding
authentication. But these commercial activities work best *on top of*
an open basic infrastructure, and not in its core.  Internet protocols
like TCP and IP are also open, and form the basis for the succes of
the internet, together with all the commercial transactions that run
on top of TCP/IP.


[To the top](#top)


588
### <a name="signature"></a>8. What are attribute-based signatures?
Bart Jacobs's avatar
Bart Jacobs committed
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624

IRMA is primarily a system for attribute-based authentication: with
IRMA you can selectively disclose attributes about yourself. But IRMA
offers more, namely attribute-based digital signatures. This is still
in an experimental phase.

With a *traditional* "wet" signature a signer agrees to the content of
a signed document. Such a traditional signature typically includes
the name of the signer, the date/time of signing, and the signer's
handwritten "scribble".

A *digital* signature is an addition that is attached to a digital
document that can be generated exclusively with the personal
(cryptographic) key of the signer. This personal *private* key is
strongly bound to an individual via a certificate that contains the
associated public key. Digital signatures that satisfy certain
requirements have a legal status.

A big disadvantage of both tranditional and current digital signatures
is that they give very little information about who precisely signs,
in which capacity.

An attribute-based signature is a special digital signature in wich
the attachment to the document securely contains a number of
attributes of the signer. These attributes are visible to everyone who
checks the signature. In this way you can see for instance that a
written account of ilness has actually been signed by a medical
doctor, via the "medical doctor" attribute, possibly combined with the
signer's medical specialisation. Another example is a request from a
citizen to the authorities, say about some permit, which is signed
with the citizen's own national registration number included as
attribute. In this way the authorities recognise that the request
really comes from a particular citizen. Also payment orders can be
realised via attribute-based signatures, by including the bank account
number of the signer as attribute in the signature.

625
626
627
Attribute-based signatures are supported by the IRMA
software. Attribute-based signatures form a novel concept with
unprecented application possiblities.
Bart Jacobs's avatar
Bart Jacobs committed
628
629
630
631

[To the top](#top)


632
### <a name="disadvantages"></a>9. What are IRMA's disadvantages?
Bart Jacobs's avatar
Bart Jacobs committed
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658

The most important advantage of IRMA is: the user maintains and fully
controls his/her own attributes. But this is at the same time a
disadvantage: an IRMA user will have to do this actively.  This
requires some effort, and also some level of understanding how IRMA
works and what has to be done.

Your identity is a very valuable asset, which you have to handle with
care in the digital world. This is something we still have to learn
collectively. With IRMA it becomes transparent which of your
attributes are requested where. You first have to load those
attributes into the IRMA app on your mobile phone. And when these
attributes expire, you will have to renew them. And when you replace
your phone itself, you will have to reload all your attributes into
(the IRMA app on) your new device. All of this is a "hassle", which is
part of careful dealing with your digital identity. IRMA puts you in
control and helps you to handle your digital identity with the same
care that you have for your passport.

These are (possible) disadvantages for users. A "system" disadvantage
is that the traditional intermediary way of making money does not work
with IRMA: users cannot be profiled by attribute issuers, and there
are no third parties that have to be payed for each authentication
session, see [above](#architecture). For IRMA users this may actually
be an advantage.

659
660
661
662
663
664
665
However, the identity platform IRMA is economically viable. Issuance
and verification of attributes may form a commercial service, which
can be performed by third parties. Also, the Privacy by Design
foundation may issue certain specialised credentials for a
fee. Possibly, in order to maintain its activities in the long-term
future, the foundation may start charging IRMA users, for instance a
couple of Euros per year, for a basic set of attributes.
666
667


Bart Jacobs's avatar
Bart Jacobs committed
668
[To the top](#top)
669

670
### <a name="contribute"></a>10. How can I participate or contribute?
671

672
673
IRMA is an identity platform that is being built up from below, and is
not imposed from above. IRMA will have to prove itself, via convincing
Bart Jacobs's avatar
Bart Jacobs committed
674
applications. Several parties are currently working on this.
675

Bart Jacobs's avatar
Bart Jacobs committed
676
677
678
679
680
Do you value careful, privacy-friendly interaction with your
customers, and do you have a good idea for an IRMA application,
for instance in your webshop or within your organisation, do
[contact](/contact-en) the Privacy by Design foundation.
For instance, the foundation can:
681

Bart Jacobs's avatar
Bart Jacobs committed
682
683
684
685
686
* advice about the organisation of attributes for the intended application;
* advice about the usage of the open source software of the foundation;
* possibly extend this software for optimal use within your
  application; such extensions will in principle also be open source
  and be available for others.
687

Bart Jacobs's avatar
Bart Jacobs committed
688
689
690
The foundation may aks a to-be-determined financial contribution for
such advice, in order to maintain its own activities. The foundation
is a not-for-profit organisation, without commercial targets.
691

Bart Jacobs's avatar
Bart Jacobs committed
692
693
694
Even if you do not have a concrete application in mind, but wish to
contribute to the IRMA development, via your efforts or via a
financial contribution, do [get in touch](/contact-en).
695

Bart Jacobs's avatar
Bart Jacobs committed
696
[To the top](#top)