IIFAA Decentralized Trusted Authentication Technical Specification - Part 1: General Requirements

This document specifies the IIFAA decentralized trusted authentication reference model, technical architecture and functionalities, service procedures, security requirements, and personal information protection requirements.

It is applicable to the development, design, deployment, application, and testing certification and other related activities of IIFAA decentralized trusted authentication.

This is an joint publication from IFFAA and W3C Chinese DID & VC Community.

Introduction

This document specifies the IIFAA decentralized trusted authentication reference model, technical architecture and functionalities, service procedures, security requirements, and personal information protection requirements.

It is applicable to the development, design, deployment, application, and testing certification and other related activities of IIFAA decentralized trusted authentication.

General Framework

Reference Model

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).

Figure 1 Reference Model

The IIFAA decentralized trusted authentication service specifically includes:

  1. 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;
  2. Upon user request, issuers grant VCs to the user side for encrypted storage;
  3. 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;
  4. 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.

Issuer

The requirements for issuers are as follows:

  1. Reliable identity verification capabilities to authenticate the real identities of users or organizations;
  2. Secure data storage and transmission capabilities to safeguard DID information from leakage or alteration;
  3. User-friendly design to offer an intuitive user interface and a seamless interactive experience;
  4. Sustainable service provision to ensure stability and reliability of services, with continual enhancements to improve user experience;
  5. Legal identity credential issuers should be legally authorized organizations;
  6. Digital asset credential issuers should have the ability to verify legal identity or service credentials before issuing digital asset credentials;
  7. 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.

Service Provider (SP)

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:

  1. Decentralized authentication capability to verify diverse VCs, including legal identity credentials, service credentials, and digital asset credentials;
  2. Capability to verify the identity of the VC issuing organizations;
  3. Capability to provide various business services to users, including but not limited to online and offline services;
  4. Security measures to ensure the safety and privacy of user VC data and prevent data leakage and misuse;
  5. 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.

Identity Provider (IDP)

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:

  1. Implementation of encryption technology to safeguard user data and ensure the security of user identity data against leakage or alteration;
  2. Adherence to relevant standards to promote data interoperability;
  3. Transparent service provision to enable users to comprehensively understand the registration and utilization of DID;
  4. Provision of various identity registration methods, including web pages, mobile applications, and APIs to facilitate user registration and the use of DID;
  5. Provision of a DID security mechanism to leverage multi-party computation and ZK-SNARK to enable recovery of lost identity information;
  6. Monitoring and operational capabilities to oversee and operate DID registration services, promptly locate and address issues to maintain system stability and reliability.

DID Holder

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:

  1. Multiple authentication methods, including but not limited to passwords, biometric technologies, etc., to ensure the user's identity is not misused;
  2. Capability to authorize other organizations or individuals to verify their identity, serving as proof of holding the current DID;
  3. Capability to issue verifiable presentations, allowing the holder to authorize and present VCs under the current DID to other organizations or individuals;
  4. Security safeguard and privacy protection abilities to prevent identity information from being leaked or misused;
  5. Scalability to support large-scale identity authentication and authorization demands;
  6. Standardization capability to enable interoperability and integration with other identity authentication and authorization systems.

Technical Architecture and Functions

Technical Architecture

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.

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.

Figure 2 Technical Architecture

User Terminal

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.

Terminal Security Foundation Layer

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.

Terminal Core Protocol Layer

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.

Terminal Core Service Layer

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.

Decentralized Identity Management

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:

  1. 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;
  2. 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;
  3. 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;"
  4. Provision of cryptographic security mechanisms to protect users' identity information from unauthorized access and cyber attacks;
  5. Recommended ease of use and configuration to offer a user-friendly interface and experience for the registration and management of decentralized identities.
Decentralized Identity Verification

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:

  1. 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;
  2. Operations based on trusted environments such as TEE or SE to ensure the trustworthiness of the identity verification computational process;
  3. Blockchain publication of non-sensitive verification key elements and methods for autonomous identity verification by any organization needing to verify user DID;
  4. Recommended ease of use and configuration to offer a user-friendly interface and experience for the utilization of decentralized identity verification features.
VC Management

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:

  1. 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;
  2. Capability for VC summary sets query to access all VC summaries under a specified DID, including information like the VC's issuers, types, etc.;
  3. Capability for detailed VC information query, including complete information of a specific VC ID;
  4. Capability to delete VCs to remove VC data corresponding to a specified VC ID.
