-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
1216 lines (1199 loc) · 72.9 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>
<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>
<meta charset="utf-8">
<title>IIFAA Decentralized Trusted Authentication Technical Specification - Part 1: General Requirements</title>
<script src="https://www.w3.org/Tools/respec/respec-w3c" class="remove"></script>
<script class='remove'>
// See https://github.com/w3c/respec/wiki/ for how to configure ReSpec
var respecConfig = {
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: "Wu Huacheng",
company: "Vivo Communication 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 Huacheng",
company: "Vivo Communication Co., Ltd.",
companyURL: ""
}
],
group: "cndid",
github:"w3c-cg/cndid"
};
</script>
</head>
<body>
<section id="abstract">
<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">
<p>
This is an joint publication from IFFAA and W3C Chinese DID & VC Community.
</p>
</section>
<section id="introduction">
<h2>Introduction</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>
<h2>General Framework</h2>
<section>
<h3>Reference Model</h3>
<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>
<h3>Issuer</h3>
<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>
<h3>Service Provider (SP)</h3>
<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>
<h3>Identity Provider (IDP)</h3>
<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>
<h3>DID Holder</h3>
<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>
<h2>Technical Architecture and Functions</h2>
<section>
<h3>Technical Architecture</h3>
<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>
<h3>User Terminal</h3>
<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>
<h4>Terminal Security Foundation Layer</h4>
<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>
<h4>Terminal Core Protocol Layer</h4>
<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>
<h4>Terminal Core Service Layer</h4>
<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>
<h5>Decentralized Identity Management</h5>
<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>
<h5>Decentralized Identity Verification</h5>
<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>
<h5>VC Management</h5>
<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>
<h5>VC Presentation</h5>
<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>
<h3>Issuer</h3>
<section>
<h4>VC Issuance</h4>
<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>
<h4>VC Revocation</h4>
<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>
<h4>VC Traceability Configuration</h4>
<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>
<h3>Decentralized Trusted Authentication Infrastructure</h3>
<section>
<h4>Identity Service</h4>
<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>
<h4>Private Key Escrow</h4>
<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>
<h4>VC Escrow</h4>
<p>The VC encryption escrow service shall be provisioned.</p>
</section>
<section>
<h4>VC Traceability</h4>
<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>
<h4>VC Escrow</h4>
<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>
<h3>SPs</h3>
<section>
<h4>VP Verification</h4>
<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>
<h4>Organization Verification</h4>
<p>SPs shall have the capability to verify the identities of VC issuers.</p>
</section>
</section>
<section>
<h3>IIFAA Ecologic Operation Platform</h3>
<section>
<h4>VC Template Management</h4>
<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>
<h4>Scenario Management</h4>
<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>
<h4>Service Scenario Display</h4>
<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>
<h4>VC List Display</h4>
<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>
<h3>Unified Service and Control Platform</h3>
<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>
<h4>Organization Management</h4>
<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>
<h4>Trust Anchoring</h4>
<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>
<h4>Traceability and Audit</h4>
<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>
<h2>Service Procedure</h2>
<section>
<h3>Organization Registration Procedure</h3>
<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>
<h4>Issuer Registration</h4>
<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>
<h4>SP Registration</h4>
<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>
<h3>VC Issuance Procedure</h3>
<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>
<h3>VP Procedure</h3>
<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>
<li>The terminal queries the configurations of the SP, and obtains the SP's requirements for user data in this scenario (2).</li>
<li>The user authorizes the application vendor and VC corresponding to the presentation.</li>
<li>The terminal selects a proper VC based on the configurations, constructs VP content using the SP's DID and public key,
and then signs the VP content with the user's private key to generate a VP (4).</li>
<li>The terminal encrypts the VP with the SP's public key and then transmits it to the SP (5).</li>
<li>The SP decrypts and verifies the VP data, and authenticates the user information based on the original data (6).</li>
<li>The SP authenticates the user, and then provides services for the user (7).</li>
</ol>
</section>
</section>
<section>
<h2>Security Requirements</h2>
<section>
<h3>Password Locks Security</h3>
<p>Applicable encryption algorithms shall be selected and applied according to specific conditions, and the encryption
algorithms for security and reliability shall be used to ensure data confidentiality, integrity, and availability. The
supported cryptographic algorithms include:</p>
<ol type="a">
<li>Symmetric encryption algorithms, including SM4, AES, etc.</li>
<li>Asymmetric encryption algorithms, including SM2, RSA (2048 or above), DSA, ECC, etc.</li>
<li>Abstract algorithm, including SM3, SHA-2, SHA-3, etc.</li>
</ol>
<p class="ednote">Note: Symmetric encryption algorithms are mainly used for encrypted data storage and transmission. Asymmetric encryption
algorithms are for digital signature and authentication. Message abstract algorithms are for cryptographic hashing and
digital signature.</p>
</section>
<section>
<h3>Data Security</h3>
<p>It shall be as per GB/T 41479, in addition to the following requirements:</p>
<ol type="a">
<li>Encryption communication: Data shall be encrypted to avoid being eavesdropped during transmission.</li>
<li>Two-way authentication: Both endpoints of the data transmission shall go through authentication to avoid illegal access
or data breach.</li>
<li>Security protocol: TLS, TLCP, or other security protocols shall be used to ensure security during data transmission.</li>
<li>Anti-replay: Measures against replay attacks, such as timestamps and random numbers, shall be taken to ensure
reliability during data transmission.</li>
<li>Data integrity: Integrity shall be ensured during data transmission to protect data from being tampered with.</li>
<li>Secure storage: Data shall be stored securely after transmission.</li>
</ol>
</section>
<section>
<h3>Server Security</h3>
<p>The requirements are as follows:</p>
<ol type="a">
<li>OS security: For device security, the security patches and software versions shall be updated in time for the operating
systems of server devices.</li>
<li>Application security: For application security, the applications installed on server devices shall be kept up-to-date,
and unaudited applications shall be avoided.</li>
<li>Password and identity authentication: The password and identity authentication shall be configured on server devices to
ensure that only authorized personnel can access these devices.</li>
<li>Anti-virus and malicious software: The anti-virus and malware scan programs shall be installed and periodically executed
to protect devices from being attacked by viruses and malware.</li>
</ol>
</section>
<section>
<h3>Terminal Security</h3>
<p>The requirements are as follows:</p>
<ol type="a">
<li>Secure boot: The OS and applications on terminals shall be protected from being tampered with or replaced by malware
during startup.</li>
<li>Secure storage: Data stored on terminals shall be encrypted and protected from being accessed or used by unauthorized
persons or malware.</li>
<li>Secure operating environment (such as TEE): The applications on terminals shall be protected from being attacked by
malware or other threats during operation.</li>
<li>Secure communication: Terminals shall be able to interact with each other securely so that data will not be tampered
with or eavesdropped during transmission.</li>
<li>Secure update: The OS and applications on terminals shall be protected from being tampered with or replaced by malware
during updates, and the update process shall be secure.</li>
<li>Trusted authentication: The user authentication on terminals shall be trusted so that only authorized users can access
devices and data.</li>
<li>The biometrics recognition on mobile devices shall be as per GB/T 37036 (All parts).</li>
</ol>
</section>
<section>
<h3>Server Security Requirements</h3>
<p>The requirements are as follows:</p>
<ol type="a">
<li>The server shall authenticate all requests to ensure that these requests come from legal users or clients.</li>
<li>The server shall implement access control so that only authorized users or clients can access specified resources.</li>
<li>The server shall handle faults and exceptions in time to avoid server attacks and service interruptions.</li>
<li>The server shall record all access logs and exception logs for tracking and analysis.</li>
<li>The server shall establish an emergency response mechanism for the timely handling of security events and threats.</li>
</ol>
</section>
</section>
<section>
<h2>Personal Information Protection Requirements</h2>
<section>
<h3>General Requirements</h3>
<p>Personal information and biometric information shall be as per GB/T 35273 and GB/T 40660. Face recognition data shall
also comply with GB/T 41819.</p>
</section>
<section>
<h3>Biometric Data Masking Requirements</h3>
<p>Raw biometric data should be anonymized into the irreversible ZK-SNARK to ensure the security and privacy of users'
biometric data.</p>
</section>
<section>
<h3>Disclosure of Personal Information</h3>
<p>The disclosure involves two methods: selective disclosure and minimum disclosure, with the requirements as follows:</p>
<ol type="a">
<li>For the selective disclosure:
<ol>
<li>SPs shall specify the user information required for services under the minimum collection principle.</li>
<li>Terminals shall list the attributes that need and do not need to be presented by users before the VC presentation.</li>
<li>For non-required attributes, users can set whether to authorize disclosure at their discretion.</li>
</ol>
</li>
<li>For the minimum disclosure:
<ol>
<li>When building VCs, issuers shall specify the required attributes under the minimum disclosure principle.</li>
<li>SPs shall specify the attributes required for service operation under the minimum disclosure principle, and define the
scope.</li>
<li>Terminals should construct presentation attributes using the ZK-SNARK before the VC presentation.</li>
<li>When verifying VPs, SPs shall determine whether the corresponding attributes are required using the ZK-SNARK.</li>
</ol>
</li>
</ol>
</section>
</section>
<section>
<h2>Test Requirements</h2>
<section>
<h3>Protocol Standard Testing</h3>
<p>Full protocol standard testing needs to be carried out on DID documents, VCs, and VPs to ensure that: 1) DID documents
can present different authentication methods and cross-chain mutual recognition; 2) VCs can prove the attribute or right
of some statements of the corresponding holders; and 3) VPs can prove the corresponding holders' identities and present
a set of VCs to third parties.</p>
<section>
<h4>DID Document Protocol Testing</h4>
<p>The test method and expected result of the DID document protocol testing are as follows:</p>
<ol type="a">
<li>Test method: When the IDP generates a DID document, check whether the DID document complies with the IIFAA decentralized
trusted authentication standards.</li>
<li>Expected result: When the IDP generates a DID document, upon check, the DID document complies with the IIFAA
decentralized trusted authentication standards.</li>
<li>Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is
unacceptable.</li>
</ol>
</section>
<section>
<h4>VC Protocol Testing</h4>
<p>The test method and expected result of the VC protocol testing are as follows:</p>
<ol type="a">
<li>Test method: When the issuer generates a VC, check whether the VC complies with the IIFAA decentralized trusted
authentication standards.</li>
<li>Expected result: When the issuer generates a VC, upon check, the VC complies with the IIFAA decentralized trusted
authentication standards.</li>
<li>Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is
unacceptable.</li>
</ol>
</section>
<section>
<h4>VP Protocol Testing</h4>
<p>The test method and expected result of the VP protocol testing are as follows:</p>
<ol type="a">
<li>Test method: When DID holder presents a VP, check whether the VP complies with the IIFAA decentralized trusted
authentication standards.</li>
<li>Expected result: When DID holder presents a VP, upon check, the VP complies with the IIFAA decentralized trusted
authentication standards.</li>
<li>Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is
unacceptable.</li>
</ol>
</section>
</section>
<section>
<h3>Operating Environment Security Testing</h3>
<p>To protect the security and credibility of decentralized trusted authentication DID keys and user data, full security
testing needs to be carried out on the terminal environment where a decentralized trusted authentication system runs,
the key algorithms used, and the data protocols adopted.</p>
<section>
<h4>Terminal Environment Security Testing</h4>
<p>The test methods and expected results of the terminal environment security testing are as follows:</p>
<ol type="a">
<li>Test methods:
<ol>
<li>Check whether DID keys are stored in a secure environment as stated in the DID document.</li>
<li>Check whether VCs are encrypted and stored.</li>
</ol>
</li>
<li>Expected results:
<ol>
<li>If DID document states SE storage, DID keys are generated and used in the security zone of the SE or SIM card on the
terminal.</li>
<li>If DID document states TEE storage, DID keys are generated and used in the TEE of the terminal.</li>
<li>VCs are encrypted and stored.</li>
</ol>
</li>
<li>Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is
unacceptable.
</li>
</ol>
</section>
<section>
<h4>Key Algorithm Security Testing</h4>
<p>The test methods and expected results of the key algorithm security testing are as follows:</p>
<ol type="a">
<li>Test methods:
<ol>
<li>Check whether key algorithms such as SM2/ECC/RSA3072, SM4/AES, and SM3/SHA2 are supported.</li>
<li>Check whether keys are stored and used in a secure environment as stated in the DID document.</li>
</ol>
</li>
<li>Expected results:
<ol>
<li>If DID document states SE storage, related keys and algorithms run in the security zone of the SE or SIM card.</li>
<li>If DID document states TEE storage, related keys and algorithms run in the TEE of the terminal.</li>
</ol>
</li>
<li>Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is unacceptable.
</li>
</ol>
</section>
<section>
<h4>Data Protocol Security Testing</h4>
<p>The test methods and expected results of the data protocol security testing are as follows:</p>