Multi-party authentication method, system and electronic device based on distributed digital identity

Abstract

The application discloses a multi-party authentication method and system based on a distributed digital identity and an electronic device, and belongs to the technical field of computers. The application independently deploys an identity authentication function as a decoupled first authentication node, and separates the first authentication node from a control plane and a data plane, so that the identity authentication is no longer dependent on a centralized certificate issuing agency, effectively eliminates single-point failure risks, and improves the overall availability and robustness of a data space authentication system. A nested token structure including an outer-layer identity token and an inner-layer scope token is generated, the node identity information is borne by the outer-layer token, and the inner-layer token limits the credential acquisition range, so that token-level fine-grained permission constraints are realized, the credential query process is strictly matched with the authorized range, and the unauthorized acquisition of the credential is prevented. Public key analysis and signature verification are performed based on a distributed digital identity identifier document, so that each participating node can independently publish and manage its own identity information.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to multi-party authentication methods, systems and electronic devices based on distributed digital identity. Background Technology

[0002] In the data space architecture, multiple independent organizations share and collaborate across domains through connector nodes. Each participant must complete identity authentication and qualification verification before data transmission to ensure that data flows only between trusted entities. Existing multi-party authentication mechanisms have the following drawbacks: First, centralized trust risks, relying on a single CA (Certificate Authority) or CA alliance to issue X.509 certificates as the root of trust. An attack on the CA or its termination of operation will cause the entire authentication system to fail. Second, lack of identity autonomy, node identity information and public keys are centrally managed by the CA. Nodes cannot independently control the issuance, updating, and revocation of their identities, nor can they independently decide the granularity of identity information disclosure, violating the principle of data sovereignty. Third, insufficient cross-domain scalability, cross-organizational identity mutual recognition requires the establishment of complex cross-authentication relationships between various CAs, resulting in high configuration and maintenance costs, and new nodes cannot be quickly connected. Fourth, limited qualification expression capabilities, traditional certificates only carry static attributes such as organization name, public key, and validity period, and cannot express dynamic qualification statements such as data security level, industry qualifications, and compliance audits. Compliance verification is forced to rely on off-chain manual review or additional centralized systems. Summary of the Invention

[0003] To address the issues of single-point failure risk, third-party control of identity data violating data sovereignty principles, complex and difficult-to-expand cross-organizational identity mutual recognition mechanisms, and the inability of digital certificate content to express complex qualification statements in existing centralized identity authentication mechanisms, this paper provides a multi-party authentication method, system, and electronic device based on distributed digital identity that aims to eliminate reliance on centralization, enable participants to autonomously control identity data, simplify cross-organizational mutual recognition, and support flexible expression of complex qualification statements.

[0004] This application provides a multi-party authentication method based on distributed digital identity, executed by a first authentication node, which is an independently deployed authentication service module, forming a decoupled architecture from the control plane and data plane; including:

[0005] Generate a nested token structure, which includes an outer token and an inner token. The outer token includes the identity information of the first authentication node, and the inner token includes scope information for limiting the scope of credential acquisition.

[0006] Send a credential retrieval request carrying the nested token structure to the second authentication node;

[0007] Receive a set of signature credentials returned by the second authentication node, wherein the set of signature credentials is determined and signed by the second authentication node based on the scope information;

[0008] Obtain the identity identifier document of the second authentication node and extract the public key of the second authentication node;

[0009] The signature of the signature credential set is verified using the public key, and the identity compliance of the second authentication node is confirmed upon successful verification.

[0010] Optionally, generating the nested token structure includes:

[0011] Generate the inner token, which includes a scope field indicating the type of credential that is allowed to be obtained;

[0012] Generate the outer token, which includes a nested field, the value of which is the inner token;

[0013] The outer token is signed using the private key of the first authentication node.

[0014] Optionally, the first authentication node is further configured to generate a verifiable credential in response to a credential issuance request, including:

[0015] The format of the voucher request is validated according to the preset voucher definition.

[0016] Conduct a compliance assessment of the supporting documentation provided by the client;

[0017] Verification is conducted based on the evaluation results and pre-set issuance conditions;

[0018] Once verification is successful, a signed, verifiable credential is generated and stored.

[0019] Optionally, the first authentication node also performs key lifecycle management, including:

[0020] When the key state changes, the identity identifier document is triggered to be updated synchronously to keep the key state consistent with the public key information recorded in the identity identifier document.

[0021] This application provides a multi-party authentication method based on distributed digital identity, executed by a second authentication node, which is an independently deployed authentication service module, forming a decoupled architecture from the control plane and data plane; including:

[0022] Receive a credential retrieval request sent by the first authentication node, the credential retrieval request carrying a nested token structure, the nested token structure including an outer token and an inner token;

[0023] Obtain the identity identifier of the first authentication node from the outer token;

[0024] Obtain the identity identifier document of the first authentication node and extract the public key of the first authentication node;

[0025] The signature of the outer token is verified using the public key. Once the verification is successful, the legitimacy of the first authentication node is confirmed.

[0026] Extract scope information from the inner token;

[0027] The matching verifiable credentials are determined based on the scope information;

[0028] The verifiable credential is signed using the private key of the second authentication node to generate a set of signed credentials;

