Cross-organization data sharing method for chain arbitration event driving and hierarchical identity encryption

Abstract

The invention relates to a cross-organization data sharing method for on-chain decision event driving and hierarchical identity encryption. The cross-organization data sharing method comprises a governance and strategy construction stage, a data request and credible decision stage and an encryption delivery stage which are executed in sequence. According to the method, decentralized credible judgment, fine-grained access control, on-chain and off-chain high-consistency and flexible and efficient key management are realized, and the security, flexibility and expandability of cross-organization data sharing are guaranteed.

Description

Technical Field

[0001] This invention relates to a cross-organizational data sharing method based on on-chain adjudication event-driven and hierarchical identity encryption. Specifically, it relates to a cross-organizational data sharing method that utilizes blockchain smart contracts to achieve fine-grained access control adjudication and drives off-chain encrypted data delivery through on-chain adjudication events. This method is applicable to on-demand data sharing and controlled use in inter-enterprise and cross-departmental collaborative scenarios and belongs to the fields of blockchain technology, access control, data security, and cross-organizational data sharing technology. Background Technology

[0002] As digital transformation deepens, enterprises and institutions are experiencing a continuous increase in demand for cross-organizational and cross-departmental data sharing in scenarios such as business collaboration, joint decision-making, and resource optimization. The core requirement of such sharing scenarios is to achieve on-demand access and controllable use of data while maintaining the data sovereignty and security boundaries of all participating parties.

[0003] Existing cross-organizational data sharing solutions mainly suffer from the following four core technical deficiencies:

