An integrated method and system for identification coding and data ownership registration

Abstract

The application discloses an integrated method and system for identification coding and data right ownership registration and belongs to the technical field of data identification and data right ownership management. The method comprises the following steps: receiving a registration request containing metadata information and a right ownership subject DID; synchronously performing identification coding generation and DRC right ownership registration record generation in the same atomic operation, and the two sub-steps are jointly submitted or jointly rolled back within the same transaction boundary, so that the identification and the right ownership are simultaneously generated and cannot be separated, a Saga compensation transaction protocol is adopted in a cross-system scenario, and each identification system is provided with a differentiated compensation strategy; right confirmation and authorization mechanisms based on public key encryption are adopted to generate right confirmation credentials, a digital envelope mechanism is adopted to process large-volume data; and a binding result is output. The application eliminates the time window risk between identification allocation and right ownership registration, realizes structural binding of the identification and the right ownership, in-encryption authorization protection, concurrent conflict defense and deterministic audit traceability, supports multi-identification system adaptation, derivative identification version linkage and cross-domain interoperation, and fundamentally solves the security risks such as inconsistency, suspended right ownership and identification forgery caused by separation of the identification and the right ownership.

Description

Technical Field

[0001] This invention relates to the field of data identification and data ownership management technology, and in particular to an integrated method and system for identification coding and data ownership registration. Background Technology

[0002] With the deepening development of the digital economy, data has become a key production factor. Data identification coding assigns a unique and resolvable digital identity to data resources, while data ownership registration establishes ownership relationships for data resources; both are fundamental components of the data governance system. However, in current mainstream technical solutions, identification coding allocation and ownership registration are always performed as two independent operations, resulting in a logical disconnect between identification and ownership. This leads to security risks such as unsecured ownership, misuse of identification, and distortion of data transfer.

[0003] Specifically, the existing technology has the following shortcomings: Chinese patent CN120151322A (Inspur Cloud) discloses a method for sharing industrial internet data. This method first assigns an identification code to the data, and then stores the ownership information as append records through a distributed ledger. This scheme has two fundamental flaws: First, identification assignment and ownership recording are two separate operations, and there is an inescapable time window between the two steps, during which the identification code may be tampered with or misused before the ownership record is written; second, ownership binding relies on distributed consensus as a trusted third party, introducing additional consensus latency and system complexity.

[0004] The European frameworks IDSA (International Data Spaces), Gaia-X, and Catena-X employ an architecture where identifiers and ownership are operated independently. Identifier allocation is handled by a metadata management component, while ownership claims are bound at runtime via data contracts or a policy engine. IDSA's data contract mechanism includes a relatively complex policy engine that supports constraints on data flow using UsageControl policies; however, its identifier allocation and ownership claims are decoupled in the time dimension. Even if the policy engine is configured correctly, a logical gap still exists between the two operations, and the identifier may be parsed and obtain unauthorized data location before the ownership claim takes effect. This runtime policy binding method carries the risk of ownership loss due to policy configuration errors, and the association between identifiers and ownership is a loosely coupled logical association rather than a structural binding.

[0005] The Handle System disclosed in US Patent 6,978,366 is a widely deployed identifier resolution system, but it only focuses on the allocation and resolution of identifiers and has no concept of ownership. Handle records can store values ​​of any type, but lack structural constraints and cryptographic protection for ownership information.

[0006] The combination of the W3C Decentralized Identifier (DID) specification and Verifiable Credential (VC) is currently the mainstream solution for decentralized identity management. Its design goal is decentralized identity management, rather than the atomic binding of identifier encoding and ownership registration. The generation of DID and the issuance of VC are independent operations performed by different components at different times. Although the DID+VC combination can indirectly achieve ownership declaration in some scenarios, it is not designed to address the technical problem of atomicity between identifier encoding and ownership registration, and the binding between the two lacks atomicity guarantees.

[0007] SparkChain's BID (Blockchain-based Identifier) ​​system supports a self-registration mechanism, but self-registration only generates an identifier code, while ownership registration requires independent subsequent operations, which also presents the problem of separation between identifier and ownership.

[0008] The inventor's prior Chinese invention patent ZL201710800793.9 (US patent family US 11,438,157 B2) \u201c Data Ownership Confirmation Method and System Based on Encryption \u201d proposed a data ownership confirmation system based on PKI encryption, realizing the basic mechanism for data ownership confirmation and authorization protection. However, in this patent, identifier allocation and ownership registration are still two separable operations. The generation of identifier codes and the registration of ownership records are not completed in the same atomic operation. When partial failure or concurrent competition occurs between the two operations, an inconsistent state may occur where the identifier has been generated but the ownership has not been registered.

[0009] In summary, there is currently no publicly available patent or standard solution that simultaneously achieves atomic integration of identifier encoding generation and ownership registration, which is precisely the core technical problem that this invention aims to solve. Summary of the Invention

[0010] The technical problem to be solved by the present invention is that in the prior art, the allocation of identification codes and the registration of ownership are two independent operations, and there is a time window between the two, which leads to security risks such as inconsistency between identification and ownership, ownership being suspended or identification being misused; and the continuity of ownership relationship cannot be guaranteed when transferring across identification systems.

[0011] To address the aforementioned technical problems, this invention provides an integrated method and system for identification encoding and data ownership registration.

[0012] An integrated method for identification coding and data ownership registration includes the following steps: Step S1: Receive a data registration request. The registration request is triggered by the same registration request and includes metadata information of the data to be registered and the distributed identity identifier (DID) of the ownership subject. Step S2, the following sub-steps are executed in the same atomic operation: Sub-step S2a, generating an identifier code based on the metadata information; Sub-step S2b, generating an ownership registration record corresponding to the identifier code in the Data Registry (DRC); Sub-step S2a and Sub-step S2b are executed within the same transaction boundary. If either sub-step fails, both sub-steps are rolled back together to ensure that the identifier code and the ownership registration record are generated simultaneously and are indivisible. Step S3: Output the binding result of the identifier code and the ownership registration record.

[0013] Furthermore, after the successful execution of step S2, the following joint signature step S2' can also be executed: Based on the public-key cryptographic rights confirmation and authorization mechanism, the private key of the rights holder is used to sign the joint hash value of the identifier code and the rights registration record to generate a rights confirmation certificate; the rights confirmation certificate binds the data ownership with the asymmetric key pair of the rights holder, forming a rights confirmation mechanism where the private key proves ownership and the public key verifies ownership in the signature direction, and any third party holding the public key of the rights holder can verify the data ownership; at the same time, the rights holder can use the public key of the authorized object to log in to the data... According to the encryption implementation technology authorization, an authorization mechanism is formed in the direction of encryption: public key encryption authorization and private key decryption use. The encrypted data can flow freely through any channel, and only authorized objects holding the corresponding private key can use it, realizing "rights follow data". The confirmation certificate carries the identification code, ownership registration record hash value and registration timestamp in the form of extended fields on the identity certificate issued by the identity provider. The confirmation certificate is stored after the signature validity is verified by DRC. When step S2' is executed, step S3 outputs the confirmation certificate accordingly.

