IIFAA Decentralized Trusted Authentication Technical Specification — Part 2: Identity Protocol and Interaction Framework

This document establishes the identity protocol and interaction flow for IIFAA decentralized authentication.

This document applies to the IIFAA decentralized authentication R&D design, deployment application, and test and authentication activities.

The following documents are referred to in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition (including any amendments) applies.

[T/IIFAA 4001-2024]: IIFAA Decentralized Authentication Technical Specification — Part 1: Overall Architecture

For the purposes of this document, the following terms and definitions apply, as well as those defined in [T/IIFAA 4001-2024].

Decentralized Identifier (DID)

A new type of identifier that supports verifiable, decentralized digital identity.

DID Document

The identity document information of the user's DID on the blockchain, which is stored in a decentralized manner to ensure that it will not be tampered with. This document describes the encryption public key, verification method, decentralized identity protocol used, and service endpoint for the specific DID.

Verifiable Credentials (VC)

VC data issued by the issuer for a user's DID is securely stored on the user side and presented to the service provider in a verifiable way after being authorized (signed) by the user.

Verifiable Presentation (VP)

It refers to the data that allows the VC holder (i.e., user) to identify himself/herself to the verifier.

Decentralized Identity Asset Wallet

A decentralized identity asset management tool based on mobile applications provided by users. Decentralized identity asset wallets usually use the security chip on the user device side to store and encrypt the user's identity private key and related asset credential data to ensure that any key identity data will not be leaked. At the same time, they also use the biometric technology of mobile devices, such as fingerprint recognition or facial recognition, to provide a more convenient and secure decentralized identity authorization method. In this document, it is also referred to as the wallet.

Identity

A set of attributes associated with an entity.

Note

Note 1: An entity can have multiple identities.

Note 2: Several entities can have the same identity.

[Source: GB/T 25069-2022, 3.512]

The following abbreviations apply to this document.

DID: Decentralized Identifier
OEM: Original Equipment Manufacturer
REE: Rich Execution Environment
SE: Secure Element
TEE: Trusted Execution Environment
VC: Verifiable Credential
VP: Verifiable Presentation

The identity protocol and device function interaction framework is shown in Figure 1.

Placeholder for Identity Protocol and Device Function Interaction Framework diagram — Figure 1 : Identity Protocol and Device Function Interaction Framework

The specific composition of each part is as follows:

Identity protocol: It describes the identity document (DID Document), verifiable credential, and verifiable presentation related to IIFAA decentralized trusted authentication, involving the roles of participants such as identity service providers, credential issuers, and application manufacturers.
Device function interaction: It describes the relevant content of IIFAA decentralized trusted authentication in the application part, mainly including such function services as identity management and authorization, and credential management and presentation, involving the roles of participants such as application manufacturers and identity service providers (providing decentralized identity asset wallet services).

The document describes the encryption materials, verification methods, decentralized identity protocols used, and service endpoints for a specific DID. Some examples of decentralized identity protocol data are shown in Appendix A.

Table 1: Attributes of DID Documents
Attribute Name	Description	Optional/Required	Example
id	DID ID	Required	`did:iifaa:2UdYuZagBsinmdRogHNJwPc8QXA4PyXdYXcY1aDaB8wR`
created	Creation time	Required	`2023-10-05T14:48:00.000Z`
update	Update time	Required	`2023-10-05T14:48:00.000Z`
status	Overall status of DID	Required	`active`
Verification Methods	See 6.4	Required	Refer to Appendix A for data sample
authentication	See 6.4	Optional	Refer to Appendix A for data sample
proof	See 6.5	Required	Refer to Appendix A for data sample

Verifiable Credentials are VC data issued by the issuer for a user's DID identity. It is securely stored on the user side and presented to the service provider in a verifiable way after being authorized (signed) by the user.

