-
Notifications
You must be signed in to change notification settings - Fork 5
/
index.html
1178 lines (1109 loc) · 49.2 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
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
114
115
116
117
118
119
120
121
122
123
124
125
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
187
188
189
190
191
192
193
194
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
223
224
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
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
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
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
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
455
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
505
506
507
508
509
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
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
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
625
626
627
628
629
630
631
632
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
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<title>Engineering Privacy for Verified Credentials</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<!--
=== NOTA BENE ===
For the three scripts below, if your spec resides on dev.w3 you can check them
out in the same tree and use relative links so that they'll work offline.
-->
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove'></script>
<!--script src='./respec-w3c-common.js' class='remove'></script-->
<script src="./common.js"></script>
<script type="text/javascript" class="remove">
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "CG-DRAFT",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "data-minimization",
// subtitle
subtitle: "In Which We Describe Data Minimization, Selective Disclosure, and Progressive Trust",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
// previousPublishDate: "1977-03-15",
// previousMaturity: "WD",
// extend the bibliography entries
localBiblio: ccg.localBiblio,
github: "https://github.com/w3c-ccg/data-minimization",
includePermalinks: false,
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "https://w3c-ccg.github.io/data-minimization/",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "Lionel Wolberger", url: "" }
],
authors: [
{ name: "Brent Zundel", url: "",
company: "Evernym/Sovrin", companyURL: "https://www.evernym.com" },
{ name: "Irene Hernandez", url: "" },
{ name: "Christopher Allen", url: "" },
{ name: "Zachary Larson", url: "" },
{ name: "Katryna Dow", url: "https://www.meeco.me/",
company: "Meeco", companyURL: "https://www.meeco.me/" },
],
// name of the WG
wg: "Credentials Community Group",
// URI of the public WG page
wgURI: "https://www.w3.org/community/credentials/",
// name (with the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-credentials",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "https://www.w3.org/community/about/agreements/cla/",
maxTocLevel: 4,
inlineCSS: true
};
</script>
</head>
<body>
<section id='abstract'>
<p>
We often share information on the World Wide Web, though some of it is private.
The W3C Credentials Community Group focuses on how privacy can be enhanced when
attributes are shared electronically. In the course of our work, we have identified
three related but distinct privacy enhancing strategies: "data minimization,"
"selective disclosure," and "progressive trust." These enhancements are enabled with
cryptography. The goal of this paper is to enable decision makers, particularly
non-technical ones, to gain a nuanced grasp of these enhancements along with some
idea of how their enablers work. We describe them below in plain English, but with
some rigor. This knowledge will enable readers of this paper to be better able to
know when they need privacy enhancements, to select the type of enhancement needed,
to assess techniques that enable those enhancements, and to adopt the correct
enhancement for the correct use case.
</p>
</section>
<section id='sotd'>
</section>
<section>
<h1>Introduction</h1>
<p>
We often share information on the World Wide Web, though some of it is private.
The W3C Credentials Community Group focuses on how privacy can be enhanced when
attributes are shared electronically. In the course of our work, we have identified
three related but distinct privacy enhancing strategies: "data minimization,"
"selective disclosure," and "progressive trust." These enhancements are enabled with
cryptography. The goal of this paper is to enable decision makers, particularly
non-technical ones, to gain a nuanced grasp of these enhancements along with some
idea of how their enablers work. We describe them below in plain English, but with
some rigor. This knowledge will enable readers of this paper to be better able to
know when they need privacy enhancements, to select the type of enhancement needed,
to assess techniques that enable those enhancements, and to adopt the correct
enhancement for the correct use case.
</p>
</section>
<section>
<h1>Three examples</h1>
<p>
Three examples of how people would like their privacy preserved in the process
of sharing credentials help to illuminate these three techniques.
</p>
<p>
<strong>Diego</strong> attempts to use an online service and is asked to share his
location in order to prove his geolocation. Diego hesitates, since the service
doesn't need his location everyday, everywhere. He knows that the service may
share this information with other parties without meaningful consent on his part.
Thoughts pass through his mind: What location data does the service actually need?
What will it read in future? Is there a way for him to share his location just this
once, or to only share an approximate location?
</p>
<p>
<strong>Selena</strong> hands her driver's license to a bouncer to prove she is
of drinking age. As he looks it over, she sees him inspecting her date of birth
and home address. He only needs to know that she is over 21. Is there a way to
disclose that she is indeed old enough without revealing her actual age, along
with her home address and city of residence as well?
</p>
<p>
<strong>Proctor</strong>, negotiating with a real estate agent to purchase a home,
reveals a
letter from his bank stating his credit limit. He wanted to reveal its approximate
amount only, but the agent insisted on verifying that the letter was authentic.
Proctor feels the agent now has the upper hand in the negotiation, as the letter
reveals more than just its authenticity. Could he have revealed only an approximate
amount and reveal more details as the negotiations progress?
</p>
<p>
Each story features information that is verifiable: a home address, age, or
credit limit. We call such information a credential, and a detail of a credential
we call an attribute. We have three strategies for enhancing the privacy of
digitally shared credential attributes, and each story highlights one. Diego's
story highlights the need for "data minimization," Selena's for "selective
disclosure," and Proctor's for "progressive trust." Let's examine each one in
detail before discussing enablers.
</p>
</section>
<section>
<h1>Privacy Enhancements</h1>
<p>
We propose the following three privacy enhancements. (Sources used to curate
these definitions are listed in <a href="#definition-sources"></a>.)
</p>
<section>
<h2>Data Minimization</h2>
<p>
Data minimization is the act of limiting the amount of shared data strictly to
the minimum necessary in order to successfully accomplish a task or goal. There
are three types of minimization:
</p>
<ul>
<li>
Content minimization – the amount of data should be strictly the minimum necessary.
</li>
<li>
Temporal minimization – the data should be stored by the receiver strictly for
the minimum amount of time necessary to execute the task.
</li>
<li>
Scope minimization – the data should only be used for the strict purpose of the
active task.
</li>
</ul>
<p>
Data minimization is enacted primarily by policy decisions made by stakeholders
in the credentials ecosystem:
</p>
<ul>
<li>
Credential issuers ensure that credentials may be presented in such a way as to
enable data minimization. This may require issuing multiple, related, granular
sub-credentials.
</li>
<li>
Credential inspectors establish in advance policies regarding the data they will
examine:
<ul>
<li>
what is the minimum data necessary to accomplish the task or goal?
</li>
<li>
what is the minimum time the data can be stored to execute the task?
</li>
<li>
what processes ensure that the data is applied only to the task at hand and does
not, by a process of scope creep, become applied to other tasks or goals?
</li>
</ul>
</li>
</ul>
<p>
Data minimization policies impact selective disclosure, the next privacy enhancement.
</p>
</section>
<section>
<h2>Selective Disclosure</h2>
<p>
Selective disclosure is the ability of an individual to granularly decide what
information to share. Stakeholders in the credentials ecosystem enable selective
disclosure capabilities in the following ways:
</p>
<ul>
<li>
Credential issuers format the credential and its attributes in such a way as to
enable selective disclosure. As with the strategy of data minimization, they may
issue multiple, related, granular sub-credentials. Each attribute and the overall
credential may be formatted to support cryptography, a capability described in
more detail below.
</li>
<li>
Credential inspectors ensure the request is framed in such a way as to enable
selective disclosure, using the cryptographic tools required.
</li>
</ul>
<p>
Once data minimization policies and selective disclosure are in place, the third
and last enhancement can be applied.
</p>
</section>
<section>
<h2>Progressive Trust</h2>
<p>
Progressive trust is the ability of an individual to gradually increase the
amount of relevant data revealed as trust is built or value generated.
</p>
<p>
To enable progressive trust capabilities, stakeholders in the credentials ecosystem
act in the following ways:
</p>
<ul>
<li>
Issuers format the credential(s) in such a way as to enable progressive trust.
This may require issuing multiple, related, atomic sub-credentials. It also may
require formatting the credential to support mathematical queries and cryptographic
proofs. Finally, the issuer's data model may express how the various sub-credentials
are related in a scenario involving progressive trust.
</li>
<li>
Inspectors ensure that requests are framed in such a way as to enable progressive
trust. They structure the communication in order to to gradually escalate credential
requests in order to enable a subject to progressively trust the inspector more
and more, revealing the minimum data necessary to accomplish each step of the
task or goal and revealing more and more as the mutual communication progresses.
</li>
</ul>
</section>
</section>
<section>
<h1>Crypto Enablers</h1>
<p>
Implementing privacy enhancements depends on organizational decisions.
Determination of the data needed, with an eye towards data minimization, along
with a clear model of how data is used over the lifecycle of engagement, goes a
long way towards enabling progressive trust. However, policies are not enough.
When enhancing privacy online, some data parts must be revealed while others
remain concealed. Concealment is achieved mostly by the art of cryptography,
from the greek word "kryptos," meaning hidden, like in a crypt. Crypto (a short
word we will use for cryptography) enables us to achieve our goal by means of
three primary enablers: having a secret, having a difficult mathematical task,
and having zero-knowledge enablers. The children's "Where's Waldo?" illustrated
book series helps us to understand these three enablers. In these books a
distinctively dressed man appears only once on each page, wearing a striped hat.
Readers are asked to scour the page and locate him. We can understand the three
enablers by examining Where's Waldo one step at a time.
</p>
<ul>
<li>
<strong>A Secret</strong>: For the new reader, Waldo's location is a secret. The
illustrator knows it, and the reader doesn't. The reader is encouraged to search
the page and find Waldo, but that is a difficult task. Some readers give up and
ask someone who has already found Waldo to show them his location. In essence,
they are asking another reader to reveal the secret. Once found, a reader could
keep the information secret by circling Waldo in red and storing the book in a
safe. This amounts to storing the secret for future use. Secrets are essential
to crypto. They are usually called keys, and they must be managed carefully.
</li>
<li>
<strong>A Difficult Task</strong>: Waldo is difficult to find on the page. The
reader has to search everywhere and mistakenly identify many Waldo look-alike
characters before reaching a satisfactory conclusion and finding him. Yet when
he is finally discovered, or someone points Waldo out, it's easy to see where he
is. That's why it's a fun task. This difference between the difficulty of
conducting the task and the ease of verifying the task lies at the heart of
cryptographic enablers.
</li>
<li>
<strong>A Zero Knowledge Enabler</strong>: Can you prove you found Waldo without
revealing the secret of his actual location on the page? There is a simple way to
do so. Take a rectangular piece of white cardboard that is much larger than the
book. Cut a hole exactly fitting Waldo to reveal his silhouette only, nothing else.
You can now show Waldo to anyone, peeking out of the cardboard. Yet the cardboard
is wide and opaque, hiding the book thoroughly, so a verifier has no idea where
Waldo is on the page. The puzzle was solved and someone verified the achievement,
without revealing any knowledge of how to solve the puzzle. The secret is still
safe, the task still just as difficult as before.
</li>
</ul>
<p>
Where's Waldo books are drawings, while crypto is built from mathematical
equations, basically puzzles based on numbers. We provide the interested reader
with a layman's overview in <a href="#basic-crypto-concepts"></a>.
</p>
</section>
<section>
<h1>Three Solutions</h1>
<p>
We now return to our opening examples, apply the privacy preserving strategies
and enablers described, and describe the improved outcomes.
</p>
<p>
The online service that <strong>Diego</strong> uses does an internal policy
review and realizes (a) it only needs a location when a user signs up for an
account, and (b) it does not need an exact address, only the county district. It
changes its interface to request a Verifiable Credential for Diego's location.
Diego's system creates this credential for him, which can be inspected to reveal
the county district. The crypto to enable this would be similar to that described
in <a href="#drinking-age-credential-implementation"></a>. With this data
minimization, the online service has less risk of violating data protection rules,
is less a target for hacking, and has lower overall costs, while at the same time
preserving Diego's privacy.
</p>
<p>
The bar seeking to verify <strong>Selena</strong>'s age uses selective disclosure
as built into the Verifiable Claims system. Selena will no longer share her date
of birth. Instead, Selena creates a secret that we harness to craft a
crypto-formatted credential. This crypto makes it easy to verify her age, but
difficult to determine her exact date of birth. The bouncer's system can perform
a zero-knowledge proof to determine the credential is valid and that Selena is
older than twenty-one, without revealing her birthday or her secret. The bouncer
sees she is over twenty-one without seeing her date of birth, residence address,
or any other unnecessary information. In <a href="#drinking-age-credential-implementation"></a>
we show the process step-by-step.
</p>
<p>
The real estate agency working with <strong>Proctor</strong> implements a data
model specifying what is required at each step of the real estate negotiation.
The first step requires only proof of being an account holder in good standing
at a known bank, so Proctor does not have to reveal the detailed letter at this
point. As their negotiation continues, Proctor reveals more and more information
as required. Some steps of the process may share Verifiable Claims encoded with
crypto.
</p>
</section>
<section>
<h1>Summary</h1>
<p>
The World Wide Web accelerates the sharing of credentials and other digital
interactions, and many regulations have been passed and strategies proposed to
protect privacy, some of which require cryptography. To align terminology, the
World Wide Web Credentials Community Group has found three related but distinct
privacy enhancing strategies that create a useful rubric for discussing the
challenges and arriving at solutions. We share the examples of Diego, Selena,
and Proctor and propose "data minimization," "selective disclosure," and
"progressive trust," with accompanying crypto protocols as useful semantics for
accelerating the adoption of digital interaction while protecting privacy.
</p>
</section>
<section class="appendix">
<h1>Definition Sources</h1>
<p>
This section contains definitions we curated, based on research and oral
interviews, to create the definitions of data minimization, selective disclosure
and progressive trust.
</p>
<section>
<h2>Data Minimization</h2>
<p>
Definitions of data minimization that we considered in the formation of our
definition above.
</p>
<ul>
<li>
GDPR Rec.39; Art.5(1)(c) definition: “The personal data should be adequate,
relevant and limited to what is necessary for the purposes for which they are
processed. This requires, in particular, ensuring that the period for which the
personal data are stored is limited to a strict minimum. Personal data should be
processed only if the purpose of the processing could not reasonably be fulfilled
by other means.”
</li>
<li>
Reducing your overall footprint of data outside of your control. Can be
accomplished by using selective disclosure.
</li>
<li>
Adequate, relevant and non-excessive.
</li>
<li>
Reducing the amount of data you are sending in a payload to only the one ...
needed. That prevents leakage of confidential information.
</li>
<li>
Providing people with the information they need without revealing non necessary
info. If I need to prove if I am old enough without revealing an actual birthdate.
</li>
<li>
Best practices – your should deeply inspect your use case and come to a
conclusion as to what is the minimum data you need to accomplish your goal. Don’t
be greedy. Data has proven to be toxic.
</li>
<li>
Mathematical – finding a way to express the data that you wish as an equation
related to the data you have.
</li>
<li>
Minimizing the amount of data to achieve your goal or communicate what you need
to.
</li>
<li>
Designing systems to operate efficiently in order to maximize privacy.
</li>
<li>
Choosing to only share the minimal amount of data about yourself or something
during an interaction.
</li>
<li>
Trying to keep the amount of info that is being disclosed as limited as possible
to the requirements of the vulnerability. The minimum is what ... will lead them
to move to action.
</li>
<li>
Always happens in a context: a relationship where the two parties are considering
interacting in some way. Sending only the signals that I want to send and that
are needed by the other party, hem to interact with me in a particular.
</li>
<li>
The least amount of data needed for a system to function.
</li>
<li>
Collecting the least amount of date for the highest outcome.
</li>
<li>
Also known as minimal disclosure, data minimization is the principle of using
the least amount of data to accomplish a transaction. This is incumbent on all
three parties in an exchange. The holder should attempt to share the minimum.
The issuer needs to create attributes designed for composition and minimal use,
as opposed to monolithic credentials with all the data. The verifier needs to
ask only for what they need. The motivation to minimize data is that unneeded
data is potentially “toxic.”
</li>
</ul>
</section>
<section>
<h2>Selective Disclosure</h2>
<p>
Definitions of selective disclosure that we considered in the formation of our
definition above.
</p>
<ul>
<li>
Ability to decide what info you give and how it can be used.
</li>
<li>
Smart disclosure, allows [selecting] what information to give based on logic.
</li>
<li>
Blind search. You can decide who gets to see what.
</li>
<li>
Means by which we achieve data minimization. Form of policies. Ability to mask
attributes that you do not have to share.
</li>
<li>
Relates to mathematical definition – the computational ability to reveal only
parts of your data profile.
</li>
<li>
Act of communicating or revealing only what you intend to, and not any peripheric
data.
</li>
<li>
Having granular control over the ways in which data is shared.
</li>
<li>
Is a pattern for user interfaces allowing people to choose what to share about
them during an interaction.
</li>
<li>
Method for achieving data minimization where only certain signals are being
shared and there is control of who it is being shared with. That control is
never perfect. The communication channel matters.
</li>
<li>
An entity having granular control on what’s revealed.
</li>
<li>
The individual having the freedom to decide what to share, or the acquirer using
data minimization approach requesting the minimum amount amount of data for the
maximum impact.
</li>
</ul>
</section>
<section>
<h2>Progressive Trust</h2>
<p>
Definitions of progressive trust that we considered in the formation of our
definition above. Note that we included definitions of progressive trust and
progressive disclosure as well.
</p>
<ul>
<li>
Procedure for increasing revelation of relevant data as the communication proceeds.
As we continue to communicate we decide to reveal more information. It becomes more
generous as trust builds.
</li>
<li>
Being able to reveal more data as you need to given certain conditions
</li>
<li>
Information is disclosed as needed when needed.
</li>
<li>
You can choose to increase the amount of data you disclose over time as needed.
</li>
<li>
Taking as little vulnerability as possible at the beginning, then gaining
information and becoming willing to take on additional vulnerability by revealing
more information.
</li>
<li>
Trust is built through step by step interactions where we start making ourselves
vulnerable in a very small way and we observe how this works out. Based on results
we consider making ourselves further vulnerable or not. It is about increasing
levels of familiarity and prediction making (I am better able to predict your
behavior).
</li>
<li>
Releasing information as needed.
</li>
<li>
Escalation of the previous steps (data minimization, selective disclosure) in
line with the value increasing.
</li>
<li>
Purpose binding is the auditable use of data, so I can audit the use of my data
and determine that it was used for the purposes declared. Progressive trust is
the feeling of assurance and safety that develops over time, based on a history
of data used only for its bound purposes, and so based on this feeling a data
holder will be ready to share more data or other data, if at some point in the
relationship this other data is requested.
</li>
Trust is required when you depend on the actions of someone who you can't control.
</ul>
</section>
</section>
<section class="appendix">
<h1>Basic Crypto Concepts</h1>
<p>
This appendix describes basic cryptographic concepts critical to the privacy
preserving engineering of credential attributes. For readability, we use the short
word, "crypto."
</p>
<section>
<h2>Overview</h2>
<p>
Crypto is a huge field with highly specialized jargon, too much to cover here.
But non-specialists would benefit from some understanding of relevant crypto in
order to make informed decisions. We begin with a brief overview of several
concepts from number theory that serve as a foundation for all crypto used in
this process. This is a curated list of topics progressing from the simple to
the more complex. Notice how ideas are re-used and layered as you read on.
</p>
</section>
<section>
<h2>Number Theory</h2>
<p>
Number theory refers to the study of the behavior of integer numbers such as one,
three, or two hundred. The following are behaviors of these numbers that make them
useful for crypto:
</p>
<ul>
<li>
<strong>Prime or not</strong>: Some numbers are only divisible by themselves and
one. These are called 'prime.'
</li>
<li>
<strong>One-way function</strong>: A numerical function that takes a publicly
known number, and without any secret information, computes a value. Like a
one-way street, the computation goes only one direction. Given the computed
value, it is hard to find the publicly known number.
</li>
<li>
<strong>Clock arithmetic</strong>, aka modular arithmetic: a system of arithmetic
where numbers "wrap around" upon reaching a certain value. A familiar use is in
the ordinary clock, in which our day is divided into twelve-hour periods. If the
time is seven o'clock now, then ten hours later it will be five o'clock, though
a military man might say seventeen hundred hours. Even he will say that ten hours
later it is three o'clock, and not twenty-seven hundred hour, because his clock
time "wraps around" every twenty-four hours (as opposed to twelve).
</li>
<li>
<strong>Groups and Finite Fields</strong>: Some subsets of all integers form a
"group" that behaves in ways very useful to the performance of cryptography. In
extremely simplified terms, a group is a self-sufficient set of integers, where
any possible manipulation returns an answer from within the group. Finite fields
are types of groups that satisfy certain demanding properties. Notice how this
resembles clock arithmetic, where the same numbers are used over and over again.
</li>
<li>
<strong>Discrete Logarithms</strong>: A discrete logarithm is a property for
numbers in a group. Since there is no efficient method for computing discrete
logarithms, they form a "difficult problem" and so are very useful in cryptography.
(The logarithm <code>log(b)</code> of <code>a</code> is an exponent <code>x</code>
such that <code>b^x</code> (<code>b</code> raised to the <code>x</code> exponent)
= <code>a</code>.)
</li>
<li>
<strong>Quadratic Residues</strong>: Quadratic refers to 'squared' numbers, a
number raised to the second exponential power. Quadratic residues are a useful
property of squared numbers as they behave in modular arithmetic.
</li>
</ul>
</section>
<section>
<h2>Primary Objectives</h2>
<p>
The curious behavior of numbers is exploited to achieve four primary crypto
objectives.
</p>
<ul>
<li>
<strong>Confidentiality</strong>: a hidden part of a credential cannot be understood
by anyone for whom it is unintended. Often called "privacy," we avoid that word
here since it can mean many things in addition to confidentiality.
</li>
<li>
<strong>Authentication</strong>: the identity of information shared can be
validated as authentic.
</li>
<li>
<strong>Integrity</strong>: the revealed part of the credential cannot be altered
without such alteration being detected. Also known as validity, fidelity or
verifiability.
</li>
<li>
<strong>Non-repudiation</strong>: aka non-deniability, a credential's creator
cannot deny at a later stage his or her involvement.
</li>
</ul>
</section>
<section>
<h2>Ten Crypto Concepts</h2>
<p>
Over the decades hundreds if not thousands of crypto protocols, processes,
algorithms and protocols have been innovated to achieve these objectives, by
cobbling together the above six behaviors in different ways. We present here a
brief tour of the ten most significant ones in our field of verifiable credentials:
</p>
<ul>
<li>
<strong>PKI</strong> or "public and private keys": a system that lies at the
heart of most relevant crypto since a publicly shared digital asset can be locked
to, or encumbered by, a private key that is kept secret. Only the person with
knoweldge of that private key can, with the right software, unlock that asset.
This enables a broad range of activities such as "signature," "authentication,"
and "certificate validation." In general we call these activities PKI, a public
key infrastructure.
</li>
<li>
<strong>Signature</strong>: a signature in this context is a use of PKI. A valid
signature gives a recipient "authentication", confidence that the message was
created by a known sender; "non-repudiation," that the sender cannot deny having
sent the message; and "integrity," that the message was not altered in transit.
Signatures enable every cryptographic objective except for confidentiality. There
are many types of signature schemes in use including Digital Signature Algorithm
(DSA), Camenisch-Lysyanskaya (CL) signatures, and Boneh–Lynn–Shacham (BLS)
signatures.
</li>
<li>
<strong>Key exchange</strong>: exchange methods enable two parties that have no
prior knowledge of each other to jointly establish a shared secret key over an
insecure channel. This key can then be used to encrypt subsequent communications
using a symmetric key cipher. Diffie–Hellman is a common example.
</li>
<li>
<strong>Elliptic-curve cryptography</strong> (ECC): an approach to PKI based on
the numeric structure of elliptic curves over finite fields. ECC is useful as it
requires smaller keys compared to non-ECC cryptography. There are many variants
of ECC used including Edwards-curve Digital Signature Algorithm (EdDSA).
</li>
<li>
<strong>Hash or message digest</strong>: one-way functions, such as SHA-256. A
set of many one-way functions may be applied to a tree of data to form a Merkle
Tree (or trie).
</li>
<li>
<strong>Zero-Knowledge</strong> (ZK): zero knowledge is defined above loosely as
a set of practices where some data is revealed while other parts are kept secret.
Many ZK methods are used in cryptography incuding Fiat Shamir, Proof of knowledge
of discrete logarithms, ZK Snarks, and ZK Starks.
</li>
<li>
<strong>Accumulators</strong>: a form of ZK, a cryptographic accumulator is a
one-way membership function that answers a query as to whether a potential
candidate is a member of a set without revealing the individual members of the set.
Similar to a one-way hash function, cryptographic accumulators generate a
fixed-size digest representing an arbitrarily large set of values. Some further
provide a fixed-size witness for any value of the set, which can be used together
with the accumulated digest to verify its membership in the set.
</li>
<li>
<strong>Commitment</strong>: a cryptographic commitment, which allows one to
commit to a chosen value (or chosen statement) while keeping it hidden to others,
with the ability to reveal the committed value later.
</li>
<li>
<strong>Witness</strong>: a term that has different applications in cryptography.
In this paper, a witness is a value used in a cryptographic accumulator. In
Bitcoin the unlocking signature is called the "witness data."
</li>
<li>
<strong>Quantum Computing</strong> and Cryptography: as quantum computing is
developed, it poses a threat to the difficulty of puzzles. For example, they are
likely to be much faster at determining if a number is truly prime or not.
</li>
</ul>
</section>
</section>
<section class="appendix">
<h1>Drinking Age Credential Implementation</h1>
<p>
The birthday of an individual is formatted into a verifiable credential, which
can be inspected to reveal the age of the credential holder without revealing
their birthdate. The flow described here is based on the developing Verifiable
Claims standard of the W3C Credentials Community Group. It uses cryptography
developed by Jan Camenisch, as implemented by Sovrin.
</p>
<p>
This is a work in progress. Note that other types of crypto could be applied to
achieve the same privacy preserving goals.
</p>
<section>
<h2>Communication Flow</h2>
<p>
The flow below may be copies and pasted into the [[WEB-SEQ]] webpage to generate
a flow diagram.
</p>
<pre>
title Verifiable credential using Selective Disclosure
participant Valid Time Oracle
participant Janet
participant ID Provider
participant Ledger
participant Bar
note over Janet:Prover
note over Bar:Validator
note over Janet,Bar: Preparation and Setup
note right of ID Provider:Infrastructure
ID Provider->Ledger: Define Schema (Name, Birthdate, Address)
ID Provider->Ledger: credential Definition (Pub Key, etc.)
ID Provider->ID Provider: Generate Prv Key for this credential
ID Provider->Ledger:Revocation Registry
note left of Bar: Prepare to accept credentials
Bar->Bar:Install Agent
Bar->Ledger: Check schema
note over Janet,Bar: Begin Use Case
Janet->ID Provider: Request ID
ID Provider-->Janet: ID will be issued as a digital credential
note right of Janet: Prepare to receive credentials
Janet->Janet: Install Agent
Janet->Janet: Prv Key Generate, Store
Janet->Ledger:Check Schema
Ledger->Janet:credential Definition
Janet-->ID Provider:Proof of Name, Birthdate, Address
Janet->ID Provider: Blinded secret
ID Provider->Janet: credential
Janet->Janet: Validate credential against credential Def
note over Janet,Bar: Janet goes to the bar
note left of Bar: Can Janet Enter?
Bar->Janet: Request Proof of Age
Janet->Valid Time Oracle: Get time
Valid Time Oracle->Janet: Time credential
Janet->Janet:Generate Proof (This person is over 21)
Janet->Bar: Provide Proof
Bar->Bar: Evaluate proof
Bar->Ledger: Verify on Ledger
Ledger->Bar: Verification
Bar->Janet: Come in
note left of Bar: Invite to club
Bar->Janet: Join loyalty club? (requires valid postal code)
Janet->Janet:Generate Proof (postal code)
Janet->Bar: Provide Proof
Bar->Bar: Evaluate proof
Bar->Ledger: Verify on Ledger
Ledger->Bar: Verification
Bar->Janet: Have Loyalty Card
</pre>
</section>
<section>
<h2>Crypto Details</h2>
<p>
Below are some of the detailed mathematics involved in issuing a verifiable
credential as implemented by Sovrin, a non-profit organization dedicated to
managing a decentralized, public network for the purposes of self-sovereign
identity.
</p>
<section>
<h3>Issuer Setup</h3>
<p>
The following setup is a necessary precursor to issuing a privacy-preserving
credential.
</p>
<section>
<h4>Compute</h4>
<p>
Perform the mathematical calculations required to curate the essential
ingredients of the operations we are about to perform. Some of these results,
like the private keys, are very sensitive and must be kept secret by the credential
holder; others are to be shared.
</p>
<ul>
<li>
Random 𝓹', 𝓺', 1024-bit prime numbers, such that 𝓹 = 2𝓹' + 1 and 𝓺 = 2𝓺' + 1 are
both 1024-bit prime numbers.
</li>
<li>
𝓷 = 𝓹𝓺.
</li>
<li>
Random quadratic residue: 𝓢 mod 𝓷
</li>
<li>
Random 𝓧<sub>𝓩</sub>, 𝓧<sub>𝓡1</sub>, . . . , 𝓧<sub>𝓡𝓵</sub> ∈ \[2: 𝓹'𝓺' - 1\],
where 𝓵 is the number of attributes in the credential.
</li>
<li>
𝓩 = 𝓢<sup>𝓧𝓩</sup> mod 𝓷
</li>
<li>
𝓡<sub>𝓲</sub> = 𝓢<sup>𝓧𝓡𝓲</sup> mod 𝓷, 1 ≤ 𝓲 ≤ 𝓵
</li>
<li>
Issuer private key 𝓼𝓴<sub>𝓬</sub> = 𝓹'𝓺'
</li>
<li>
Issuer public key 𝓹𝓴<sub>𝓬</sub> = {𝓷, 𝓢, 𝓩, 𝓡<sub>1</sub>, . . . , 𝓡<sub>𝓵</sub> }
</li>
</ul>
</section>
<section>
<h4>Proof of Correctness</h4>
<p>
As a result of the above computations, we then curate the following. This proof,
along with the public keys, is the computational algorithm that will be used to
validate the credential.
</p>
<ul>
<li>
Random 𝓧'<sub>𝓩</sub>, 𝓧'<sub>𝓡1</sub>, . . . , 𝓧'<sub>𝓡𝓵</sub> ∈ \[2: 𝓹'𝓺' - 1\]
</li>
<li>
𝓩' = 𝓢<sup>𝓧'𝓩</sup> mod 𝓷
</li>
<li>
𝓡'<sub>𝓲</sub> = 𝓢<sup>𝓧'𝓡𝓲</sup> mod 𝓷, 1 ≤ 𝓲 ≤ 𝓵
</li>
<li>
𝓬 = 𝓗𝓪𝓼𝓱 ( 𝓩 || 𝓡<sub>1</sub> || . . . || 𝓡<sub>𝓵</sub> || 𝓩' || 𝓡'<sub>1</sub>
|| . . . || 𝓡'<sub>𝓵</sub> )
</li>
<li>
𝓧''<sub>𝓩</sub> = 𝓧'<sub>𝓩</sub> + 𝓬 𝓧<sub>𝓩</sub>
</li>
<li>
𝓧''<sub>𝓡𝓲</sub> = 𝓧'<sub>𝓡𝓲</sub> + 𝓬 𝓧<sub>𝓡𝓲</sub> , 1 ≤ 𝓲 ≤ 𝓵
</li>
</ul>
<p>
The Cred Def is comprised of the public key and the proof of correctness;
this is published to the distributed ledger.
</p>
</section>
</section>
<section>
<h3>Issuing a Credential</h3>
<p>
With setup complete, we can now issue the credential in a privacy-preserving
manner.
</p>
<section>
<h4>For Each Credential</h4>
<p>
For each credential issued, perform the following operations.
</p>
<section>
<h5>Issuer Computes</h5>
<p>
A cryptographic accumulator is constructed in order to enable zero-knowledge
queries further on. It is a one-way membership function, including the claim in
the membership set. The operation can then answers a query as to whether a
potential candidate is a member of a set without revealing the individual members
of the set.
</p>
<ul>
<li>
𝓐<sub>𝓲</sub> = accumulator index
</li>
<li>
𝓤<sub>𝓲</sub> = user index
</li>
<li>
𝓶<sub>2</sub> = 𝓗𝓪𝓼𝓱 ( 𝓐<sub>𝓲</sub> || 𝓤<sub>𝓲</sub> )
</li>
<li>
256-bit integer representations of each of the attributes: 𝓶<sub>3</sub> , . . . ,
𝓶<sub>𝓵</sub>
</li>
<li>
𝓷<sub>0</sub> = nonce
</li>
</ul>
</section>
<section>
<h5>Issuer Sends 𝓷<sub>0</sub> to Prover</h5>
<p>
This nonce is provided to the Prover for calculation of the Prover's proof of
correctness.
</p>
</section>
<section>
<h5>
Prover Receives 𝓷<sub>0</sub> and Computes the Following
</h5>
<p>
The prover aggregates and prepares public keys for use in validating the
signatures. The prover also commits to a chosen value while keeping it temporarily
hidden, making the calculation binding.
</p>
<ul>
<li>
Retrieves Issuer’s public key 𝓹𝓴<sub>𝓬</sub>
</li>
<li>
Retrieves Issuer’s proof of correctness
</li>
<li>
Generates:
<ul>
<li>
𝓶<sub>1</sub> = pedersen commitment of claim link secret
</li>