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

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.

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.

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.

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.

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.

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.

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.

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

The VC encryption escrow service shall be provisioned.

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.

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.

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.

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

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.

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.

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

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

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

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:

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

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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