Decentralized identity lifecycle management method and device for judicial cross-domain mutual trust

Abstract

The application relates to a decentralized identity life cycle management method and device for judicial cross-domain mutual trust, which comprises the following specific steps: S1, identity registration and cross-domain trust establishment; S2, certificate issuance and business context binding; S3, normal use of the certificate and cross-domain access; S4, revocation triggering and legal authentication updating; S5, on-chain revocation registration and state updating; S6, post-revocation verification and zero-knowledge proof output; S7, expiration cleaning and audit tracking. The application guarantees the non-tamperability and global verifiability of the revocation state through a block chain and a sparse Merkle tree, binds judicial authentication and legal basis to make the technical operation have legal constraints, and combines zero-knowledge proof to complete state verification without leaking sensitive information, so that the defects of the traditional DID mechanism, such as lack of legal endorsement, single-point failure and privacy protection difficulty, are solved, and the application has the advantages of compliance, safety and traceability.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, specifically to a decentralized identity lifecycle management method and apparatus for cross-domain mutual trust in judicial matters. Background Technology

[0002] Decentralized identity is a brand-new way of identifying identity. It does not rely on accounts, emails, or phone numbers issued by any single institution or platform. Decentralized identity is identity information generated and controlled by the user himself, and can be identified and verified in decentralized systems such as blockchain.

[0003] While decentralized identity technology provides a decentralized identity management solution for cross-jurisdictional trust scenarios, existing decentralized identity revocation mechanisms have the following problems:

[0004] 1. Relying on a centralized revocation list poses a single point of failure risk. When a node malfunctions, the verifier must revert to offline verification, which violates the original intention of decentralized design. 2. It only possesses cryptographic validity, but is not bound to judicial entities or legal basis, making it difficult to obtain legal enforcement power under regulations such as GDPR, which is not conducive to the tracing of responsibility; 3. There are significant differences in rules across jurisdictions. Existing solutions rely on offline agreements or manual configuration, lacking unified on-chain coding and automatic execution mechanisms, making it difficult to handle rule conflicts. 4. Centralized revocation authority is prone to unilateral abuse of power and does not comply with due process of law; 5. The cancellation status verification requires exposing sensitive information such as credential identifiers and legal details, which is insufficient for privacy protection and cannot meet the requirements of regulatory oversight and minimal disclosure. Based on the above problems, a decentralized identity lifecycle management method and device for cross-jurisdictional mutual trust in judicial practice are proposed to solve these problems. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a decentralized identity lifecycle management method and device for cross-jurisdictional mutual trust, which has advantages such as compliance, security, and traceability, and solves the aforementioned problems.

[0006] To achieve the above objectives, this invention provides the following technical solution: a decentralized identity lifecycle management method for cross-jurisdictional mutual trust, comprising the following specific steps: S1: Identity Registration and Cross-Domain Trust Establishment: First, create identity identifiers and public keys for judicial entities and record them on the blockchain. Configure domain identifiers and legal roles, register the real-name DIDs of case handlers, bind attributes and generate basic credentials. Configure cross-domain trust information for each participating domain, form cross-domain trust entries and write them to the blockchain. S2: Credential Issuance and Business Context Binding: When the business system triggers a credential issuance request, it sends the issuance context to the legal authentication engine. The legal authentication engine obtains the judicial authorization token based on the OAuth2.0 / JWT protocol, generates a legal authentication A_j with a judicial threshold signature, generates a verifiable credential C_j and binds it to the legal authentication A_j, and issues it after being authenticated by the holder. S3: Normal use of credentials and cross-domain access: The holder initiates an authentication, access or delegation request based on the verifiable credential C_j. The multi-signature verifier performs threshold verification on the multi-party signatures and checks the cross-domain trust entries on the blockchain. Only credentials are allowed to be used under valid trust relationships. S4: Revocation Trigger and Legal Authentication Update: Identify the revocation trigger conditions, generate a revocation business request R_j with a digital signature and submit it to the legal authentication engine. The legal authentication engine re-obtains judicial authorization, generates a revocation-type legal authentication A_j' and maintains the version association with legal authentication A_j. S5: On-chain deregistration and status update: The deregistered smart contract calculates the sparse Merkle tree leaf node index corresponding to the verifiable credential C_j, constructs the leaf node content containing the deregistration status, H(A_j') and nonce, loads the corresponding domain rules and verifies compliance, and updates the Merkle tree and domain root after passing the verification, and records the transaction metadata. S6: Post-revocation verification and zero-knowledge proof output: A third-party verifier initiates a zero-knowledge proof request. The proof generation end inputs the private witness into the zk-SNARKs circuit to generate a zero-knowledge proof. The verifier verifies the proof based on the public input and outputs the truth value of the revocation state without disclosing sensitive information. S7: Expiration Cleanup and Audit Tracking: Revoking smart contracts prunes expiration and revocation records in batches according to the rules of the jurisdiction, and the regulatory platform associates blockchain transactions and business logs to replay the identity lifecycle, achieving regulatory oversight and accountability.