[0014] Furthermore, for data exceeding a preset threshold, a digital envelope mechanism is employed to improve encryption efficiency: a randomly generated symmetric key CEK is used to encrypt the data body using the AES or SM4 algorithm, and then the public key of the authorized object is used as KEK to encrypt the CEK using the RSA or SM2 algorithm. The encrypted data body and the encrypted CEK are combined into a digital envelope, and only the authorized object holding the corresponding private key can decrypt the KEK to obtain the CEK and then decrypt the data body.

[0015] Furthermore, the identification code carries the ownership subject identity information in one of the following ways: (1) directly embedded in the coding structure, using the hash digest of the ownership subject's DID as a component field of the coding structure; (2) as an extension field of the identification system, adding an ownership identification extension field to the identification record; (3) as a metadata field of the identification system, associating the ownership subject information in the identification metadata; (4) as an external reference field of the identification code, associating it with the ownership registration record through a reference pointer. The above four carrying methods are selected according to the field specifications of the identification system. When the identification system supports the embedding of the coding structure, method (1) is preferred. When there are limitations on the field length or format of the identification system, methods (2) to (4) are used.

[0016] Furthermore, the ownership certificate is a PKI digital certificate extension format, and the ownership certificate contains the identification code, the DID of the ownership subject, the hash value of the ownership registration record, and the registration timestamp; the signing subject of the ownership certificate is the ownership subject itself, the CA is responsible for issuing the ownership subject's identity certificate, and the DRC is responsible for verifying the validity of the signature of the ownership certificate and storing it as evidence, with the three roles separated.

[0017] Furthermore, in step S2a, when generating the identifier code, the one-code-two-record atomic operation is adapted to multiple identifier systems through an identifier system adapter. The identifier system includes at least one of the Handle system, the Spark Identifier BID system, and the OID system. The identifier system adapter includes a mapping table, field conversion rules, and conflict handling rules. The mapping table defines the field name and field format of the ownership identifier field in each identifier system. The field conversion rules define the encoding conversion method from DID hash digest to the target identifier system field value. The conflict handling rules define the overwrite, append, or error reporting strategy when the target identifier system field already has a value.

[0018] Furthermore, when the ownership of the subject changes, the atomic operation of step S2 is re-executed to generate a derived identifier and a new ownership registration record. The derived identifier contains a reference relationship to the original identifier code. The original identifier code is retained as a historical version and can still be verified. At the same time, a change association relationship between the new ownership record and the old ownership record is established in the DRC. The change association relationship includes the original identifier code, the derived identifier, the change time, and the change reason, thereby realizing ownership version linkage.

[0019] Furthermore, when data flows from the first identification system to the second identification system, the atomic operation of step S2 is re-executed in the second identification system to generate an identification code and ownership registration record in the second identification system. At the same time, a cross-domain mapping relationship is established in the DRC between the ownership records in the first and second identification systems. The cross-domain mapping relationship includes the source identification system identifier, the source identification code, the target identification system identifier, the target identification code, the mapping signature signed by the PKI private key, and the ownership inheritance declaration. Before establishing the cross-domain mapping, the validity of the ownership certificate signature in the source identification system is verified. After confirming the legality of the source ownership, the atomic registration is re-executed in the target identification system, and the new ownership record and mapping relationship are PKI signed. When there are conflicting ownership declarations for the same data between the two identification systems, the ownership record registered first in the source identification system shall prevail.

[0020] Furthermore, the atomic operations within the same transaction boundary in step S2 are implemented in one of the following ways: when the identifier encoding generation and DRC ownership registration are executed in the same local database, a local database transaction is used; when the identifier encoding generation and DRC ownership registration involve different systems, a compensation transaction protocol based on the Saga pattern is used. The Saga pattern splits the atomic operation into a set of ordered sub-transactions, each sub-transaction is equipped with a corresponding compensation operation, and when any sub-transaction fails, the compensation operations of the completed sub-transactions are executed in reverse order to roll back to a consistent state.

[0021] An integrated system for identifier encoding and data ownership registration includes: a registration request receiving module for receiving data registration requests; an atomic registration engine for performing identifier encoding generation and DRC ownership registration record generation in the same atomic operation, wherein the atomic registration engine contains a transaction coordinator responsible for maintaining transaction state, scheduling local database transactions when deployed locally, orchestrating Saga sub-transaction sequences and coordinating compensation operations when deployed across systems, and detecting and rejecting duplicate registration requests in concurrent scenarios through a version number optimistic locking mechanism; an identifier system adapter for adapting the atomic operations of the atomic registration engine to multiple identifier systems, wherein the identifier system adapter includes a mapping table, field conversion rules, and conflict handling rules, and each adapter interacts with the atomic registration engine through a unified interface; a PKI ownership confirmation and signature module for generating ownership confirmation credentials by joint signature using the ownership subject's PKI private key; and a binding result output module for outputting binding results.

[0022] Terminology Definition The terms used in this specification are defined as follows: Dual-code recording: refers to the simultaneous generation of the identifier code and the ownership registration record in the data registration center within the same atomic operation triggered by the same registration request. The identifier code and the ownership registration record are either successfully generated at the same time or fail to be generated at the same time, and an integrated ownership certificate is formed through joint signature.

[0023] DRC (Data Registration Center): A distributed directory system used to store data ownership registration records. Each ownership registration record contains an identifier code, the ownership subject's DID, the registration time, and data classification and grading information. There is a one-to-one correspondence between ownership registration records and identifier codes.

[0024] DID (Decentralized Identifier): A unique digital identity registered in a DRC by the ownership entity, used to identify the natural or legal person to whom data ownership belongs. A DID contains its own public key information, establishing a binding relationship between identity and public key without third-party issuance. It serves as the identity foundation for PKI systems in decentralized or multi-entity peer-to-peer scenarios. In scenarios with centralized control, a CA (Certificate Authority) issues identity certificates, performing the same function. Both identity establishment methods serve public key encryption for authorization and confirmation mechanisms; the choice depends on the deployment scenario.

[0025] PKI (Public Key Infrastructure) is an asymmetric encryption-based system for establishing and authorizing ownership. It comprises two core directions: signature (private key signing proves ownership, public key verification confirms ownership) and encryption (public key encryption grants authorization, private key decryption grants usage rights). The combination of these two directions embeds ownership and authorization within cryptographic protection rather than relying on external access control, achieving "ownership follows the data." For large volumes of data, a digital envelope mechanism (symmetric key CEK encrypts data, asymmetric key KEK encrypts CEK) is used to balance efficiency and security.