[0004] 1. Inherent Risks of Centralized Architecture: Most mainstream solutions adopt centralized data exchange platforms or unified authorization services, with a single controlling party leading identity management, permission configuration, and access adjudication. This model not only creates a single point of trust dependence (requiring complete trust in the controlling party's integrity and security capabilities) but also poses a single point of failure risk—the failure or attack of the central node will paralyze the entire shared system. Furthermore, the management systems and permission rules of different organizations vary significantly, making centralized maintenance of permission policies extremely costly, inflexible, and difficult to adapt to cross-organizational collaboration scenarios with frequently changing permission relationships.

[0005] 2. Poor adaptability of access control models: In cross-organizational scenarios, traditional role-based access control (RBAC) models are prone to problems such as role inflation, complex role mapping, and maintenance difficulties due to inconsistent role definitions and semantic standards among different organizations. Moreover, this model relies on predefined role relationships and cannot uniformly describe and dynamically adjudicate multi-subject, multi-resource, and multi-dimensional access conditions (such as data sensitivity and access time windows), making it difficult to support fine-grained on-demand data sharing needs.

[0006] 3. Lack of consistency between on-chain and off-chain interactions: In existing blockchain-related solutions, the access control and data security delivery logic are not clearly coupled, and there is no verifiable causal relationship between on-chain adjudication results and off-chain data delivery. Moreover, on-chain and off-chain interactions mostly adopt active query or centralized callback modes, which have hidden dangers such as inconsistent timing and delayed state synchronization. This can easily lead to invalid or malicious requests directly reaching the data source, threatening data security.

[0007] 4. Inefficient encryption and key management systems: Cross-organizational data delivery often relies on certificate-based public key systems or centralized key management mechanisms, which have problems such as complex certificate issuance, distribution and verification processes, lengthy trust chains, high key maintenance costs and insufficient scalability. At the same time, the lack of effective mapping between encrypted identities and adjudication subjects leads to the obstruction of the entire chain from authorization confirmation to data decryption, making it difficult to adapt to scenarios of increasing subject size or dynamic adjustment of organizational structure.

[0008] With its decentralized, immutable, and fully auditable characteristics, combined with the programmable automatic execution capabilities of smart contracts, blockchain technology provides a new technical path for trusted data sharing across organizations. However, existing blockchain solutions have not yet solved the aforementioned core defects, and there is an urgent need for a technical solution that can achieve decentralized adjudication, fine-grained control, strong on-chain and off-chain consistency, and efficient key management. Summary of the Invention

[0009] To overcome the shortcomings of existing cross-organizational data sharing schemes, such as centralized dependence, coarse-grained access control, poor on-chain and off-chain consistency, and complex key management, this invention provides a cross-organizational data sharing method based on on-chain adjudication event-driven and hierarchical identity encryption. This method achieves decentralized trusted adjudication, fine-grained access control, strong on-chain and off-chain consistency, and flexible and efficient key management, ensuring the security, flexibility, and scalability of cross-organizational data sharing.

[0010] A cross-organizational data sharing approach with on-chain adjudication event-driven and layered identity encryption, comprising a governance and policy building phase, a data request and trusted adjudication phase, and an encrypted delivery phase executed sequentially;

[0011] The governance and strategy construction phase includes the following steps:

[0012] Step 1.1: Deploy and run a set of smart contracts for attribute-based access control on the blockchain, the set of smart contracts including at least a subject attribute management contract, a resource attribute management contract, a policy management contract, and an attribute domain authority contract;

[0013] Step 1.2: Initialize the mapping relationship between the attribute domain and the corresponding attribute authority entity through the attribute domain authority contract;

[0014] Step 1.3: The attribute authority entity writes or updates the subject attributes with the blockchain account address as the unique identifier for the data requester through the subject attribute management contract. The subject attributes are divided into main attributes and extended attributes. The main attributes are the basic attributes that each subject has, including at least the organization, department level and job level.

[0015] Step 1.4: The data resource owner registers a unique resource identifier and its corresponding set of resource attributes for its data resources through the resource attribute management contract;

[0016] Step 1.5: The data resource owner constructs an access control policy quadruple based on the subject attribute, resource attribute, operation type and environment context, registers the access control policy through the policy management contract, and generates and maintains the corresponding policy version number.

[0017] The data request and trusted adjudication phase includes the following steps:

[0018] Step 2.1: Construct and submit a data access request transaction containing the subject identifier, resource identifier, requested operation, and data receiving address in the data request direction permission arbitration contract;

[0019] Step 2.2: The permission adjudication contract reads the subject attribute facts from the subject attribute management contract and the resource attribute facts from the resource attribute management contract, and queries the associated candidate strategies from the strategy management contract based on the resource identifier and request operation, and filters out the effective strategy set in combination with the current block time;

[0020] Step 2.3: The permission adjudication contract performs attribute matching and operation matching judgments on each of the effective policy sets. When at least one policy satisfies the subject attribute matching, resource attribute matching, and operation matching, an adjudication result allowing access is generated.

[0021] Step 2.4: The audit contract encapsulates the unique identifier of the requesting entity, the entity's core attributes, the ruling transaction hash, the ruling result, and the corresponding strategy version number into a ruling evidence event and publishes it to the blockchain;

[0022] The encrypted delivery phase includes the following steps:

[0023] Step 3.1: Continuously monitor the adjudication evidence events on the blockchain, perform consistency verification on the adjudication results and key information of the adjudication evidence events, and drive the data resource owner to execute data delivery after the verification is passed;

[0024] Step 3.2: Based on the adjudication evidence event, the data resource owner binds the data resource to be shared with the adjudication transaction hash, policy version number and adjudication digest, and constructs a hierarchical identity path based on the unique identifier and backbone attribute of the requesting subject. The hierarchical identity path is used as the encryption public key to perform encryption operation, generate a ciphertext delivery package and push it to the data receiving address.

[0025] Step 3.3: After obtaining the user-level identity private key corresponding to the hierarchical identity path, the data requester decrypts the encrypted delivery packet and restores the corresponding data resource content.

[0026] In step 1.1, the attribute domain authority contract is used to maintain the mapping relationship between the attribute domain and multiple attribute authority entities, and to implement decentralized governance. When the subject attribute facts are written or updated, the attribute domain authority contract verifies the caller's permissions to ensure that the source of the subject attribute facts is trustworthy.

[0027] In addition to being used for on-chain adjudication in the data request and trusted adjudication phases, the main attributes in step 1.3 are also used to construct the hierarchical identity path in the encrypted delivery phase, achieving a consistent association between adjudication evidence and encrypted identity; the extended attributes are supplementary attributes flexibly defined according to business needs, used to support fine-grained attribute-based access control.

[0028] In step 1.5, the environment context in the access control policy quadruple includes at least the policy effective start time and effective end time; the permission adjudication contract uses the current block time as the adjudication context parameter to filter the candidate policies for effectiveness, and only determines the policies within the effective start time to effective end time interval as the effective policy set to participate in subsequent adjudication.

[0029] In step 2.1, the permission adjudication contract is the sole entry point for data access requests. All data access requests are submitted in the form of blockchain transactions and permission adjudication is completed on the chain. Before the adjudication evidence event that allows access is generated, the data resource service endpoint is not visible to the data requester, thereby reducing the risk of invalid or malicious requests directly reaching the data source.

[0030] The attribute matching and operation matching judgment in step 2.3 specifically includes: the permission adjudication contract matching the on-chain subject attribute facts with the subject attribute constraints of the effective policy, matching the on-chain resource attribute facts with the resource attribute constraints of the effective policy, and matching the request operation with the operation constraints of the effective policy; when all three of the above matching conditions of any effective policy are met, an adjudication result allowing access is output and the audit contract is triggered to publish the adjudication evidence event; otherwise, an adjudication result denying access is output.

[0031] In step 2.4, the adjudication evidence event serves as the sole trusted trigger for off-chain data delivery, driving off-chain data sharing. The encrypted delivery phase does not actively participate in permission determination but passively responds based solely on the on-chain adjudication result corresponding to the adjudication evidence event.

[0032] The consistency verification in step 3.1 specifically includes: obtaining the corresponding transaction receipt based on the ruling transaction hash in the ruling evidence event, verifying the event log in the transaction receipt, and confirming the authenticity and integrity of the ruling evidence event; only after the verification is passed can the process proceed to the encrypted delivery stage.

[0033] The encryption operation in step 3.2 adopts a hierarchical identity encryption scheme; the hierarchical identity path consists of a hierarchical structure of (organization, department level, job level, and unique identifier of the subject), and is directly mapped through the backbone attributes of the requesting subject on the blockchain; the user-level identity private key can be derived step by step along the organizational hierarchy.

[0034] The encrypted delivery package in step 3.3 includes at least encrypted data, a ruling transaction hash, a strategy version number, and a ruling digest. Before decryption, the data requester performs a consistency check against the ruling evidence event on the blockchain based on the ruling transaction hash, strategy version number, and ruling digest in the encrypted delivery package. After confirming the authenticity of the data delivery process, the decryption operation is then performed.

[0035] The overall architecture of the technical solution of this invention is divided into three layers: governance and strategy layer, trusted adjudication and audit layer, and encrypted delivery layer, corresponding to three core implementation stages: governance and strategy construction stage, data request and trusted adjudication stage, and encrypted delivery stage, as detailed below:

[0036] Governance and Policy Layer: Deployed on the blockchain, this layer consists of various smart contracts used to build a trusted attribute-based access control foundation. It employs authoritative sources to provide rules and facts, specifically including subject attribute facts, resource attribute facts, and policy facts. This layer, through on-chain governance, enables authoritative entities and data resource owners to construct a trusted attribute-based access control scheme.

[0037] Attribute Domain Authority Contract: This contract is used to maintain the mapping relationship between attribute domains and attribute authority entities on the blockchain, enabling decentralized issuance. Its core logic lies in implementing decentralized governance for different attribute domains (such as organization domains, specific project domains, and security domains), verifying the caller's permissions when writing attributes, and ensuring that only authorized attribute authority entities can issue attributes for the corresponding domains, guaranteeing the source of the trusted information.

[0038] Subject Attribute Management Contract: This contract is used to maintain the subject attributes of data users on-chain. To distinguish different subjects in the system, we use the blockchain account address of the data user as the unique identifier of the subject. In addition, each subject can be associated with multiple attributes, which can be divided into two categories: core attributes and extended attributes. Core attributes are basic attributes that each subject has, including at least the organization, department level, and job title. Extended attributes can be freely defined to meet the needs of fine-grained and highly flexible attribute-based access control. When writing or updating subject attributes, the attribute domain authority contract must be called for permission verification to provide tamper-proof subject facts for subsequent permission decisions.

[0039] Resource Attribute Management Contract: Similar to the Subject Attribute Management Contract, this contract is used to maintain the resource attributes of the data owner on the chain. By establishing the correspondence between the unique identifier of the resource and the resource attributes (such as the organization to which it belongs, resource class, data sensitivity), the resource metadata is solidified into verifiable facts on the chain. The granting of these attributes can only be executed by the resource administrator (the owner of the data resource).

[0040] Policy Management Contract: This contract is responsible for storing and managing attribute-based access control policies and maintaining policy version numbers. A policy is a logical combination of subject attributes, object attributes, operations, and environmental context. Each policy can handle access control between multiple objects and multiple subjects, thereby achieving many-to-many access control. This invention introduces a time-dimensional dynamic policy as the policy's environmental context, allowing the setting of the policy's effective start and end times. Furthermore, only the data resource owner has the right to formulate and manage related access policies. Policy updates increment the policy version number, providing a version anchor for adjudication evidence to support audit review and encrypted binding.

[0041] The trusted adjudication and audit layer is used to receive access requests from data users, automatically execute trusted adjudications using smart contracts based on attributes and policies in the governance and strategy layer, and output on-chain events of the adjudication results.

[0042] Trusted adjudication and auditing layer: Deployed on the blockchain, responsible for authority adjudication and auditing records, including:

[0043] Permission Adjudication Contract: This contract is the core of the on-chain adjudication process. It is responsible for controlling a subject's access requests to objects. Calling the Permission Adjudication Contract requires initiating a transaction containing the required request information. Upon receiving the request transaction, the Permission Adjudication Contract queries the relevant subject attributes, object attributes, and policies from the Subject Attribute Management Contract, Resource Attribute Management Contract, and Policy Registration Contract. Based on these attributes and policies, it provides an adjudication result regarding whether the subject is allowed to execute its resource request.

[0044] Audit Contract: This contract publishes standardized on-chain adjudication evidence events based on the judgment results of the authorization adjudication contract, and provides an index to support adjudication queries and audits. The events contain key fields such as the adjudication transaction hash, decision result, strategy version, and response address, serving as the sole trusted trigger source for off-chain delivery.

[0045] Encrypted Delivery Layer: Located off-chain, it passively responds to on-chain adjudication events and uses the Hierarchical Identity Encryption (HIBE) scheme to perform data encryption and delivery.

[0046] The encrypted delivery layer, acting as an off-chain execution entity, does not actively participate in permission determination. Instead, it passively and continuously monitors the adjudication evidence events published by smart contracts on the blockchain, using the on-chain adjudication result as the sole trigger. It only responds to access requests that have been verified for on-chain consistency and are explicitly authorized. During delivery, a layered identity-based encryption mechanism is employed. Key information in the data delivery and on-chain adjudication evidence (including transaction hashes, policy versions, and adjudication summaries) is encrypted using the data requester's hierarchical identity information. The resulting ciphertext delivery packet is pushed to the requester, ensuring that only requesters with matching identity levels and verified adjudication evidence consistency can successfully decrypt the key and data. This achieves the collaborative execution of on-chain adjudication driven by on-chain events and off-chain encrypted delivery.

[0047] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0048] Decentralized and trustworthy adjudication eliminates single point of failure risk: A decentralized governance system is built through blockchain smart contracts. The attribute domain authority contract realizes the decentralized issuance of attributes, and the permission adjudication contract automatically executes the adjudication. All attributes, strategies and adjudication results are recorded on the blockchain, which is immutable and verifiable. This completely solves the single point of trust and failure risk of centralized solutions and realizes decentralized and trustworthy execution of cross-organizational access permission determination.