[0007] Furthermore, the judicial entities mentioned in step S1 include courts, procuratorates, and public security organs. The case handlers' real-name DIDs are bound to their police numbers, affiliated institutions, and terminal device attributes. The cross-domain trust entries include source domain ID, target domain ID, trust level, validity period, public key, and digital signature.

[0008] Furthermore, the issuance context mentioned in step S2 includes the case number, the real name (DID) of the case handler, the description of the target resource, the applicable legal domain and the expected validity period, and the legal authentication A_j includes the court identifier, the applicable legal domain, the legal basis clause, the revocation conditions and time limit information.

[0009] Furthermore, the revocation triggering conditions mentioned in step S4 include changes in identity status to REVOKED / LOCKED, case closure, expiration of permissions, unauthorized access, key leakage, and significant compliance risks.

[0010] Furthermore, the formula for calculating the sparse Merkle leaf node index in step S5 is i=H(C_j)mod2^d, where d is the preset tree depth, and the legal rules include a legal basis whitelist, maximum revocation period, and data retention strategy.

[0011] Furthermore, the private witness described in step S6 includes a verifiable credential C_j, a Merkel path, a state triple, a digest of the revocation-type legal authentication A_j', and a judicial threshold signature. The public inputs include the revocation Merkel root Root_rev^J corresponding to the jurisdiction, a set of judicial public keys, and threshold parameters.

[0012] Another technical problem solved by the present invention is to provide a decentralized identity lifecycle management device for cross-jurisdictional mutual trust in accordance with any of the above claims, including an identity and credential management module, a legal authentication module, a multi-party consensus and signature verification module, a blockchain deregistration module, a cross-jurisdictional rule management module, and a privacy protection verification module; The identity and credential management module is used to generate, store and update the real-name DID of case handlers, manage the mapping relationship between the real-name DID of case handlers and entities, and generate and bind verifiable credential C_j based on the judicial authentication results; The legal authentication module includes a judicial identity docking unit, a legal proof generation unit, and a legal signature unit, which are used to obtain a judicial authorization token, generate legal authentication A_j and revocation-type legal authentication A_j', and perform judicial threshold signature. The multi-party consensus and signature verification module includes a holder signature collection unit, a judicial signature collection unit, and a threshold aggregation verification unit, which are used to implement k-of-n threshold signature control and verification. The blockchain revocation registration module includes an index calculation unit, a state update unit, a domain root maintenance unit, and a transaction metadata recording unit, which are used to maintain the on-chain revocation status. The cross-jurisdictional rule management module includes a rule storage unit, a rule loading and matching unit, and an optional conflict handling unit, used to store and execute revocation and data retention rules for each jurisdiction; The privacy protection verification module includes a proof circuit construction unit, a proof generation unit, and a proof verification unit, and implements zero-knowledge verification based on zk-SNARKs circuits.

[0013] Furthermore, it also includes hardware and software. The hardware includes servers and hardware security modules for judicial key escrow, while the software includes contract components, middleware, and application programming interfaces and event subscription interfaces for issuers, verifiers, and auditors.

[0014] Furthermore, the zk-SNARKs circuit of the privacy protection verification module constrains the correctness of the Merkel path, the revocation status being true, and the validity of the judicial threshold signature.