[0026] Ownership identifier field: The field containing the identity information of the ownership subject embedded or associated with the identifier code. Its carrying methods include: directly embedded in the code structure, as an extended field of the identifier system, as a metadata field of the identifier system, or as an external reference field of the identifier code.

[0027] Derived Identifier: When ownership changes, a new version identifier is generated based on the original identifier code. The derived identifier retains the reference relationship with the original identifier code. The original identifier code is retained as a historical version and can still be verified. The derived identifier and the original identifier code together constitute the identifier version chain.

[0028] Cross-domain mapping: When data flows from the first identification system to the second identification system, the mapping relationship of ownership records between the source identification system and the target identification system established in DRC includes source identification code, target identification code, mapping time, mapping signature and ownership inheritance declaration.

[0029] Append-Hash Chain Log: An audit log structure in which each log entry contains the hash value of the previous entry and is signed by the logger’s PKI private key, forming an immutable chain of records. The append time complexity is O(1), and the verification time complexity is O(n).

[0030] Technical difficulties and creative demonstration

[0031] The inventiveness of this invention does not stem from the conventional approach of incorporating two operations into the same transaction, but rather from the specific technical difficulties overcome in the atomication process of identifier encoding and ownership registration, and the unexpected technical effects resulting therefrom. The specific arguments are as follows: Technical Challenge 1: Heterogeneous identifier systems make it difficult to unify transaction boundaries. Identifier code generation is handled by interfaces specific to the identifier system (such as the RPC interface of the Handle system and the REST interface of the BID system), while the write operation of ownership registration records is performed in DRC. These two operations belong to different technical systems, with different data models, interface protocols, and error semantics. Conventional database transactions can only guarantee the atomicity of operations within the same database and cannot cross the system boundary between the identifier system interface and the DRC database.

[0032] It is important to note that the adapter design of this invention differs fundamentally from general software adapter patterns (such as DAO pattern, Adapter design pattern, microservice gateway, etc.). General adapter patterns only handle the syntax-level conversion of interface protocols—converting one calling form to another, without altering the semantics of the encapsulated operation itself. However, the `\u201c undone\u201d` operation in the identifier encoding system has fundamentally different semantics from the `\u201c delete\u201d` operation in the database: once an identifier is assigned, it may already be cached or referenced by other systems. Simple deletion can cause parsing errors for those referencing the cached identifier. Therefore, `undone` in the identifier system typically requires semantically preserved operations such as `\u201c mark as invalid\u201d` or `\u201c record undone declaration\u201d`, rather than directly removing the record from storage. The fundamental difference between the revocation semantics and database deletion semantics necessitates that the adapter cannot simply perform interface syntax conversion; it must translate the revocation semantics specific to different identity systems into transaction compensation operations. This means the adapter needs to design differentiated compensation strategies based on different identity systems (e.g., compensation for invalidation flags in the Handle system, compensation for revocation declarations in the BID system, and compensation for deletion and logging in DRC). It must uniformly encapsulate the system-specific revocation operations into forward sub-transaction / compensation operation pairs, enabling the atomic registration engine's transaction coordinator to orchestrate cross-system operations using a unified protocol. The mapping tables, field conversion rules, and conflict handling rules in the adapter ensure the deterministic representation of ownership identifier fields across different identity systems, a prerequisite for achieving atomic operations across heterogeneous systems. Without the adapter's conversion of revocation-deletion semantic differences and encapsulation of transaction compensation operations, the transaction coordinator cannot incorporate identity system interfaces into a unified transaction boundary.

[0033] Technical Challenge Two: Compensation Logic Design for Cross-System Atomic Operations. The revocation of an identifier code is not a simple deletion as in general database operations—in the identifier resolution system, the assigned identifier code may already be cached or referenced by other systems, and simple deletion cannot guarantee the consistency of references. This invention designs differentiated compensation strategies for different identifier systems: the Handle system uses a compensation operation that marks the identifier as invalid instead of a deletion operation, causing it to return an "identity revoked" status during parsing, avoiding parsing errors for referencers that have cached the identifier; the BID system uses a "revocation declaration" method, writing the revocation information into the extended field of the BID record; DRC uses a "delete registration record and record revocation log" method. These differentiated compensation strategies ensure the semantic correctness of rollback operations in their respective systems, rather than simple data deletion.

[0034] Technical Challenge 3: Defense against Concurrent Registration Conflicts. In high-concurrency scenarios, the same data resource may trigger multiple registration requests simultaneously. Without a conflict prevention mechanism, the same data may generate multiple different identifier codes and ownership records. This invention adopts a version number-based optimistic locking mechanism: the DRC ownership registration record contains a globally unique fingerprint (metadata hash value) and version number of the data. The first registration version number for the same data is 1. When concurrent registration requests carry the same fingerprint, DRC rejects duplicate registrations through fingerprint uniqueness constraints. Only the first successfully submitted request takes effect, and subsequent requests return a "registered" status and an existing binding result, thereby avoiding inconsistencies caused by duplicate registrations.

[0035] Unexpected Technical Benefit 1: One-time Completion of Identifier Resolution and Ownership Verification. In existing technologies, identifier resolution and ownership verification are two separate query operations—first, data location information is obtained through identifier resolution, and then the ownership status is queried through the ownership registration system. This invention embeds an ownership identifier field into the identifier encoding, so the identifier resolution process itself contains ownership information. Data location and ownership status can be obtained simultaneously with a single resolution, merging the two queries into one. In pilot deployments of the Industrial Internet of Things (test conditions: single-node identifier resolution service, average daily resolution requests of 100,000, compared to the traditional architecture of separate identifier resolution and ownership query deployment), this reduces the query traffic of the identifier resolution service by approximately 40% (because the original request requiring a second query for ownership status is no longer needed), while also reducing the risk of inconsistency caused by status changes between the two queries.

[0036] Unexpected technical benefit two: Automatic and synchronized propagation of ownership changes. Because the identifier code and ownership registration record are bound in atomic operations, and the identifier code embeds an ownership identifier field, ownership changes only require triggering a new atomic registration operation. The generation of the derived identifier and the registration of the new ownership record are automatically synchronized, and the parsing result of the original identifier is automatically marked as a "historical version." This synchronized mechanism requires no additional message notifications or state synchronization mechanisms, greatly simplifying the operation and maintenance process for ownership changes. In traditional solutions, ownership changes require updating both the identifier metadata and the ownership declaration system separately, significantly increasing the risk of inconsistency and operational complexity.

[0037] Unexpected Technical Effect Three: Natural Coupling of the Audit Chain and Atomic Operations. Atomic operations ensure the simultaneous generation of identifiers and ownership rights, allowing the audit log to record only one operation to fully cover both dimensions. Each record in the audit chain naturally contains complete binding information: 'identifier code + ownership record'. In the traditional two-step operation scheme, the audit log needs to record two events separately: identifier allocation and ownership registration. The correlation between these two events requires an additional log association mechanism, increasing the complexity and error probability of the audit.