Table 2: Attributes of VCs
Attribute Name	Description	Optional/Required	Example
id	Unique identifier of VC	Required	`did:credential:disable:BovPfgFcvy4eRuDcf1w9Wa7zSgbnsd1FuFeh6SxQhJVm#1682320755035`
type	VC type set, with the first type as the main type of the current VC, and the rest as subtypes, which can be customized by the application	Required	`["Disable Credential Type", "Selective Disclosure Credential Type"]`
issuer	DID of the issuer. Business service providers can query the issuer's public key on the blockchain through the issuer's DID to verify whether the VC is from a trusted source	Required	`did:myidentity:E2h3D7FgsoNiFDzE6gSv4F2MqjK6mSmv9WZqLB7jBYq1`
Issuance Date	Issuance date	Required	`2023-04-24 15:19:15`
expiration Date	Valid expiration date	Required	`2033-04-24 15:19:15`
credentialSubject.claims.subject	VC attribute data stored in the form of KV	Required	`{"name": "Zhang San", "disableIdNum": "330133199903033333", "endValidDate": "2032-04-14", "level": "1", "type": "4"}`
credentialSubject.claims.seed	Selectively disclosed seed information	Required	`eaa02887e4834024b954fb7b0c063ae7`
Credential Status	VC status, provided to the business service provider for verification to determine whether the VC has been revoked	Required	`{"id": "https://szcldemo.zjdpf.org.cn/idp/credentials/status/0#26", "type": "StatusList2021", "statusPurpose": "revocation", "statusListIndex": "26", "statusListCredential": "https://szcldemo.zjdpf.org.cn/idp/credentials/status/0"}`
proof	See 6.5	Required	See Appendix A

Verifiable Presentation (VP) refers to the data that allows the VC holder (i.e., user) to identify himself/herself to the verifier.

Table 3: Attributes of VP
Attribute Name	Description	Optional/Required	Example
id	Unique identifier of VC under the same issuer	Required	`did:credential:disable:BovPfgFcvy4eRuDcf1w9Wa7zSgbnsd1FuFeh6SxQhJVm#1682320755035`
type	List of VC types, with the first type as the main type of the current VC, and the rest as subtypes, which can be customized by the application	Required	`["VerifiablePresentation", "SelectiveDisclosurePresentation"]`
created	Creation time	Required	`2023-10-05T14:48:00.000Z`
Verifiable Credential	VCs have a set attribute that contains a list of VCs provided by the holder. Refer to VCs in 6.2	Required	Refer to data samples of VCs in 6.2
proof	Refer to the proof in 6.5	Required	Refer to data samples of the proof in 6.5

Example 1

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": [
    "VerifiablePresentation"
  ],
  "created": "Wed Apr 26 14:50:56 GMT+08:00 2023",
  "domain": "did:iifaa:123456",
  "verifiableCredential": [
    { /* vc set */ }
  ],
  "proof": {
    "type": "SM2Signature2024",
    "created": "2024-07-11T13:50:18+08:00",
    "creator": "did:example:123OUgINRNdf0kIeo",
    "verificationMethod": "did:cndid:cndid#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "MEYCIQCpy0HOUgINRNdf0kIeoStR94v7W3OcfoBpWel6TAckqwIhAPdTq7u/ZpTOOp1VLtLCOuFpOVL7AYpys/OHnL8Uqwr5"
  }
}

The verification method associated with DID identity is used to verify the VP signature and complete DID identity authentication.

Table 4: Attributes of Verification Method
Attribute Name	Description	Optional/Required	Example
id	ID of the current verification method	Required	`did:example:123456#sm2-1`
type	Type of the current verification method, which determines how to verify statements or operations related to the identity, such as digital signatures and encryption.	Required	`SM2VerificationKey2024`
Public Key	Verification value corresponding to the current verification method, which has two specific forms: publicKeyJwk and publicKeyHex	Required	`MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnKcEGSwB6OE0MzhDRD3CRMqUJ9DaLg4NfA8i8uz7LOykF171K_2EqRpGNUik6HeKdnbZQ7O5xv8rGk77OD5puZP9IOqWNvu`
status	Status of the current verification method, e.g., whether it has been abandoned	Required	`active`
controller	DID account ID associated with the current verification method	Required	`did:example:123456789abcdefghi`
securityLevel	Security level of the current verification method, refer to 6.6 "Security Level"	Required	`256`

Example 2

{
  "type": "SM2VerificationKey2024",
  "id": "did:example:123456#sm2-1",
  "controller": "did:example:123456",
  "status": "active",
  "securityLevel": "256",
  "publicKeyHex": "04[{x-coordinate in hex}][{y-coordinate in hex}]"
}

Example 3

{
  "id": "did:example:123456#ecdsa-p256-1",
  "type": "JsonWebKey2020",
  "controller": "did:example:123456",
  "status": "active",
  "securityLevel": "256",
  "publicKeyJwk": {
    "kty": "EC",
    "crv": "P-256",
    "x": "...",
    "y": "..."
  }
}