[0049] Fine-grained dynamic access control, adaptable to complex collaborations: The attribute-based access control model does not require predefined role relationships. It achieves unified modeling and dynamic matching of access conditions for multiple subjects, multiple resources, and multiple dimensions through policy quadruples, avoiding the role expansion and maintenance problems of traditional RBAC models. Policies support version management and dynamic updates, which can flexibly adapt to scenarios with complex and frequently changing permission relationships in cross-organizational collaborations, and realize fine-grained on-demand data sharing.

[0050] Strong consistency between on-chain and off-chain operations reduces security risks: On-chain adjudication evidence events serve as the sole triggering source for off-chain delivery, achieving logical decoupling between access control and data delivery and establishing a strong causal relationship between the two; the permission adjudication contract serves as the sole request entry point, hiding the data service endpoint when unauthorized, significantly reducing the risk of invalid or malicious requests reaching the data source, and resolving the hidden dangers of inconsistent timing and asynchronous states in on-chain and off-chain interactions.

[0051] Efficient key management and encryption protection enhance scalability: The layered identity encryption scheme generates identity paths based on backbone attribute mapping, enabling encryption without a complex certificate system and reducing the operational costs of cross-organization certificate management; user-level private keys can be derived along the organizational hierarchy, eliminating the need for centralized maintenance of all subject keys, adapting to the growth of subject size and dynamic adjustments to organizational structure, and avoiding the single point of failure risk of centralized key management.