[0038] The present invention has the following advantages over the prior art: First, it eliminates the time window risk between identifiers and ownership. This invention synchronously completes identifier encoding generation and DRC ownership registration within the same atomic operation triggered by a single registration request. The two sub-steps are executed, jointly committed, or jointly rolled back within the same transaction boundary, fundamentally eliminating the inconsistency of an identifier being generated but ownership not registered. In the local transaction implementation mode, the end-to-end latency from receiving the binding result output to the registration request is no more than 50 milliseconds (test environment: 4-core 8GB server, SSD storage, single registration record, local DRC instance; end-to-end latency in cross-system Saga mode is approximately 200 milliseconds). In existing technologies, identifier allocation and ownership confirmation are executed separately. The technical time consumption of identifier allocation itself is typically in the millisecond range, but additional coordination processes are required between the two operations to ensure consistency, resulting in an overall process latency significantly higher than the single atomic operation of this invention.

[0039] Second, it achieves a structural binding between identifiers and ownership. This invention provides four ways to carry ownership identifier fields (encoded structure embedding, extended fields, metadata fields, and external reference fields). The adaptation method can be selected according to the field specifications of different identifier systems, so that the binding between identifiers and ownership can be achieved in any identifier system, improving the efficiency of ownership verification—ownership verification can be completed simultaneously in a single identifier parsing, eliminating the need for independent secondary ownership queries.

[0040] Third, the invention achieves cryptographic non-repudiation and clear roles based on a public-key encryption ownership confirmation mechanism. This invention inherits the basic mechanism for public-key encryption ownership confirmation and authorization protection established by ZL201710800793.9 (its US counterpart, US 11,438,157 B2), fully embodying the two directions of public-key encryption: In the signature direction, data ownership is bound to the public key of the ownership subject—only the holder of the corresponding private key can prove ownership, and any third party can verify ownership through the public key, realizing the ownership confirmation mechanism of "private key proves ownership, public key verifies ownership"; in the encryption direction, the ownership subject uses the public key of the authorized object to encrypt the data—only the authorized object holding the corresponding private key can decrypt and use the data, realizing the authorization mechanism of "public key encryption authorization, private key decryption and use". The combination of these two approaches embeds ownership and authorization within the cryptographic protection itself. Encrypted data can flow freely through any channel, but only authorized entities can use it, achieving "ownership follows data." Compared to schemes relying solely on external access control lists (ACLs), ownership and authorization are inseparable from the data, significantly enhancing security and traceability. For large datasets, a digital envelope mechanism (CEK+KEK) is employed to achieve efficient encryption while maintaining PKI ownership and authorization semantics. Identity providers support both CA and DID modes: in centralized management scenarios, CA-issued certificates provide a trust anchor; in decentralized or multi-principal peer-to-peer scenarios, DID self-contained public key declarations are used. Both modes are fully compatible with ZL201710800793.9 (US 11,438,157 B2) and form an incremental mechanism.

[0041] Fourth, it provides unified adaptation to multiple identification systems with specific mapping rules. This invention adapts the single-code dual-record atomic operation to multiple identification systems such as Handle, BID, and OID through an identification system adapter that includes a mapping table, field conversion rules, and conflict resolution rules. The adapter not only defines the interface but also specifies the specific mapping method, conversion logic, and conflict resolution strategy, ensuring the determinism and feasibility of the adaptation.

[0042] Fifth, the derived identifier linkage ensures consistency of ownership and preserves the persistence of the identifier. When ownership changes, a new atomic registration operation is automatically triggered, generating a derived identifier and a new ownership record. At the same time, the original identifier code is retained as a historical version and can still be verified. The derived identifier and the original identifier code form a version chain, which not only ensures the real-time consistency between ownership status and identifier, but also preserves the historical traceability of the identifier, eliminating the security risk that the old identifier still points to the original owner after the ownership change.

[0043] Sixth, cross-domain interoperability ensures the continuity of ownership and provides complete inheritance and conflict handling. When data flows across identification systems, a single-code dual-record atomic operation is automatically performed in the new system, and a cross-domain mapping relationship containing ownership inheritance declarations and mapping signatures is established in DRC. Before establishing the mapping, the validity of the source certificate is verified. In case of conflict, the ownership registered first takes precedence. The continuity of ownership relationship is not broken due to the switch of identification systems, effectively solving the ownership tracking problem in cross-domain flow scenarios.

[0044] The method described in this invention incorporates the following safety considerations and designs: Response to Private Key Leakage. When the private key of the owner is leaked, the attacker may impersonate the owner to sign false ownership certificates or authorizations. The present invention adopts the following countermeasures: (1) Key rotation mechanism - The owner can generate a new key pair and update the public key binding through DID document update or CA certificate revocation / resignation. After the update, the atomic registration operation of ownership change is triggered, generating a derived identifier and a new ownership certificate. The original identifier is marked as "key has been rotated"; (2) Certificate revocation list - DRC maintains a list of revoked ownership certificate serial numbers. When verifying the certificate, the verifier needs to check the signature validity and also query the revocation list to confirm that the certificate has not been revoked.

[0045] Prevention of DID hijacking. DID hijacking attack refers to the attacker tampering with the public key information in the DID document to impersonate the owner. The present invention adopts the following preventive measures: (1) The change operation of the DID document must be authorized by the private key corresponding to the current DID. The DRC will only perform the update after verifying the validity of the signature of the change request; (2) Critical changes (such as public key replacement) require multi-signature confirmation or a time lock-in period. During the lock-in period, the old public key can still initiate a revocation request.

[0046] Defense against replay attacks. Attackers may intercept legitimate registration requests and resend them to carry out replay attacks. The present invention adopts the following defense measures: (1) Each registration request contains a nonce and a timestamp. DRC maintains a recent nonce cache, and requests with duplicate nonces are directly rejected; (2) The confirmation certificate contains a registration timestamp. The verifier can set the validity period of the certificate according to the business policy. Expired certificates are considered invalid.

[0047] Defense against man-in-the-middle attacks in cross-domain mapping. When data flows across different identity systems, attackers may impersonate the source identity system and return false ownership information. This invention enforces verification of the source system's ownership certificate signature validity before establishing a cross-domain mapping, and the cross-domain mapping relationship itself is protected by PKI private key signature. The verifier can verify the authenticity of the mapping relationship through the public key, making it impossible for a man-in-the-middle to forge a cross-domain mapping relationship with a legitimate signature.

[0048] Concurrency conflict prevention. In high-concurrency scenarios, the same data may be registered repeatedly. This invention sets a globally unique fingerprint (metadata hash value) and version number for the data in the DRC ownership registration record. The fingerprint uniqueness constraint ensures that the same data can only be registered once, realizing optimistic locking conflict detection. Attached Figure Description