RsaVerificationKey2018:

Example 4

{
  "id": "did:example:123456789abcdefghi#keys-1",
  "type": "RsaVerificationKey2018",
  "controller": "did:example:123456789abcdefghi",
  "status": "active",
  "securityLevel": "256",
  "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}

RsaVerificationKey2020:

Example 5

{
  "id": "did:example:123456789abcdefghi#key-1",
  "type": "RsaVerificationKey2020",
  "controller": "did:example:123456789abcdefghi",
  "status": "active",
  "securityLevel": "256",
  "publicKeyJwk": {
    "kty": "RSA",
    "e": "AQAB",
    "n": "0S25ZgyZ..."
  }
}

Table 5: Comparison of Different RSAs
Features	RsaVerificationKey2018	RsaVerificationKey2020
Public Key Format	The PEM format or JWK format is allowed (but PEM is more commonly used)	The JWK format is required (standardized, machine parsable)
Specification Version	Defined in earlier draft DID specifications (such as the 2018 standard)	Defined in the updated DID Core v1.0 and subsequent versions
Signature Algorithm Support	The algorithm may not be clearly defined (need to be combined with JWS independent statement)	Explicitly support common algorithms (such as RS256 and PS256) to enhance interoperability
Usage Scenarios	Compatibility first, may depend on tools in early versions	New project recommendation, in line with modern safety standards and specifications

Self-certification data of the current VC, through which the business service provider can verify whether the VC has been tampered with and whether it comes from a trusted issuer.

Table 6: Attributes of Proof
Attribute Name	Description	Optional/Required	Example
type	Type of the current verification method, which determines how to verify statements or operations related to the identity, such as digital signatures and encryption.	Required	`SM2VerificationKey2024`
creator	To identify the DID identity of a proof creator	Optional	`did:example:1230UgINRNdf0kIeo`
created	Proof creation time, using ISO 8601 standard time	Required	`2024-07-11T13:50:18+08:00`
Verification Method	Referenced verification method ID, refer to 6.4 "Verification Method"	Required	`did:cndid:cndid#key-1`
proofValue	base64Url encoding of the DER signature value, usually used to store the VC main body signature data, among which the binary encoding of the SM2 signature follows the ASN.1 DER encoding rules	Required	`MEYCIQCpy0HOUgINRNdf0kIeoStR94v7W30cfoBpWel6TAckqwIhAPdTq7u`
challenge	A bidirectional challenge value issued and verified by the SP server during the VP phase for SP generation and verification	Optional	`15ecc79e-1490-4096-9684-46b0e92d4aec`
alg	Signature result base64 URL, suitable for signature algorithms, RS256 (RSA+SHA256), ES256 (P-256 curve + SHA256)	RS256, ES256 required	`RS256`

Example 6

{
  "type": "SM2Signature2024",
  "created": "2024-07-11T13:50:18+08:00",
  "creator": "did:example:123OUgINRNdf0kIeo",
  "verificationMethod": "did:cndid:cndid#key-1",
  "proofPurpose": "assertionMethod",
  "proofValue": "MEYCIQCpy0HOUgINRNdf0kIeoStR94v7W3OcfoBpWel6TAckqwIhAPdTq7u/ZpTOOp1VLtLCOuFpOVL7AYpys/OHnL8Uqwr5",
  "challenge": "15ecc79e-1490-4096-9684-46b0e92d4aec"
}

Example 7

{
  "type": "BasicJsonWebSignature2024",
  "alg": "RS256",
  "created": "2024-07-11T13:50:18+08:00",
  "verificationMethod": "did:cndid:cndid#key-1",
  "proofPurpose": "assertionMethod",
  "proofValue": "MEYCIQCpy0HOUgINRNdf0kIeoStR94v7W3OcfoBpWel6TAckqwIhAPdTq7u/ZpTOOp1VLtLCOuFpOVL7AYpys/OHnL8Uqwr5"
}

The DID identity security level identifier SecurityLevel consists of two bytes of data, where the low-order byte (bits 1~8) identifies the authentication type, and the high-order byte (bits 9~16) identifies the operating environment.

Table 7: Attributes of Security Level
Bit	Meaning Classification	Description of Meaning
1	Authentication method	Whether a local password is set
2		Reserved (used to add low-security level authentication methods)
3		Reserved (used to add low-security level authentication methods)
4		Reserved (used to add low-security level authentication methods)
5		Whether local biometrics are set
6		Reserved (used to add high-security level authentication methods)
7		Reserved (used to add high-security level authentication methods)
8		Reserved (used to add high-security level authentication methods)
9	Operating environment	Private keys are stored and used in REE
10		Reserved (to add the definition of the REE security scheme)
11		Reserved (to add the definition of the REE security scheme)
12		Private keys are stored and used in TEE
13		Private keys are stored and used in SE
14		Reserved
15		Reserved
16		Reserved

Table 8: Data Samples of Security Level
Bit	1	2~4	5	6~8	9	10	11	12	13	14	15~16	Int value
Meaning
Authentication Type					Operating Environment
No authentication method, private key in REE	0	0	0	0	1	0	0	0	0	0	0	256
Local password, private key in REE	1	0	0	0	1	0	0	0	0	0	0	257
No authentication method, private key in SIM	0	0	0	0	0	0	0	0	1	0	0	8192
Local password, private key in SIM	1	0	0	0	0	0	0	0	1	0	0	8193

Get the operating environment:

int secureLevel = 257;
int secureArea = secureLevel & 0xFF00; //secureArea : 256--REE

Get the authentication type:

int secureLevel = 257;
int authType = secureLevel & 0x00FF; //authType : 1--Local password

This section mainly describes the function interaction flow specifications, such as identity creation and credential management, for device-based decentralized trusted authentication provided to users.

Enter the wallet and determine whether there is DID identity data locally. If not, enter the identity creation process, see Figure 2.

Placeholder for DID Creation Flowchart — Figure 2 : Flowchart of DID Creation

The sequence diagram is shown in Figure 3.

Placeholder for DID Creation Sequence Diagram — Figure 3 : DID Creation Sequence Diagram

Enter the VC management page and determine whether there is corresponding VC data locally. If not, an application button is displayed. If so, a view button is displayed. The flowchart is shown in Figure 4.

Placeholder for VC Application Flowchart — Figure 4 : Flowchart of VC Application

The VC application sequence diagram is shown in Figure 5.

Placeholder for VC Application Sequence Diagram — Figure 5 : VC Application Sequence Diagram

The device only provides the query service for the local VC summary information list, with the specific process as follows:

Enter the page, get VCUIStyle/VC templates and VC data from the IDP server and DIDSDK, respectively. The flowchart is shown in Figure 6.

Placeholder for VC Viewing Flowchart — Figure 6 : Flowchart of VC Viewing

The sequence diagram is shown in Figure 7.

Placeholder for VC Viewing Sequence Diagram — Figure 7 : VC Viewing Sequence Diagram

The SP passes in the required VC content and the specified VM type to pull up the wallet, and the wallet passes the parameters to the SDK. After the SDK completes verification and signing, it returns the result. The flowchart is shown in Figure 8.

Placeholder for VP Issuance Flowchart — Figure 8 : VP Issuance Flowchart

The sequence diagram is shown in Figure 9.

Placeholder for VP Issuance Sequence Diagram — Figure 9 : VP Issuance Sequence Diagram

Example 8

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:cdid:iifaa:123456789abcdefghi",
  "version": "1.0.0",
  "created": "2023-10-05T14:48:00.000Z",
  "update": "2023-10-15T14:48:00.000Z",
  "status": "active",
  "verificationMethods": [
    {
      "type": "SM2VerificationKey2024",
      "id": "did:example:123456#sm2-1",
      "controller": "did:example:123456",
      "status": "active",
      "securityLevel": "256",
      "publicKeyHex": "04a34e...a72c0e"
    }
  ],
  "authentication": [
    {
      "type": "SM2VerificationKey2024",
      "id": "did:example:123456#sm2-1",
      "controller": "did:example:123456",
      "status": "active",
      "securityLevel": "256",
      "publicKeyHex": "04a34e...a72c0e"
    }
  ],
  "proof": {
    "type": "SM2Signature2024",
    "created": "2024-07-11T13:50:18+08:00",
    "creator": "did:example:123OUgINRNdf0kIeo",
    "verificationMethod": "did:cndid:cndid#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "MEYCIQCpy0HOUgINRNdf0kIeoStR94v7W3OcfoBpWel6TAckqwIhAPdTq7u/ZpTOOp1VLtLCOuFpOVL7AYpys/OHnL8Uqwr5"
  }
}

