-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathCG-FINAL-iifaa-did-20241231.html
1697 lines (1560 loc) · 121 KB
/
CG-FINAL-iifaa-did-20241231.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">
<meta name="generator" content="ReSpec 35.2.1">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<style>
.issue-label{text-transform:initial}
.warning>p:first-child{margin-top:0}
.warning{padding:.5em;border-left-width:.5em;border-left-style:solid}
span.warning{padding:.1em .5em .15em}
.issue.closed span.issue-number{text-decoration:line-through}
.issue.closed span.issue-number::after{content:" (Closed)";font-size:smaller}
.warning{border-color:#f11;border-color:var(--warning-border,#f11);border-width:.2em;border-style:solid;background:#fbe9e9;background:var(--warning-bg,#fbe9e9);color:#000;color:var(--text,#000)}
.warning-title:before{content:"⚠";font-size:1.3em;float:left;padding-right:.3em;margin-top:-.3em}
li.task-list-item{list-style:none}
input.task-list-item-checkbox{margin:0 .35em .25em -1.6em;vertical-align:middle}
.issue a.respec-gh-label{padding:5px;margin:0 2px 0 2px;font-size:10px;text-transform:none;text-decoration:none;font-weight:700;border-radius:4px;position:relative;bottom:2px;border:none;display:inline-block}
</style>
<style>
dfn{cursor:pointer}
.dfn-panel{position:absolute;z-index:35;min-width:300px;max-width:500px;padding:.5em .75em;margin-top:.6em;font-family:"Helvetica Neue",sans-serif;font-size:small;background:#fff;background:var(--indextable-hover-bg,#fff);color:#000;color:var(--text,#000);box-shadow:0 1em 3em -.4em rgba(0,0,0,.3),0 0 1px 1px rgba(0,0,0,.05);box-shadow:0 1em 3em -.4em var(--tocsidebar-shadow,rgba(0,0,0,.3)),0 0 1px 1px var(--tocsidebar-shadow,rgba(0,0,0,.05));border-radius:2px}
.dfn-panel:not(.docked)>.caret{position:absolute;top:-9px}
.dfn-panel:not(.docked)>.caret::after,.dfn-panel:not(.docked)>.caret::before{content:"";position:absolute;border:10px solid transparent;border-top:0;border-bottom:10px solid #fff;border-bottom-color:var(--indextable-hover-bg,#fff);top:0}
.dfn-panel:not(.docked)>.caret::before{border-bottom:9px solid #a2a9b1;border-bottom-color:var(--indextable-hover-bg,#a2a9b1)}
.dfn-panel *{margin:0}
.dfn-panel b{display:block;color:#000;color:var(--text,#000);margin-top:.25em}
.dfn-panel ul a[href]{color:#333;color:var(--text,#333)}
.dfn-panel>div{display:flex}
.dfn-panel a.self-link{font-weight:700;margin-right:auto}
.dfn-panel .marker{padding:.1em;margin-left:.5em;border-radius:.2em;text-align:center;white-space:nowrap;font-size:90%;color:#040b1c}
.dfn-panel .marker.dfn-exported{background:#d1edfd;box-shadow:0 0 0 .125em #1ca5f940}
.dfn-panel .marker.idl-block{background:#8ccbf2;box-shadow:0 0 0 .125em #0670b161}
.dfn-panel a:not(:hover){text-decoration:none!important;border-bottom:none!important}
.dfn-panel a[href]:hover{border-bottom-width:1px}
.dfn-panel ul{padding:0}
.dfn-panel li{margin-left:1em}
.dfn-panel.docked{position:fixed;left:.5em;top:unset;bottom:2em;margin:0 auto;max-width:calc(100vw - .75em * 2 - .5em - .2em * 2);max-height:30vh;overflow:auto}
</style>
<style id="respec-mainstyle">
@keyframes pop{
0%{transform:scale(1,1)}
25%{transform:scale(1.25,1.25);opacity:.75}
100%{transform:scale(1,1)}
}
a.internalDFN{color:inherit;border-bottom:1px solid #99c;text-decoration:none}
a.externalDFN{color:inherit;border-bottom:1px dotted #ccc;text-decoration:none}
a.bibref{text-decoration:none}
.respec-offending-element:target{animation:pop .25s ease-in-out 0s 1}
.respec-offending-element,a[href].respec-offending-element{text-decoration:red wavy underline}
@supports not (text-decoration:red wavy underline){
.respec-offending-element:not(pre){display:inline-block}
.respec-offending-element{background:url(data:image/gif;base64,R0lGODdhBAADAPEAANv///8AAP///wAAACwAAAAABAADAEACBZQjmIAFADs=) bottom repeat-x}
}
#references :target{background:#eaf3ff;animation:pop .4s ease-in-out 0s 1}
cite .bibref{font-style:normal}
a[href].orcid{padding-left:4px;padding-right:4px}
a[href].orcid>svg{margin-bottom:-2px}
ol.tof,ul.tof{list-style:none outside none}
.caption{margin-top:.5em;font-style:italic}
#issue-summary>ul{column-count:2}
#issue-summary li{list-style:none;display:inline-block}
details.respec-tests-details{margin-left:1em;display:inline-block;vertical-align:top}
details.respec-tests-details>*{padding-right:2em}
details.respec-tests-details[open]{z-index:999999;position:absolute;border:thin solid #cad3e2;border-radius:.3em;background-color:#fff;padding-bottom:.5em}
details.respec-tests-details[open]>summary{border-bottom:thin solid #cad3e2;padding-left:1em;margin-bottom:1em;line-height:2em}
details.respec-tests-details>ul{width:100%;margin-top:-.3em}
details.respec-tests-details>li{padding-left:1em}
.self-link:hover{opacity:1;text-decoration:none;background-color:transparent}
aside.example .marker>a.self-link{color:inherit}
.header-wrapper{display:flex;align-items:baseline}
:is(h2,h3,h4,h5,h6):not(#toc>h2,#abstract>h2,#sotd>h2,.head>h2){position:relative;left:-.5em}
:is(h2,h3,h4,h5,h6):not(#toch2)+a.self-link{color:inherit;order:-1;position:relative;left:-1.1em;font-size:1rem;opacity:.5}
:is(h2,h3,h4,h5,h6)+a.self-link::before{content:"§";text-decoration:none;color:var(--heading-text)}
:is(h2,h3)+a.self-link{top:-.2em}
:is(h4,h5,h6)+a.self-link::before{color:#000}
@media (max-width:767px){
dd{margin-left:0}
}
@media print{
.removeOnSave{display:none}
}
</style>
<meta name="color-scheme" content="light">
<meta name="description" content="This document specifies the IIFAA decentralized trusted authentication reference model, technical architecture and
functionalities, service procedures, security requirements, and personal information protection requirements.">
<link rel="canonical" href="https://www.w3.org/community/reports/cndid/iifaa-did/">
<style>
var{position:relative;cursor:pointer}
var[data-type]::after,var[data-type]::before{position:absolute;left:50%;top:-6px;opacity:0;transition:opacity .4s;pointer-events:none}
var[data-type]::before{content:"";transform:translateX(-50%);border-width:4px 6px 0 6px;border-style:solid;border-color:transparent;border-top-color:#222}
var[data-type]::after{content:attr(data-type);transform:translateX(-50%) translateY(-100%);background:#222;text-align:center;font-family:"Dank Mono","Fira Code",monospace;font-style:normal;padding:6px;border-radius:3px;color:#daca88;text-indent:0;font-weight:400}
var[data-type]:hover::after,var[data-type]:hover::before{opacity:1}
</style>
<script id="initialUserConfig" type="application/json">{
"specStatus": "CG-FINAL",
"shortName": "iifaa-did",
"editors": [
{
"name": "Wang Yongtao",
"company": "Ant Group",
"companyURL": "https://www.antgroup.com/"
},
{
"name": "Zhang Wu",
"company": "Ant Group",
"companyURL": "https://www.antgroup.com/"
},
{
"name": "Sun Weichao",
"company": "Ant Group",
"companyURL": "https://www.antgroup.com/"
},
{
"name": "Peng Jin",
"company": "Ant Group",
"companyURL": "https://www.antgroup.com/"
},
{
"name": "Lin Guanchen",
"company": "Ant Group",
"companyURL": "https://www.antgroup.com/"
},
{
"name": "Huang Lin",
"company": "Ant Group",
"companyURL": "https://www.antgroup.com/"
},
{
"name": "Wu Sijie",
"company": "Ant Group",
"companyURL": "https://www.antgroup.com/"
},
{
"name": "Xu Yijia",
"company": "Ant Group",
"companyURL": "https://www.antgroup.com/"
},
{
"name": "Lyu Lei",
"company": "National Engineering Research Center for Cryptography",
"companyURL": ""
},
{
"name": "Yin Yihua",
"company": "National Engineering Research Center for Cryptography",
"companyURL": ""
},
{
"name": "Lai Tao",
"company": "National Engineering Research Center for Cryptography",
"companyURL": ""
},
{
"name": "Fu Shan",
"company": "China Academy of Information and Communications Technology (CAICT)",
"companyURL": "http://www.catr.cn/"
},
{
"name": "Wei Fanxing",
"company": "China Academy of Information and Communications Technology (CAICT)",
"companyURL": "http://www.catr.cn/"
},
{
"name": "Yang Bo",
"company": "Beijing UnionPay Gold Card Technology Co., Ltd.",
"companyURL": "http://www.bctest.com/"
},
{
"name": "Zhang Yanchao",
"company": "Beijing UnionPay Gold Card Technology Co., Ltd.",
"companyURL": ""
},
{
"name": "Zhuang Huaiyu",
"company": "China Mobile Fintech Co. Ltd.",
"companyURL": ""
},
{
"name": "Guo Yanhong",
"company": "China Mobile Fintech Co. Ltd.",
"companyURL": ""
},
{
"name": "Li Zhichao",
"company": "Honor Terminal Co., Ltd.",
"companyURL": "https://www.honor.com/global/"
},
{
"name": "Luo Guangwen",
"company": "Honor Terminal Co., Ltd.",
"companyURL": "https://www.honor.com/global/"
},
{
"name": "Zhao Xiaona",
"company": "Honor Terminal Co., Ltd.",
"companyURL": "https://www.honor.com/global/"
},
{
"name": "Shi Xinling",
"company": "Ruift Co., Ltd.",
"companyURL": ""
},
{
"name": "Ju Mingqi",
"company": "Ruift Co., Ltd.",
"companyURL": ""
},
{
"name": "Liu Weihua",
"company": "Zhengzhou XindaJiean Information Technology Co., Ltd.",
"companyURL": "www.xdja.com"
},
{
"name": "Huang Xiaoni",
"company": "Beijing d-Ear Technologies Co., Ltd.",
"companyURL": "http://www.d-ear.com/"
},
{
"name": "Zheng Fang",
"company": "Beijing d-Ear Technologies Co., Ltd.",
"companyURL": "http://www.d-ear.com/"
},
{
"name": "Lyu Fang",
"company": "Cilent Service International, Inc.",
"companyURL": ""
},
{
"name": "Wu Yue",
"company": "Beijing Samsung Communication Technology Research Institute Co., Ltd.",
"companyURL": ""
},
{
"name": "Yang Chunlin",
"company": "Beijing Eyecool Technology Co, Ltd.",
"companyURL": "http://www.eyecool.cn/"
},
{
"name": "Wang Jun",
"company": "Beijing eSand Information Technology Co., Ltd.",
"companyURL": "https://www.esandinfo.com/"
},
{
"name": "Lu Ruyi",
"company": "Beijing eSand Information Technology Co., Ltd.",
"companyURL": "https://www.esandinfo.com/"
},
{
"name": "Zhang Shengyi",
"company": "Beijing eSand Information Technology Co., Ltd.",
"companyURL": "https://www.esandinfo.com/"
},
{
"name": "Li Angyang",
"company": "Beijing Allhopes Trusted Link Technology Co., Ltd.",
"companyURL": "www.allhopes.com"
},
{
"name": "Zhu Pengfei",
"company": "Feitian Technologies Co., Ltd.",
"companyURL": "https://www.ftsafe.com"
},
{
"name": "Meng Ru",
"company": "Koal Software, Inc.",
"companyURL": "http://www.koal.com/"
},
{
"name": "Cao Haihong",
"company": "Shanghai Paraview Software Co., Ltd.",
"companyURL": ""
},
{
"name": "Ping Zhenghai",
"company": "ZTE Corporation",
"companyURL": ""
},
{
"name": "Huang Xixin",
"company": "Meizu Technology Co., Ltd.",
"companyURL": ""
},
{
"name": "Wang Xiang",
"company": "Henan Province Information Group Co., Ltd.",
"companyURL": "https://www.hnxaca.com/"
},
{
"name": "Wu Huancheng",
"company": "Vivo Communication Co., Ltd.",
"companyURL": ""
}
],
"group": "cndid",
"github": "w3c-cg/cndid",
"publishISODate": "2024-12-31T00:00:00.000Z",
"generatedSubtitle": "Final Community Group Report 31 December 2024"
}</script>
<link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/2021/cg-final"></head><body data-new-gr-c-s-check-loaded="14.1214.0" data-gr-ext-installed="" class="h-entry informative"><div class="head">
<h1 id="title" class="title">IIFAA Decentralized Trusted Authentication Technical Specification - Part 1: General Requirements</h1>
<p id="w3c-state">
<a href="https://www.w3.org/standards/types#reports">Final Community Group Report</a>
<time class="dt-published" datetime="2024-12-31">31 December 2024</time>
</p>
<dl>
<dt>This version:</dt><dd>
<a class="u-url" href="https://www.w3.org/community/reports/cndid/CG-FINAL-iifaa-did-20241231/">https://www.w3.org/community/reports/cndid/CG-FINAL-iifaa-did-20241231/</a>
</dd>
<dt>Latest editor's draft:</dt><dd><a href="https://w3c-cg.github.io/cndid/">https://w3c-cg.github.io/cndid/</a></dd>
<dt>Editors:</dt><dd class="editor p-author h-card vcard">
<span class="p-name fn">Wang Yongtao</span> (<a class="p-org org h-org" href="https://www.antgroup.com/">Ant Group</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Zhang Wu</span> (<a class="p-org org h-org" href="https://www.antgroup.com/">Ant Group</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Sun Weichao</span> (<a class="p-org org h-org" href="https://www.antgroup.com/">Ant Group</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Peng Jin</span> (<a class="p-org org h-org" href="https://www.antgroup.com/">Ant Group</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Lin Guanchen</span> (<a class="p-org org h-org" href="https://www.antgroup.com/">Ant Group</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Huang Lin</span> (<a class="p-org org h-org" href="https://www.antgroup.com/">Ant Group</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Wu Sijie</span> (<a class="p-org org h-org" href="https://www.antgroup.com/">Ant Group</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Xu Yijia</span> (<a class="p-org org h-org" href="https://www.antgroup.com/">Ant Group</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Lyu Lei</span> (<span class="p-org org h-org">National Engineering Research Center for Cryptography</span>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Yin Yihua</span> (<span class="p-org org h-org">National Engineering Research Center for Cryptography</span>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Lai Tao</span> (<span class="p-org org h-org">National Engineering Research Center for Cryptography</span>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Fu Shan</span> (<a class="p-org org h-org" href="http://www.catr.cn/">China Academy of Information and Communications Technology (CAICT)</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Wei Fanxing</span> (<a class="p-org org h-org" href="http://www.catr.cn/">China Academy of Information and Communications Technology (CAICT)</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Yang Bo</span> (<a class="p-org org h-org" href="http://www.bctest.com/">Beijing UnionPay Gold Card Technology Co., Ltd.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Zhang Yanchao</span> (<span class="p-org org h-org">Beijing UnionPay Gold Card Technology Co., Ltd.</span>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Zhuang Huaiyu</span> (<span class="p-org org h-org">China Mobile Fintech Co. Ltd.</span>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Guo Yanhong</span> (<span class="p-org org h-org">China Mobile Fintech Co. Ltd.</span>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Li Zhichao</span> (<a class="p-org org h-org" href="https://www.honor.com/global/">Honor Terminal Co., Ltd.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Luo Guangwen</span> (<a class="p-org org h-org" href="https://www.honor.com/global/">Honor Terminal Co., Ltd.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Zhao Xiaona</span> (<a class="p-org org h-org" href="https://www.honor.com/global/">Honor Terminal Co., Ltd.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Shi Xinling</span> (<span class="p-org org h-org">Ruift Co., Ltd.</span>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Ju Mingqi</span> (<span class="p-org org h-org">Ruift Co., Ltd.</span>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Liu Weihua</span> (<a class="p-org org h-org" href="www.xdja.com">Zhengzhou XindaJiean Information Technology Co., Ltd.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Huang Xiaoni</span> (<a class="p-org org h-org" href="http://www.d-ear.com/">Beijing d-Ear Technologies Co., Ltd.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Zheng Fang</span> (<a class="p-org org h-org" href="http://www.d-ear.com/">Beijing d-Ear Technologies Co., Ltd.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Lyu Fang</span> (<span class="p-org org h-org">Cilent Service International, Inc.</span>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Wu Yue</span> (<span class="p-org org h-org">Beijing Samsung Communication Technology Research Institute Co., Ltd.</span>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Yang Chunlin</span> (<a class="p-org org h-org" href="http://www.eyecool.cn/">Beijing Eyecool Technology Co, Ltd.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Wang Jun</span> (<a class="p-org org h-org" href="https://www.esandinfo.com/">Beijing eSand Information Technology Co., Ltd.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Lu Ruyi</span> (<a class="p-org org h-org" href="https://www.esandinfo.com/">Beijing eSand Information Technology Co., Ltd.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Zhang Shengyi</span> (<a class="p-org org h-org" href="https://www.esandinfo.com/">Beijing eSand Information Technology Co., Ltd.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Li Angyang</span> (<a class="p-org org h-org" href="www.allhopes.com">Beijing Allhopes Trusted Link Technology Co., Ltd.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Zhu Pengfei</span> (<a class="p-org org h-org" href="https://www.ftsafe.com">Feitian Technologies Co., Ltd.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Meng Ru</span> (<a class="p-org org h-org" href="http://www.koal.com/">Koal Software, Inc.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Cao Haihong</span> (<span class="p-org org h-org">Shanghai Paraview Software Co., Ltd.</span>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Ping Zhenghai</span> (<span class="p-org org h-org">ZTE Corporation</span>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Huang Xixin</span> (<span class="p-org org h-org">Meizu Technology Co., Ltd.</span>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Wang Xiang</span> (<a class="p-org org h-org" href="https://www.hnxaca.com/">Henan Province Information Group Co., Ltd.</a>)
</dd><dd class="editor p-author h-card vcard">
<span class="p-name fn">Wu Huancheng</span> (<span class="p-org org h-org">Vivo Communication Co., Ltd.</span>)
</dd>
<dt>Feedback:</dt><dd>
<a href="https://github.com/w3c-cg/cndid/">GitHub w3c-cg/cndid</a>
(<a href="https://github.com/w3c-cg/cndid/pulls/">pull requests</a>,
<a href="https://github.com/w3c-cg/cndid/issues/new/choose">new issue</a>,
<a href="https://github.com/w3c-cg/cndid/issues/">open issues</a>)
</dd>
</dl>
<p class="copyright">
<a href="https://www.w3.org/policies/#copyright">Copyright</a>
©
2024
the Contributors to the IIFAA Decentralized Trusted Authentication Technical Specification - Part 1: General Requirements Specification, published by <a href="https://www.iifaa.org.cn/index">IIFAA</a> and
<a href="https://www.w3.org/groups/cg/cndid">Chinese DID & VC Community Group</a> under the
<a href="https://www.w3.org/community/about/agreements/cla/">W3C Community Contributor License Agreement (CLA)</a>. A
human-readable
<a href="https://www.w3.org/community/about/agreements/cla-deed/">summary</a>
is available.
</p>
<hr title="Separator for header">
</div><div class="logo-container">
<a class="logo" href="https://www.iifaa.org.cn/index"><img class="logo-1" alt="IIFAA" height="88" src="img/iifaa-logo.jpg" width="auto"></a>
<a class="logo" href="https://www.w3.org/community"><img class="logo-2" alt="W3C Community Group" height="88" src="img/cgbg-logo.svg" width="auto" text-align:="" “right;=""></a>
</div>
<title>IIFAA Decentralized Trusted Authentication Technical Specification - Part 1: General Requirements</title>
<section id="abstract" class="introductory"><h2>Abstract</h2>
<p>This document specifies the IIFAA decentralized trusted authentication reference model, technical architecture and
functionalities, service procedures, security requirements, and personal information protection requirements.</p>
<p>It is applicable to the development, design, deployment, application, and testing certification and other related
activities of IIFAA decentralized trusted authentication.
</p>
</section>
<section id="sotd" class="introductory">
<h2>Status of This Document</h2>
<p>
This specification was published by the <a href="https://www.iifaa.org.cn/index">IIFAA</a> and
<a href="https://www.w3.org/groups/cg/cndid">Chinese DID & VC Community Group</a>. It is not a W3C Standard nor
is it
on the W3C Standards Track.
Please note that under the
<a href="https://www.w3.org/community/about/agreements/cla/">W3C Community Contributor License Agreement (CLA)</a>
there is a limited opt-out and other conditions apply.
Learn more about
<a href="https://www.w3.org/community/">W3C Community and Business Groups</a>.
</p>
<a href="https://github.com/w3c-cg/cndid/issues/">GitHub Issues</a> are preferred for
discussion of this specification.
</p></section><nav id="toc"><h2 class="introductory" id="table-of-contents">Table of Contents</h2><ol class="toc"><li class="tocline"><a class="tocxref" href="#abstract">Abstract</a></li><li class="tocline"><a class="tocxref" href="#sotd">Status of This Document</a></li><li class="tocline"><a class="tocxref" href="#introduction"><bdi class="secno">1. </bdi>Introduction</a></li><li class="tocline"><a class="tocxref" href="#general-framework"><bdi class="secno">2. </bdi>General Framework</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#reference-model"><bdi class="secno">2.1 </bdi>Reference Model</a></li><li class="tocline"><a class="tocxref" href="#issuer"><bdi class="secno">2.2 </bdi>Issuer</a></li><li class="tocline"><a class="tocxref" href="#service-provider-sp"><bdi class="secno">2.3 </bdi>Service Provider (SP)</a></li><li class="tocline"><a class="tocxref" href="#identity-provider-idp"><bdi class="secno">2.4 </bdi>Identity Provider (IDP)</a></li><li class="tocline"><a class="tocxref" href="#did-holder"><bdi class="secno">2.5 </bdi>DID Holder</a></li></ol></li><li class="tocline"><a class="tocxref" href="#technical-architecture-and-functions"><bdi class="secno">3. </bdi>Technical Architecture and Functions</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#technical-architecture"><bdi class="secno">3.1 </bdi>Technical Architecture</a></li><li class="tocline"><a class="tocxref" href="#user-terminal"><bdi class="secno">3.2 </bdi>User Terminal</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#terminal-security-foundation-layer"><bdi class="secno">3.2.1 </bdi>Terminal Security Foundation Layer</a></li><li class="tocline"><a class="tocxref" href="#terminal-core-protocol-layer"><bdi class="secno">3.2.2 </bdi>Terminal Core Protocol Layer</a></li><li class="tocline"><a class="tocxref" href="#terminal-core-service-layer"><bdi class="secno">3.2.3 </bdi>Terminal Core Service Layer</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#decentralized-identity-management"><bdi class="secno">3.2.3.1 </bdi>Decentralized Identity Management</a></li><li class="tocline"><a class="tocxref" href="#decentralized-identity-verification"><bdi class="secno">3.2.3.2 </bdi>Decentralized Identity Verification</a></li><li class="tocline"><a class="tocxref" href="#vc-management"><bdi class="secno">3.2.3.3 </bdi>VC Management</a></li><li class="tocline"><a class="tocxref" href="#vc-presentation"><bdi class="secno">3.2.3.4 </bdi>VC Presentation</a></li></ol></li></ol></li><li class="tocline"><a class="tocxref" href="#issuer-0"><bdi class="secno">3.3 </bdi>Issuer</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#vc-issuance"><bdi class="secno">3.3.1 </bdi>VC Issuance</a></li><li class="tocline"><a class="tocxref" href="#vc-revocation"><bdi class="secno">3.3.2 </bdi>VC Revocation</a></li><li class="tocline"><a class="tocxref" href="#vc-traceability-configuration"><bdi class="secno">3.3.3 </bdi>VC Traceability Configuration</a></li></ol></li><li class="tocline"><a class="tocxref" href="#decentralized-trusted-authentication-infrastructure"><bdi class="secno">3.4 </bdi>Decentralized Trusted Authentication Infrastructure</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#identity-service"><bdi class="secno">3.4.1 </bdi>Identity Service</a></li><li class="tocline"><a class="tocxref" href="#private-key-escrow"><bdi class="secno">3.4.2 </bdi>Private Key Escrow</a></li><li class="tocline"><a class="tocxref" href="#vc-escrow"><bdi class="secno">3.4.3 </bdi>VC Escrow</a></li><li class="tocline"><a class="tocxref" href="#vc-traceability"><bdi class="secno">3.4.4 </bdi>VC Traceability</a></li><li class="tocline"><a class="tocxref" href="#vc-escrow-0"><bdi class="secno">3.4.5 </bdi>VC Escrow</a></li></ol></li><li class="tocline"><a class="tocxref" href="#sps"><bdi class="secno">3.5 </bdi>SPs</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#vp-verification"><bdi class="secno">3.5.1 </bdi>VP Verification</a></li><li class="tocline"><a class="tocxref" href="#organization-verification"><bdi class="secno">3.5.2 </bdi>Organization Verification</a></li></ol></li><li class="tocline"><a class="tocxref" href="#iifaa-ecologic-operation-platform"><bdi class="secno">3.6 </bdi>IIFAA Ecologic Operation Platform</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#vc-template-management"><bdi class="secno">3.6.1 </bdi>VC Template Management</a></li><li class="tocline"><a class="tocxref" href="#scenario-management"><bdi class="secno">3.6.2 </bdi>Scenario Management</a></li><li class="tocline"><a class="tocxref" href="#service-scenario-display"><bdi class="secno">3.6.3 </bdi>Service Scenario Display</a></li><li class="tocline"><a class="tocxref" href="#vc-list-display"><bdi class="secno">3.6.4 </bdi>VC List Display</a></li></ol></li><li class="tocline"><a class="tocxref" href="#unified-service-and-control-platform"><bdi class="secno">3.7 </bdi>Unified Service and Control Platform</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#organization-management"><bdi class="secno">3.7.1 </bdi>Organization Management</a></li><li class="tocline"><a class="tocxref" href="#trust-anchoring"><bdi class="secno">3.7.2 </bdi>Trust Anchoring</a></li><li class="tocline"><a class="tocxref" href="#traceability-and-audit"><bdi class="secno">3.7.3 </bdi>Traceability and Audit</a></li></ol></li></ol></li><li class="tocline"><a class="tocxref" href="#service-procedure"><bdi class="secno">4. </bdi>Service Procedure</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#organization-registration-procedure"><bdi class="secno">4.1 </bdi>Organization Registration Procedure</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#issuer-registration"><bdi class="secno">4.1.1 </bdi>Issuer Registration</a></li><li class="tocline"><a class="tocxref" href="#sp-registration"><bdi class="secno">4.1.2 </bdi>SP Registration</a></li></ol></li><li class="tocline"><a class="tocxref" href="#vc-issuance-procedure"><bdi class="secno">4.2 </bdi>VC Issuance Procedure</a></li><li class="tocline"><a class="tocxref" href="#vp-procedure"><bdi class="secno">4.3 </bdi>VP Procedure</a></li></ol></li><li class="tocline"><a class="tocxref" href="#security-requirements"><bdi class="secno">5. </bdi>Security Requirements</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#password-locks-security"><bdi class="secno">5.1 </bdi>Password Locks Security</a></li><li class="tocline"><a class="tocxref" href="#data-security"><bdi class="secno">5.2 </bdi>Data Security</a></li><li class="tocline"><a class="tocxref" href="#server-security"><bdi class="secno">5.3 </bdi>Server Security</a></li><li class="tocline"><a class="tocxref" href="#terminal-security"><bdi class="secno">5.4 </bdi>Terminal Security</a></li><li class="tocline"><a class="tocxref" href="#server-security-requirements"><bdi class="secno">5.5 </bdi>Server Security Requirements</a></li></ol></li><li class="tocline"><a class="tocxref" href="#personal-information-protection-requirements"><bdi class="secno">6. </bdi>Personal Information Protection Requirements</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#general-requirements"><bdi class="secno">6.1 </bdi>General Requirements</a></li><li class="tocline"><a class="tocxref" href="#biometric-data-masking-requirements"><bdi class="secno">6.2 </bdi>Biometric Data Masking Requirements</a></li><li class="tocline"><a class="tocxref" href="#disclosure-of-personal-information"><bdi class="secno">6.3 </bdi>Disclosure of Personal Information</a></li></ol></li><li class="tocline"><a class="tocxref" href="#test-requirements"><bdi class="secno">7. </bdi>Test Requirements</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#protocol-standard-testing"><bdi class="secno">7.1 </bdi>Protocol Standard Testing</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#did-document-protocol-testing"><bdi class="secno">7.1.1 </bdi>DID Document Protocol Testing</a></li><li class="tocline"><a class="tocxref" href="#vc-protocol-testing"><bdi class="secno">7.1.2 </bdi>VC Protocol Testing</a></li><li class="tocline"><a class="tocxref" href="#vp-protocol-testing"><bdi class="secno">7.1.3 </bdi>VP Protocol Testing</a></li></ol></li><li class="tocline"><a class="tocxref" href="#operating-environment-security-testing"><bdi class="secno">7.2 </bdi>Operating Environment Security Testing</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#terminal-environment-security-testing"><bdi class="secno">7.2.1 </bdi>Terminal Environment Security Testing</a></li><li class="tocline"><a class="tocxref" href="#key-algorithm-security-testing"><bdi class="secno">7.2.2 </bdi>Key Algorithm Security Testing</a></li><li class="tocline"><a class="tocxref" href="#data-protocol-security-testing"><bdi class="secno">7.2.3 </bdi>Data Protocol Security Testing</a></li></ol></li><li class="tocline"><a class="tocxref" href="#basic-function-testing"><bdi class="secno">7.3 </bdi>Basic Function Testing</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#registration-and-management-of-decentralized-identities"><bdi class="secno">7.3.1 </bdi>Registration and Management of Decentralized Identities</a></li><li class="tocline"><a class="tocxref" href="#vc-issuance-and-storage"><bdi class="secno">7.3.2 </bdi>VC Issuance and Storage</a></li><li class="tocline"><a class="tocxref" href="#vp-presentation"><bdi class="secno">7.3.3 </bdi>VP Presentation</a></li></ol></li><li class="tocline"><a class="tocxref" href="#performance-and-stability-testing"><bdi class="secno">7.4 </bdi>Performance and Stability Testing</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#key-performance-testing"><bdi class="secno">7.4.1 </bdi>Key Performance Testing</a></li><li class="tocline"><a class="tocxref" href="#performance-and-stability-testing-of-the-service-system"><bdi class="secno">7.4.2 </bdi>Performance and Stability Testing of the Service System</a></li></ol></li></ol></li><li class="tocline"><a class="tocxref" href="#terms"><bdi class="secno">8. </bdi>Terms</a></li><li class="tocline"><a class="tocxref" href="#reference"><bdi class="secno">A. </bdi>Reference</a></li></ol></nav>
<section id="introduction"><div class="header-wrapper"><h2 id="x1-introduction"><bdi class="secno">1. </bdi>Introduction</h2><a class="self-link" href="#introduction" aria-label="Permalink for Section 1."></a></div>
<p>This document specifies the IIFAA decentralized trusted authentication reference model, technical architecture and
functionalities, service procedures, security requirements, and personal information protection requirements.</p>
<p>It is applicable to the development, design, deployment, application, and testing certification and other related
activities of IIFAA decentralized trusted authentication.
</p>
</section>
<section id="general-framework"><div class="header-wrapper"><h2 id="x2-general-framework"><bdi class="secno">2. </bdi>General Framework</h2><a class="self-link" href="#general-framework" aria-label="Permalink for Section 2."></a></div>
<section id="reference-model"><div class="header-wrapper"><h3 id="x2-1-reference-model"><bdi class="secno">2.1 </bdi>Reference Model</h3><a class="self-link" href="#reference-model" aria-label="Permalink for Section 2.1"></a></div>
<p>The IIFAA decentralized trusted authentication service reference model is depicted in Figure 1. It comprises four
pivotal roles: issuer, service provider, identity provider, and DID holder; two key data types: VCs and VPs; and a
foundational infrastructure: IIFAA decentralized trusted authentication infrastructure (cloud-chain).</p>
<div><img src="img/Figure1.png" height="auto" width="800"><p>Figure 1 Reference Model</p></div>
<p>The IIFAA decentralized trusted authentication service specifically includes:</p>
<ol type="a">
<li>
Organizations or individuals in the decentralized trusted authentication ecosystem must register a DID through an
identity provider and upload decentralized identity documents containing their identity public key to the blockchain for
storage and verification;
</li>
<li>
Upon user request, issuers grant VCs to the user side for encrypted storage;
</li>
<li>
When users need to present relevant VCs in specific service scenarios, they authorize, assemble, and issue a verifiable
presentation on their side, which is then submitted to the service provider;
</li>
<li>
The service provider, utilizing the infrastructure, accesses the public keys of users and issuers, verifies the user's
authorization and the issuer's identity within the verifiable presentation, and upon successful validation, provides the
requisite services based on the declared content meeting service scenario needs.
</li>
</ol>
</section>
<section id="issuer"><div class="header-wrapper"><h3 id="x2-2-issuer"><bdi class="secno">2.2 </bdi>Issuer</h3><a class="self-link" href="#issuer" aria-label="Permalink for Section 2.2"></a></div>
<p>The requirements for issuers are as follows:</p>
<ol type="a">
<li>
Reliable identity verification capabilities to authenticate the real identities of users or organizations;
</li>
<li>
Secure data storage and transmission capabilities to safeguard DID information from leakage or alteration;
</li>
<li>
User-friendly design to offer an intuitive user interface and a seamless interactive experience;
</li>
<li>
Sustainable service provision to ensure stability and reliability of services, with continual enhancements to improve
user experience;
</li>
<li>
Legal identity credential issuers should be legally authorized organizations;
</li>
<li>
Digital asset credential issuers should have the ability to verify legal identity or service credentials before issuing
digital asset credentials;
</li>
<li>
Desirable monitoring and operational capabilities are necessary to oversee and operate VC issuance services, and
promptly locate and address issues to maintain system stability and reliability.
</li>
</ol>
</section>
<section id="service-provider-sp"><div class="header-wrapper"><h3 id="x2-3-service-provider-sp"><bdi class="secno">2.3 </bdi>Service Provider (SP)</h3><a class="self-link" href="#service-provider-sp" aria-label="Permalink for Section 2.3"></a></div>
<p>Within the decentralized trusted authentication system, service providers are organizations that offer a range of
business services to users. These providers rely on decentralized trusted authentication capabilities and perform
services following VC verification. The requirements for service providers are as follows:</p>
<ol type="a">
<li>Decentralized authentication capability to verify diverse VCs, including legal identity credentials, service
credentials, and digital asset credentials;</li>
<li>Capability to verify the identity of the VC issuing organizations;</li>
<li>Capability to provide various business services to users, including but not limited to online and offline services;</li>
<li>Security measures to ensure the safety and privacy of user VC data and prevent data leakage and misuse;</li>
<li>Desirable monitoring and operational capabilities are necessary to oversee and operate VC verification services, and
promptly locate and address issues to maintain system stability and reliability.</li>
</ol>
</section>
<section id="identity-provider-idp"><div class="header-wrapper"><h3 id="x2-4-identity-provider-idp"><bdi class="secno">2.4 </bdi>Identity Provider (IDP)</h3><a class="self-link" href="#identity-provider-idp" aria-label="Permalink for Section 2.4"></a></div>
<p>The identity provider in the decentralized trusted authentication system offers secure and trustworthy DID registration
services to various organizations and users. The requirements for identity provider are as follows:</p>
<ol type="a">
<li>Implementation of encryption technology to safeguard user data and ensure the security of user identity data against
leakage or alteration;</li>
<li>Adherence to relevant standards to promote data interoperability;</li>
<li>Transparent service provision to enable users to comprehensively understand the registration and utilization of DID;</li>
<li>Provision of various identity registration methods, including web pages, mobile applications, and APIs to facilitate
user registration and the use of DID;</li>
<li>Provision of a DID security mechanism to leverage multi-party computation and ZK-SNARK to enable recovery of lost
identity information;</li>
<li>Monitoring and operational capabilities to oversee and operate DID registration services, promptly locate and address
issues to maintain system stability and reliability.</li>
</ol>
</section>
<section id="did-holder"><div class="header-wrapper"><h3 id="x2-5-did-holder"><bdi class="secno">2.5 </bdi>DID Holder</h3><a class="self-link" href="#did-holder" aria-label="Permalink for Section 2.5"></a></div>
<p>DID holders can be any organization or individual that holds a DID, such as an ordinary user, issuer, or service
provider. They possess private rights to use their DIDs. The requirements for DID holders are as follows:</p>
<ol type="a">
<li>Multiple authentication methods, including but not limited to passwords, biometric technologies, etc., to ensure the
user's identity is not misused;</li>
<li>Capability to authorize other organizations or individuals to verify their identity, serving as proof of holding the
current DID;</li>
<li>Capability to issue verifiable presentations, allowing the holder to authorize and present VCs under the current DID to
other organizations or individuals;</li>
<li>Security safeguard and privacy protection abilities to prevent identity information from being leaked or misused;</li>
<li>Scalability to support large-scale identity authentication and authorization demands;</li>
<li>Standardization capability to enable interoperability and integration with other identity authentication and
authorization systems.</li>
</ol>
</section>
</section>
<section id="technical-architecture-and-functions"><div class="header-wrapper"><h2 id="x3-technical-architecture-and-functions"><bdi class="secno">3. </bdi>Technical Architecture and Functions</h2><a class="self-link" href="#technical-architecture-and-functions" aria-label="Permalink for Section 3."></a></div>
<section id="technical-architecture"><div class="header-wrapper"><h3 id="x3-1-technical-architecture"><bdi class="secno">3.1 </bdi>Technical Architecture</h3><a class="self-link" href="#technical-architecture" aria-label="Permalink for Section 3.1"></a></div>
<p>The IIFAA decentralized trusted authentication system's technical architecture is depicted in Figure 2. This
architecture includes underlying storage, a unified service and control platform, the IIFAA ecosystem operation
platform, issuers, the decentralized trusted authentication infrastructure, service providers, and user sides.</p>
<p>The underlying storage module is primarily responsible for the public display of DID identity documents on the
blockchain, using smart contract capabilities for adding and modifying DID documents. The unified service and control
platform manages organizational entities, trust anchoring, and is responsible for VC presentation traceability and
statistics. It ensures the trusted entry of VC issuing organizations and the trusted access of identity service
providers and conducts VC presentation tracing and auditing for unified management and standardized growth. The IIFAA
ecologic operation platform handles VC template management, service scenario management, and service administration. It
is responsible for the configuration, application, and approval processes of various VC templates and service scenarios,
as well as user service management. Issuers and service providers primarily focus on VC issuance and validation. The
decentralized trusted authentication infrastructure offers general SaaS capabilities, such as interactions between
identity services and blockchain, user private key escrow, and VC presentation escrow and traceability. The user side is
responsible for managing user VCs and presentations, as well as handling decentralized identities on user terminals.</p>
<div><img src="img/Figure2.png" height="auto" width="800"><p>Figure 2 Technical Architecture</p> </div>
</section>
<section id="user-terminal"><div class="header-wrapper"><h3 id="x3-2-user-terminal"><bdi class="secno">3.2 </bdi>User Terminal</h3><a class="self-link" href="#user-terminal" aria-label="Permalink for Section 3.2"></a></div>
<p>Comprising a terminal security foundation layer, core protocol layer, and application service layer, the decentralized
trusted authentication system provides services such as decentralized identity and VC information management for users.
These components collaborate to secure and maintain the confidentiality of user identities and VCs.</p>
<section id="terminal-security-foundation-layer"><div class="header-wrapper"><h4 id="x3-2-1-terminal-security-foundation-layer"><bdi class="secno">3.2.1 </bdi>Terminal Security Foundation Layer</h4><a class="self-link" href="#terminal-security-foundation-layer" aria-label="Permalink for Section 3.2.1"></a></div>
<p>This layer provides security based on the terminal environment. Utilizing the terminal's Trusted Execution Environment
(TEE or SE) and SIM card security areas, it offers core security functionalities for higher-level services, including
but not limited to secure storage, trusted computing, key management, trusted interactions, and device authentication.</p>
</section>
<section id="terminal-core-protocol-layer"><div class="header-wrapper"><h4 id="x3-2-2-terminal-core-protocol-layer"><bdi class="secno">3.2.2 </bdi>Terminal Core Protocol Layer</h4><a class="self-link" href="#terminal-core-protocol-layer" aria-label="Permalink for Section 3.2.2"></a></div>
<p>Building upon the security capabilities of the terminal security foundation layer, this layer offers unified
decentralized identity management services, including local identity creation and update, authorization, and
verification. Additionally, it provides VC management services, such as VC import and revocation, and verifiable
presentation management, including issuance, selective disclosure, ZK-SNARK, etc. These services enhance the security
and trustworthiness of decentralized identities, underpinning digital identity applications with robust terminal
foundation support.</p>
</section>
<section id="terminal-core-service-layer"><div class="header-wrapper"><h4 id="x3-2-3-terminal-core-service-layer"><bdi class="secno">3.2.3 </bdi>Terminal Core Service Layer</h4><a class="self-link" href="#terminal-core-service-layer" aria-label="Permalink for Section 3.2.3"></a></div>
<p>Built on the DID core protocol layer, this layer links decentralized identity infrastructure, issuers, and service
providers to offer users complete decentralized trusted authentication capabilities and services.</p>
<section id="decentralized-identity-management"><div class="header-wrapper"><h5 id="x3-2-3-1-decentralized-identity-management"><bdi class="secno">3.2.3.1 </bdi>Decentralized Identity Management</h5><a class="self-link" href="#decentralized-identity-management" aria-label="Permalink for Section 3.2.3.1"></a></div>
<p>Decentralized identity management involves storing and using decentralized identities on various user devices, including
but not limited to smartphones and servers. The requirements for decentralized identity management are as follows:</p>
<ol type="a">
<li>Capability for decentralized identity registration, involving the generation of identity keys at the user's end during
registration, coupled with the generation of a complete decentralized identity document through the identity provider,
followed by blockchain storage;</li>
<li>Capability for storage and utilization of decentralized identity keys, securely housed on the user side, to enable
operations such as data signing post user authorization;</li>
<li>Capability for decentralized identity cancellation to allow users to actively deregister their decentralized identity
and change the status of the blockchain decentralized identity document to "Closed;"</li>
<li>Provision of cryptographic security mechanisms to protect users' identity information from unauthorized access and cyber
attacks;</li>
<li>Recommended ease of use and configuration to offer a user-friendly interface and experience for the registration and
management of decentralized identities.</li>
</ol>
</section>
<section id="decentralized-identity-verification"><div class="header-wrapper"><h5 id="x3-2-3-2-decentralized-identity-verification"><bdi class="secno">3.2.3.2 </bdi>Decentralized Identity Verification</h5><a class="self-link" href="#decentralized-identity-verification" aria-label="Permalink for Section 3.2.3.2"></a></div>
<p>Decentralized identity verification refers to the independent verification of identity by any organization within the
decentralized trusted authentication system, devoid of reliance on centralized nodes. By leveraging the terminal's
trusted environment, it combines verification methods like passwords and facial or fingerprint recognition with
technologies such as DPKI and ZK-SNARK. Verification key elements and methods are made public on the blockchain,
enabling any organization requiring user DID verification to independently access blockchain identity information and
complete identity verification through methods like private key signature validation and ZK-SNARK checks. The
requirements for decentralized verification are as follows:</p>
<ol type="a">
<li>Identity verification capabilities use methods like passwords, fingerprints, or facial recognition to verify the current
user's identity and prevent identity impersonation, adhering to the fingerprint verification requirements specified in
IIFAA Local Password-Free Technology Specification 2.0;</li>
<li>Operations based on trusted environments such as TEE or SE to ensure the trustworthiness of the identity verification
computational process;</li>
<li>Blockchain publication of non-sensitive verification key elements and methods for autonomous identity verification by
any organization needing to verify user DID;</li>
<li>Recommended ease of use and configuration to offer a user-friendly interface and experience for the utilization of
decentralized identity verification features.</li>
</ol>
</section>
<section id="vc-management"><div class="header-wrapper"><h5 id="x3-2-3-3-vc-management"><bdi class="secno">3.2.3.3 </bdi>VC Management</h5><a class="self-link" href="#vc-management" aria-label="Permalink for Section 3.2.3.3"></a></div>
<p>VC management involves centralized storage and management of various VCs, including legal identity credentials, service
credentials, and digital asset credentials. This ensures the security and validity of these VCs, preventing illegal use
and alteration. The requirements for VC management are as follows:</p>
<ol type="a">
<li>VC import capability to allow the importation of VC data encrypted with the user's public key to the user side, followed
by decryption and persistent storage;</li>
<li>Capability for VC summary sets query to access all VC summaries under a specified DID, including information like the
VC's issuers, types, etc.;</li>
<li>Capability for detailed VC information query, including complete information of a specific VC ID;</li>
<li>Capability to delete VCs to remove VC data corresponding to a specified VC ID.</li>
</ol>
</section>
<section id="vc-presentation"><div class="header-wrapper"><h5 id="x3-2-3-4-vc-presentation"><bdi class="secno">3.2.3.4 </bdi>VC Presentation</h5><a class="self-link" href="#vc-presentation" aria-label="Permalink for Section 3.2.3.4"></a></div>
<p>Based on current scenario requirements, users are provided with a selection and authorization of VC content that meets
the criteria. Following the principle of minimal privacy disclosure, users select and authorize the presentation of
relevant fields. Then, according to standard protocols, a VP is assembled, and signed with the DID private key, and the
signed VP information is presented to the scenario-based service provider for validation. Throughout the entire process,
the handling and signing of VCs are carried out within a secure environment on the user side. This is done following the
principle of minimal privacy disclosure for both selection and authorization, ensuring the security and privacy of user
data. The requirements for VC presentation functionality are as follows:</p>
<ol type="a">
<li>
Adherence to the principle of minimal privacy disclosure when presenting relevant fields to safeguard user identity
information from leakage or misuse;
</li>
<li>
Assembling VP according to standard protocols and signing with the DID private key to ensure the authenticity and
completeness of VCs;
</li>
<li>
Completing VC processing and signing within a trusted environment like TEE or SE to guarantee the security and privacy
of user data.
</li>
</ol>
</section>
</section>
</section>
<section id="issuer-0"><div class="header-wrapper"><h3 id="x3-3-issuer"><bdi class="secno">3.3 </bdi>Issuer</h3><a class="self-link" href="#issuer-0" aria-label="Permalink for Section 3.3"></a></div>
<section id="vc-issuance"><div class="header-wrapper"><h4 id="x3-3-1-vc-issuance"><bdi class="secno">3.3.1 </bdi>VC Issuance</h4><a class="self-link" href="#vc-issuance" aria-label="Permalink for Section 3.3.1"></a></div>
<p>The requirements for VC issuance are as follows:</p>
<ol type="a">
<li>VC template verification capability, with issuers verifying the template before each VC issuance after completing
registration and template configuration on the IIFAA ecologic operation platform, to ensure the issued VCs complies with
standards;</li>
<li>Identity authentication capability, with issuers conducting varying levels of customer identity checks based on the type
of VC being issued in the VC application and issuance process;</li>
<li>Privacy disclosure processing capability, with issuers implementing the issuer's logic for privacy disclosure in the VC
issuance procedure, if such abilities and types are defined in the issuer's template configuration, including but not
limited to selective disclosure, minimal privacy disclosure, ZK-SNARK, etc.;</li>
<li>Credential encryption issuance capability, with issuers encrypting VCs before delivering them to users;</li>
<li>Issuers should establish a mapping relationship between the VC ID, subject ID, and existing data of the issuer.</li>
</ol>
</section>
<section id="vc-revocation"><div class="header-wrapper"><h4 id="x3-3-2-vc-revocation"><bdi class="secno">3.3.2 </bdi>VC Revocation</h4><a class="self-link" href="#vc-revocation" aria-label="Permalink for Section 3.3.2"></a></div>
<p>The requirements for VC revocation functionality are as follows:</p>
<ol type="a">
<li>If issuers need to define a VC status field for VC, they should maintain VC status information as per the W3C-defined VC
status standard. They must also provide an interface as defined in the VC status information for querying VC
information;</li>
<li>Issuers shall maintain the VC revocation status by means including but not limited to blockchain, database, and caches,
and configure an interface for revocation status query as defined in the VC status information.</li>
</ol>
</section>
<section id="vc-traceability-configuration"><div class="header-wrapper"><h4 id="x3-3-3-vc-traceability-configuration"><bdi class="secno">3.3.3 </bdi>VC Traceability Configuration</h4><a class="self-link" href="#vc-traceability-configuration" aria-label="Permalink for Section 3.3.3"></a></div>
<p>If an issuer requires VCs to be traceable, he/she shall configure the corresponding VC template that supports
traceability on the IIFAA ecological operation platform, and define the specific information that needs to be traced.</p>
</section>
</section>
<section id="decentralized-trusted-authentication-infrastructure"><div class="header-wrapper"><h3 id="x3-4-decentralized-trusted-authentication-infrastructure"><bdi class="secno">3.4 </bdi>Decentralized Trusted Authentication Infrastructure</h3><a class="self-link" href="#decentralized-trusted-authentication-infrastructure" aria-label="Permalink for Section 3.4"></a></div>
<section id="identity-service"><div class="header-wrapper"><h4 id="x3-4-1-identity-service"><bdi class="secno">3.4.1 </bdi>Identity Service</h4><a class="self-link" href="#identity-service" aria-label="Permalink for Section 3.4.1"></a></div>
<p>The identity service requirements are as follows:</p>
<ol type="a">
<li>DID service to implement the DID parsing layer, which enables the interaction with the blockchain through a smart
contract, for DID creation, query, modification, and deletion;</li>
<li>Recommended alias service with functions such as quick use and retrieval of DIDs, including defining the basic alias
rules, maintaining the one-to-one mapping relationships between an alias and a DID, and implementing alias creation,
query, modification, and deletion.</li>
</ol>
</section>
<section id="private-key-escrow"><div class="header-wrapper"><h4 id="x3-4-2-private-key-escrow"><bdi class="secno">3.4.2 </bdi>Private Key Escrow</h4><a class="self-link" href="#private-key-escrow" aria-label="Permalink for Section 3.4.2"></a></div>
<p>The decentralized DID private key escrow service shall be provisioned based on technologies including but not limited to
MPC Key Share, TEE, privacy computing, access control and permission management, and multi-factor authentication (MFA).</p>
</section>
<section id="vc-escrow"><div class="header-wrapper"><h4 id="x3-4-3-vc-escrow"><bdi class="secno">3.4.3 </bdi>VC Escrow</h4><a class="self-link" href="#vc-escrow" aria-label="Permalink for Section 3.4.3"></a></div>
<p>The VC encryption escrow service shall be provisioned.</p>
</section>
<section id="vc-traceability"><div class="header-wrapper"><h4 id="x3-4-4-vc-traceability"><bdi class="secno">3.4.4 </bdi>VC Traceability</h4><a class="self-link" href="#vc-traceability" aria-label="Permalink for Section 3.4.4"></a></div>
<p>The VC traceability requirements are as follows:</p>
<ol type="a">
<li>VC traceability, that is, when a user presents a VP containing a VC that needs to be traceable, the VC shall be
encrypted using a security key of the IIFAA decentralized infrastructure, and an interface shall be configured for SPs
to obtain the security key for decryption before authenticating the VP. VC traceability information is classified into
basic information and custom information. The basic information is stored in plaintext and contains issuer DID, SP DID,
VC type, VC presentation time, and VC authentication time. The custom information is encrypted for storage and includes
user DID, VC ID, and service scenarios.</li>
<li>Capability to query VC traceability information, and provisioning of an interface for issuers to query the above VC
traceability information.</li>
</ol>
</section>
<section id="vc-escrow-0"><div class="header-wrapper"><h4 id="x3-4-5-vc-escrow"><bdi class="secno">3.4.5 </bdi>VC Escrow</h4><a class="self-link" href="#vc-escrow-0" aria-label="Permalink for Section 3.4.5"></a></div>
<p>The VP encryption escrow capability shall be provisioned. That is, when a user encrypts a VP and submits the encrypted
VP to the platform, the platform returns a unique encrypted ID, based on which, SPs can query the encrypted VP.</p>
</section>
</section>
<section id="sps"><div class="header-wrapper"><h3 id="x3-5-sps"><bdi class="secno">3.5 </bdi>SPs</h3><a class="self-link" href="#sps" aria-label="Permalink for Section 3.5"></a></div>
<section id="vp-verification"><div class="header-wrapper"><h4 id="x3-5-1-vp-verification"><bdi class="secno">3.5.1 </bdi>VP Verification</h4><a class="self-link" href="#vp-verification" aria-label="Permalink for Section 3.5.1"></a></div>
<p>During VP verification, SPs shall have the capability to verify the signature of the verifiable statement, the signature
and status of the VC(s) contained in the verifiable statement, the nature of privacy disclosure, and the subject
consistency between the VC and the verifiable statement. If SPs are required to be capable of verifying whether the VP
is anti-replay, such capability shall be deployed on the IIFAA decentralized trusted authentication infrastructure, and
the anti-replay check shall be executed.</p>
<p>During statement verification, SPs shall have the capability to verify the identities of organizations that issue legal
identity credentials.</p>
</section>
<section id="organization-verification"><div class="header-wrapper"><h4 id="x3-5-2-organization-verification"><bdi class="secno">3.5.2 </bdi>Organization Verification</h4><a class="self-link" href="#organization-verification" aria-label="Permalink for Section 3.5.2"></a></div>
<p>SPs shall have the capability to verify the identities of VC issuers.</p>
</section>
</section>
<section id="iifaa-ecologic-operation-platform"><div class="header-wrapper"><h3 id="x3-6-iifaa-ecologic-operation-platform"><bdi class="secno">3.6 </bdi>IIFAA Ecologic Operation Platform</h3><a class="self-link" href="#iifaa-ecologic-operation-platform" aria-label="Permalink for Section 3.6"></a></div>
<section id="vc-template-management"><div class="header-wrapper"><h4 id="x3-6-1-vc-template-management"><bdi class="secno">3.6.1 </bdi>VC Template Management</h4><a class="self-link" href="#vc-template-management" aria-label="Permalink for Section 3.6.1"></a></div>
<p>The IIFAA ecologic operation platform shall provide the management of VC templates to constrain the attribute profiles
of the VCs issued by issuers. The attribute profile management ensures unified attribute fields of VC templates. An
issuer can request issuing VCs in a specified VC template, and after the request is approved, the issuer can issue VCs
using this template. SPs can query VCs that are already issued by issuers through scenario configurations, and use the
appropriate VCs.</p>
<p>VC templates shall be hierarchical. That is, legal identity VC templates are available for legal identity issuers only,
and general identity VC templates are available for both legal identity issuers and general identity issuers. In
addition, VC templates should be classified according to different industries, and their application scopes shall be
clearly defined.</p>
<p>For this feature, the IIFAA platform:</p>
<ol type="a">
<li>Should have the capability to input attributes, and specify the available attributes of VC templates and their
definition;</li>
<li>Should have the capability to edit attributes by modifying their definitions;</li>
<li>Should have the capability to query the list of attributes, query all existing attributes in an trusted manner, and
input VC templates. It can configure VC type, VC level, and VC template name & description, and select the attributes
required by the template to configure jsonSchema constraints corresponding to the VC template;</li>
<li>Shall have the capability to edit VC templates by modifying information about the template except for the template name;</li>
<li>Shall have the capability to query VC template list, that is, to query all configured VC templates;</li>
<li>Shall have the capability to apply for VC templates as an issuer. Issuers can apply for existing VC templates;</li>
<li>Shall have the capability to approve VC templates as an issuer. When an issuer applies for a VC template, the VC
template needs to be reviewed by the IDP operator, and after that, the issuer can issue VCs using this VC template;</li>
<li>Shall have the capability to query the VC template list as a specified issuer, that is to query all VC templates that
have been reviewed and approved by issuers. SPs can configure their service scenario policies using these templates.</li>
</ol>
</section>
<section id="scenario-management"><div class="header-wrapper"><h4 id="x3-6-2-scenario-management"><bdi class="secno">3.6.2 </bdi>Scenario Management</h4><a class="self-link" href="#scenario-management" aria-label="Permalink for Section 3.6.2"></a></div>
<p>The service scenario policy configuration function shall be provisioned so that an SP can configure a VC policy for the
current scenario using a VC template that has been reviewed and approved by the corresponding issuer. After the IDP
operator reviews the scenario, the service scenario can go online for specified VCs.</p>
<p>For this feature, the IIFAA platform:</p>
<ol type="a">
<li>Should have the capability to create VC policies. In most cases, to build a VC use policy, the platform specifies the VC
information to be used in this policy, whether each attribute is required in each VC, and whether the required fields
are subject to the minimum disclosure policy.</li>
<li>Should have the capability to query VC policies, that is, to query all created VC policies.</li>
<li>Shall have the capability to apply service scenarios, that is, to create a complete scenario request sheet by selecting
a VC policy and filling in basic scenario information such as logo, destination address, encryption algorithm, and
service DID.</li>
<li>Shall have the capability to review service scenarios. It is recommended that the IDP operator or the related issuer in
the VC policy be responsible for the review of the scenario.</li>
<li>Shall have the capability to modify service scenarios, that is, enable the SP owning a scenario to modify the scenario,
and such modification will take effect only after being re-approved.</li>
<li>Shall have the capability to query service scenario list, that is, to query all approved scenarios.</li>
</ol>
</section>
<section id="service-scenario-display"><div class="header-wrapper"><h4 id="x3-6-3-service-scenario-display"><bdi class="secno">3.6.3 </bdi>Service Scenario Display</h4><a class="self-link" href="#service-scenario-display" aria-label="Permalink for Section 3.6.3"></a></div>
<p>A list page should be configured to display all online service scenarios so that users can enjoy desired services via
the corresponding ingresses.</p>
</section>
<section id="vc-list-display"><div class="header-wrapper"><h4 id="x3-6-4-vc-list-display"><bdi class="secno">3.6.4 </bdi>VC List Display</h4><a class="self-link" href="#vc-list-display" aria-label="Permalink for Section 3.6.4"></a></div>
<p>A list page should be configured to display all online VCs so that users can apply for desired VCs for use.</p>
</section>
</section>
<section id="unified-service-and-control-platform"><div class="header-wrapper"><h3 id="x3-7-unified-service-and-control-platform"><bdi class="secno">3.7 </bdi>Unified Service and Control Platform</h3><a class="self-link" href="#unified-service-and-control-platform" aria-label="Permalink for Section 3.7"></a></div>
<p>The unified service and control platform is used for organization registration and authentication, and it can provide
the trust anchoring service to establish an organization information chain. It also has certain VC traceability and
audit capability.</p>
<section id="organization-management"><div class="header-wrapper"><h4 id="x3-7-1-organization-management"><bdi class="secno">3.7.1 </bdi>Organization Management</h4><a class="self-link" href="#organization-management" aria-label="Permalink for Section 3.7.1"></a></div>
<p>The platform shall implement the registration and management of organization information, and these organizations may be
issuers or SPs. Organizations that issue legal identity credentials shall be certified by an authoritative CA agency,
while for those that issue service credentials or digital asset credentials, domain name-based authentication is
recommended.</p>
<p>For this module, the unified service and control platform shall have the following capabilities:</p>
<ol type="a">
<li>Capability to register organization information and store organization-related information securely;</li>
<li>Capability to review organization information for authentication of service organizations or legal identity credential
issuers;</li>
<li>Capability to edit organization information;</li>
<li>Capability to query organization, that is, to query organizations from the organization information list.</li>
</ol>
</section>
<section id="trust-anchoring"><div class="header-wrapper"><h4 id="x3-7-2-trust-anchoring"><bdi class="secno">3.7.2 </bdi>Trust Anchoring</h4><a class="self-link" href="#trust-anchoring" aria-label="Permalink for Section 3.7.2"></a></div>
<p>Trust anchoring is a process of establishing and maintaining trust on the basis of a reliable entity or mechanism. As a
key component for building a trust architecture, trust anchoring provides a verifiable and reliable reference point that
assures participants of the confidence level of a system or entity.</p>
<p>Decentralized identity trust anchoring shall enable trusted authentication of issuers and access of legal identity
issuers, for unified management, control, and standardized development of organizations including issuers and SPs.</p>
</section>
<section id="traceability-and-audit"><div class="header-wrapper"><h4 id="x3-7-3-traceability-and-audit"><bdi class="secno">3.7.3 </bdi>Traceability and Audit</h4><a class="self-link" href="#traceability-and-audit" aria-label="Permalink for Section 3.7.3"></a></div>
<p>The user identity credential traceability and audit capacity shall be provisioned. For this module, the unified service
and control platform shall have the following capabilities:</p>
</section>
<ol type="a">
<li>Capability to record the usage history of all VCs for traceability and audit.</li>
<li>Capability to record the privacy protection of user information during record use without retaining any VC details, and
ensure that identity information is accessible to authorized individuals or organizations only.</li>
<li>Traceability and audit capability based on VC issuers, that is, to measure the presentations of VCs issued by an issuer.</li>
<li>Traceability and audit capability based on SPs, that is, to measure the presentations of VCs used by an SP.</li>
</ol>
</section>
</section>
<section id="service-procedure"><div class="header-wrapper"><h2 id="x4-service-procedure"><bdi class="secno">4. </bdi>Service Procedure</h2><a class="self-link" href="#service-procedure" aria-label="Permalink for Section 4."></a></div>
<section id="organization-registration-procedure"><div class="header-wrapper"><h3 id="x4-1-organization-registration-procedure"><bdi class="secno">4.1 </bdi>Organization Registration Procedure</h3><a class="self-link" href="#organization-registration-procedure" aria-label="Permalink for Section 4.1"></a></div>
<p>In the decentralized trusted authentication system, organizations fall into two categories: VC issuers who issue VCs to
users, and SPs who, based on the VPs given by users, obtain user information and provide services. The prerequisite for
the healthy operation of the decentralized trusted authentication system is that users hold reliable VCs. Therefore,
when registering with the unified service and control platform, issuers need to go through an authentication procedure
to verify that they are authoritative and reliable. Although the right to use data belongs to users, for healthy data
transfer, SPs also need to go through authentication to avoid malicious information collection and data abuse.</p>
<section id="issuer-registration"><div class="header-wrapper"><h4 id="x4-1-1-issuer-registration"><bdi class="secno">4.1.1 </bdi>Issuer Registration</h4><a class="self-link" href="#issuer-registration" aria-label="Permalink for Section 4.1.1"></a></div>
<img src="img/Figure3.png" height="auto" width="800"><p>Figure 3 Issuer Registration Procedure</p>
<p>The issuer registration procedure is shown in Figure 3. During registration, an issuer needs to submit related
information as required by the unified service and control platform. After the information is reviewed, the platform
notifies the IDP to generate a DID for the issuer and uploads some information to the blockchain for publicity. Issuers
are divided into legal organizations and ordinary organizations. The digital VCs issued by legal organizations are more
authoritative and have a wider range of application scenarios. Therefore, legal organizations need to go through a more
stringent authentication, for which, CA-based authentication is recommended. For ordinary organizations, domain
name-based authentication is recommended. The specific issuer registration procedure is as follows:</p>
<ol type="a">
<li>
An issuer generates private keys and stores them securely (1).
</li>
<li>
The issuer submits information such as public keys, website domain name, and website name to the unified service and
control platform (2).
</li>
<li>
The issuer selects an appropriate authentication method depending on its organization type. If the issuer is a legal
organization, it selects CA authentication and submits a CA certificate issued by an authoritative CA agency for
authentication. If the issuer is an ordinary organization, it goes through domain name-based authentication (3).
</li>
<li>
The unified service and control platform reviews and verifies the information submitted by the issuer. After successful
verification, the platform notifies the IDP to generate a DID, uploads it to the blockchain, and returns the related
information to the issuer (4, 5, 6, 7).
</li>
</ol>
</section>
<section id="sp-registration"><div class="header-wrapper"><h4 id="x4-1-2-sp-registration"><bdi class="secno">4.1.2 </bdi>SP Registration</h4><a class="self-link" href="#sp-registration" aria-label="Permalink for Section 4.1.2"></a></div>
<img src="img/Figure4.png" height="auto" width="800"><p>Figure 4 SP Registration Procedure</p>
<p>The SP registration procedure is shown in Figure 4. During registration, an SP submits information as required. After
the information is reviewed, the IDP generates the corresponding DID and uploads some information to the blockchain.
When creating an application scenario, the SP can select a specified issuer as the data issuer. To prevent SPs from
maliciously collecting and abusing data, the unified service and control platform or issuer will review the SP's
scenario access based on the issuer's data use requirements. After the review, the scenario is configured for future
use. The specific procedure is as follows:</p>
<ol type="a">
<li>An SP generates private keys and stores them securely (1).</li>
<li>The SP submits information such as name, logo, and public keys to the unified service and control platform (2).</li>
<li>The platform reviews and verifies the information submitted by the SP. After the information is reviewed, the platform
notifies the IDP to generate a DID, uploads it to the blockchain, and returns it to the SP (3, 4).</li>
<li>The SP creates an application scenario on the platform and specifies the dependent data source (5).</li>
<li>If the issuer specifies that approval is required for its VCs, the SP initiates an application (6).</li>
<li>After the application is approved by the issuer, the platform generates the scenario configuration for future use by the
SP (7).</li>
</ol>
</section>
</section>
<section id="vc-issuance-procedure"><div class="header-wrapper"><h3 id="x4-2-vc-issuance-procedure"><bdi class="secno">4.2 </bdi>VC Issuance Procedure</h3><a class="self-link" href="#vc-issuance-procedure" aria-label="Permalink for Section 4.2"></a></div>
<p>The VC issuance procedure is shown in Figure 5. A user creates a DID and applies for a VC on the terminal, and the
corresponding issuer authenticates the user's identity and then issues the VC. The issuance procedure is the same for
different types of VC, with some differences in user authentication. To issue a legal identity credential, the
corresponding issuer authenticates the user's identity through face and ID comparison. To issue a service credential or
digital asset credential, the corresponding issuer can authenticate the user's identity through face and ID comparison
or based on the user's legal identity credential on the terminal.</p>
<img src="img/Figure6.png" height="auto" width="800"><p>Figure 6 VP Procedure</p>
<p>The VC issuance procedure is as follows:</p>
<ol type="a">
<li>A user initiates a request for creating a DID on the app (1).</li>
<li>The trusted key components of the terminal generate public and private keys (2).</li>
<li>The terminal uploads public keys to the IDP and initiates a request for creating a DID (3).</li>
<li>The IDP generates a DID document based on the public keys and uploads the public keys and DID document to the blockchain
(4).</li>
<li>The terminal receives the DID document returned by the IDP and calls the trusted storage components for data storage
(5).</li>
<li>The terminal applies for a VC from the issuer (6).</li>
<li>Depending on the type of the applied VC, the issuer authenticates the user's identity using an appropriate method (7).</li>
<li>The issuer signs the VC with its own DID private key and then encrypts it with the user's DID public key. The encrypted
data is sent to the terminal, which stores it securely through the trusted storage component (8).</li>
</ol>
<p>In the above steps, if the terminal already has a DID, ignore steps a) to e), and go to step f) directly.</p>
</section>
<section id="vp-procedure"><div class="header-wrapper"><h3 id="x4-3-vp-procedure"><bdi class="secno">4.3 </bdi>VP Procedure</h3><a class="self-link" href="#vp-procedure" aria-label="Permalink for Section 4.3"></a></div>
<img src="img/Figure5.png" height="auto" width="800"><p>Figure 5 VC Issuance Procedure</p>
<p>The VP procedure is shown in Figure 6. To enjoy the services provided by an SP, a user needs to apply for a VC from the
asset issuer and generate a VP per the SP's service scenario requirements. After the VP is generated, the SP verifies
the VP to complete user authentication, and then provides services for the user. The specific procedure is as follows:</p>
<ol type="a">
<li>Before using the services provided by an SP, a user needs to submit his/her data and information for authentication (1).</li>