[0052] End-to-end auditing and traceability to meet compliance requirements: All data access requests, attribute changes, policy updates, and adjudication results are recorded in the form of blockchain transactions or events. Any access behavior can be traced back to the specific requesting entity, the applicable policy version, and the adjudication time, providing a reliable basis for post-event auditing and compliance supervision, and clarifying data access responsibilities. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 This is a schematic diagram of the architecture of the cross-organizational data sharing method with on-chain adjudication event-driven and layered identity encryption of the present invention. It shows the hierarchical relationship of the governance and policy layer, the trusted adjudication and audit layer, and the encrypted delivery layer, as well as the interaction logic of data requesters, data resource owners, and multi-attribute authoritative entities in the on-chain and off-chain environments.

[0055] Figure 2 This is a schematic diagram of the on-chain permission adjudication and trusted adjudication evidence event generation process based on attributes of the present invention, showing the complete process of data access request from submission, attribute / policy query, effective policy filtering, matching judgment to adjudication evidence event publication;

[0056] Figure 3 This is a schematic diagram illustrating the mapping relationship between the organizational structure hierarchy and the hierarchical identity key system of this invention. It shows the process of constructing public keys (based on backbone attributes) and deriving private keys level by level from the group level (top level) to the user level (bottom level). Detailed Implementation

[0057] 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.

[0058] The architectural diagram of the present invention is as follows: Figure 1As shown, it can be divided into a governance and strategy layer, a data request and trusted adjudication layer, and a cryptographic delivery layer. Specifically, the governance and strategy layer is located on the blockchain and consists of multiple collaborative governance smart contracts, used to form an authoritative source of facts for subject attributes, resource attributes, and access policies; the data request and trusted adjudication layer is also deployed on the blockchain, responsible for automatically and verifiable permission adjudication of data access requests and generating standardized adjudication evidence events; the cryptographic delivery layer is located off-chain, and is only triggered by on-chain adjudication events, driving the data owner to be responsible for executing the encrypted data delivery.

[0059] In this embodiment, taking "a junior engineer in the R&D department of Group A requesting data C from Group B" as an example, the system participants include: the data requester, namely the junior engineer in the R&D department of Group A, whose blockchain account address is 0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2; and the data resource owner, namely the data center manager of Group B, whose blockchain account address is 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4. The authoritative entities, namely the identity and security management departments of Group A and Group B respectively, have blockchain account addresses of 0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db and 0x78731D3Ca6b7E34aC0F824c42a7cC18A495cabaB. The blockchain network adopts a consortium blockchain model, with participating parties such as Group A and Group B deploying and running blockchain nodes respectively, jointly participating in consensus maintenance and ledger synchronization.

[0060] In this use case, the present invention provides a cross-organizational data sharing method and system based on blockchain trusted adjudication event-driven approach. The specific implementation method includes the following three stages: governance and policy construction stage, data request and trusted adjudication stage, and encrypted delivery stage.

[0061] 1. Governance and Strategy Building Phase:

[0062] This invention establishes attribute facts and policies for attribute-based access control through on-chain smart contracts during the governance and strategy construction phase, unifying and solidifying the subject identity, resource attributes, and access policies involved in cross-organizational data sharing into a unified blockchain state. Specifically, subject attributes and resource attributes are treated as on-chain facts and maintained by different authoritative entities. Subject attributes include at least two categories: core attributes and extended attributes. Core attributes are basic attributes possessed by every subject, including at least their organization, department level, and job level. Extended attributes are supplementary attributes that can be flexibly defined according to business needs to support more granular attribute-based access control. In this invention, the subject core attributes are used not only for on-chain adjudication but also to construct a hierarchical identity path for the subsequent encrypted delivery phase, achieving a consistent association between adjudication evidence and encrypted identity.