[0029] The set of signature credentials is sent to the first authentication node.

[0030] Optionally, determining the matching verifiable credential based on the scope information includes:

[0031] Match the credential type indicated in the scope information with the type of verifiable credential stored in the second authentication node;

[0032] When a match is successful, the corresponding verifiable credential is selected to generate the set of signature credentials.

[0033] Optionally, the second authentication node is further configured to generate a verifiable credential in response to a credential issuance request, including:

[0034] Receive a request for certificate issuance, the request including certificate type information and supporting documents;

[0035] Verify the validity of the voucher type information according to the preset voucher definition;

[0036] A compliance assessment will be conducted on the aforementioned supporting documents;

[0037] Verification is conducted based on the evaluation results and pre-set issuance conditions;

[0038] Once verification is successful, a signed and verifiable credential is generated and stored.

[0039] Optionally, the second authentication node also performs key lifecycle management, including:

[0040] When the key status changes, the identity identifier document is triggered to be updated synchronously so that the public key information recorded in the identity identifier document is consistent with the current key status of the second authentication node.

[0041] This application provides a multi-party authentication system based on distributed digital identity, including a first authentication node and a second authentication node. The first authentication node and the second authentication node are both independently deployed authentication service modules, forming a decoupled architecture with the control plane and the data plane.

[0042] The first authentication node is used to execute the multi-party authentication method based on distributed digital identity;

[0043] The second authentication node is used to execute the multi-party authentication method based on distributed digital identity.

[0044] This application also provides an electronic device, including:

[0045] At least one processor; and

[0046] A memory communicatively connected to the at least one processor; wherein,

[0047] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, cause the at least one processor to perform the multi-party authentication method based on distributed digital identity.

[0048] The beneficial effects of the above technical solution are as follows:

[0049] In this technical solution, the multi-party authentication method based on distributed digital identity deploys the identity authentication function independently as a decoupled first authentication node, separating it from the control plane and data plane. This eliminates the reliance on centralized certificate authorities, effectively removing single-point-of-failure risks and improving the overall availability and robustness of the data space authentication system. By generating a nested token structure containing an outer identity token and an inner scope token, with the outer token carrying node identity information and the inner token limiting the scope of credential acquisition, fine-grained token-level permission constraints are achieved. This ensures that the credential query process strictly matches the authorized scope, preventing unauthorized access to credentials. Public key parsing and signature verification based on distributed digital identity identifier documents enable participating nodes to independently publish and manage their own identity information, achieving cross-organizational identity mutual recognition without relying on third-party institutions. This simplifies the mutual recognition process while protecting data sovereignty. Furthermore, the signature verification mechanism using verifiable credential sets can flexibly carry and verify complex qualification statements, including data security authentication and industry processing capabilities, meeting diverse compliance verification needs in the data space. Attached Figure Description

[0050] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0051] Figure 1 This is a flowchart of one embodiment of the multi-party authentication method based on distributed digital identity in Embodiment 1 of this application;

[0052] Figure 2 This is a flowchart of one embodiment of the multi-party authentication method based on distributed digital identity, which is a second embodiment of this application.

[0053] Figure 3 An exemplary structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0054] The advantages of this application are further illustrated below with reference to the accompanying drawings and specific embodiments.

[0055] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0056] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0057] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0058] In the description of this application, it should be understood that the numerical labels before the steps do not indicate the order of the steps, but are only used to facilitate the description of this application and to distinguish each step, and therefore should not be construed as a limitation of this application.

[0059] The following terms are used in this document:

[0060] DID (Decentralized Identifier): A decentralized identity identifier defined by the World Wide Web Consortium specification. Its format is "did:method:method-specific identifier". Holders can control it independently without relying on a centralized registration authority.

[0061] DCP (Decentralized Claims Protocol): A protocol specification for the exchange of verifiable credentials in the data space;

[0062] JWT (JSON Web Token, Access Token): A signed token carrying claim information, used in this application as a self-signed identity token and inner access token;

[0063] JWK (JSON Web Key): A standard for representing keys in JSON format, used to publish public keys in the verification method of DID documents;

[0064] did:web: A DID method based on the W3C decentralized identity standard, used for publishing and resolving DID documents via web domains;

[0065] JSON-LD: A JSON format based on the Semantic Web, used to express structured data with explicit semantics. DID documents and verifiable credentials both use this format.

[0066] Example 1

[0067] This embodiment provides a multi-party authentication method based on distributed digital identity, executed by a first authentication node. The first authentication node is an independently deployed authentication service module, forming a decoupled architecture with the control plane and data plane; it includes the following steps:

[0068] A1. Generate a nested token structure, the nested token structure including an outer token and an inner token, the outer token including the identity information of the first authentication node, and the inner token including scope information for limiting the scope of credential acquisition;

[0069] It should be noted that the outer token includes the identity information of the first authentication node and is signed with a private key, while the inner token includes scope information for limiting the scope of credential acquisition and is set with a preset validity period.

[0070] A2. Send a credential retrieval request carrying the nested token structure to the second authentication node;

[0071] A3. Receive the set of signature credentials returned by the second authentication node, wherein the set of signature credentials is determined and signed by the second authentication node based on the scope information;