VC Presentation

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:

  1. Adherence to the principle of minimal privacy disclosure when presenting relevant fields to safeguard user identity information from leakage or misuse;
  2. Assembling VP according to standard protocols and signing with the DID private key to ensure the authenticity and completeness of VCs;
  3. Completing VC processing and signing within a trusted environment like TEE or SE to guarantee the security and privacy of user data.

Issuer

VC Issuance

The requirements for VC issuance are as follows:

  1. 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;
  2. 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;
  3. 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.;
  4. Credential encryption issuance capability, with issuers encrypting VCs before delivering them to users;
  5. Issuers should establish a mapping relationship between the VC ID, subject ID, and existing data of the issuer.

VC Revocation

The requirements for VC revocation functionality are as follows:

  1. 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;
  2. 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.

VC Traceability Configuration

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.

Decentralized Trusted Authentication Infrastructure

Identity Service

The identity service requirements are as follows:

  1. 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;
  2. 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.

Private Key Escrow

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).

VC Escrow

The VC encryption escrow service shall be provisioned.

VC Traceability

The VC traceability requirements are as follows:

  1. 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.
  2. Capability to query VC traceability information, and provisioning of an interface for issuers to query the above VC traceability information.

VC Escrow

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.

SPs

VP Verification

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.

During statement verification, SPs shall have the capability to verify the identities of organizations that issue legal identity credentials.

Organization Verification

SPs shall have the capability to verify the identities of VC issuers.

IIFAA Ecologic Operation Platform

VC Template Management

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.

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.

For this feature, the IIFAA platform:

  1. Should have the capability to input attributes, and specify the available attributes of VC templates and their definition;
  2. Should have the capability to edit attributes by modifying their definitions;
  3. 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;
  4. Shall have the capability to edit VC templates by modifying information about the template except for the template name;
  5. Shall have the capability to query VC template list, that is, to query all configured VC templates;
  6. Shall have the capability to apply for VC templates as an issuer. Issuers can apply for existing VC templates;
  7. 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;
  8. 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.

Scenario Management

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.

For this feature, the IIFAA platform:

  1. 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.
  2. Should have the capability to query VC policies, that is, to query all created VC policies.
  3. 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.
  4. 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.
  5. 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.
  6. Shall have the capability to query service scenario list, that is, to query all approved scenarios.

Service Scenario Display

A list page should be configured to display all online service scenarios so that users can enjoy desired services via the corresponding ingresses.

VC List Display

A list page should be configured to display all online VCs so that users can apply for desired VCs for use.

Unified Service and Control Platform

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.

Organization Management

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.

For this module, the unified service and control platform shall have the following capabilities:

  1. Capability to register organization information and store organization-related information securely;
  2. Capability to review organization information for authentication of service organizations or legal identity credential issuers;
  3. Capability to edit organization information;
  4. Capability to query organization, that is, to query organizations from the organization information list.

Trust Anchoring

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.

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.

Traceability and Audit

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:

  1. Capability to record the usage history of all VCs for traceability and audit.
  2. 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.
  3. Traceability and audit capability based on VC issuers, that is, to measure the presentations of VCs issued by an issuer.
  4. Traceability and audit capability based on SPs, that is, to measure the presentations of VCs used by an SP.

Service Procedure

Organization Registration Procedure

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.

Issuer Registration

Figure 3 Issuer Registration Procedure

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:

  1. An issuer generates private keys and stores them securely (1).
  2. The issuer submits information such as public keys, website domain name, and website name to the unified service and control platform (2).
  3. 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).
  4. 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).

SP Registration

Figure 4 SP Registration Procedure

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:

  1. An SP generates private keys and stores them securely (1).
  2. The SP submits information such as name, logo, and public keys to the unified service and control platform (2).
  3. 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).
  4. The SP creates an application scenario on the platform and specifies the dependent data source (5).
  5. If the issuer specifies that approval is required for its VCs, the SP initiates an application (6).
  6. After the application is approved by the issuer, the platform generates the scenario configuration for future use by the SP (7).

VC Issuance Procedure

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.

Figure 6 VP Procedure

The VC issuance procedure is as follows:

  1. A user initiates a request for creating a DID on the app (1).
  2. The trusted key components of the terminal generate public and private keys (2).
  3. The terminal uploads public keys to the IDP and initiates a request for creating a DID (3).
  4. The IDP generates a DID document based on the public keys and uploads the public keys and DID document to the blockchain (4).
  5. The terminal receives the DID document returned by the IDP and calls the trusted storage components for data storage (5).
  6. The terminal applies for a VC from the issuer (6).
  7. Depending on the type of the applied VC, the issuer authenticates the user's identity using an appropriate method (7).
  8. 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).