[0063] Access control policies adopt an attribute-based policy expression model, defined as an access control policy quadruple.<SubjectAttributes, ResourseAttributes, Action, EnvContext> The environment context EnvContext contains at least the policy start time and end time conditions. All policies have a unique policy version identifier, which will be referenced in the subsequent adjudication and cryptographic delivery stages to trace the basis of on-chain adjudication.

[0064] The aforementioned governance and strategy development phase specifically includes the following steps:

[0065] Step 1.1: Group A and Group B, as members of the consortium blockchain, deploy and run blockchain nodes respectively to jointly maintain the ledger and consensus; and deploy the following set of smart contracts on the consortium blockchain for attribute-based access control: Subject Attribute Management Contract (address 0x99CF4c4CAE3bA61754Abd22A8de7e8c7ba3C196d), used to store, query, and update subject attribute facts; Resource Attribute Management Contract (address 0xd7B63981A38ACEB507354DF5b51945b) acbe28414), used to store, query, and update resource attribute facts; Policy Management Contract (address 0xC03226fEBD45ca82BAfEC6Ca72F863f5158f395a), used to register, query, and maintain access control policies and their versions; Attribute Domain Authority Contract (address 0x746C5707Bfd8a4Be44332F21AC78A28e9340a9F4), used to maintain the mapping relationship between attribute domains and attribute authority entities and to verify attribute write permissions.

[0066] Step 1.2: Initialize the mapping relationship between "attribute domain and attribute authority entity" through the attribute domain authority contract. Map the subject attribute domains such as the main organization / department level / job level of Group A to the address of the identity management department of Group A, and map the resource attribute domains such as the resource sensitivity level / resource classification of Group B to the address of the security management department of Group B. Based on this, perform permission verification for subsequent attribute writing and updating.

[0067] Step 1.3: The attribute authority entity (0x4B…) writes or updates the subject attributes through the subject attribute management contract using the blockchain account address 0xAb… as the data requester with SubjectID A Group. The core attributes include at least the organization Org=OrgA (Group A), the department level Deptment=RD (R&D Department), and the job level PositionLevel=J1 (Junior Engineer). Additional extended attributes (such as Project=Project X, Clearance=Internal, etc.) can be added as needed to support more granular strategy expression.

[0068] Step 1.4: The data resource owner (0xB1...) registers the unique resource identifier ResourceID RC1001 and its resource attribute set for "Group B's Data C" through the resource attribute management contract, such as Org=OrgB (Group B), DataCategory=Monthly Budget, Sensitivity=2, etc., so that the resource attribute facts can be obtained on the chain by using ResourceID as an index.

[0069] Step 1.5: The data resource owner (0xB1…) constructs an access control policy quadruple based on on-chain queryable subject attribute facts, resource attribute facts, request operation type, and environment context, and registers it through the policy management contract. Simultaneously, it generates and maintains the policy version number. For resource RC1001, the registered policy must satisfy: SubjectAttributes satisfy Org=OrgA and Deptment=RD, PositionLevel≥J1; ResourceAttributes satisfy DataCategory=MonthlyBudge and Sensitivity≤2, Action=READ; and EnvContext is the policy's effective block time StartTime=1767858323 to its expiration block time EndTime=1770536722 (i.e., valid for one month). Its policy version number… It is 0.

[0070] Data Request and Trusted Adjudication Phase:

[0071] In this stage, the present invention uses the on-chain permission adjudication contract as the sole entry point for data access requests, such as... Figure 2 As shown, all data access requests must be submitted as blockchain transactions and permission decisions must be made on-chain. Each access request is defined as the following four-tuple of data requests:<SubjectID, ResourceID, Action, CallBack> Wherein, SubjectID is the blockchain account identifier of the data requesting subject, ResourceID is the unique identifier of the resource, Action is the type of operation to be performed, and CallBack is the data receiving address used in the delivery phase.

[0072] Upon receiving a data access request transaction, the permission adjudication contract first uses the SubjectID carried in the request as an index to read the corresponding subject attribute facts from the subject attribute management contract; and then uses the ResourceID as an index to read the corresponding resource attribute facts from the resource attribute management contract. Simultaneously, based on the resource identifier and the request operation type, the permission adjudication contract queries the policy registration contract for the set of candidate access control policies associated with it.

[0073] Subsequently, the permission adjudication contract uses the current block time as the environmental context parameter to determine the effectiveness of the candidate access control policy set, retaining only policies that are effective at the adjudication time. Based on the filtered effective policy set, the permission adjudication contract executes a deterministic attribute matching adjudication process, specifically including: sequentially determining whether the request subject's subject attributes meet the SubjectAttributes conditions defined in the policy, whether the requested resource's resource attributes meet the ResourceAttributes conditions, and whether the requested operation meets the Action conditions defined in the policy.