[0049] Figure 1 This is a flowchart of the atomic registration process for dual-code recording, illustrating the complete process of the method described in this invention from receiving the registration request to outputting the binding result. It particularly shows the execution logic and rollback mechanism of sub-steps S2a and S2b in the same atomic operation in step S2, as well as the process of outputting the binding result when the atomic operation is successful and performing a compensation operation when it fails in step S3.

[0050] Figure 2 This diagram illustrates the encoding format for embedding an ownership identifier field in the identifier encoding. It shows the hierarchical structure of the identifier encoding, including the identifier prefix segment, the data feature segment, the ownership identifier field (DID hash digest), and the verification segment.

[0051] Figure 3 This is a schematic diagram of the ownership certificate structure, showing the internal structure of the ownership certificate in the extended format of PKI digital certificate, which includes an identifier encoding field, an ownership subject DID field, an ownership registration record hash value field, a registration timestamp field, and a PKI signature field.

[0052] Figure 4 The diagram shows the architecture of the multi-identifier system adapter, illustrating the relationship between the atomic registration engine and the Handle adapter, BID adapter, and OID adapter through a unified interface, as well as the mapping tables, field conversion rules, and conflict handling rules in each adapter.

[0053] Figure 5 The flowchart for cross-domain one-code-two-record interoperability shows the complete process of verifying the source credential, performing one-code-two-record atomic operations in the new system, and establishing a cross-domain mapping relationship including ownership inheritance declaration when data flows from the first identification system to the second identification system.

[0054] Figure 6 This is a module architecture diagram of a dual-code system, showing the connection relationships between the registration request receiving module, atomic registration engine (including transaction coordinator), DRC ownership registration module, identifier encoding generation module, PKI ownership confirmation and signature module, identifier system adapter, ownership change linkage module, cross-domain interoperability module, and binding result output module. Detailed Implementation

[0055] The technical solutions in 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.

[0056] Reference Figure 1 The method described in this invention starts from receiving the registration request and simultaneously executes the identifier encoding generation (sub-step S2a) and DRC ownership registration (sub-step S2b) in the same atomic operation. The two are committed or rolled back together within the same transaction boundary. If the atomic operation is successful, the ownership certificate is generated based on the joint signature and the binding result is output. If it fails, the compensation operation is performed in reverse order and the failure information is returned.

[0057] Example 1: One-code dual-recording registration of sensor data in the Industrial Internet Identifier Resolution System

[0058] This embodiment takes the identification and ownership registration of sensor data in an industrial internet scenario as an example to illustrate the specific implementation process of the method described in this invention.

[0059] In an industrial internet environment, a manufacturing company's production line is equipped with numerous temperature sensors. The temperature data collected by each sensor needs to be registered in an identifier resolution system, and it's also necessary to clearly state that the data belongs to the company. In existing solutions, the company must first apply for an identifier code from the identifier resolution system and then submit an ownership declaration to the data registration center. These two steps require additional coordination to ensure consistency. This embodiment employs the dual-code registration method of the present invention to achieve simultaneous registration of the identifier and ownership.

[0060] Step S1: The registration request receiving module receives the registration request for sensor data. This registration request includes: metadata information, including sensor type (temperature sensor), sampling frequency, data accuracy, and production station number; and the ownership entity DID, which is the distributed identity identifier registered by the manufacturing company in the DRC.

[0061] Step S2: The atomic registration engine initiates a one-code-two-record atomic operation. The following two sub-steps are executed within the local database transaction (in this embodiment, the identifier encoding generation module and DRC are deployed on the same server, using a local database transaction; when deployed across systems, the Saga compensation transaction mode is used, see Embodiment 2 for details): Sub-step S2a: The identifier encoding generation module generates identifier codes based on metadata information. This embodiment uses the Handle protocol of the Industrial Internet Identifier Resolution System to generate Handle identifiers. The ownership identifier field is directly embedded in the encoding structure; this field is the SHA-256 hash digest of the ownership subject's DID, occupying 32 bytes. The complete identifier encoding layered structure is shown below. Figure 2 This includes: an identifier prefix segment (identifier system prefix) + a data feature segment (data feature identifier) ​​+ an ownership identifier field (DID hash digest) + a check segment (CRC32 checksum). If the target identifier system field is not long enough to embed the DID hash digest, the ownership identifier information is carried using an extended field method or an external reference field method.

[0062] In sub-step S2b, the DRC ownership registration module generates ownership registration records. These records include: an identifier code, the ownership entity's DID, the registration time, and data classification and grading information. The ownership registration records are stored in the DRC's ownership registry, with a one-to-one correspondence between the identifier code and the registration record.

[0063] The atomic registration engine guarantees that sub-steps S2a and S2b are executed within the local database transaction. If Handle identifier generation fails (e.g., due to prefix conflict), the DRC ownership record is rolled back simultaneously; if the DRC ownership record write fails (e.g., DID verification fails), the Handle identifier allocation is rolled back simultaneously. Through this atomic operation mechanism, identifier encoding and ownership registration records either succeed simultaneously or fail to be generated simultaneously, fundamentally eliminating the occurrence of inconsistent states.

[0064] In step S2', the PKI ownership confirmation and signature module uses the PKI private key of the ownership subject to sign the joint hash value of the identifier code and the ownership registration record, generating an ownership confirmation certificate. This achieves the following: `private key proves ownership, public key verifies ownership` in the signature direction. The structure of the ownership confirmation certificate is as follows: Figure 3The system adopts an extended format for identity credentials issued by the identity provider: the certificate subject is the ownership subject's DID; the extended fields include the identifier code, the hash value of the ownership registration record, and the registration timestamp; the signature algorithm is RSA-2048 with SHA-256 (or SM2 with SM3). This ownership credential is signed by the ownership subject's PKI private key, and its validity is verified by the DRC before being stored as evidence. In this embodiment, the manufacturing enterprise has its identity certificate issued by a CA in a centralized management environment, providing a certificate trust chain; in a decentralized multi-entity collaboration scenario, the DID self-contained declaration public key can be used as the identity trust anchor. The DRC is responsible for verification and storage, but does not participate in signing. When the sensor data needs to be authorized for use by supply chain partners, the ownership subject uses the public key of the authorized object (supply chain partner) to encrypt the data, achieving the following encryption direction: public key encryption authorization, private key decryption and use—only the supply chain partner's private key can decrypt and use the data, thus achieving technology authorization. Due to the large volume of sensor data, a digital envelope mechanism is adopted: a randomly generated symmetric key CEK (using AES-256 or SM4 algorithm) is used to encrypt the main body of the sensor data. Then, the public key of the supply chain partner is used as KEK (using RSA-2048 or SM2 algorithm) to encrypt the CEK. The encrypted data body and the encrypted CEK are combined into a digital envelope. After receiving the digital envelope, the supply chain partner uses its own private key to decrypt the KEK to obtain the CEK, and then uses the CEK to decrypt the data body.