[0072] A4. Obtain the identity identifier document of the second authentication node and extract the public key of the second authentication node;

[0073] A5. Use the public key to verify the signature of the signature credential set, and confirm the identity compliance of the second authentication node after successful verification.

[0074] In this embodiment, the first authentication node is deployed independently as the identity center, forming a three-layer decoupled authentication architecture together with the control plane responsible for contract negotiation and the data plane responsible for actual data transmission. The identity center is responsible for the management and publication of distributed digital identity identifier documents, the issuance and storage of verifiable credentials, the generation and verification of verifiable representations, the issuance of security tokens, and the full lifecycle management of key pairs. The control plane invokes the identity center's token verification capability to authenticate the peer's identity when initiating negotiation. The data plane embeds identity information into the access token referenced by the endpoint data through the data plane authorization service, realizing identity-based access control. The three layers communicate via an HTTP interface, each layer is independent and replaceable, and the identity authentication logic is completely separated from the business logic and data transmission logic.

[0075] In this embodiment, the multi-party authentication method based on distributed digital identity deploys the identity authentication function independently as a decoupled first authentication node, separating it from the control plane and data plane. This eliminates the reliance on centralized certificate authorities, effectively removing single-point-of-failure risks and improving the overall availability and robustness of the data space authentication system. By generating a nested token structure containing an outer identity token and an inner scope token, with the outer token carrying node identity information and the inner token limiting the scope of credential acquisition, fine-grained token-level permission constraints are achieved. This ensures that the credential query process strictly matches the authorized scope, preventing unauthorized access to credentials. Public key parsing and signature verification based on distributed digital identity identifier documents enable participating nodes to independently publish and manage their own identity information, achieving cross-organizational identity mutual recognition without relying on third-party institutions. This simplifies the mutual recognition process while protecting data sovereignty. Furthermore, the signature verification mechanism using verifiable credential sets can flexibly carry and verify complex qualification statements, including data security authentication and industry processing capabilities, meeting diverse compliance verification needs in the data space.

[0076] In an optional embodiment, the process of the first authentication node obtaining the identity identifier document of the second authentication node is implemented based on the distributed digital identity identifier publishing and parsing mechanism. Specifically, the distributed digital identity identifier of each authentication node is generated using the "did:web" method, with the format "did:web:domain:path", and the corresponding identity identifier document is published externally through HTTPS service. The identity identifier document conforms to the W3C DID core specification, is stored in JSON-LD format, and includes identifier fields, a list of verification methods, authentication references, and server endpoint information. When an authentication node is created, the key pair service automatically generates an initial key pair, the identity identifier document service automatically creates and initializes the document, the local publisher stores the document in local storage and provides an external access interface, and listens for document publishing and unpublishing events to maintain document consistency. During the authentication process, the peer authentication node converts the target identifier into an HTTPS address through the DID resolver, initiates a request to that address, parses the response body into an identity identifier DID document data structure in JSON format, and extracts public key information from the list of verification methods. The public key supports JWK (JSON Network Key) format or PEM format. The above mechanism enables each authentication node to independently publish its own identity information, and peer nodes can directly obtain the public key required for verification without relying on a centralized certificate authority, thus achieving decentralized identity mutual recognition.

[0077] In an optional embodiment, step A1 generates a nested token structure, including the following steps:

[0078] A11. Generate the inner token, which includes a scope field indicating the type of credential that is allowed to be obtained;

[0079] A12. Generate the outer token, which includes a nested field, the value of which is the inner token;

[0080] A13. Sign the outer token using the private key of the first authentication node.

[0081] In this embodiment, the process of generating the nested token structure is as follows: First, an inner token is generated, which contains a scope field indicating the types of credentials that are allowed to be obtained; then, an outer token is generated, which contains a nested field whose value is set to the inner token; finally, the outer token is signed using the private key of the first authentication node. In the nested token structure formed in the above manner, the inner token carries scope information to declare the range of credential types requested by the first authentication node. The second authentication node filters matching verifiable credentials based on this declaration. The outer token protects the integrity and immutability of the inner token through its signature and simultaneously declares the identity of the first authentication node. When a credential acquisition request is sent to the second authentication node, the second authentication node must first verify the signature of the outer token to confirm the authenticity of the first authentication node's identity. After successful verification, the scope information is extracted from the inner token, and matching verifiable credentials are filtered accordingly. This ensures that the second authentication node can only obtain credentials within its authorized scope, preventing unauthorized credential disclosure. This token construction method, which nests inner permission constraints with outer identity verification, maintains the simplicity of token transmission and processing while enabling fine-grained control over credential access permissions, effectively supporting secure interaction based on the principle of least privilege in distributed multi-party authentication scenarios.

[0082] In an optional embodiment, the first authentication node is further configured to generate a verifiable credential in response to a credential issuance request, including the following steps:

[0083] The format of the voucher request is validated according to the preset voucher definition.

[0084] Conduct a compliance assessment of the supporting documentation provided by the client;

[0085] Verification is conducted based on the evaluation results and pre-set issuance conditions;

[0086] Once verification is successful, a signed, verifiable credential is generated and stored.

