GB/T 47702-2026Blockchain and distributed ledger technology - General services - Technical requirements for decentralized identity systems (English PDF)

5.3 Distributed Identity Capability Layer

5.3.1 DID Subsystem The DID subsystem provides DID identifier and DID document management functions, including DID creation, parsing, use, update, recovery, and deregistration. Etc. The syntax structure related to DID identifiers is shown in Appendix A.

5.3.2 Voucher Subsystem The credential subsystem includes a VC module and a VP module, providing management functions for VCs and VPs, including VC issuance, verification, and updating. This includes cancellation, transfer, deletion, and the presentation and verification of VPs. Appendix B uses the process of logistics document and voucher transfer in a cross-border trade scenario as an example to illustrate this. This highlights the advantages of using a distributed identity system.

5.3.3 Verifiable Data Registration Subsystem The verifiable data registration subsystem includes a DID data registration module, a VC data registration module, and a VP data registration module, combined with the underlying... Storage infrastructure together constitutes VDR, providing secure data storage and access functions, and ensuring data immutability, traceability, and reliability. audit.

5.4 Infrastructure Layer The infrastructure layer of a distributed identity system includes storage infrastructure and cryptographic infrastructure.

a) Storage infrastructure provides data storage services for distributed identity systems, including distributed ledgers, trusted databases, etc., depending on the application. For different scenarios, decentralized distributed ledgers or centralized trusted databases can be chosen as the storage infrastructure;

b) Cryptographic infrastructure provides cryptographic services for distributed identity systems, including personal key devices or systems (TEE, SE, cryptographic modules). Blocks, etc.), key custody devices or systems (key vaults, key management systems, etc.), cryptographic computing devices (cryptographic machines, cryptographic cards). etc.

5.5 Cross-functional layer The cross-functional layer includes the security management module, governance module, and audit module.

a) The security management module is used to ensure the security and privacy protection of DID and VC identity information;

b) The governance module establishes a management framework and technical standards by designating a management body, thereby achieving transparency, compliance, and efficiency across the entire ecosystem. Operation;

c) The audit module records, monitors, and evaluates all operations in the system, ensuring that all identity-related behaviors are traceable, compliant, and secure.

6.Technical Requirements for Service Interface Layer Distributed identity systems provide services externally through SDKs, clients, APIs, etc., and meet the following requirements.

a) Measures should be taken to ensure the accuracy and reliability of data collected through the interface;

b) Measures should be taken to ensure the confidentiality of data transmission through the interface;

c) Measures should be taken to ensure the integrity of data transmission during interface data transfer;

7.1 DID Subsystem

7.1.1 DID Creation DID creation generates and associates DID identifiers and DID documents, meeting the following requirements.

a) It is advisable to generate DID public/private key pairs through a user agent;

b) A DID identifier should be created based on information such as the DID public key;

c) A corresponding DID document should be created based on the DID identifier, DID public key, etc.

d) The DID identifier and the DID document should have a one-to-one correspondence;

e) The uniqueness of the DID identifier should be ensured;

f) It is advisable to verify the authenticity of the DID subject's identity with an authoritative institution before creating the DID.

Note. The authoritative institution for verifying the authenticity of natural persons' identities is the National Online Identity Authentication Public Service Platform.

7.1.2 DID Resolution DID parsing retrieves the DID document based on the DID identifier, and must meet the following requirements.

a) The DID document should be obtained by parsing the VDR based on the DID identifier;

b) Specific attributes in the DID document can be retrieved from the VDR;

c) The DID document corresponding to the specified version of the DID identifier can be parsed from the VDR.

7.1.3 DID Usage DID is used for signing or encryption using application DID, and must meet the following requirements.

a) Data should be digitally signed using the DID private key, and the signature should be verified using the corresponding DID public key;

7.2 Voucher Subsystem

7.2.1 VC Issuance The VC issuance process involves the issuer issuing VCs to the holder, and must meet the following requirements.

a) The holder should have created a DID identifier and corresponding DID document before the issuer issues the VC;

b) When a holder requests the issuance of a VC, they should digitally sign it using the private key corresponding to their DID identifier;

c) When issuing a VC, the issuer should use the public key corresponding to the holder's DID identifier to verify the digital signature in the VC issuance request. It is proven that he/she is the holder of the DID identifier;

d) After the identity attribute verification is successful, the issuer should use its private key to sign the holder's identity information and issue the VC;

e) It is advisable to load the VC template from the VDR and issue VC based on the VC template;

f) After issuing the VC, the issuer shall send the VC from the issuer to the holder via a secure channel;

g) It is advisable to use privacy-preserving technologies such as zero-knowledge proofs and Merkle trees to generate VCs.

7.2.2 VC Verification The VC validation process involves the validator verifying the validity of the VC, and it must meet the following requirements.

a) The validity of the issuer's digital signature should be verified;

b) It should be verified whether the VC has been withdrawn;

c) The validity period of the VC should be verified;

d) It should have the ability to verify VCs generated using privacy-preserving technologies such as zero-knowledge proofs.

7.2.3 VC Update The VC update process requires the issuer to update VC properties in accordance with the following requirements.

7.3 Verifiable Data Registration Subsystem