[0065] Step S3: The binding result output module outputs the binding result, including: identifier code, ownership registration record, and confirmation certificate. The three-party binding result is returned as a whole to the registration requester.

[0066] In this embodiment, the execution time from step S1 to step S3 is no more than 50 milliseconds in local transaction mode (test environment: 4-core 8GB server, SSD storage, single registration record, local DRC instance), and the end-to-end latency in cross-system Saga mode is approximately 200 milliseconds (test environment: 2 4-core 8GB servers connected by gigabit network, single registration record). In the prior art, identifier allocation and ownership confirmation are executed separately. Although the technical time consumption of identifier allocation itself is also in the millisecond range, additional coordination processes are required between the two operations to ensure consistency (such as distributed transaction coordination or manual confirmation), and the overall process latency is significantly higher than the single atomic operation of this invention.

[0067] Example 2: Data flow across identification systems (Handle to BID) with one code and dual recording

[0068] This embodiment takes the transfer of data from the Industrial Internet Handle system to the Spark Identifier BID system as an example to illustrate the specific implementation process of the cross-domain interoperability method described in this invention.

[0069] In industrial collaboration scenarios, sensor data from the aforementioned manufacturing enterprises needs to be shared from the Handle system to a supply chain platform based on the BID system. When data flows across systems, the original Handle identifier cannot be directly parsed in the BID system, and ownership relationships need to be re-established in the new system. In existing solutions, ownership relationships are broken after cross-system transfers, requiring manual intervention to re-establish ownership. This embodiment employs the cross-domain one-code dual-recording method of the present invention to ensure the continuity of ownership relationships during identifier system switching.

[0070] In this embodiment, the Handle identifier resolution system and the BID identifier resolution system are deployed on different servers. The atomic registration engine cannot guarantee consistency using local database transactions. Therefore, a compensatory transaction protocol based on the Saga pattern is adopted to implement cross-system atomic operations, referring to... Figure 5 Cross-domain interoperability process.

[0071] Step S1: The cross-domain interoperability module detects a data transfer event. First, the cross-domain interoperability module verifies the validity of the ownership certificate signature in the source Handle system, confirming that the data belongs to the original manufacturing enterprise. After confirming the legality of the source ownership, it sends a cross-domain registration request to the registration request receiving module. This request includes: original metadata information, the original ownership subject's DID, the source identification system identifier, the source identifier code, and the source ownership certificate.

[0072] Step S2: The atomic registration engine initiates a cross-domain one-code dual-record atomic operation, using the Saga compensated transaction mode, with the transaction coordinator arranging the following sub-transaction sequence: Sub-transaction T1 (forward operation): The identifier encoding generation module calls the BID adapter to generate a BID identifier. (BID adapter reference...) Figure 4 The multi-identifier adapter architecture shown determines the field name of the ownership identifier field in the BID system based on the mapping table, maps the DID hash digest to the BID encoding space according to the field conversion rules, and checks whether the target field already has a value according to the conflict handling rules. The BID system returns a success response. The corresponding compensation operation C1: calls the BID adapter to perform the "record revocation declaration" operation, writes the revocation information to the extended field of the BID record, so that the identifier returns the "revoked" status during parsing.

[0073] Sub-transaction T2 (forward operation): The DRC ownership registration module generates a new ownership registration record and prepares a cross-domain mapping record. The new ownership registration record includes: target identifier code, ownership subject DID, registration time, and data classification level. The cross-domain mapping record includes: source identifier system, source identifier code, target identifier system, target identifier code, mapping time, mapping signature (signed by the PKI private key), and ownership inheritance declaration. DRC returns a success response. Corresponding compensation operation C2: DRC deletes the newly generated ownership registration record and cross-domain mapping record, and records the reversal operation in the reversal log.

[0074] The compensation process when any sub-transaction fails is as follows: (1) If sub-transaction T1 fails (BID identifier generation fails), no compensation is required (T1 was not successfully executed), and failure is returned directly; (2) If sub-transaction T2 fails (DRC write fails), the compensation operation of the completed sub-transaction is executed in reverse order - first, the compensation operation C1 is executed, the generated BID identifier is marked as revoked, and then failure is returned; (3) In the network partition scenario, if the transaction coordinator cannot communicate with the BID system or DRC, for sub-transactions that have received a successful response but have not confirmed the final commit, the final status is queried after the network is restored. If it is still in the 'preparing' state, the compensation operation is executed, and the eventual consistency model is used to ensure the consistency of cross-system data.

[0075] In step S2', the PKI ownership confirmation signature module uses the PKI private key of the ownership subject to sign the joint hash value of the new BID identifier encoding, the new ownership registration record, and the cross-domain mapping record, generating a cross-domain ownership confirmation certificate. This cross-domain ownership confirmation certificate adds a source identifier encoding field and a cross-domain mapping signature field to the original ownership confirmation certificate structure, achieving cryptographic proof of the ownership source chain. This certificate is then stored after DRC verification.

[0076] Step S3: The binding result output module outputs the cross-domain binding result, including: BID identifier code, new ownership registration record, cross-domain mapping record, and cross-domain ownership confirmation certificate.

[0077] Through the aforementioned cross-domain dual-recording operation, the ownership relationship of data in the BID system and the ownership relationship in the Handle system are continuously tracked through DRC cross-domain mapping. Either party can obtain the complete ownership chain by querying the DRC, and the ownership relationship is not broken due to the switch of the identification system. If there are conflicting ownership claims for the same data between the two identification systems, the ownership record registered first in the source identification system shall prevail.

[0078] Example 3: Cross-institutional registration of medical and health data using a single code and dual recording

[0079] This embodiment uses the identification and ownership registration of electronic health record data in a medical and health scenario as an example to illustrate the applicability of the present invention in different industries.

[0080] In a regional healthcare collaboration scenario, the electronic health record data of a tertiary hospital needs to be shared on a regional health information platform. Simultaneously, data ownership needs to be clearly defined, and patient privacy must be ensured. In existing solutions, the hospital first submits a data catalog to the regional platform to obtain an identification code, and then registers patient authorization information with the ownership system. Between these two steps, the patient's medical data may have already been accessed by other institutions, but ownership has not yet been established. This embodiment employs the one-code dual-recording method of the present invention.

[0081] Step S1: The registration request receiving module receives a registration request for health record data. This request includes: metadata information, including data type (electronic health record), data generating institution, data classification and grading (medical data / personal sensitive data); and the ownership entity DID, which is the distributed identity identifier registered by the patient in the DRC. Each registration request includes a nonce and a timestamp to defend against replay attacks.