[0087] In this embodiment, the process of the first authentication node generating a verifiable credential in response to a credential issuance request employs a two-stage verification mechanism. The first authentication node internally maintains a credential definition registry, where each credential type corresponds to a credential definition. This definition includes the credential type name, supported credential formats, a list of supporting document types to be evaluated before issuance, and a list of issuance rules. Upon receiving a credential issuance request, the first authentication node first performs a first-stage verification: querying the credential definition registry by the credential definition identifier in the request to confirm that all requested credential types have corresponding credential definitions; verifying that the format of the request matches the format supported by the credential definition; and verifying that the currently registered decentralized declaration protocol configuration file supports the format. If any verification fails, issuance is rejected. After the first-stage verification passes, the second stage begins: summarizing all supporting document types declared in the requested credential definitions, and using a proof evaluation pipeline to evaluate whether the context of the supporting documents provided by the applicant meets the requirements of all supporting document types. If the evaluation fails, an unauthorized error is returned; if the evaluation passes, the pipeline returns the declaration information extracted from the supporting documents. Subsequently, the credential issuance rule evaluator combines the issuance rules in the credential definition with the extracted declaration information for conditional verification. If the rules are not met, issuance is rejected. After both phases of verification pass, the issuing service creates an issuing process entity, recording the holder identifier, a list of credential definition identifiers, credential format, declaration information, and participant context identifiers. The status is set to approved, and the entity is persistently stored and asynchronously driven to generate, sign, and push the credential. Through this two-phase verification mechanism, the first authentication node can perform multi-level verification at the source of credential issuance, including format validation, material compliance review, and rule determination. This ensures that only entities that fully meet compliance requirements can obtain the corresponding verifiable credential. Simultaneously, the credential issuance process is decoupled from subsequent authentication interactions, supporting flexible definition of credential types and issuance rules according to different application scenarios.

[0088] In this embodiment, the specific process by which the first authentication node generates a verifiable credential in response to a credential issuance request is as follows: The first authentication node receives a credential issuance request from a client, which carries credential type information and relevant supporting documents; subsequently, the first authentication node performs format verification on the credential request according to a preset credential definition to confirm that the requested credential type matches the credential format supported by the system; after the format verification is passed, the first authentication node performs a compliance assessment on the supporting documents submitted by the client to verify the authenticity and validity of the supporting documents; based on the passing of the supporting document assessment, the first authentication node further performs a comprehensive verification based on the assessment results and preset issuance conditions to determine whether the current request meets the credential issuance rules; after all three verification steps are passed, the first authentication node generates a signed verifiable credential and stores it in the local credential repository.

[0089] Through the aforementioned two-stage verification mechanism, the first authentication node can perform multi-level verification of credential format, compliance of supporting materials, and issuance rules during the credential issuance process, effectively preventing the incorrect issuance or malicious acquisition of non-compliant credentials. Simultaneously, the credential issuance process is independent of subsequent credential query and authentication processes, decoupling credential generation and management from specific business interactions. This enhances the security and accuracy of credential issuance while supporting flexible definition of credential types and issuance rules based on different application scenarios, meeting the diverse compliance verification needs in the data space.

[0090] This embodiment defines verifiable credentials in JWT format and associated data proof format. Within the same credential issuance framework, support for other credential formats (such as SD-JWT selective disclosure of JWT, BBS+signature, etc.) can be extended by implementing a new credential format converter and registering it in the converter registry, without modifying the core logic of the two-phase verification mechanism.

[0091] In an optional embodiment, the first authentication node further performs key lifecycle management, including:

[0092] When the key state changes, the identity identifier document is triggered to be updated synchronously to keep the key state consistent with the public key information recorded in the identity identifier document.

[0093] In this embodiment, the first authentication node performs full lifecycle management on the key pairs it manages and automatically triggers the synchronous update of the identity identifier document when the key status changes. Specifically, when a key pair moves from the creation state to the activation state, the first authentication node adds the corresponding public key to the verification method list in its identity identifier document; when the key pair enters the rotation phase, the first authentication node generates a new key pair and activates it, while deleting the old private key. During a preset transition period, the old public key is retained in the identity identifier document to support the validity verification of historical signature credentials. After the transition period expires, the old public key is retained in the verification method list but is no longer used for identity authentication; when a key pair is revoked, the first authentication node immediately deletes the corresponding private key and triggers an event that completely removes the public key from the identity identifier document, so that the leaked or invalid public key is no longer trusted by any peer node.

[0094] In an optional embodiment, the rotation phase in the key lifecycle management further includes: after generating a new key pair and entering an active state, deleting the private key of the old key pair, updating the status to rotated, and setting a configurable transition period; during the transition period, the old public key remains in the verification method list of the identity identifier document to support the validity verification of historical credentials or tokens signed with the old key; after the transition period ends, an event is triggered in the identity identifier document to remove the old public key authentication reference, but the old public key is retained in the verification method list to continue supporting historical signature verification until all credentials relying on that public key expire naturally. By setting a transition period, this embodiment ensures secure key rotation while avoiding the interruption of historical signature credential verification due to key updates.