[0015] Compared with the prior art, the technical solution of this application has the following beneficial effects: 1. This invention does not use a centralized revocation list. Instead, it utilizes the distributed nature of blockchain and sparse Merkle tree storage to ensure that the revocation status is globally verifiable and tamper-proof, thus avoiding trust rollback due to a single node failure. 2. This invention binds the signature of the judicial entity, legal basis, and jurisdiction information through a judicial authentication engine, enabling on-chain revocation actions to obtain legally enforceable offline authentication, which complies with regulations such as GDPR. 3. This invention encodes compliance rules for each jurisdiction on the blockchain, automatically verifies the legality and timeliness of revocation actions, and can handle rule differences between different jurisdictions without human intervention, thus improving the efficiency of cross-jurisdictional collaboration; 4. This invention adopts a signature method with thresholds for both the holder and the judiciary, and key operations require joint authorization from both parties, which can avoid unilateral operations; 5. This invention utilizes zero-knowledge proof technology, allowing the verifier to know only the truth value of the revocation status without needing to obtain sensitive information such as credential identifiers and legal details, thus balancing regulatory compliance with minimal disclosure. 6. This invention uses a sparse Merkle tree, which supports O(logn) efficient updates and batch processing. Compared with traditional list-based solutions, it reduces storage overhead and operation latency on the blockchain, making it suitable for high-frequency use in judicial scenarios. 7. This invention adopts a complete lifecycle covering identity registration, credential issuance, revocation to cleanup, and achieves accurate traceability and responsibility determination of operational behavior by linking blockchain logs with business logs. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the LSRR three-layer hybrid structure of the present invention, which consists of a "credential layer - legal layer - blockchain layer". Figure 2 This is a graph comparing the time overhead of different undo batches according to the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Please see Figure 1-2 The decentralized identity lifecycle management method for cross-domain judicial trust in this embodiment includes the following specific steps: S1: Identity Registration and Cross-Domain Trust Establishment: First, create identity identifiers and public keys for judicial entities and record them on the blockchain. Configure legal domain identifiers and legal roles, register the real-name DIDs of case handlers, bind attributes and generate basic credentials. Configure cross-domain trust information for each participating domain, form cross-domain trust entries and write them to the blockchain. Judicial entities include courts, procuratorates and public security organs. The real-name DIDs of case handlers are bound to police numbers, affiliated institutions and terminal device attributes. Cross-domain trust entries include source domain ID, target domain ID, trust level, validity period, public key and digital signature. S2: Credential Issuance and Business Context Binding: When the business system triggers a credential issuance request, it sends the issuance context to the legal authentication engine. The legal authentication engine obtains the judicial authorization token based on the OAuth2.0 / JWT protocol, generates a legal authentication A_j with a judicial threshold signature, generates a verifiable credential C_j and binds it to the legal authentication A_j. After being authenticated by the holder, the credential is issued. The issuance context includes the case number, the real name DID of the case handler, the description of the target resource, the applicable legal domain and the expected validity period. The legal authentication A_j includes the court identifier, the applicable legal domain, the legal basis clause, the revocation conditions and time limit information. S3: Normal use of credentials and cross-domain access: The holder initiates an authentication, access or delegation request based on the verifiable credential C_j. The multi-signature verifier performs threshold verification on the multi-party signatures and checks the cross-domain trust entries on the blockchain. Only credentials are allowed to be used under valid trust relationships. S4: Revocation Trigger and Legal Authentication Update: Identify revocation trigger conditions, generate a revocation business request R_j with a digital signature and submit it to the legal authentication engine. The legal authentication engine re-obtains judicial authorization, generates a revocation-type legal authentication A_j' and maintains the version association with legal authentication A_j. Among them, revocation trigger conditions include identity status change to REVOKED / LOCKED, case closure, permission expiration, unauthorized access, key leakage and major compliance risks. S5: On-chain Revocation Registration and Status Update: The revocation smart contract calculates the sparse Merkle tree leaf node index corresponding to the verifiable credential C_j, constructs the leaf node content containing the revocation status, H(A_j'), and nonce, loads the corresponding jurisdiction rules and verifies compliance. After passing the verification, the Merkle tree and jurisdiction root are updated, and transaction metadata is recorded. The sparse Merkle tree leaf node index is calculated using the formula i=H(C_j)mod2^d, where d is the preset tree depth. The jurisdiction rules include the legal basis whitelist, the maximum revocation period, and the data retention strategy. S6: Post-revocation verification and zero-knowledge proof output: A third-party verifier initiates a zero-knowledge proof request. The proof generator inputs the private witness into the zk-SNARKs circuit to generate a zero-knowledge proof. The verifier verifies the proof based on the public input and outputs the truth value of the revocation state without disclosing sensitive information. The private witness includes the verifiable credential C_j, Merkel path, state triplet, digest of revocation-type legal authentication A_j', and judicial threshold signature. The public input includes the revocation Merkel root Root_rev^J corresponding to the jurisdiction, the judicial public key set, and threshold parameters. S7: Expiration Cleanup and Audit Tracking: Revoking smart contracts prunes expiration and revocation records in batches according to the rules of the jurisdiction, and the regulatory platform associates blockchain transactions and business logs to replay the identity lifecycle, achieving regulatory oversight and accountability.