[0082] Step S2: The atomic registration engine initiates a dual-record atomic operation. The regional health information platform and DRC are deployed on different servers, employing the Saga compensated transaction model, with the transaction coordinator orchestrating the sub-transaction sequence. Sub-transaction T1: The identifier encoding generation module calls the OID adapter (medical data typically uses the OID identifier system) to generate OID identifiers. The OID adapter determines the carrying method of the ownership identifier field in the OID system based on the mapping table; it uses the extended field method (OID encoding length is limited, so DID hash digests cannot be directly embedded). Based on the field conversion rules, it encodes the DID hash digest into an OID extended attribute value. Corresponding compensation operation C1: The OID adapter is called to execute the `\u201c` mark as invalid `\u201d` operation.

[0083] Sub-transaction T2: The DRC ownership registration module generates ownership registration records, including OID identifier code, patient DID, registration time, and data classification / grading (medical data / personal sensitive data). DRC uses a globally unique fingerprint (metadata hash value) and version number to implement optimistic locking conflict detection, ensuring that the same health record data for the same patient can only be registered once, preventing duplicate registration. Corresponding compensation operation C2: DRC deletes the ownership registration record and records it in the revocation log.

[0084] In step S2', the PKI ownership confirmation and signature module uses the patient's private key to sign the joint hash value of the OID identifier code and the ownership registration record, generating an ownership confirmation certificate. Since medical data is sensitive personal data, the ownership subject (patient) uses the public key of the authorized object (the medical institution to which the attending physician belongs) to encrypt the data to implement technical authorization, employing a digital envelope mechanism: a randomly generated CEK (using the SM4 algorithm, compliant with national cryptographic standards in the medical industry) is used to encrypt the health record data, and then the public key of the authorized object is used as the KEK (using the SM2 algorithm) to encrypt the CEK, combining them into a digital envelope. The ownership confirmation certificate signature algorithm uses SM2 with SM3, complying with the requirements of the Cryptography Law for domestically produced commercial cryptographic algorithms for critical information infrastructure. In this decentralized scenario, the DID self-contained declaration public key is used as the identity trust anchor, allowing patients to manage their identity and keys independently through the DID, without relying on a CA center.

[0085] Step S3: The binding result output module outputs the binding result.

[0086] When a patient changes hospitals, the ownership change linkage module automatically triggers a new atomic registration operation, generating a derived identifier and a new ownership record. The original OID identifier is marked as "historical version," and the new identifier is atomically bound to the new ownership record. At the same time, the DRC establishes a change association record. This mechanism ensures that the ownership of a patient's medical data remains consistent and traceable across different medical institutions.

[0087] Explanation of Ownership Change Linkage

[0088] In the above embodiments, when the ownership subject changes, the ownership change linkage module automatically triggers a new atomic registration operation. The atomic registration engine re-executes step S2, generating a derived identifier containing a new ownership identifier field and a new ownership registration record. The original identifier code is retained as a historical version and is still verifiable. Simultaneously, a change association record is established in the DRC, recording the change relationship from the original identifier code to the derived identifier, the change time, and the change reason. This ownership version linkage mechanism ensures that after an ownership change, the parsing result of the original identifier code is marked as "historical version, ownership has changed," and the derived identifier remains atomically bound to the new ownership record. This eliminates the security risk of the original identifier still representing the current ownership status after an ownership change, while preserving the historical traceability of the identifier.

[0089] Audit Mechanism Explanation

[0090] The auditing mechanism of this invention employs an append-only hash chain log with PKI signatures, referencing the design principles of RFC 6962 Certificate Transparency. After each atomic registration operation, the operation record (including the identifier code, ownership subject DID, and timestamp) is appended to the hash chain log. Each log record contains the hash value of the previous record and is signed by the ownership subject's PKI private key. This log is append-only, immutable, and undeletable; any tampering with historical records will result in a break in the hash chain and be detected. Because atomic operations guarantee the simultaneous generation of the identifier and ownership, each record in the audit chain naturally contains complete binding information: 'identifier code + ownership record', achieving complete audit traceability without the need for additional log association mechanisms.

[0091] Fault Tolerance and Recovery Mechanism Explanation

[0092] The data recovery process after a system failure follows these steps: (1) In local transaction mode, the transaction log of the database system ensures data consistency after the failure is recovered, and unfinished transactions are automatically rolled back; (2) In Saga mode, the transaction coordinator maintains the Saga execution status log. After the failure is recovered, the unfinished Saga instances are determined based on the status log, and compensation operations or resubmissions are performed on the sub-transactions that have been executed but not confirmed; (3) The ownership registration records of DRC are stored in append mode, and the deletion operation records are logical deletions (marked as undoing rather than physical deletion) to ensure the integrity of data recovery.

[0093] 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 method for integrating identification coding and data ownership registration, characterized in that, Includes the following steps: Step S1: Receive a data registration request, the registration request containing metadata information of the data to be registered and a distributed identity identifier (DID) of the ownership subject; Step S2: Execute the following sub-steps in the same atomic operation: Sub-step S2a: Generate an identifier code based on the metadata information; Sub-step S2b: Generate an ownership registration record corresponding to the identifier code in the Data Registry (DRC). Sub-steps S2a and S2b are executed within the same transaction boundary, and the two sub-steps are committed or rolled back together to ensure that the identifier code and the ownership registration record are generated simultaneously and are indivisible; Step S3: Output the binding result of the identifier code and the ownership registration record.

2. The method according to claim 1, characterized in that, After the successful execution of step S2, a joint signature step can be performed: the private key of the ownership subject is used to sign the joint hash value of the identifier code and the ownership registration record to generate a confirmation certificate; the confirmation certificate binds the data ownership with the asymmetric key pair of the ownership subject, forming a confirmation mechanism where the private key proves ownership and the public key verifies ownership in the signature direction; simultaneously, the ownership subject can use the public key of the authorized object to encrypt the data to implement technical authorization, forming an authorization mechanism where the public key encrypts the authorization and the private key decrypts the data in the encryption direction, and the encrypted data can be transferred through any channel and can only be used by the holder of the private key of the authorized object, realizing that the rights follow the data; the confirmation certificate carries the identifier code, the hash value of the ownership registration record and the registration timestamp in the form of extended fields on the identity credential issued by the identity provider, and the confirmation certificate is stored after the signature validity is verified by DRC; when the joint signature step is executed, step S3 outputs the confirmation certificate accordingly.

3. The method according to claim 2, characterized in that, The identity provider is a CA (Certificate Authority) that issues identity certificates in a centralized management scenario to bind the ownership entity to its public key, providing an identity trust anchor.

4. The method according to claim 2, characterized in that, The identity provider is a DID (Distributed Identity Provider). In decentralized or multi-principal peer-to-peer scenarios, the binding relationship between identity and public key is established by DID's self-contained public key declaration, without the need for third-party signing.