In the above steps, if the terminal already has a DID, ignore steps a) to e), and go to step f) directly.

VP Procedure

Figure 5 VC Issuance Procedure

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:

  1. Before using the services provided by an SP, a user needs to submit his/her data and information for authentication (1).
  2. The terminal queries the configurations of the SP, and obtains the SP's requirements for user data in this scenario (2).
  3. The user authorizes the application vendor and VC corresponding to the presentation.
  4. 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).
  5. The terminal encrypts the VP with the SP's public key and then transmits it to the SP (5).
  6. The SP decrypts and verifies the VP data, and authenticates the user information based on the original data (6).
  7. The SP authenticates the user, and then provides services for the user (7).

Security Requirements

Password Locks Security

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:

  1. Symmetric encryption algorithms, including SM4, AES, etc.
  2. Asymmetric encryption algorithms, including SM2, RSA (2048 or above), DSA, ECC, etc.
  3. Abstract algorithm, including SM3, SHA-2, SHA-3, etc.

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.

Data Security

It shall be as per GB/T 41479, in addition to the following requirements:

  1. Encryption communication: Data shall be encrypted to avoid being eavesdropped during transmission.
  2. Two-way authentication: Both endpoints of the data transmission shall go through authentication to avoid illegal access or data breach.
  3. Security protocol: TLS, TLCP, or other security protocols shall be used to ensure security during data transmission.
  4. Anti-replay: Measures against replay attacks, such as timestamps and random numbers, shall be taken to ensure reliability during data transmission.
  5. Data integrity: Integrity shall be ensured during data transmission to protect data from being tampered with.
  6. Secure storage: Data shall be stored securely after transmission.

Server Security

The requirements are as follows:

  1. OS security: For device security, the security patches and software versions shall be updated in time for the operating systems of server devices.
  2. Application security: For application security, the applications installed on server devices shall be kept up-to-date, and unaudited applications shall be avoided.
  3. 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.
  4. 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.

Terminal Security

The requirements are as follows:

  1. Secure boot: The OS and applications on terminals shall be protected from being tampered with or replaced by malware during startup.
  2. Secure storage: Data stored on terminals shall be encrypted and protected from being accessed or used by unauthorized persons or malware.
  3. Secure operating environment (such as TEE): The applications on terminals shall be protected from being attacked by malware or other threats during operation.
  4. Secure communication: Terminals shall be able to interact with each other securely so that data will not be tampered with or eavesdropped during transmission.
  5. 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.
  6. Trusted authentication: The user authentication on terminals shall be trusted so that only authorized users can access devices and data.
  7. The biometrics recognition on mobile devices shall be as per GB/T 37036 (All parts).

Server Security Requirements

The requirements are as follows:

  1. The server shall authenticate all requests to ensure that these requests come from legal users or clients.
  2. The server shall implement access control so that only authorized users or clients can access specified resources.
  3. The server shall handle faults and exceptions in time to avoid server attacks and service interruptions.
  4. The server shall record all access logs and exception logs for tracking and analysis.
  5. The server shall establish an emergency response mechanism for the timely handling of security events and threats.

Personal Information Protection Requirements

General Requirements

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.

Biometric Data Masking Requirements

Raw biometric data should be anonymized into the irreversible ZK-SNARK to ensure the security and privacy of users' biometric data.

Disclosure of Personal Information

The disclosure involves two methods: selective disclosure and minimum disclosure, with the requirements as follows:

  1. For the selective disclosure:
    1. SPs shall specify the user information required for services under the minimum collection principle.
    2. Terminals shall list the attributes that need and do not need to be presented by users before the VC presentation.
    3. For non-required attributes, users can set whether to authorize disclosure at their discretion.
  2. For the minimum disclosure:
    1. When building VCs, issuers shall specify the required attributes under the minimum disclosure principle.
    2. SPs shall specify the attributes required for service operation under the minimum disclosure principle, and define the scope.
    3. Terminals should construct presentation attributes using the ZK-SNARK before the VC presentation.
    4. When verifying VPs, SPs shall determine whether the corresponding attributes are required using the ZK-SNARK.

Test Requirements

Protocol Standard Testing

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.

DID Document Protocol Testing

The test method and expected result of the DID document protocol testing are as follows:

  1. Test method: When the IDP generates a DID document, check whether the DID document complies with the IIFAA decentralized trusted authentication standards.
  2. Expected result: When the IDP generates a DID document, upon check, the DID document complies with the IIFAA decentralized trusted authentication standards.
  3. Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is unacceptable.