[0019] Another technical problem solved by the present invention is to provide a decentralized identity lifecycle management device based on the above-mentioned cross-jurisdictional mutual trust, including an identity and credential management module, a legal authentication module, a multi-party consensus and signature verification module, a blockchain revocation registration module, a cross-jurisdictional rule management module and a privacy protection verification module, a server and a hardware security module for judicial key custody, contract components, middleware and application programming interfaces and event subscription interfaces for issuers, verifiers and auditors; The identity and credential management module is used to generate, store and update the real-name DIDs of case handlers, manage the mapping relationship between the real-name DIDs of case handlers and entities, and generate and bind verifiable credentials C_j based on the judicial authentication results; The legal authentication module includes a judicial identity docking unit, a legal proof generation unit, and a legal signature unit, which are used to obtain a judicial authorization token, generate legal authentication A_j and revocation-type legal authentication A_j', and perform judicial threshold signature. The multi-party consensus and signature verification module includes a holder signature collection unit, a judicial signature collection unit, and a threshold aggregation verification unit, which are used to implement k-of-n threshold signature control and verification. The blockchain revocation registration module includes an index calculation unit, a state update unit, a domain root maintenance unit, and a transaction metadata recording unit, which are used to maintain the on-chain revocation status. The cross-jurisdictional rule management module includes a rule storage unit, a rule loading and matching unit, and an optional conflict handling unit, used to store and execute revocation and data retention rules for each jurisdiction; The privacy protection verification module includes a proof circuit construction unit, a proof generation unit, and a proof verification unit. It implements zero-knowledge verification based on zk-SNARKs circuits, and constrains the correctness of Merkel paths, the revocation status as true, and the validity of judicial threshold signatures.

[0020] The overall structure adopts a three-layer hybrid LSRR structure of "credential layer - legal layer - blockchain layer". Each layer interacts through standard interfaces and forms a closed-loop control with the regulatory platform.

[0021] (I) Overall hierarchical structure 1. Certificate Layer The credential layer is deployed within the judicial intranet and consists of various business systems used to support specific case handling and data access scenarios, mainly including: Identity Management System: Responsible for the real-name DID, status management, and basic credential generation of judicial entities and registered case handlers; The investigation and case-handling platform is responsible for business operations such as case claiming, initiating evidence collection requests, and writing evidence. Cross-domain mutual trust system: responsible for configuring and managing cross-domain trust relationships between source and target domains; Data storage and authorized access system: responsible for the secure storage and access authorization of evidence documents and business data.

[0022] The main responsibilities of the certificate layer are: During the identity registration phase, the establishment and maintenance of real-name DIDs for judicial entities and case-handling personnel are completed; During the case handling process, requests for the issuance and revocation of certificates are submitted to the legal department based on business needs; During the credential usage phase, authentication and access control logic is triggered based on the verifiable credential C_j. After receiving the credentials and revocation status returned by the legal and blockchain layers, update the local business status.

[0023] 1. Legal level The legal layer is deployed in the judicial private network, serving as a middleware layer between the business system and the blockchain, and mainly consists of the following modules: Legal authentication engine: Connects to court / regulatory IdP, obtains JWT carrying legal_attestation declaration according to the OAuth2.0 / JWT process described in the technical solution, and generates or updates the corresponding judicial legal authentication A_j and revocation legal authentication A_j'. Multisignature verifier: It generates and verifies multi-party threshold signatures such as holder signature and judicial signature, provides k-of-n threshold control, and can interface with cryptographic devices such as hardware security modules.