[0095] Through the aforementioned linkage update mechanism between the key lifecycle and the identity identifier document, the first authentication node can ensure that its publicly released public key information remains consistent with the actual state of its local keys in real time. During normal key rotation, the transition period ensures that previously issued historical signature credentials can still be correctly verified within their validity period, avoiding authentication interruptions caused by key updates. In the event of key leakage or expiration, the corresponding public key is immediately removed from the identity identifier document, effectively preventing the revoked key from being maliciously used to forge identities or signatures. This automated synchronization method eliminates the configuration lag and inconsistency risks that may arise from manual document updates, significantly improving the security and operational reliability of the distributed identity authentication system during the dynamic evolution of keys.

[0096] Example 2

[0097] This embodiment provides a multi-party authentication method based on distributed digital identity, executed by a second authentication node. The second authentication node is an independently deployed authentication service module, forming a decoupled architecture from the control plane and data plane. Figure 2 As shown, it includes the following steps:

[0098] B1. Receive a credential retrieval request sent by the first authentication node, wherein the credential retrieval request carries a nested token structure, the nested token structure including an outer token and an inner token;

[0099] B2. Obtain the identity identifier of the first authentication node from the outer token;

[0100] B3. Obtain the identity identifier document of the first authentication node and extract the public key of the first authentication node;

[0101] B4. Verify the signature of the outer token using the public key, and confirm the legitimacy of the first authentication node's identity upon successful verification;

[0102] B5. Extract scope information from the inner token;

[0103] B6. Determine the matching verifiable credentials based on the scope information;

[0104] B7. Use the private key of the second authentication node to sign the verifiable credential, and generate a set of signed credentials;

[0105] B8. Send the set of signature credentials to the first authentication node.

[0106] In Embodiment 2, a multi-party authentication method based on distributed digital identity is provided, executed by a second authentication node. This second authentication node, along with the first authentication node, is an independently deployed authentication service module, forming a decoupled architecture from the control plane and data plane. The specific execution steps of this method are as follows: The second authentication node first receives a credential retrieval request sent by the first authentication node. This request carries a nested token structure, which consists of an outer token and an inner token. The second authentication node extracts the distributed digital identity identifier of the first authentication node from the outer token, obtains the first authentication node's identity identifier document based on this identifier, and parses the first authentication node's public key from the document. Subsequently, the second authentication node uses this public key to verify the signature of the outer token. Upon successful verification, the identity of the first authentication node is confirmed to be authentic and valid, completing the authentication of the requester. After successful identity authentication, the second authentication node extracts the scope information used to limit the scope of credential acquisition from the inner token, and searches for a matching verifiable credential in the locally stored credential repository based on the scope information. After determining the matching credential, the second authentication node uses its own private key to sign the selected verifiable credential as a whole, generates a set of signed credentials, and sends the set of signed credentials back to the first authentication node.

[0107] In an optional embodiment, before generating the set of signed credentials, the second authentication node also performs a verifiable representation query and generation process. The verifiable representation query interface provided by the second authentication node requires the requester to include an outer self-signed identity token in the authorization header. After receiving the credential acquisition request, the second authentication node first performs JSON-LD expansion on the request body to identify the protocol version and selects the corresponding converter registry and protocol scope identifier; then it calls the self-signed token verifier to perform a full verification of the outer token in the authorization header. If the verification fails, it returns an authentication failure error; if the verification passes, it extracts the scope declaration from the inner token as the permission scope for credential query; next, the credential query parser queries the local credential storage for matching verifiable credentials according to the participant context identifier and scope declaration. If the requested credential type exceeds the scope of the scope declaration, it returns an unauthorized access denied return; then, the verifiable representation service packages the queried credential list into a verifiable representation, sets the holder to the node's distributed digital identity identifier, sets the audience to the first authentication node, and signs the representation using the node's currently active private key; finally, it compresses the generated verifiable representation according to the protocol version's namespace using JSON-LD and returns it to the requester. After receiving the verifiable statement, the first authentication node obtains the public key verification statement signature by parsing the identity identifier document of the second authentication node, and then verifies the signature of each credential by parsing the identity identifier documents of each credential issuing authority, thereby completing the comprehensive verification of the identity of the second authentication node and the credential it holds.

[0108] Through the execution of the above steps, the second authentication node, after verifying the legitimacy of the first authentication node's identity, strictly provides verifiable credentials according to the scope declared in the inner token. This achieves on-demand credential disclosure based on the principle of least privilege, effectively preventing excessive exposure of credential information. The step-by-step processing mechanism of outer token signature verification and inner token scope extraction allows identity authentication and access control to be executed independently yet in tandem, ensuring the security of the authentication process while implementing fine-grained constraints on credential access. Furthermore, the second authentication node signs the matching credentials and returns them, enabling the first authentication node to verify the integrity and authenticity of the credential set by verifying the signature. This establishes a two-way trusted identity recognition relationship between the two parties, laying a reliable foundation for subsequent secure interactions between the control plane and data plane.

[0109] In an optional embodiment, step B6, which determines a matching verifiable credential based on the scope information, includes the following steps:

[0110] B61. Match the credential type indicated in the scope information with the type of verifiable credential stored in the second authentication node;