[0074] When at least one access control policy simultaneously meets the above matching conditions, the permission adjudication contract determines that the data access request is permitted; otherwise, the access request is deemed not permitted. The above adjudication process is entirely executed automatically on the blockchain by the permission adjudication contract, and its adjudication results are recorded and published in the form of blockchain events, thereby ensuring the verifiability and immutability of the adjudication process.

[0075] The data request and trusted adjudication phase mentioned above includes the following steps:

[0076] Step 2.1: In this embodiment, the data requester (0xAb…) constructs a data access request quadruple based on the business requirement of “requesting data C from Group B” and initiates an on-chain transaction. The quadruple includes at least SubjectID=0xAb…, ResourceID=RC1001 (the unique identifier of data C), Action=READ, and a callback endpoint CallBack=CB for subsequent data delivery. The request transaction is then submitted to the permission adjudication contract of the consortium blockchain.

[0077] Step 2.2: After receiving the request transaction, the permission adjudication contract reads the subject trunk attributes and extended attributes from the subject attribute management contract using SubjectID=0xAb… as the index, and reads the resource attribute facts from the resource attribute management contract using ResourceID=RC1001 as the index. At the same time, it retrieves the associated candidate access control policies from the policy management contract based on ResourceID and Action, and filters out the effective policy set in combination with the current block time.

[0078] Step 2.3: In this embodiment, the permission adjudication contract executes a deterministic attribute matching adjudication process on each of the filtered policies, sequentially determining whether the subject attribute meets the policy SubjectAttributes condition, whether the resource attribute meets the ResourceAttributes condition, and whether the request operation meets the Action condition. When at least one policy meets the above conditions, it is determined to Allow; otherwise, it is determined to Deny. The final adjudication result is then bound to the version number of the matched policy and output.