[0024] The legal layer interacts with the credential layer and the blockchain layer through standard APIs, and its main responsibilities are: Receive requests for the issuance and revocation of credentials initiated by investigation and case-handling platforms, identity management systems, etc. Map the business context to legally valid legal authentication A_j and revocation-type legal authentication A_j'; After multisignature verification, the state change associated with the verifiable credential C_j is submitted to the blockchain layer for on-chain registration.

[0025] 1. Blockchain Layer The blockchain layer runs on consortium blockchains or private network blockchain nodes and mainly consists of revocable smart contracts and their associated state and rule modules: Revocation smart contract: Maintain a sparse Merkle tree of revocation status on the chain, divided by legal jurisdiction, record the revocation status of verifiable certificate C_j and its binding relationship with revocation-type legal certification A_j', and provide operation interfaces such as revocation registration, status query and expiration cleanup; Sparse Merkle tree state storage module: As the underlying state structure for revoking smart contracts, it locates leaf nodes according to i=H(C_j)mod2^d and maintains the triple (status,H(A_j'),nonce), while maintaining the revocation tree root Root_rev^J corresponding to each domain J; Cross-jurisdictional rule management module: Maintains on-chain rules such as the whitelist of legal basis, the upper limit of revocation time limit, and data retention and cleanup strategies for each jurisdiction J, so that revocation smart contracts can perform compliance verification when executing revocation registration and expiration cleanup; Zero-knowledge proof and verification module: Based on on-chain state and public parameters, it generates or verifies zero-knowledge proofs of the revocation status of a certain credential C_j, and outputs verification results such as "revoked / not revoked" without disclosing the plaintext identifier and legal text content of the credential.

[0026] The blockchain layer exposes transaction records and status change information to the regulatory platform through node or observer node interfaces, providing a data foundation for auditing and accountability.

[0027] (II) Module Connection Relationship 1. The connection between the evidentiary layer and the legal layer After completing the registration of real-name DIDs for judicial entities and case-handling personnel, the identity management system writes the relevant identifiers and attributes into the blockchain or judicial intranet directory, and provides the basic credential information to business systems such as the investigation and case-handling platform. In scenarios such as case claiming, cross-domain evidence collection, or delegation of authority, the investigation and case handling platform and the cross-domain mutual trust system initiate a credential issuance request to the legal authentication engine, and initiate a revocation request R_j to the legal authentication engine when it is necessary to terminate or restrict the use of the credential; When the data storage and authorized access system performs access control based on verifiable credential C_j, it verifies the multi-party threshold signature results of the holder's signature and judicial signature through a multi-signature verifier to ensure that critical operations are jointly authorized by both parties.