VC Protocol Testing

The test method and expected result of the VC protocol testing are as follows:

  1. Test method: When the issuer generates a VC, check whether the VC complies with the IIFAA decentralized trusted authentication standards.
  2. Expected result: When the issuer generates a VC, upon check, the VC complies with the IIFAA decentralized trusted authentication standards.
  3. Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is unacceptable.

VP Protocol Testing

The test method and expected result of the VP protocol testing are as follows:

  1. Test method: When DID holder presents a VP, check whether the VP complies with the IIFAA decentralized trusted authentication standards.
  2. Expected result: When DID holder presents a VP, upon check, the VP complies with the IIFAA decentralized trusted authentication standards.
  3. Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is unacceptable.

Operating Environment Security Testing

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.

Terminal Environment Security Testing

The test methods and expected results of the terminal environment security testing are as follows:

  1. Test methods:
    1. Check whether DID keys are stored in a secure environment as stated in the DID document.
    2. Check whether VCs are encrypted and stored.
  2. Expected results:
    1. 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.
    2. If DID document states TEE storage, DID keys are generated and used in the TEE of the terminal.
    3. VCs are encrypted and stored.
  3. Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is unacceptable.

Key Algorithm Security Testing

The test methods and expected results of the key algorithm security testing are as follows:

  1. Test methods:
    1. Check whether key algorithms such as SM2/ECC/RSA3072, SM4/AES, and SM3/SHA2 are supported.
    2. Check whether keys are stored and used in a secure environment as stated in the DID document.
  2. Expected results:
    1. If DID document states SE storage, related keys and algorithms run in the security zone of the SE or SIM card.
    2. If DID document states TEE storage, related keys and algorithms run in the TEE of the terminal.
  3. Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is unacceptable.

Data Protocol Security Testing

The test methods and expected results of the data protocol security testing are as follows:

  1. Test methods:
    1. In the DID registration phase, verify whether the public key data and security environment statement generated on the terminal are signed with the private keys of the corresponding security zone.
    2. In the VC issuance phase, check whether VCs are issued after being encrypted with the private keys of the specified user DID.
    3. In the VC import phase, check whether VCs are encrypted and stored in a security zone as stated in the DID document.
    4. In the VP issuance phase, check whether the VP data is encrypted with the DID keys of the designated service organization.
  2. Expected results:
    1. In the DID registration phase, the public key data and security environment statement generated on the terminal are signed with the private keys of the corresponding security zone.
    2. In the VC issuance phase, VCs are issued after being encrypted with the private keys of the specified user DID.
    3. In the VC import phase, VCs are encrypted and stored in a security zone as stated in the DID document.
    4. In the VP issuance phase, the VP data is encrypted with the DID keys of the designated service organization.
  3. Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is unacceptable.

Basic Function Testing

Decentralized trusted authentication is to build a decentralized identity authentication infrastructure with minimum trust, high privacy protection, and efficient operation. Its basic functions include identity registration and management, VC issuance and storage, and VP presentation, based on which, the test requirements are as follows sections.

Registration and Management of Decentralized Identities

The test methods and result judgment of the decentralized identity management procedure are as follows:

  1. Test methods:
    1. During identity registration, check whether the keys on the terminal are generated properly.
    2. During identity registration, check whether the private keys are stored according to security requirements.
    3. During identity registration, check whether the public keys and corresponding decentralized identity documents are stored on the blockchain.
    4. During use, check whether identity authentication methods are available to verify the user's identity.
    5. During identity deregistration, check whether the key information and the corresponding data on the blockchain are set to "disabled" or "deleted".
  2. Expected results:
    1. During identity registration, the keys on the terminal are generated properly.
    2. During identity registration, the private keys on the terminal are stored securely according to security requirements.
    3. During identity registration, the public keys and corresponding decentralized identity documents are stored on the blockchain properly.
    4. During use, identity authentication methods are available to verify the user's identity.
    5. During identity deregistration, the key information and the corresponding data on the blockchain are set to disabled or deleted.
  3. Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is unacceptable.

VC Issuance and Storage