5. The method according to claim 2, characterized in that, For data exceeding a preset threshold, a digital envelope mechanism is used: a randomly generated symmetric key CEK is used to encrypt the data subject, and then the public key of the authorized object is used as KEK to encrypt the CEK, which is combined into a digital envelope. Only the authorized object holding the corresponding private key can decrypt the KEK to obtain the CEK and then decrypt the data subject.

6. The method according to claim 1, characterized in that, The atomic operations within the same transaction boundary in step S2 are implemented in one of the following ways: when the identifier encoding generation and DRC ownership registration are executed in the same local database, a local database transaction is used; when the identifier encoding generation and DRC ownership registration involve different systems, a compensation transaction protocol based on the Saga pattern is used. The Saga pattern splits the atomic operation into a set of ordered sub-transactions, each sub-transaction is equipped with a corresponding compensation operation, and when any sub-transaction fails, the compensation operations of the completed sub-transactions are executed in reverse order to roll back to a consistent state.

7. The method according to claim 6, characterized in that, The compensation operation adopts a differentiated strategy for different identification systems: the Handle system adopts the compensation operation of marking 'invalid' as 'invalid', so that the 'revoked' status is returned when the identification is resolved; the BID system adopts the method of 'revoking the record', which writes the revocation information into the extended field of the BID record. DRC uses a logical deletion method and records the undo log.

8. The method according to claim 1, characterized in that, The identification code carries the ownership subject identity information in one of the following ways: (1) directly embedded in the coding structure, with the hash digest of the ownership subject DID as a component field of the coding structure; (2) as an extension field of the identification system, adding an ownership identification extension field to the identification record; (3) as a metadata field of the identification system, associating ownership subject information in the identification metadata; (4) as an external reference field of the identification code, associating it with the ownership registration record through a reference pointer; the above four carrying methods are selected according to the field specifications of the identification system.

9. The method according to claim 8, characterized in that, The hash digest of the DID is generated using the SHA-256, SHA-3, or SM3 algorithm.

10. The method according to claim 1, characterized in that, In step S2a, when generating the identifier encoding, the atomic operation is adapted to multiple identifier systems through an identifier system adapter. The identifier system includes at least one of the Handle system, Spark Identifier BID system, and OID system. The identifier system adapter includes a mapping table, field conversion rules, and conflict handling rules. The mapping table defines the field name and field format of the ownership identifier field in each identifier system. The field conversion rules define the encoding conversion method from DID hash digest to the target identifier system field value. The conflict handling rules define the processing strategy when the target identifier system field already has a value.

11. The method according to claim 10, characterized in that, The conflict handling rules include at least one of the following: overwrite strategy, append strategy, and error reporting strategy: overwrite strategy, which replaces the existing value with the new value; append strategy, which appends the new value to the existing value; and error reporting strategy, which refuses to write and returns a conflict message.

12. The method according to claim 1, characterized in that, When the ownership of a subject changes, the atomic operation of step S2 is re-executed to generate a derived identifier and a new ownership registration record. The derived identifier contains a reference relationship to the original identifier code. The original identifier code is retained as a historical version and can still be verified. The derived identifier and the original identifier code form a version chain. At the same time, a change association relationship is established between the new ownership record and the old ownership record in the DRC. The change association relationship includes the original identifier code, the derived identifier, the change time, and the change reason.

13. The method according to claim 1, characterized in that, When data flows from the first identification system to the second identification system, the validity of the ownership certificate signature in the source identification system is first verified. After confirming the legality of the source ownership, the atomic operation of step S2 is re-executed in the second identification system to generate the identification code and ownership registration record in the second identification system. At the same time, a cross-domain mapping relationship is established in the DRC between the ownership records in the first and second identification systems. The cross-domain mapping relationship includes the source identification system identifier, the source identification code, the target identification system identifier, the target identification code, the mapping signature signed by the PKI private key, and the ownership inheritance declaration. When there are conflicting ownership declarations for the same data between the two identification systems, the ownership record registered first in the source identification system shall prevail.

14. The method according to claim 1, characterized in that, The atomic operation records of step S2 are appended to the hash chain log of the PKI signature. Each log record contains the hash value of the previous record and is signed by the PKI private key of the ownership subject, forming an immutable audit chain.

15. The method according to claim 1, characterized in that, In step S2, the DRC ownership registration record contains a globally unique fingerprint and version number of the data. The fingerprint uniqueness constraint enables optimistic locking conflict detection and rejects duplicate registration requests.

16. The method according to claim 6, characterized in that, Data recovery after a system failure follows this process: In local transaction mode, the database transaction log ensures data consistency after failure recovery; in Saga mode, the transaction coordinator maintains the Saga execution status log, and after failure recovery, it determines the incomplete Saga instances based on the status log and performs compensation operations or recommits them. DRC ownership registration records are stored in an append-only manner, and deletion operations are logical deletions.

17. An integrated system for identification coding and data ownership registration, characterized in that, include: The registration request receiving module is used to receive data registration requests, wherein the registration request includes metadata information of the data to be registered and the distributed identity identifier (DID) of the ownership subject; The atomic registration engine is used to perform identifier encoding generation and DRC ownership registration record generation in the same atomic operation. The atomic registration engine contains a transaction coordinator, which is responsible for maintaining transaction state, scheduling local database transactions when deployed locally, orchestrating Saga sub-transaction sequences and coordinating compensation operations when deployed across systems, and detecting and rejecting duplicate registration requests through version number optimistic locking mechanism in concurrent scenarios. An identifier system adapter is used to adapt the atomic operations of the atomic registration engine to multiple identifier systems. The identifier system adapter includes a mapping table, field conversion rules, and conflict handling rules. Each adapter interacts with the atomic registration engine through a unified interface. The PKI ownership confirmation and signature module is used to sign the joint hash value of the identifier code and the ownership registration record using the ownership subject's PKI private key to generate ownership confirmation certificate; The binding result output module is used to output the binding result of the identifier code, the ownership registration record and the confirmation certificate.

18. The system according to claim 17, characterized in that, It also includes an ownership change linkage module, which is used to trigger the atomic registration engine to re-execute atomic operations when the ownership of the ownership subject changes, generate a derived identifier and a new ownership registration record, retain the original identifier code as a historical version, form a version chain with the derived identifier and the original identifier code, and establish a change association relationship in DRC.

19. The system according to claim 17, characterized in that, It also includes a cross-domain interoperability module, which is used to first verify the validity of the ownership certificate signature in the source identity system when data flows from the first identity system to the second identity system, then trigger the atomic registration engine to perform atomic operations in the second identity system, and establish a cross-domain mapping relationship in DRC that includes ownership inheritance declaration. The cross-domain mapping relationship is protected by PKI private key signature.

20. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 16.

21. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 16.

Images