forked from w3c/did-rubric
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
4329 lines (4262 loc) · 142 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 lang="en">
<head>
<meta charset="utf-8">
<title>DID Method Rubric v1.0</title>
<script src="https://www.w3.org/Tools/respec/respec-w3c" defer="defer" class="remove"></script>
<script class='remove' src="./common.js"></script>
<script class='remove'>
// See https://github.com/w3c/respec/wiki/ for how to configure ReSpec
var respecConfig = {
// the W3C WG and public mailing list
group: "did",
wgPublicList: "public-did-wg",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "did-rubric",
// specification status (e.g., WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "FPWD-NOTE",
// Editor's Draft URL
edDraftURI: "https://w3c.github.io/did-rubric/",
// subtitle for the spec
// subtitle: "A reproducible method for evaluating DID Methods",
// if you wish the publication date to be other than today, set this
publishDate: "2021-08-26",
//previousMaturity: "ED",
// automatically allow term pluralization
pluralize: true,
// extend the bibliography entries
localBiblio: ccg.localBiblio,
github: {
repoURL: "https://github.com/w3c/did-rubric/",
branch: "main"
},
includePermaLInks: false,
noRecTrack: "true",
maxTocLevel: 3,
// list of specification editors
editors: [{
name: "Joe Andrieu",
company: "Invited Expert",
url: "http://legreq.com",
w3cid: 97261
}, {
name: "Daniel Hardman",
url: "https://www.linkedin.com/in/danielhardman/",
company: "Invited Expert",
w3cid: 108790
}],
// list of specification authors
authors: [{
name: "Joe Andrieu",
company: "Invited Expert",
url: "http://legreq.com",
w3cid: 97261
},
{
name: "Daniel Hardman",
url: "https://www.linkedin.com/in/danielhardman/",
company: "Invited Expert",
w3cid: 108790
},
{
name: "Shannon Appelcline"
},
{
name: "Amy Guy"
},
{
name: "Joachim Lohkamp"
},
{
name: "Drummond Reed",
url: "https://www.linkedin.com/in/drummondreed/",
company: "Evernym",
companyURL: "https://www.evernym.com/",
w3cid: 3096
},
{
name: "Markus Sabadello",
url: "https://www.linkedin.com/in/markus-sabadello-353a0821",
company: "Danube Tech",
companyURL: "https://danubetech.com/",
w3cid: 46729
},
{
name: "Oliver Terbu"
}
]
};
</script>
</head>
<body>
<section id="abstract">
<p>
The communities behind Decentralized Identifiers (DIDs) bring together a
diverse group of contributors who have decidedly different notions of exactly
what "decentralization" means.
</p>
<p>
Rather than attempting to resolve this potentially unresolvable question, we
propose a rubric — a scoring guide used to evaluate performance, a
product, or a project — that teaches how to evaluate a given DID Method
according to one's own requirements.
</p>
<p>
This rubric presents a set of criteria which an <a>Evaluator</a> can apply to
any DID Method based on the use cases most relevant to them. We avoid reducing
the Evaluation to a single number because the criteria tend to be multidimensional
and many of the possible responses are not necessarily good or bad. It is up
to the <a>Evaluator</a> to understand how each response in each criteria might
illuminate favorable or unfavorable consequences for their needs.
</p>
<p>
While this rubric allows the evaluation of many aspects of decentralization of
a DID Method, it is not exhaustive, and does not cover other factors that may
affect selection or adoption of a particular Method, such as privacy, security,
reliability, or efficiency.
</p>
</section>
<section id="sotd">
</section>
<section class="informative">
<h2>Introduction</h2>
<section>
<h3>Background</h3>
<p>
A rubric is a tool used in academia to communicate expectations and evaluate
performance. It consists of a set of criteria to be evaluated, possible
responses for each criteria, and a scoring guide explaining both how to
choose and interpret each response. The act of evaluating a rubric, which we
call an Evaluation, provides basis for self-evaluation, procurement decisions,
or even marketing points. Written records of
an evaluation, which we'll call an <a>Evaluation Report</a>, document how a
particular subject is measured against the criteria. For students, a rubric
helps to clarify how their work will be evaluated by others. For
<a>Evaluator</a>s, a rubric provides a consistent framework for investigating
and documenting the performance of a subject against a particular set of
criteria.
</p>
<p>
We were inspired to develop a rubric for
decentralization when discussions about the requirements for decentralized
identifiers, aka DIDs, led to intractable disagreement. It became clear that
no single definition of "decentralized" would suffice for all of the
motivations that inspired developers of DID Methods to work on a new
decentralized approach to identity. Despite this challenge, two facts remained
clear:
</p>
<ol>
<li>
the people invested in this work shared a common goal of reversing the
problems with centralized identity systems and
</li>
<li>
they also had numerous, distinct reasons for doing so.
</li>
</ol>
<p>
Rather than attempt to force a definition of "decentralized" that might work
for many but would alienate others, the group set out to capture the
measurable factors that could enable <a>Evaluator</a>s to judge the
decentralization of DID Methods based on their own independent requirements,
with minimal embedded bias.
</p>
</section> <!-- background -->
<section>
<h3>How to apply this rubric</h3>
<p>
Pick the most important criteria for your use, ask each question, and select the
most appropriate response. Do this for all of the DID
Methods under consideration.
</p>
<p>
Each <a>Evaluation</a> should start with an explicit framing of the use under
consideration. Are you evaluating the Method for use in Internet-of-Things
(IoT)? For school childrens' extra-curricular activities? For international
travel? The use, or set of uses, will directly affect how some of the
questions are answered.
</p>
<p>
Where a given Method offers variability, such as multiple networks for the
same Method, then evaluate each variant. For example, did:ethr supports
Ethereum mainnet, multiple testnets and permissioned EVM-compliant networks
such as Quorum. To apply a criteria to did:ethr, you will evaluate it against
all the variations that matter <em>to you</em>. Each variation should get its
own <a>Evaluation</a>. This applies to Level 2 Networks that can operate on
multiple Level 1 Networks as well as DID Methods that directly offer support
for multiple underlying DID registries.
</p>
<p>
When creating an <a>Evaluation Report</a>, we recommend noting both the
<a>Evaluator</a> and the date of the <a>Evaluation</a>. Many of the criteria
are subjective and all of them may evolve. Tracking who
made the <a>Evaluation</a> and when they made it will help readers better
understand any biases or timeliness issues that may affect the applicability
of the <a>Evaluation</a>.
</p>
<p>
Be selective and acknowledge the subjective. <a>Evaluations</a> do not need to
be exhaustive. There is no requirement to answer all the questions. Simply
answer the ones most relevant to the use contemplated. Similarly, understand
that any recorded <a>Evaluation</a> is going to represent the biases of the
<a>Evaluator</a> in the context of their target use. Even the same
<a>Evaluator</a>, evaluating the same Method for a different use, may come up
with slightly different answers—for example, that which is economically
accessible for small businesses might not be cost-effective for refugees, and
that could affect how well-suited a given Method is for a specific use.
</p>
<p>
Finally, note that this particular rubric is about decentralization. It
doesn't cover all of the other criteria that might be relevant to evaluating a
given DID Method. There are security, privacy, and economic concerns that
should be considered. We look forward to working with the community to develop
additional rubrics for these other areas and encourage <a>Evaluator</a>s to
use this rubric as a starting point for their own work rather than the final
say in the merit of any given Method.
</p>
<p>
In short, use this rubric to help understand if a given DID Method is
decentralized enough for your needs.
</p>
</section> <!-- how to apply -->
<section>
<h3>Evaluation reports</h3>
<p>
To record and report an <a>Evaluation</a>, we recommend two possible formats,
either comprehensive or comparative.
</p>
<p>
A comprehensive <a>Evaluation</a> applies a single set of criteria to just one
Method. This set is chosen by the <a>Evaluator</a>; it need not be all
possible criteria, but it is all relevant criteria as judged by the
<a>Evaluator</a>.
</p>
<p>
A comparative <a>Evaluation</a> includes multiple Methods in the same table to
easily compare and contrast two or more different Methods. This may include
any number of criteria. These are the type of reports we use as examples
throughout the criteria list.
</p>
<p>
In addition to the selected criteria, we recommend each report specify
</p>
<ol>
<li>
The Method(s) being evaluated
</li>
<li>
A link to the Method specification
</li>
<li>
The <a>Evaluator</a>(s)
</li>
<li>
The date of the <a>Evaluation</a>
</li>
<li>
A description of the use case(s) for which the Method is being evaluated
</li>
<li>
The rubric used for the <a>Evaluation</a>, along with reference to the
specific version.
</li>
<li>
Optionally, a URL for retrieving the report.
</li>
</ol>
</section> <!-- evaluation -->
<section>
<h3>Categories of criteria</h3>
<p>
We have grouped our criteria into several categories:
</p>
<ol>
<li>
Rulemaking
</li>
<li>
Design
</li>
<li>
Operations
</li>
<li>
Enforcement
</li>
<li>
Alternatives
</li>
<li>
Adoption & Diversity
</li>
<li>
Security
</li>
<li>
Privacy</li>
</ol>
<p>
<a>Evaluator</a>s should consider criteria from all groups, as best fits
your use cases.
</p>
<p>
Three categories cover how a given Method is governed:
Rulemaking, Operations, and Enforcement.
Our approach parallels the same separation of
authority embodied in the United States Constitution.
</p>
<p>
<strong>Rulemaking</strong> addresses who makes the rules and how. (This is
the legislative branch in the US.)
</p>
<p>
<strong>Operations</strong> addresses how those rules are executed and how
everyone knows that they are carried out. (This is the executive branch in the
US.)
</p>
<p>
<strong>Enforcement</strong> addresses how we find and respond to rule
breaking. (This is the judicial branch in the US.)
</p>
<p>
This mental model is key to understanding the criteria of each section as well
as why we included some criteria and not others.
</p>
<p>The remaining categories each covers different areas worth considering
when evaluating DID Methods.</p>
<p>
<strong>Design</strong> addresses the method <em>as designed</em>. In other words, the output of the rulemaking:
what rules apply
to this DID method?
</p>
<p>
<strong>Alternatives</strong> address the availability and quality
of different implementation choices.
</p>
<p>
<strong>Adoption & Diversity</strong> covers questions related to how widely a
DID Method is used.
</p>
<p>
<strong>Security</strong> influences overall trust in the
ecosystem. Different DID methods offer different security guarantees, or guarantees of different strengths.
</p>
<p>
<strong>Privacy</strong> addresses the ability of a DID method to
ensure various privacy mechanisms. When DIDs are used as
identifiers for people, it becomes important to consider what
tools a DID method offers to operate at different levels
of privacy.
</p>
</section> <!-- categories -->
<section>
<h3>The architecture</h3>
<p>
When evaluating the governance of DID Methods, three potentially independent
layers should be considered: the specification, the network, and the registry.
</p>
<ul>
<li>
The <strong>specification</strong> is the governing document for the Method
that outlines how that particular Method implements the required and any
optional components of the DID Core specification [[DID-CORE]].
</li>
<li>
The <strong>network</strong> is the underlying communications layer, i.e., how
users of the Method communicate with others to invoke the operations of the
Method.
</li>
<li>
The <strong>registry</strong> is a given instance of recorded state changes,
managed according to the specification, using the communications channel.
</li>
</ul>
<p>
For Rulemaking, the criteria should be evaluated against all three of the
above layers.
</p>
<p>
For Operations, the criteria should be evaluated against the network and the
registry. The specification is taken as a given (it is the core output of
Rulemaking).
</p>
<p>
For Adoption, the criteria should be evaluated for each major software
component: wallet, resolver, and registry.
</p>
<p>
For Alternatives, the criteria should be evaluated against the particular DID
Method.
</p>
<p>
For the examples in the rest of this document we refer to a set of Methods
that are familiar to the authors and exhibit interesting characteristics for
<a>Evaluation</a>. These are listed in the "Comparative Evaluation Report
Header" table below.
</p>
</section> <!-- architecture -->
<section>
<h3>Comparative evaluation report header</h3>
<table class="simple">
<caption>
Comparison Evaluation (used throughout the criteria list)
</caption>
<tr>
<th>
<a>Evaluator</a>s
</th>
<td>
Joe Andrieu <<a href="mailto:[email protected]">[email protected]</a>>
</td>
</tr>
<tr>
<th>
Evaluation date
</th>
<td>
2020-01-03
</td>
</tr>
<tr>
<th>
Use cases
</th>
<td>
<p>
<strong>Verifiable software development.</strong> The signing of commits by
developers and their verification to ensure that source code in a particular
git repository is authentic.
</p>
<p>
<strong>User authentication.</strong> The use of DIDs for authenticating users
for access to system services.
</p>
<p>
<strong>Long term verifiable credentials.</strong> The use of DIDs as subject
identifiers for long term (life-long) verifiable credentials such as earned
academic degrees.
</p>
</td>
</tr>
<tr>
<th>
Report URL
</th>
<td>
TBD
</td>
</tr>
<tr>
<th>
Rubric
</th>
<td>
<a href="https://www.w3.org/TR/did-rubric/">DID Method Rubric v1.0.0</a>
</td>
</tr>
<tr>
<th>
Rubric URL
</th>
<td>
<a href="https://www.w3.org/TR/did-rubric/">https://www.w3.org/TR/did-rubric/</a>
</td>
</tr>
</table>
<table class="simple">
<caption>
<p>Methods considered</p>
</caption>
<tr>
<th>
Method
</th>
<th>
Specification
</th>
<th>
Network
</th>
<th>
Registry
</th>
</tr>
<tr>
<td>
did:peer
</td>
<td>
<a href="https://identity.foundation/peer-did-method-spec/index.html">Peer DID
Method Spec</a>
</td>
<td>
n/a (communications can flow over any agreeable channel)
</td>
<td>
Held by each peer
</td>
</tr>
<tr>
<td>
did:git
</td>
<td>
<a href="https://github.com/dhuseby/did-git-spec/blob/master/did-git-spec.md">
DID git Spec</a>
</td>
<td>
<a href="https://git-scm.com/">git</a> (an open source version control system)
</td>
<td>
Any Method-compliant git repository
</td>
</tr>
<tr>
<td>
did:btcr
</td>
<td>
<a href="https://w3c-ccg.github.io/didm-btcr/">DID Method BTCR</a>
</td>
<td>
Bitcoin
</td>
<td>
Bitcoin
</td>
</tr>
<tr>
<td>
did:sov
</td>
<td>
<a href="https://github.com/sovrin-foundation/sovrin/blob/master/spec/did-method-spec-template.html">
Sovrin DID Method Spec</a>
</td>
<td>
Hyperledger Indy
</td>
<td>
A particular instance of Hyperledger Indy
</td>
</tr>
<tr>
<td>
did:ethr
</td>
<td>
<a href="https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md">
ethr DID Method Spec</a>
</td>
<td>
Ethereum
</td>
<td>
Specific smart contracts for each network.
</td>
</tr>
<tr>
<td>
did:jolo
</td>
<td>
<a href="https://github.com/jolocom/jolocom-did-driver/blob/master/jolocom-did-method-specification.md">
Jolocom DID Method Specification</a>
</td>
<td>
Ethereum
</td>
<td>
Specific smart contracts for different networks and subnetworks.
</td>
</tr>
</table>
<p class="note">
Note: The evaluations in this document are made by Joe Andrieu
<[email protected]>. Other authors have expressed different evaluations,
because of different weighting of the relevant of different characteristics
in particular methods. This should be expected in any evaluation: they will
always be colored by the particular perspective of the <a>Evaluator</a>.
</p>
</section> <!-- evaluation report header -->
<section>
<h3>Criteria and Criterion</h3>
<p>The term "criteria" is often treated as both a
singular and a plural noun. In the singular, we say "The most
important criteria is the buyer's age". This singular use of
criteria has been in use for over half a century <a
href="https://www.merriam-webster.com/dictionary/criterion#usage-1">https://www.merriam-webster.com/dictionary/criterion#usage-1</a>
In the plural we say "That proposal doesn't meet all of the
criteria." Sometimes people use both in the same sentence: "Select
one criteria from the list of criteria."
</p>
<p>However, for formal use, "criteria" is more broadly accepted as
plural while "criterion" is singular. By this style rule, the last
sentence in the previous paragraph <em>should</em> be "Select one
criterion from the list of criteria." </p>
<p>As editors of a Note published by the World Wide Web Consortium,
we are torn. We would prefer to use
rigorous grammar and be consistent in doing so. At the same time,
we find attempts to enforce the formal rule sometimes leads people
to using the inverse, such as "Select a criteria from the list of
criterion." This is the exact opposite of our desired outcome.</p>
<p>In our own work with implementers and developers of the DID
Core specification, we have found that the singular "criteria" is
readily accepted and understood and leads to no confusion when
used, even alongside plural usage. Since the DID Method Rubric
is, at its core, a set of criteria with ample reason to refer to,
for example, "Criteria #23", we find the combined singular and
plural use is cleaner (just stick with "criteria"), less
confusing, and more aligned with common usage among our audience.</p>
<p>As such, throughout the DID Method Rubric, we use the term
"criteria" to refer to both singular instances of
criteria and plural sets of criteria.</p>
</section> <!-- criteria v criterion -->
</section> <!-- introduction -->
<section>
<h2>The criteria</h2>
<section>
<h3>Rulemaking</h3>
<p>
Rulemaking addresses who makes the rules and how. Output of rulemaking are the
rules.
</p>
<section>
<h4 id="criteria-1">Open contribution (participation)</h4>
<a href="#criteria-1">https://www.w3.org/TR/did-rubric#criteria-1</a>
<section>
<h5>Question</h5>
<p>
How open is participation in governance decisions?
</p>
</section>
<section>
<h5>Responses</h5>
<ol type="A">
<li>
Anyone can participate in an open, fair process where all participants have
equal opportunity to be heard and influence decisions.
</li>
<li>
Anyone can comment and contribute to open debate, but decisions are ultimately
made by a closed group.
</li>
<li>
Debate is restricted to a selected but known group.
</li>
<li>
Debate is conducted in secret by an unknown group.
</li>
</ol>
</section>
<section>
<h5>Relevance</h5>
<p>
Governance determines how the rules of the underlying network are set and
maintained. The more parties that are able to contribute to governance debates,
the more decentralized the governance.
</p>
</section>
<section>
<h5>Examples</h5>
<table class="simple">
<tr>
<th>
Method
</th>
<th>
Spec.
</th>
<th>
Net.
</th>
<th>
Reg.
</th>
<th>
Notes
</th>
</tr>
<tr>
<td>
did:peer
</td>
<td>
B
</td>
<td>
C
</td>
<td>
C
</td>
<td>
did:peer has no intrinsic network. It can use any communications channel
between parties. Only those two parties are privy to the decisions made about
communications and recordation. The spec is openly developed on github by a
listed set of contributors and issues may be raised by anyone.
</td>
</tr>
<tr>
<td>
did:git
</td>
<td>
B
</td>
<td>
C
</td>
<td>
D
</td>
<td>
The git network is the git source code, which is controlled (currently) by 16
people. They do not have a public issues process. The spec is openly developed
on github by a listed set of contributors and issues may be raised by anyone.
Each registry is controlled by potentially unknown parties as negotiated in
"meatspace".
</td>
</tr>
<tr>
<td>
did:btcr
</td>
<td>
B
</td>
<td>
D
</td>
<td>
D
</td>
<td>
Changes to the bitcoin protocol are chaotic and uncertain. They use BIPs, but
the path to adoption is uncertain and the relative power of developers, miners,
and users is open to debate. The spec is openly developed on github by a
listed set of contributors and issues may be raised by anyone.
</td>
</tr>
<tr>
<td>
did:sov
</td>
<td>
B
</td>
<td>
B
</td>
<td>
B
</td>
<td>
The Sovrin Foundation has an open community governance model but has not yet
had open elections of trustees.
</td>
</tr>
<tr>
<td>
did:ethr
</td>
<td>
C
</td>
<td>
B
</td>
<td>
n/a
</td>
<td>
The network is Ethereum, which evolves through EIPs proposed by anyone,
discussed by "the community" and ultimately adopted by Ethereum core devs. The
spec is published on GitHub with issues open to the public. The smart contract
for the registry is immutable.
</td>
</tr>
<tr>
<td>
did:jolo
</td>
<td>
D
</td>
<td>
B
</td>
<td>
D
</td>
<td>
Jolocom's network is Ethereum. Decisions over Jolocom's smart contracts are
made by an unknown group within Jolocom. The specification (as listed in the
DID Method Registry [[DID-SPEC-REGISTRIES]]) is currently archived and not
open to public comment.
</td>
</tr>
</table>
</section>
</section> <!-- participation -->
<section>
<h4 id="criteria-2">Transparency</h4>
<a href="#criteria-2">https://www.w3.org/TR/did-rubric#criteria-2</a>
<p>
</p>
<section>
<h5>Question</h5>
<p>
How visible are rulemaking processes?
</p>
</section>
<section>
<h5>Responses</h5>
<ol type="A">
<li>
Agendas and participation details for all meetings are publicly announced, the
meetings are broadcast in real-time to any listeners, and all minutes and
recordings are captured in realtime and publicly reviewable in perpetuity.
</li>
<li>
Minutes of meetings are reviewable by the public, including all votes and who
cast them, but real-time observation may be limited.
</li>
<li>
All current rules are publicly available.
</li>
<li>
Rules may be changed without public notice.
</li>
</ol>
</section>
<section>
<h5>Relevance</h5>
<p>
While participation measures active contribution, transparency measures the
visibility of discussions affecting rule making. If such discussions are only
visible to a limited group, it centralizes decision making in ways that
<a>Evaluators</a> and users cannot easily see.
</p>
</section>
<section>
<h5>Examples</h5>
<table class="simple">
<tr>
<th>
Method
</th>
<th>
Spec.
</th>
<th>
Net.
</th>
<th>
Reg.
</th>
<th>
Notes
</th>
</tr>
<tr>
<td>
did:peer
</td>
<td>
C
</td>
<td>
n/a
</td>
<td>
B
</td>
<td>
Rules for accepting changes to the business rules are bilaterally negotiated
between the peers, subject to conformance with the specification.
</td>
</tr>
<tr>
<td>
did:git
</td>
<td>
C
</td>
<td>
n/a
</td>
<td>
D
</td>
<td>
The controllers of the git repo are a limited set, but their decisions are
"meatspace protocol" and hence not explicitly transparent.
</td>
</tr>
<tr>
<td>
did:btcr
</td>
<td>
C
</td>
<td>
C
</td>
<td>
C
</td>
<td>
The spec is maintained by volunteers, operating in an open fashion but without
formal processes for announcements and meeting notes. The network and registry
are bitcoin, which has a fairly public but messy innovation process, without
formal meetings or votes.
</td>
</tr>
<tr>
<td>
did:sov
</td>
<td>
B
</td>
<td>
B
</td>
<td>
B
</td>
<td>
The Sovrin Governance Framework actually requires all minutes of Sovrin
governance discussions are public with a handful of exceptions for legal
reasons (e.g., HR actions, legal actions). See Section 9 of
<a href="https://sovrin.org/wp-content/uploads/Sovrin-Governing-Body-Policies-V1.pdf">
Sovrin Governing Body Policies</a>.
</td>
</tr>
<tr>
<td>
did:ethr
</td>
<td>
C
</td>
<td>
C
</td>
<td>
D
</td>
<td>
The governance is controlled by a smart contract, which is immutable.
</td>
</tr>
<tr>
<td>
did:jolo
</td>
<td>
C
</td>
<td>
C
</td>
<td>
D
</td>
<td>
Jolocom does not expose the internal and/or customer conversations that drive
rulemaking.
</td>
</tr>
</table>
</section>