The test methods and result judgment of the VC issuance and storage procedure are as follows:

  1. Test methods:
    1. Check whether the VC issuance interface has the identity authentication capability.
    2. Simulate the issuance process and test the issuer's key management and signature mechanisms to ensure that VCs can be correctly signed, issued, encrypted, and then transmitted to the holders.
    3. Check whether VCs can be decrypted properly with the user's private keys on the terminal and whether the VC data integrity is compliant with the VC template requirements.
    4. Check whether VCs can be stored securely and persistently on the terminal.
    5. Check whether VC summaries and details can be queried properly on the terminal.
    6. Check whether VCs can be normally canceled by the issuer.
    1. As required by the issuer, the VC insurance interface has the identity authentication capability.
    2. The data of the issued VCs are encrypted with the user's public keys and can be decrypted properly with the user's private keys.
    3. VCs are securely and persistently stored in the corresponding security zone on the terminal.
    4. VC summaries and details can be queried properly on the terminal.
    5. VCs can be normally canceled by the issuer.
  3. Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is unacceptable.

VP Presentation

The test methods and result judgment of the VP presentation procedure are as follows:

  1. Test methods:
    1. Check whether VPs present relevant fields per the principle of minimal privacy disclosure to prevent any breach or abuse of user information.
    2. Check whether VPs are assembled according to the standard protocols, signed with the user's private keys, and encrypted with service providers' public keys.
    3. Check whether service providers can obtain the data presented by VCs through VPs.
  2. Expected results:
    1. VPs present relevant fields per the principle of minimal privacy disclosure to prevent any breach or abuse of user information.
    2. VPs are assembled according to the standard protocols, signed with the user's private keys, and encrypted with service providers' public keys.
    3. Service providers can obtain the data presented by VCs through VPs.
  3. Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is unacceptable.

Performance and Stability Testing

To ensure the user experience for decentralized trusted authentication and the reliability and stability of the system, a performance test needs to be carried out on terminal keys, and performance and stability tests be conducted on the service system.

Key Performance Testing

The test methods and expected results of the key performance security test are as follows:

  1. Test methods:
    1. Trigger the terminal to generate DID keys for 100 cycles, and calculate the average time spent.
    2. Sign data with the DID keys for 100 cycles, and calculate the average time spent.
    3. Verify digital signatures with the DID keys for 100 cycles, and calculate the average time spent.
    4. Encrypt data with the DID keys for 100 cycles, and calculate the average time spent.
    5. Decrypt data with the DID keys for 100 cycles, and calculate the average time spent.
  2. Expected results:
    1. When the terminal is triggered to generate DID keys for 100 cycles, all the cycles are executed successfully and the average time spent is less than 200 ms.
    2. When DID keys are used to sign data for 100 cycles, all the cycles are executed successfully and the average time spent is less than 100 ms.
    3. When DID keys are used to verify digital signatures for 100 cycles, all the cycles are executed successfully and the average time spent is less than 100 ms.
    4. When DID keys are used to encrypt data for 100 cycles, all the cycles are executed successfully and the average time spent is less than 200 ms.
    5. When DID keys are used to decrypt data for 100 cycles, all the cycles are executed successfully and the average time spent is less than 200 ms.
  3. Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is unacceptable.

Performance and Stability Testing of the Service System

The test methods and expected results of the performance and stability tests of the service system are as follows:

  1. Test methods:
    1. Carry out stress test and stability test on the DID identities created by the IDP, and calculate the QPS and system stability.
    2. Carry out stress test and stability test on the DID identities queried by the IDP, and calculate the QPS and system stability.
    3. Carry out stress test and stability test on the VCs generated by the issuer, and calculate the QPS and system stability.
    4. Carry out stress test and stability test on the VPs presented by service providers, and calculate the QPS and system stability.
    1. After the stress test and stability test are carried out on the DID identities created by the IDP, the results show that the QPS is greater than 500 and the system stability is up to 99.9%.
    2. After the stress test and stability test are carried out on the DID identities queried by the IDP, the results show that the QPS is greater than 500 and the system stability is up to 99.9%.
    3. After the stress test and stability test are carried out on the VCs generated by the issuer, the results show that the QPS is greater than 500 and the system stability is up to 99.9%.
    4. After the stress test and stability test are carried out on the VPs presented by service providers, the results show that the QPS is greater than 500 and the system stability is up to 99.9%.
  3. Result judgment: If the actual test result is the same as expected, the test is acceptable; otherwise, it is unacceptable.

Terms

any terms below overlay with W3C terms?

Reference

Fixed layout later.

GB/T 35273 Information security technology – Personal information security specification GB/T 37036 (All parts) Information technology – Biometrics used with mobile devices GB/T 40660 Information security technology – General requirements for biometric information protection GB/T 41479 Information security technology – Network data processing security requirements GB/T 41819 Information security technology – Security requirements of face recognition data IIFAA Local Password-Free Technology Specification 2.0