[0028] 1. Connection between the legal layer and the blockchain layer After completing the generation or update of legal certification, the legal certification engine calls the revocation smart contract through the blockchain client to submit a request to revoke registration or update status, and binds H(A_j) or H(A_j') with the corresponding verifiable credential C_j and writes it on the chain; After completing the multi-signature verification, the multi-signature verifier passes the verification result as a parameter to the revocation smart contract client to control whether sensitive operations such as revocation registration can be implemented on the blockchain. When the legal authentication engine needs to query the status of credential revocation or obtain zero-knowledge proofs, it obtains the Merkel path and verification results by calling the revocation smart contract and zero-knowledge proof module, and then sends the results back to the credential layer business system.

[0029] 1. Connection between the blockchain layer and the regulatory platform The regulatory platform obtains transaction and event logs related to identity registration, credential issuance, cross-domain access, registration revocation, and status verification by accessing read-only or observation nodes on the blockchain. The regulatory platform combines the operation logs generated by the business system to replay and analyze the entire identity lifecycle, enabling auditing and accountability tracking of when and on what legal basis each entity performs what operations in various jurisdictions.

[0030] (III) Correspondence between system architecture and methodological steps The identity management system, investigation and case-handling platform, cross-domain mutual trust system, and data storage and authorized access system in the credential layer work together to realize the relevant steps of "identity registration and cross-domain trust" and "credential issuance and use" in the technical solution and key processes; The legal authentication engine and multi-signature verifier module in the legal layer realize legal authentication and threshold multi-signature control for the issuance and revocation of credentials, corresponding to key steps such as "judicial authentication acquisition, legal proof generation and multi-signature consensus". The blockchain layer includes a revocation smart contract module, a sparse Merkle tree state module, a JurisdictionRules module, and a zero-knowledge proof module, which implement steps such as "on-chain revocation registration and state maintenance", "post-revocation verification and zero-knowledge proof", and "expiration cleanup and audit tracking". The regulatory platform conducts unified audits of the above steps based on blockchain and business logs, thereby providing closed-loop support at the system level for the decentralized identity lifecycle management method proposed in this invention.

[0031] Example 1 1. Hardware Deployment The system uses a server as the deployment platform, and configures a hardware security module to host judicial threshold keys, ensuring the security of key storage and use. Cluster nodes are distributed across the judicial private network and cross-domain trust domains, and data transmission is achieved through encrypted communication protocols.

[0032] 2. Software Implementation Contract Components: Deploy revocation smart contracts and jurisdiction rule management contracts, providing batch update, pruning and status query interfaces. Contract update overhead is approximately 142kgas / time, and status verification is approximately 28kgas / time. Middleware: Deploys legal authentication module and multi-party consensus and signature verification module services, supports k-of-n threshold signature and batch submission, and the legal authentication module connects to the judicial IdP based on OAuth2.0 / JWT protocol; Interface layer: Provides RESTful APIs and event subscription mechanisms for issuers, verifiers, and auditors, supporting rapid integration of business systems.

[0033] 3. Process Execution (1) Identity registration The judicial administrator creates a DID and public key for a court through the identity management system, records it on the consortium blockchain, configures the jurisdiction identifier J1 and the "issuing authority" role, registers a real-name DID for the judge, binds the police number "XXXXXXX", the court to which the judge belongs and office terminal information, generates basic credentials and registers them on the blockchain. The public security domain and the court domain configure trust entries through the cross-domain mutual trust system, including the public keys of both parties, the trust level "Level 1" and the validity period of 1 year, and writes them into the blockchain.

[0034] (2) Issuance of vouchers After a judge claims a case on the investigation and case handling platform, they initiate a cross-domain evidence collection request. The platform sends information such as the case number "YYYYYY", the applicant's DID, the target resource "the flow of funds involved in the case", and the applicable jurisdiction J1 to the legal authentication module. The legal authentication module initiates OAuth2.0 authorization to the court's IdP, obtains a JWT containing a legal_attestation statement, extracts the legal basis "Article 54 of the ZZZZZZ", generates a legal authentication A_j through a 3-of-5 judicial threshold signature, and generates a verifiable credential C_j in VC format and binds it to the legal authentication A_j. After the judge completes fingerprint authentication, the verifiable credential C_j is issued to their identity wallet.

[0035] (3) Use of vouchers The judge initiates a data access request to the bank domain based on the verifiable credential C_j. The multi-party consensus and signature verification module verifies the judge's signature against the judicial threshold signature, and at the same time checks the validity of the trust entries in the on-chain public security domain and bank domain, allowing the access request to be executed.

[0036] (4) Revocation of trigger and authentication update After the case is closed, the investigation and case handling platform triggers the revocation conditions, generates a revocation business request R_j containing the platform's digital signature, specifies the verifiable credential C_j, the revocation reason "case closed", and the applicable legal domain J1. The legal authentication module re-obtains authorization from the court's IdP, generates a revocation-type legal authentication A_j' and associates it with legal authentication A_j, and records the version mapping relationship.

[0037] (5) On-chain deregistration The leaf node index i = H(C_j) mod 2^20 of the verifiable credential C_j is calculated to revoke the smart contract. The leaf node content (1, H(A_j'), nonce=5) is constructed. The rule set of J1 is loaded, and the legal basis of the revocation-type legal authentication A_j' is verified to be within the whitelist and compliant with the time limit. The sparse Merkle tree is updated, and a new corresponding revocation Merkle root Root_rev^J1 is generated. The transaction hash, timestamp, and triggering party identifier are recorded.

[0038] (6) Zero-knowledge proof verification The bank domain needs to verify the state of the verifiable credential C_j and initiates a zero-knowledge proof request. The proof generator obtains the Merkel path and state triple from the blockchain, combines it with the digest of the revocation-type legal authentication A_j' and the judicial signature as private witnesses, and uses the corresponding revocation Merkel root Root_rev^J1 and the judicial public key set as public inputs to generate a zero-knowledge proof. The bank domain verifies the proof through a verification algorithm to confirm that the verifiable credential C_j has been revoked and no sensitive information has been obtained.

[0039] (7) Due date clearance and audit Three months later, the revocation smart contract was pruned according to Rule J1, retaining only the summary information; the regulatory platform traced back to "the court revoked the verifiable credential C_j on May 20, 2024, based on Article 54 of the ZZZZZZ" through the blockchain logs and the case handling platform logs, thus completing the audit trail.

[0040] 4. Performance Indicators Single cancellation end-to-end delay: ≤1s; Batch cancellation of 100 items took approximately 12.3 seconds. zk-SNARKs verification overhead: off-chain generation ≈ 4.8s, on-chain verification ≈ 1.2s; The above metrics can be adjusted according to chain parameters and deployment scale, significantly improving efficiency compared to traditional list-based registry entries.

[0041] The working principle of the above embodiments is as follows: 1. This invention does not use a centralized revocation list. Instead, it utilizes the distributed nature of blockchain and sparse Merkle tree storage to ensure that the revocation status is globally verifiable and tamper-proof, thus avoiding trust rollback due to a single node failure. 2. This invention binds the signature of the judicial entity, legal basis, and jurisdiction information through a judicial authentication engine, enabling on-chain revocation actions to obtain legally enforceable offline authentication, which complies with regulations such as GDPR. 3. This invention encodes compliance rules for each jurisdiction on the blockchain, automatically verifies the legality and timeliness of revocation actions, and can handle rule differences between different jurisdictions without human intervention, thus improving the efficiency of cross-jurisdictional collaboration; 4. This invention adopts a signature method with thresholds for both the holder and the judiciary, and key operations require joint authorization from both parties, which can avoid unilateral operations; 5. This invention utilizes zero-knowledge proof technology, allowing the verifier to know only the truth value of the revocation status without needing to obtain sensitive information such as credential identifiers and legal details, thus balancing regulatory compliance with minimal disclosure. 6. This invention uses a sparse Merkle tree, which supports O(logn) efficient updates and batch processing. Compared with traditional list-based solutions, it reduces storage overhead and operation latency on the blockchain, making it suitable for high-frequency use in judicial scenarios. 7. This invention adopts a complete lifecycle covering identity registration, credential issuance, revocation to cleanup, and achieves accurate traceability and responsibility determination of operational behavior by linking blockchain logs with business logs.

[0042] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0043] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A decentralized identity lifecycle management method for cross-jurisdictional mutual trust, characterized in that, The specific steps include the following: S1: Identity Registration and Cross-Domain Trust Establishment: First, create identity identifiers and public keys for judicial entities and record them on the blockchain. Configure domain identifiers and legal roles, register the real-name DIDs of case handlers, bind attributes and generate basic credentials. Configure cross-domain trust information for each participating domain, form cross-domain trust entries and write them to the blockchain. S2: Credential Issuance and Business Context Binding: When the business system triggers a credential issuance request, it sends the issuance context to the legal authentication engine. The legal authentication engine obtains the judicial authorization token based on the OAuth2.0 / JWT protocol, generates a legal authentication A_j with a judicial threshold signature, generates a verifiable credential C_j and binds it to the legal authentication A_j, and issues it after being authenticated by the holder. S3: Normal use of credentials and cross-domain access: The holder initiates an authentication, access or delegation request based on the verifiable credential C_j. The multi-signature verifier verifies the holder's signature and judicial signature, and combined with the cross-domain trust entry check on the blockchain, the credential is only allowed to be used under a valid trust relationship. S4: Revocation Trigger and Legal Authentication Update: Identify the revocation trigger conditions, generate a revocation business request R_j with a digital signature and submit it to the legal authentication engine. The legal authentication engine re-obtains judicial authorization, generates a revocation-type legal authentication A_j' and maintains the version association with legal authentication A_j. S5: On-chain deregistration and status update: The deregistration smart contract calculates the sparse Merkle tree leaf node index corresponding to the verifiable certificate C_j, constructs the leaf node content containing the deregistration status, H(A_j'), and nonce, loads the corresponding legal domain rules and verifies compliance. After passing the verification, the Merkle tree and legal domain root are updated, and transaction metadata is recorded; H(A_j') represents the hash digest of the deregistration-type legal certification A_j'. S6: Post-revocation verification and zero-knowledge proof output: A third-party verifier initiates a zero-knowledge proof request. The proof generation end inputs the private witness into the zk-SNARKs circuit to generate a zero-knowledge proof. The verifier verifies the proof based on the public input and outputs the truth value of the revocation state without disclosing sensitive information. The private witness includes a verifiable credential C_j, a Merkel path, a state triple, a digest of the revocation-type legal authentication A_j', and a judicial threshold signature; the public input includes the revocation Merkel root Root_rev^J corresponding to the jurisdiction, a set of judicial public keys, and threshold parameters; the state triple is status,H(A_j') and nonce; S7: Expiration Cleanup and Audit Tracking: Revoking smart contracts prunes expiration and revocation records in batches according to the rules of the jurisdiction, and the regulatory platform associates blockchain transactions and business logs to replay the identity lifecycle, achieving regulatory oversight and accountability.

2. The decentralized identity lifecycle management method for cross-jurisdictional mutual trust as described in claim 1, characterized in that, The judicial entities mentioned in step S1 include courts, procuratorates, and public security organs. The case handlers' real-name DIDs are bound to their police numbers, affiliated institutions, and terminal device attributes. The cross-domain trust entries include source domain ID, target domain ID, trust level, validity period, public key, and digital signature.

3. The decentralized identity lifecycle management method for cross-jurisdictional mutual trust as described in claim 1, characterized in that, The issuance context mentioned in step S2 includes the case number, the real name (DID) of the case handler, the description of the target resource, the applicable legal domain and the expected validity period. The legal authentication A_j includes the court identifier, the applicable legal domain, the legal basis clause, the revocation conditions and the time limit information.

4. The decentralized identity lifecycle management method for cross-jurisdictional mutual trust as described in claim 1, characterized in that, The revocation triggering conditions mentioned in step S4 include changes in identity status to REVOKED / LOCKED, case closure, expiration of permissions, unauthorized access, key leakage, and significant compliance risks.

5. The decentralized identity lifecycle management method for cross-jurisdictional mutual trust as described in claim 1, characterized in that, The formula for calculating the sparse Merkle leaf node index in step S5 is i=H(C_j)mod2^d, where d is the preset tree depth, and the domain rules include the legal basis whitelist, the maximum revocation period, and the data retention strategy.

6. A decentralized identity lifecycle management device for cross-jurisdictional trust, implementing the decentralized identity lifecycle management method for cross-jurisdictional trust as described in any one of claims 1-5, characterized in that, It includes modules for identity and credentials management, legal authentication, multi-party consensus and signature verification, blockchain deregistration, cross-jurisdictional rules management, and privacy protection verification. The identity and credential management module is used to generate, store and update the real-name DID of case handlers, manage the mapping relationship between the real-name DID of case handlers and entities, and generate and bind verifiable credential C_j based on the judicial authentication results; The legal authentication module includes a judicial identity docking unit, a legal proof generation unit, and a legal signature unit, which are used to obtain a judicial authorization token, generate legal authentication A_j and revocation-type legal authentication A_j', and perform judicial threshold signature. The multi-party consensus and signature verification module includes a holder signature collection unit, a judicial signature collection unit, and a threshold aggregation verification unit, which are used to implement k-of-n threshold signature control and verification. The blockchain revocation registration module includes an index calculation unit, a state update unit, a domain root maintenance unit, and a transaction metadata recording unit, which are used to maintain the on-chain revocation status. The cross-jurisdictional rule management module includes a rule storage unit, a rule loading and matching unit, and an optional conflict handling unit, used to store and execute revocation and data retention rules for each jurisdiction; The privacy protection verification module includes a proof circuit construction unit, a proof generation unit, and a proof verification unit, and implements zero-knowledge verification based on zk-SNARKs circuits.

7. The decentralized identity lifecycle management device for cross-jurisdictional mutual trust as described in claim 6, characterized in that, It also includes hardware and software. The hardware includes servers and hardware security modules for judicial key escrow, while the software includes contract components, middleware, and application programming interfaces and event subscription interfaces for issuers, verifiers, and auditors.

8. The decentralized identity lifecycle management device for cross-jurisdictional mutual trust as described in claim 6, characterized in that, The privacy protection verification module's zk-SNARKs circuit constrains the correctness of the Merkel path, the revocation status being true, and the validity of the judicial threshold signature.

Images