7.3.1 DID Data Registration The DID data registration process records and manages DID identifiers and DID documents in the VDR, meeting the following requirements.

a) It should have the ability to register DID identifiers and DID documents;

b) It should have the ability to retrieve DID documents from the VDR based on the DID identifier;

c) The DID document should be updated in the VDR;

d) It is advisable to store DID usage records in VDR.

7.3.2 VC Data Registration The VC data registration process records and manages VC auxiliary verification information in the VDR, and should meet the following requirements.

a) Has the ability to register VC templates;

b) Possesses the ability to register auxiliary verification information such as the VC revocation list and the issuer's public key;

c) It has the ability to register VC hash values, providing integrity protection for VCs;

d) Possesses the ability to query VC status;

e) Record the issuance, verification, update, and revocation of VC in VDR for evidence storage.

7.3.3 VP Data Registration The VP data registration process records and manages VP auxiliary verification information in the VDR, and should meet the following requirements.

a) Possesses the ability to register auxiliary verification information such as VP hash values;

b) Has the ability to register VP templates;

8.1 Storage Infrastructure

8.1.1 Distributed Ledger Distributed ledgers provide decentralized, immutable recording capabilities, meeting the following requirements.

a) The basic functions of a distributed ledger should comply with the requirements of GB/T 42752;

b) On-chain data should be updated by deploying smart contracts;

c) Encryption algorithms should be used to protect the confidentiality and integrity of data, and verification methods should be provided;

d) It should have cross-chain functionality to enable cross-chain interoperability of relevant identity data;

e) It is advisable to provide API or SDK access methods.

8.1.2 Trusted Database Trusted databases used in distributed identity systems provide confidentiality, integrity, and availability guarantees for data storage, conforming to the following. Require.

a) Data should be stored locally in encrypted form;

b) An access control mechanism should be in place, using role and permission management to ensure that all reading and modification operations on identity data are authorized and controlled. Authorization;

c) User privacy should be protected through data anonymization and pseudo-anonymization techniques;

d) Fine-grained access control and dynamic authorization mechanisms should be provided;

e) It should have disaster recovery and recovery mechanisms to recover data after data loss or corruption;

f) Security auditing functionality should be provided for the database. Audit logs should include audit information such as access time, user ID, and operation type. It facilitates tracing and analysis in the event of a security incident;

g) The integrity of the audit log should be protected to prevent tampering with the audit records;

9.1.1 DID Security and Privacy Protection

9.1.1.1 Security Protection of DID Provide security measures for DID identifiers and DID documents, meeting the following requirements.

a) Password authentication, biometric identification, or multi-factor authentication should be performed when accessing a user agent or before performing cryptographic operations such as digital signatures. Identification;

b) It is advisable to generate the public/private key pair for creating the DID in the user's local secure environment;

c) The DID private key should be securely stored in the user's local secure environment;

d) Verification methods based on digital signatures and verifiable timestamps should be used in DID documents;

e) DID key escrow services can be provided by a trusted third-party organization that meets national and industry regulatory requirements.

9.1.1.2 Privacy Protection of DID Provide privacy protection measures for DID identifiers and DID documents, meeting the following requirements.

a) The processing of personal information in DID identifiers and DID documents shall comply with the relevant requirements of GB/T 35273;

b) When creating a DID identifier based on the entity's real identity information, de-identification and de-sensitization processing should be performed;

c) Measures should be taken to ensure that the DID document does not contain personal information or encrypted values of personal information;

d) Measures should be taken to ensure that different anonymous DIDs for the same entity correspond to different public keys;

e) An anonymous DID mechanism should be provided, allowing the same entity to derive multiple anonymous DIDs based on different application scenarios. These DIDs cannot be used without the user's consent. Should be associated;

f) Policies should be set up to prevent the leakage of personal privacy through server endpoints;

g) It is advisable to avoid adding additional attributes to the DID document that may explicitly or implicitly infer the DID body type information.

9.1.2 Credential Security and Privacy Protection

9.1.2.1 Security Protection of Credentials Provide security protection measures for VC and VP, meeting the following requirements.

a) When issuing a VC, the issuer should digitally sign it to enable verification of the VC's authenticity and non-repudiation;

b) When the holder generates a VP, they should digitally sign it to enable verification of the VP's authenticity and non-repudiation;

c) Confidentiality and integrity protection should be ensured when VCs are transferred between issuers and holders;

d) Confidentiality and integrity protection should be ensured when VPs are transferred between holders and validators;

e) When a VC contains dynamic information, the expiration time should be set correctly;

f) When accessing a user agent or performing cryptographic operations such as digital signatures, password authentication, biometric identification, or multi-factor authentication should be performed. Identification;

g) VC should be securely stored in the user's local secure environment;

h) It is advisable to generate the VP in a local secure environment through a user agent.

9.1.2.2 Privacy Protection of Credentials Provide privacy protection measures for VCs and VPs, meeting the following requirements.

a) The classification and grading of personal identification data should comply with the relevant requirements of GB/T 43697;

b) Where personal information processing is involved in VC or VP, it shall comply with the relevant requirements of GB/T 35273;

c) When a verifier requests personally identifiable information, the request should be made through a user agent, and the information can only be shared after authorization from the holder.

d) A selective disclosure mechanism for personal information should be provided;