[0111] B62. When a match is successful, select the corresponding verifiable credential to generate the set of signature credentials.

[0112] In this embodiment, the process by which the second authentication node determines the matching verifiable credentials based on the scope information is as follows: After extracting the scope information from the inner token, the second authentication node parses one or more credential type identifiers indicated in the scope information and compares these identifiers with the credential types of each verifiable credential stored locally on the node. When a matching item of the same type exists, the second authentication node includes the verifiable credential corresponding to that matching item in the set of credentials to be signed. Through this type matching method, the second authentication node can ensure that only the credential types that the first authentication node is authorized to obtain are included in the returned set of signed credentials, and any credentials exceeding the scope declaration will not be selected or disclosed. This mechanism effectively implements the principle of least privilege, ensuring that the scope of credential acquisition is entirely constrained by the scope of the token held by the first authentication node. Even if the requester's identity is legitimate, they cannot exceed their authority to obtain credential information that does not match their permissions, thereby significantly reducing the risk of accidental leakage of sensitive credentials while achieving secure credential sharing.

[0113] In an optional embodiment, the second authentication node is further configured to generate a verifiable credential in response to a credential issuance request, including:

[0114] Receive a request for certificate issuance, the request including certificate type information and supporting documents;

[0115] Verify the validity of the voucher type information according to the preset voucher definition;

[0116] A compliance assessment will be conducted on the aforementioned supporting documents;

[0117] Verification is conducted based on the evaluation results and pre-set issuance conditions;

[0118] Once verification is successful, a signed and verifiable credential is generated and stored.

[0119] In this embodiment, the second authentication node also has the function of generating verifiable credentials in response to credential issuance requests. The specific execution process is as follows: The second authentication node receives a credential issuance request from the client. The request contains the type information of the credential to be issued and the supporting materials used to prove the qualification. The second authentication node first verifies whether the credential type information in the request matches the registered credential definition according to the preset credential definition registry, confirming that the credential type is a legal type supported by the system. After the verification is passed, the second authentication node calls the supporting material evaluation module to evaluate the compliance of the supporting materials submitted by the client, verifying the authenticity and completeness of the material content. Based on the passing of the material evaluation, the second authentication node further compares and verifies the evaluation result with the preset credential issuance rules, and comprehensively determines whether the current request meets all the issuance conditions of this type of credential. After all the above multi-level verifications are passed, the second authentication node generates a unique identifier for the credential, digitally signs the credential content using its own private key, generates a signed verifiable credential, and stores the credential in the local credential repository for subsequent authentication processes to retrieve and use.

[0120] Through the above steps, the second authentication node can implement strict format verification, material review, and rule judgment at the source of credential generation, effectively preventing the issuance of unqualified credentials and ensuring that only entities that fully meet compliance requirements can obtain verifiable credentials with corresponding permissions. Simultaneously, the credential issuance process is independent of the real-time authentication interaction, separating the application, review, and issuance stages of credentials from subsequent credential acquisition request processing. This reduces the processing burden during the authentication interaction process and supports dynamic adjustment of credential definitions and issuance rules according to business scenarios, meeting the differentiated authentication needs of different levels and industries of qualification declarations in the data space. This credential generation mechanism, in conjunction with the aforementioned credential query and verification process, constitutes the second authentication node's complete credential management and service capabilities.

[0121] In an optional embodiment, the second authentication node further performs key lifecycle management, including:

[0122] When the key status changes, the identity identifier document is triggered to be updated synchronously so that the public key information recorded in the identity identifier document is consistent with the current key status of the second authentication node.

[0123] In this embodiment, the second authentication node implements full lifecycle management of the key pairs it holds and automatically triggers a synchronous update operation of the identity identifier document when the key status changes. Specifically, when the second authentication node generates a new key pair and enters the activation state, the corresponding public key is immediately added to the verification method list of its identity identifier document; when the key pairs are rotated periodically, the second authentication node deletes the old private key after generating and activating the new key pair, and retains the old public key in the identity identifier document during the configured transition period to maintain the verification capability for credentials signed with the old key. After the transition period expires, the old public key is retained in the verification method list but is no longer used for identity authentication; when a key pair needs to be revoked due to leakage or invalidation, the second authentication node immediately deletes the corresponding private key and synchronously triggers an update event to completely remove the public key from the identity identifier document, so that the revoked public key is no longer released to the public.

[0124] Through the aforementioned linkage update mechanism between the key lifecycle and the identity identifier document, the second authentication node can consistently ensure real-time consistency between the publicly released public key information and the actual state of its local keys. During normal key rotation, the strategy of retaining old public keys during the transition period ensures that the first authentication node or other peer nodes can still verify credentials or tokens previously issued by the second authentication node, avoiding interruptions to the authentication process due to key updates. In the event of abnormal key revocation, expired public keys are immediately removed from the identity identifier document, effectively preventing attackers from using leaked private keys to forge the second authentication node's signature credentials for identity impersonation. This automated synchronization mechanism eliminates the configuration lag and state inconsistency risks that may arise from manual maintenance of the identity identifier document, significantly enhancing the security and operational reliability of the distributed authentication system during the dynamic evolution of keys.

[0125] Example 3