Example 9

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": ["DisableCredentialType", "SelectiveDisclosureCredentialType"],
  "templateId": "200457",
  "version": "1.1.1",
  "id": "did:credential:disable:BovPfgFcvy4eRuDcf1w9Wa7zSgbnsd1FuFeh6SxQhJVm#1682320755035",
  "issuer": "did:myidentity:E2h3D7FgsoNiFDzE6gSv4F2MqjK6mSmv9WZqLB7jBYq1",
  "issuanceDate": "2023-04-24 15:19:15",
  "expirationDate": "2033-04-24 15:19:15",
  "credentialSubject": {
    "id": "7cf59e33f1fad217421aa6d970ec169c49c23362f7b1affdff6bccdfd9e42bcb",
    "did": "did:myidentity:E2h3D7FgsoNiFDzE6gSv4F2MqjK6mSmv9WZqLB7jBYq1",
    "claims": {
      "subject": {
        "name": "Zhang San",
        "disableIdNum": "330133199903033333",
        "endValidDate": "2032-04-14",
        "level": "1",
        "type": "4"
      },
      "seed": "eaa02887e4834024b954fb7b0c063ae7"
    }
  },
  "credentialStatus": {
    "id": "https://szcldemo.zjdpf.org.cn/idp/credentials/status/0#26",
    "type": "StatusList2021",
    "statusPurpose": "revocation",
    "statusListIndex": "26",
    "statusListCredential": "https://szcldemo.zjdpf.org.cn/idp/credentials/status/0"
  },
  "proof": {
    "type": "SM2Signature2024",
    "created": "2024-07-11T13:50:18+08:00",
    "creator": "did:example:1230UgINRNdf0kIeo",
    "verificationMethod": "did:cndid:cndid#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "MEYCIQCpy0H0UgINRNdf0kIeoStR94v7W30cfoBpWel6TAckqwIhAPdTq7u/ZpTOOp1VLtLCOuFpOVL7AYpys/0HnL8Uqwr5"
  }
}