[0079] Step 2.4: After completing the adjudication, the authorization adjudication contract calls the audit contract to publish a "Trusted Adjudication Evidence Event" in the form of a blockchain event. This event includes at least: the transaction hash (TxHash) for this adjudication, SubjectID=0xAb…, ResourceID=RC1001, Action=READ, the adjudication result (Decision (Allow / Deny), and the policy version. =0, and DecisionDigest; wherein the credible decision evidence event is generated by the audit contract called during the execution of the decision transaction and written to the transaction receipt log, supporting Group A, Group B and the auditor to trace and provide evidence of "who accessed which resources, when, and based on what strategy, and obtained what decision result".

[0080] Encrypted delivery phase:

[0081] During the encrypted delivery phase, this invention employs an on-chain event-driven mechanism, using on-chain adjudication evidence events as the sole trigger for off-chain data delivery. The encrypted delivery layer continuously monitors adjudication evidence events published on the blockchain, and only when the adjudication result indicates that access is permitted, it drives the encrypted delivery layer to execute the corresponding data encryption and delivery operations.

[0082] During a data delivery process, to prevent the adjudication result from being replayed, tampered with, or reused across requests, the data resource owner constructs encrypted input for the shared data resource used in this access request. This data resource is then bound to key information from the on-chain adjudication evidence before encryption. By directly incorporating the adjudication evidence into the encrypted input, the generated ciphertext is logically valid only for this specific adjudication result.

[0083] Specifically, the data resource owner associates the adjudication transaction hash, the applicable policy version number, and the adjudication result summary with the data resource to form data binding information for encryption. The adjudication transaction hash is used to uniquely identify this access request, the policy version number is used to constrain the consistency between the delivery behavior and the specific policy state, and the adjudication result summary is used to protect the adjudication result and its context.

[0084] In this invention, the data resource owner reads the unique identifier of the requesting subject (i.e., the blockchain address of the requesting subject) and the backbone attributes from the adjudication evidence event, and constructs the layered identity path in the layered identity encryption mechanism accordingly:

[0085]

[0086] Subsequently, the data resource owner uses the hierarchical identity path ID as the public key to perform hierarchical identity encryption on the data resource and its bound information, generating a ciphertext delivery packet:

[0087]

[0088] in, This indicates an identity encryption operation based on a hierarchical identity path. The resulting ciphertext delivery packet can only be successfully decrypted by a requesting entity whose identity level matches the stated identity path and whose adjudication evidence consistency verification passes.

[0089] like Figure 3As shown, the hierarchical identity key system of this invention corresponds to organizational levels. The requester's identity path, i.e., the backbone attribute of the requesting subject on the chain, serves as the public key. The requesting subject's private key is derived and distributed by the hierarchical key management entity of its organization according to organizational level. In a data request process, after submitting an access request on the chain, the requesting subject can wait in parallel for the release of on-chain adjudication evidence events and the acquisition of the corresponding user-level identity private key. When both are satisfied, the requesting subject can use its user-level identity private key to complete data decryption, thereby avoiding premature exposure of decryption capabilities before the on-chain adjudication is completed.

[0090] The specific implementation steps of the above-mentioned encrypted delivery phase are as follows:

[0091] Step 3.1: Group B, the data resource owner, continuously subscribes to trusted adjudication evidence events issued by the permission adjudication contract on the consortium blockchain, and verifies the existence and consistency of the event based on the adjudication transaction receipt. Only when the transaction receipt corresponding to the event is verifiable and the adjudication result is Allow, the subsequent encrypted delivery process is triggered, and the TxHash, PolicyVersion, and DecisionDigest carried by the event are recorded as the binding basis for this delivery.

[0092] Step 3.2: The data resource owner reads the request subject identifier and its core attribute mapping information from the verified adjudication evidence event and constructs a hierarchical identity path for the data requester (Group A, R&D Department, Junior Engineer, On-chain Request Subject Identifier), i.e., ID_Path=(OrgA, RD, J1, 0xAb…); then, hierarchical identity encryption is performed on the data C to be delivered using the hierarchical identity path, and TxHash, PolicyVersion, DecisionDigest are bound to the current encryption input and encapsulated into a ciphertext delivery package Pkg, which is pushed to the data requester according to the delivery endpoint agreed in the request, thereby preventing the delivered content from being replayed, tampered with, or reused across requests.

[0093] Step 3.3: After receiving the data, the requester first verifies the consistency of TxHash, PolicyVersion, and DecisionDigest in Pkg based on the on-chain adjudication evidence event and transaction receipt. Then, the requester applies to use the HIBE private key that matches its identity path to complete the decryption and obtain the plaintext of data C, thereby achieving verifiable consistency between "on-chain trusted adjudication evidence" and "off-chain encrypted delivery content".

[0094] This invention provides an on-chain event-driven data sharing method. The encrypted delivery process of shared data is driven by on-chain adjudication events, so that the off-chain encrypted delivery process no longer relies on active queries or centralized callback mechanisms, but uses on-chain adjudication evidence events as the only trusted trigger source. This logically decouples access control and data security, and establishes a strong and consistent causal relationship between on-chain adjudication results and off-chain data delivery behavior. In addition, the on-chain trusted adjudication layer, as the only entry point for data requests, effectively hides the address of the data service endpoint, reducing the risk of invalid requests reaching the data service endpoint.

[0095] This invention provides an attribute-based on-chain access control mechanism at the governance and strategy layer and the trusted adjudication and audit layer. By uniformly modeling and dynamically matching subject attributes, object attributes, and environmental context conditions, it achieves refined description and adjudication of access conditions for multiple subjects, multiple resources, and multiple dimensions without relying on predefined role relationships. This effectively supports the access control needs of complex and frequently changing permission relationships in cross-departmental data sharing scenarios between enterprises, avoiding the problems of role bloat and maintenance difficulties that traditional role-based access control models are prone to in cross-domain collaboration. At the same time, the access control adjudication logic is deployed on the blockchain in the form of smart contracts. The relevant attribute states and policy rules are maintained on-chain data and automatically executed by the contract. The adjudication results are recorded and published in an immutable manner, thereby achieving decentralized and verifiable execution of cross-organizational access permission determination and eliminating the trust risks caused by single point of control or post-event tampering in centralized authorization models.

[0096] This invention employs a layered identity encryption mechanism at the encryption delivery layer, providing fine-grained encrypted data security. Specifically, in the context of encryption applications for data sharing between enterprise departments, requesting entities naturally possess clear hierarchical characteristics, such as their organization, department level, and job level. This invention directly maps the requesting entity's core attributes to an identity path, enabling the encryption party to complete encryption solely based on the requesting entity's core attributes. This avoids the complex trust and maintenance costs introduced by cross-departmental certificate issuance, distribution, and verification in traditional certificate-based public key systems. Simultaneously, the private key can be derived hierarchically along the organizational level, allowing key management to naturally expand with the organizational structure. There is no need to centrally maintain keys for all entities. Compared to flat identity or centralized key management mechanisms, this invention offers excellent scalability as the entity size grows or the organization adjusts, and effectively avoids threats such as single points of failure.

[0097] Each access request and its ruling result are recorded on the blockchain in the form of transactions and events. This invention supports the auditing and accountability of cross-institutional data access behavior, so that any data access result can be traced back to the specific requesting entity, the applicable policy version and the ruling time, thereby providing a reliable basis for post-event auditing and compliance supervision.

[0098] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings, but the present invention is not limited to the described embodiments. For those skilled in the art, various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the present invention, and these variations still fall within the protection scope of the present invention.

Claims

1. A cross-organizational data sharing method with on-chain adjudication event-driven and hierarchical identity encryption, characterized in that: The governance and policy building phase, the data request and trusted decision-making phase, and the encrypted delivery phase are executed in sequence. The governance and policy building phase comprises the following steps: Step 1.1: deploying and running a set of smart contracts for attribute-based access control on a blockchain, the set of smart contracts comprising at least a subject attribute management contract, a resource attribute management contract, a policy management contract, and an attribute domain authority contract; Step 1.2: initializing a mapping relationship between an attribute domain and a corresponding attribute authority entity through the attribute domain authority contract; Step 1.3: the attribute authority entity writes or updates subject attributes for a data requester in the subject attribute management contract, the subject attributes being divided into main attributes and extended attributes, wherein the main attributes are basic attributes possessed by each subject and at least include an organization to which the subject belongs, a department level, and a post level; Step 1.4: a data resource owner registers a resource unique identifier and a corresponding resource attribute set for a data resource through the resource attribute management contract; Step 1.5: the data resource owner constructs an access control policy four-tuple based on subject attributes, resource attributes, operation types, and environmental context, and registers the access control policy in the policy management contract, while generating and maintaining a corresponding policy version number; The data request and trusted decision-making phase comprises the following steps: Step 2.1: a data requester constructs and submits a data access request transaction containing a subject identifier, a resource identifier, a request operation, and a data receiving address to a permission decision contract; Step 2.2: the permission decision contract reads subject attribute facts from the subject attribute management contract, reads resource attribute facts from the resource attribute management contract, and queries associated candidate policies from the policy management contract based on the resource identifier and the request operation, and filters out an effective policy set in combination with the current block time; Step 2.3: the permission decision contract performs attribute matching and operation matching judgment on each of the effective policy set, and generates a decision result allowing access when at least one policy satisfies subject attribute matching, resource attribute matching, and operation matching; Step 2.4: an audit contract encapsulates a request subject unique identifier, subject main attributes, a decision transaction hash, a decision result, and a corresponding policy version number into a decision evidence event and publishes it to a blockchain; The encrypted delivery phase comprises the following steps: Step 3.1: continuously monitoring the decision evidence event on the blockchain, performing consistency verification on the decision result and key information of the decision evidence event, and driving a data resource owner to perform data delivery after the verification is passed; Step 3.2: the data resource owner binds a data resource to be shared with the decision transaction hash, the policy version number, and the decision digest based on the decision evidence event, constructs a hierarchical identity path based on the unique identifier and the main attributes of the request subject, performs an encryption operation based on the hierarchical identity path as an encryption public key, generates a ciphertext delivery package, and pushes it to the data receiving address. Step 3.3: After obtaining the user-level identity private key corresponding to the hierarchical identity path, the data requester decrypts the ciphertext delivery package to recover the corresponding data resource content.

2. The cross-organizational data sharing method of chain-on-stake adjudicated event-driven and layered identity-encrypted according to claim 1, characterized in that: The attribute domain authority contract in step 1.1 is used to maintain the mapping relationship between the attribute domain and multiple attribute authority entities, implementing decentralized governance; and when the subject attribute fact is written or updated, the attribute domain authority contract checks the permission of the caller to ensure that the source of the subject attribute fact is trustworthy.

3. The cross-organizational data sharing method of chain-on-stake adjudicated event-driven and layered identity-encrypted according to claim 2, characterized in that: The main attribute in step 1.3 is used not only for on-chain decision-making in the data request and trusted decision-making stage, but also for constructing the hierarchical identity path in the encrypted delivery stage, realizing consistent association of decision-making evidence and encrypted identity; the extended attribute is a supplementary attribute defined flexibly according to business needs, used to support fine-grained attribute-based permission control.

4. The chain-on-resolution event-driven and layered identity-encrypted cross-organization data sharing method according to claim 3, characterized in that: The environment context in the four-tuple of the access control policy in step 1.5 at least includes the policy effective start time and the effective end time; the permission decision contract takes the current block time as the decision context parameter to filter the effectiveness of the candidate policy, and only the policy within the effective start time to the effective end time interval is determined as the effective policy set to participate in subsequent decision-making.

5. The chain-on-resolution event-driven and layered identity-encrypted cross-organizational data sharing method according to claim 1, characterized in that: The permission decision contract in step 2.1 is the only entrance for data access requests, all data access requests are submitted in the form of a block chain transaction and the permission decision is completed on the chain; before the decision-making evidence event allowing access is generated, the data resource service endpoint is invisible to the data requester, reducing the risk of invalid requests or malicious requests directly reaching the data source.

6. The chain-on-resolution event-driven and layered identity-encrypted cross-organization data sharing method according to claim 5, characterized in that: The attribute matching and operation matching judgment in step 2.3 specifically includes: the permission decision contract matches the on-chain subject attribute fact with the subject attribute constraint of the effective policy, matches the on-chain resource attribute fact with the resource attribute constraint of the effective policy, and matches the request operation with the operation constraint of the effective policy; when the above three matching conditions of any effective policy are all met, the decision result allowing access is output and the audit contract is triggered to issue the decision-making evidence event; otherwise, the decision result rejecting access is output.

7. The chain-on-chain adjudicated event-driven and layered identity-encrypted cross-organizational data sharing method of claim 6, wherein: The decision-making evidence event in step 2.4 is the only trusted trigger source for off-chain data delivery, driving off-chain data sharing; the encrypted delivery stage does not actively participate in permission determination, but passively responds only when the on-chain decision result corresponding to the decision-making evidence event is triggered.

8. The cross-organizational data sharing method of chain-based adjudicative event-driven and layered identity-encrypted according to claim 1, characterized in that: The consistency check in step 3.1 specifically includes: based on the decision transaction hash in the decision-making evidence event, the corresponding transaction receipt is obtained, the event log in the transaction receipt is checked, and the authenticity and integrity of the decision-making evidence event are confirmed; after the check passes, the step of entering the encrypted delivery stage is allowed.

9. The chain-on-chain adjudicated event-driven and layered identity-encrypted cross-organizational data sharing method of claim 8, wherein: The ciphertext delivery package in step 3.3 at least includes ciphertext data, decision transaction hash, policy version number, and decision summary; before decryption, the data requester performs consistency check based on the decision transaction hash, policy version number, and decision summary in the ciphertext delivery package with the decision-making evidence event on the block chain, and confirms the authenticity of the data delivery process before performing the decryption operation.

Images