[0126] This embodiment provides a multi-party authentication system based on distributed digital identity, including a first authentication node and a second authentication node. The first authentication node and the second authentication node are both independently deployed authentication service modules, forming a decoupled architecture with the control plane and the data plane.

[0127] The first authentication node is used to execute the method described in Embodiment 1;

[0128] The second authentication node is used to execute the method described in Embodiment 2.

[0129] In this embodiment, the multi-party authentication system based on distributed digital identity includes a first authentication node and a second authentication node. Both authentication nodes are independently deployed authentication service modules, forming a decoupled architecture with their respective control planes and data planes. The first authentication node executes the aforementioned multi-party authentication method implemented by itself, namely, generating a nested token structure and initiating a credential acquisition request, and receiving and verifying the set of signed credentials returned by the second authentication node. The second authentication node executes the aforementioned multi-party authentication method implemented by itself, namely, receiving and verifying the nested token structure from the first authentication node, filtering matching verifiable credentials based on the scope information in the inner token, signing them, and returning them to the first authentication node.

[0130] Through the collaborative work of the first and second authentication nodes, the system can establish decentralized, two-way identity recognition relationships among all participants in the data space. Since the authentication nodes are deployed independently of the control plane and data plane, the identity authentication logic is completely separated from the business processing logic and data transmission logic. A failure in any authentication node will not affect the authentication capabilities of other participants, eliminating the single point of failure risk inherent in traditional centralized authentication architectures. Simultaneously, both authentication nodes use distributed digital identity identifier documents for public key acquisition and signature verification, enabling cross-organizational identity recognition without relying on third-party certificate authorities, simplifying the authentication process in multi-organizational scenarios. The constraint mechanism of the inner scope in the nested token structure ensures that the second authentication node can only obtain credentials within its authorized scope, achieving minimal disclosure of credentials on demand and effectively preventing the excessive exposure of sensitive information. Furthermore, the verification of the signed credential set by the first authentication node includes: verifying the signature of the set to confirm transmission integrity and source authenticity, and verifying the signature of the credential issuer to confirm credential authenticity, thereby confirming the identity of the second authentication node and the compliance of its held credentials, providing a trusted identity foundation for subsequent contract negotiation in the control plane and secure transmission in the data plane.

[0131] In this embodiment, the authentication process is divided into an initialization phase and a runtime continuous authentication phase. The initialization phase occurs at the beginning of system deployment or connection establishment: each authentication node first generates and publishes its own distributed digital identity identifier document, creates and activates an initial key pair, and self-signs or applies for a credential issuance service for basic verifiable credentials. This phase mainly involves the management of distributed digital identity identifier documents, key lifecycle management, and verifiable credential issuance within the identity center. The runtime continuous authentication phase occurs with each business interface call: when the control plane corresponding to the first authentication node needs to initiate contract negotiation or data transmission requests to the second authentication node, the control plane first requests the generation of a nested token from its own identity center, and then sends a credential retrieval request to the identity center of the second authentication node with this token. After verifying the token, the second authentication node returns a set of signed credentials. After the first authentication node verifies the credentials, it confirms the other party's identity is compliant, and both parties complete two-way identity mutual recognition. Subsequently, the control plane and data plane perform secure interactions based on this. By separating the initialization authentication from the runtime authentication, the system reduces the authentication overhead for each business interaction while ensuring authentication security.

[0132] The identity authentication protocol flow of this embodiment based on a distributed digital identity multi-party authentication system is as follows:

[0133] The first authentication node (consumer) generates a nested token structure, including an outer identity token and an inner scope token. The outer token contains the node's identity information, and the inner token contains scope information that limits the scope of credential acquisition. The first authentication node sends a credential acquisition request carrying this nested token structure to the second authentication node (provider). Upon receiving the request, the second authentication node extracts the first authentication node's identity identifier from the outer token, obtains the first authentication node's public key by parsing the identity identifier document, and verifies the outer token signature to confirm the legitimacy of the first authentication node's identity. After successful verification, the second authentication node extracts the scope information from the inner token and matches locally stored verifiable credentials according to the credential type indicated in the scope. The second authentication node signs the matching credential set using its own private key, generates a signed credential set, and returns it to the first authentication node. Upon receiving this, the first authentication node obtains the second authentication node's identity identifier document and extracts its public key. It uses this public key to verify the signature of the signed credential set. After successful verification, the second authentication node's identity is confirmed to be compliant, and both parties complete two-way identity mutual recognition. Subsequently, the control plane and data plane can use this to negotiate contracts and transmit secure data.