Example 10

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": [
    "VerifiablePresentation"
  ],
  "created": "Wed Apr 26 14:50:56 GMT+08:00 2023",
  "domain": "did:iifaa:123456",
  "verifiableCredential": [
    { /* vc set */ }
  ],
  "proof": {
    "type": "SM2Signature2024",
    "created": "2024-07-11T13:50:18+08:00",
    "creator": "did:example:1230UgINRNdf0kIeo",
    "verificationMethod": "did:cndid:cndid#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "MEYCIQCpy0HOUgINRNdf0kIeoStR94v7W30cfoBpWel6TAckqwIhAPdTq7u/ZpTOOp1VLtLCOuFpOVL7AYpys/OHnL8Uqwr5"
  }
}

IIFAA Decentralized Trusted Authentication Technical Specification — Part 2: Identity Protocol and Interaction Framework

Abstract

Status of This Document

1. Scope

2. Normative References

3. Terms and Definitions

4. Abbreviations

5. Identity Protocol and Device Function Interaction Framework

6. Identity Protocol

6.1 DID Document

6.1.1 Overview

6.1.2 Attributes

6.2 Verifiable Credentials

6.2.1 Overview

6.2.2 Attributes

6.3 Verifiable Presentation

6.3.1 Overview

6.3.2 Attributes

6.3.3 Data Sample

6.4 Verification Methods / Authentication

6.4.1 Overview

6.4.2 Attributes

6.4.3 Data Sample

6.4.3.1 SM2 key

6.4.3.2 ECC NIST curve (p256, etc.)

6.4.3.3 RSA key

6.5 Proof

6.5.1 Overview

6.5.2 Attributes

6.5.3 Data Sample

6.5.3.1 SM2 signature

6.5.3.2 ECC NIST curve (p256, etc.) signature, RSA signature

6.6 Security Level

6.6.1 Overview

6.6.2 Attributes

6.6.3 Data Sample

7. Device Function Interaction

7.1 Overview

7.2 DID creation

7.2.1 Flowchart

7.2.2 Sequence Diagram

7.3 VC Application

7.3.1 Flowchart

7.3.2 Sequence Diagram

7.4 Viewing VC

7.4.1 Flowchart

7.4.2 Sequence Diagram

7.5 Issuing VP

7.5.1 Flowchart

7.5.2 Sequence Diagram

A. Data Sample of Identity Protocol

A.1 Data Sample of Decentralized Identity Protocol

A.2 Data Example of VCs

A.3 Data Samples of VPs