[0134] In summary, the multi-party authentication method and system based on distributed digital identity provided in this application have at least the following beneficial effects: It adopts a three-layer decoupled authentication architecture, independently deploying the identity center and completely separating it from the control plane and data plane, eliminating the risk of centralized single point of failure and improving system availability and maintainability; it employs a nested token structure, with the outer self-signed identity token carrying node identity information and the inner access token carrying a precise scope declaration to constrain the query scope of verifiable credentials, achieving fine-grained access control at the token level while maintaining a simple token structure, preventing tokens from being used to obtain credentials without authorization; and it adopts a two-phase verifiable credential issuance and verification mechanism, through credential definition registration. The table manages credential type configurations and employs dual content verification through a proof material evaluation pipeline and a credential issuance rule evaluator to ensure the security and flexibility of credential issuance. It utilizes a four-stage key pair lifecycle management and an automatic linkage update mechanism for identity identifier documents. Through key status management in four stages—creation, activation, rotation, and revocation—and event-driven document synchronization, it ensures real-time consistency between key status and publicly released public key information. Furthermore, it employs a decentralized public key parsing and signature verification mechanism based on distributed digital identity identifier documents, enabling participating nodes to complete cross-organizational identity mutual recognition without relying on third-party certificate authorities, simplifying the mutual recognition process and safeguarding data sovereignty.

[0135] Example 4

[0136] This application also provides an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as cellular phones, smartphones, wearable devices, and other similar computing devices.

[0137] The electronic device includes: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the methods provided in any one or more embodiments of this application. Figure 3An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0138] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103 and output device 1104 may be connected by a bus or other means, as shown in the figure, which is connected by a bus.

[0139] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0140] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0141] In this embodiment, a computer-readable medium stores a computer program / instructions that, when executed by a processor, implement the steps of the methods provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into that device. The aforementioned computer-readable medium carries one or more computer-readable instructions.

[0142] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0143] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0144] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0145] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0146] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0147] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0148] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0149] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0150] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first," "second," etc., are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0151] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A multi-party authentication method based on distributed digital identity, executed by a first authentication node, wherein the first authentication node is an independently deployed authentication service module, forming a decoupled architecture with the control plane and data plane; characterized in that, include: Generate a nested token structure, which includes an outer token and an inner token. The outer token includes the identity information of the first authentication node, and the inner token includes scope information for limiting the scope of credential acquisition. Send a credential retrieval request carrying the nested token structure to the second authentication node; Receive a set of signature credentials returned by the second authentication node, wherein the set of signature credentials is determined and signed by the second authentication node based on the scope information; Obtain the identity identifier document of the second authentication node and extract the public key of the second authentication node; The signature of the signature credential set is verified using the public key, and the identity compliance of the second authentication node is confirmed upon successful verification.

2. The method according to claim 1, characterized in that, The generation of the nested token structure includes: Generate the inner token, which includes a scope field indicating the type of credential that is allowed to be obtained; Generate the outer token, which includes a nested field, the value of which is the inner token; The outer token is signed using the private key of the first authentication node.

3. The method according to claim 1, characterized in that, The first authentication node is also configured to generate verifiable credentials in response to a credential issuance request, including: The format of the voucher request is validated according to the preset voucher definition. Conduct a compliance assessment of the supporting documentation provided by the client; Verification is conducted based on the evaluation results and pre-set issuance conditions; Once verification is successful, a signed, verifiable credential is generated and stored.

4. The method according to claim 1, characterized in that, The first authentication node also performs key lifecycle management, including: When the key state changes, the identity identifier document is triggered to be updated synchronously to keep the key state consistent with the public key information recorded in the identity identifier document.

5. A multi-party authentication method based on distributed digital identity, executed by a second authentication node, wherein the second authentication node is an independently deployed authentication service module, forming a decoupled architecture with the control plane and data plane; characterized in that, include: Receive a credential retrieval request sent by the first authentication node, the credential retrieval request carrying a nested token structure, the nested token structure including an outer token and an inner token; Obtain the identity identifier of the first authentication node from the outer token; Obtain the identity identifier document of the first authentication node and extract the public key of the first authentication node; The signature of the outer token is verified using the public key. Once the verification is successful, the legitimacy of the first authentication node is confirmed. Extract scope information from the inner token; The matching verifiable credentials are determined based on the scope information; The verifiable credential is signed using the private key of the second authentication node to generate a set of signed credentials; The set of signature credentials is sent to the first authentication node.

6. The method according to claim 5, characterized in that, The step of determining the matching verifiable credential based on the scope information includes: Match the credential type indicated in the scope information with the type of verifiable credential stored in the second authentication node; When a match is successful, the corresponding verifiable credential is selected to generate the set of signature credentials.

7. The method according to claim 5, characterized in that, The second authentication node is also configured to generate verifiable credentials in response to a credential issuance request, including: Receive a request for credential issuance, the request including credential type information and supporting documents; Verify the validity of the voucher type information according to the preset voucher definition; A compliance assessment will be conducted on the aforementioned supporting documents; Verification is conducted based on the evaluation results and pre-set issuance conditions; Once verification is successful, a signed and verifiable credential is generated and stored.

8. The method according to claim 5, characterized in that, The second authentication node also performs key lifecycle management, including: When the key status changes, the identity identifier document is triggered to be updated synchronously so that the public key information recorded in the identity identifier document is consistent with the current key status of the second authentication node.

9. A multi-party authentication system based on distributed digital identity, characterized in that, It includes a first authentication node and a second authentication node, both of which are independently deployed authentication service modules, forming a decoupled architecture from the control plane and the data plane; The first authentication node is used to perform the method according to any one of claims 1 to 4; The second authentication node is used to perform the method described in any one of claims 5 to 8.

10. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 4, or to perform the method according to any one of claims 5 to 8.

Images