A multi-party supervision data management method

Abstract

The present invention specifically relates to a multi-party supervision data management method, comprising the following steps: creating distributed digital identities for all supervision participants; defining different categories of supervision data and their sensitivity levels; when a supervision participant needs to obtain supervision data, the participant needs to initiate a data authorization request to a supervision unit; after receiving the request, the supervision unit decides whether to approve the request based on the identity authentication and data access rules of the requester; if the request is approved, the supervision unit will issue a verifiable statement through its own identity private key and the distributed digital identity of the requester; after receiving the verifiable statement, the construction unit sends it together with the data acquisition request to the data provider; after receiving the request, the data provider extracts the information in the verifiable statement; the data provider uses the identity public key of the requester to verify the verifiable statement, and after confirming that it is correct, provides corresponding supervision data according to the authorization scope in the verifiable statement.

Description

Technical Field

[0001] The present invention belongs to the field of data management, and in particular relates to a multi-party supervision data management method. Background Art

[0002] In the field of engineering construction and supervision, supervision data usually involves information on project management, engineering progress, quality inspection, etc. These data often contain sensitive corporate information and personal privacy, such as financial data, contract terms, personnel arrangements, etc. Existing data management methods are insufficient in ensuring data security, which can easily lead to data leakage and abuse, thus affecting the interests and reputation of enterprises.

[0003] Supervision work often involves multiple parties, including construction units, supervision units, construction units, etc. In the case of multiple parties, how to establish a mutual trust mechanism and ensure that all parties can abide by the common data usage rules is a difficult point. The existing data sharing mechanism lacks effective means of trust building, resulting in information asymmetry and lack of trust in the cooperation process.

[0004] Supervision data will change over time, such as changes in project progress, discovery of quality problems, etc. Existing data management systems often cannot achieve real-time updates and synchronization, making it difficult to ensure the timeliness and accuracy of data. This not only affects the decision-making efficiency of the project, but may also lead to wrong decisions.

[0005] In a multi-party collaborative environment, data consistency is very important. If there is information asymmetry between different participants or data is not updated in a timely manner, it may lead to wrong decisions. Existing data management methods lack an effective mechanism to ensure the consistency of data throughout the life cycle, which easily leads to information islands and data conflicts.

[0006] Different roles need to access different types of data. For example, supervision engineers need to check the construction progress, while quality inspectors are more concerned about material quality and construction technology. Existing permission management systems are often too rigid and cannot flexibly adapt to the needs of different roles, resulting in excessive exposure of information or limited access, affecting work efficiency.

[0007] In summary, the problems of the existing technology are:

[0008] Data security issues: Existing data management methods lack effective security measures, which can easily lead to the leakage and abuse of sensitive data. Traditional centralized data storage methods increase the risk of data being attacked and cannot meet high security requirements.

[0009] Insufficient trust mechanism: The existing data sharing mechanism lacks effective means of building trust, resulting in information asymmetry and lack of trust between participants. This not only affects the efficiency of cooperation, but may also lead to legal disputes and economic losses.

[0010] Insufficient management of data timeliness and dynamics: The existing data management system cannot achieve real-time updates and synchronization, making it difficult to ensure the timeliness and accuracy of data. This affects the decision-making efficiency of the project and may lead to wrong decisions.

[0011] Data consistency issues: Existing data management methods lack an effective mechanism to ensure data consistency throughout the entire life cycle, which can easily lead to information islands and data conflicts. This not only increases management difficulty, but can also lead to wrong decisions.

[0012] Inflexible rights management: Existing rights management systems are often too rigid and cannot flexibly adapt to the needs of different roles, resulting in excessive exposure of information or restricted access, affecting work efficiency. This not only increases management costs, but may also lead to information leakage and abuse. Summary of the invention

[0013] The purpose of the present invention is to provide a multi-party supervision data management method to solve the problems raised in the above background technology.

[0014] In order to solve the above technical problems, the present invention provides the following technical solutions:

[0015] A multi-party supervision data management method comprises the following steps:

[0016] Create distributed digital identities for all supervisory participants and register these distributed digital identities and their public keys in the distributed ledger system;

[0017] Assign corresponding distributed digital identity information to each participant and ensure that this information can be accessed by all participants for identity verification;

[0018] Define different categories of supervision data and their sensitivity levels, including project management information, engineering progress, and quality inspection reports;

[0019] When a supervision participant needs to obtain supervision data, the participant needs to initiate a data authorization request to the supervision unit;

[0020] After receiving the request, the supervision unit decides whether to approve the request based on the identity authentication and data access rules of the requester;

[0021] If the request is approved, the supervisor will issue a verifiable statement using its own private key and the requester’s distributed digital identity;

[0022] After receiving the verifiable statement, the construction unit sends it to the data provider together with the data acquisition request;

[0023] After receiving the request, the data provider extracts the information in the verifiable statement and obtains the public key of the requester's identity from the distributed ledger system through the requester's distributed digital identity;

[0024] The data provider uses the requester's identity public key to verify the verifiable statement. After confirmation, it provides the corresponding supervision data according to the authorization scope in the verifiable statement.

[0025] Furthermore, it also includes that the data provider can process the data according to the instructions in the verifiable declaration before providing the supervision data; it also includes that after the processing is completed, the data provider encrypts the processing results and sends them to the requesting party; it also includes that if the supervision unit decides to revoke the authorization, the status information of the verifiable declaration can be changed by sending a revocation request to the distributed ledger system.

[0026] Furthermore, distributed digital identities are created for all supervisory participants, and these distributed digital identities and their public keys are registered in the distributed ledger system. Specifically, the following are included:

[0027] Generate identity public and private keys:

[0028] Use an asymmetric encryption algorithm to generate a pair of public and private keys for each participant. The private key is kept properly by the participant, and the public key is used in the subsequent registration and verification process.

[0029] Construct a distributed digital identity document containing the public key and basic information of the participants; the distributed digital identity document will serve as a digital proof of the identity of the participants;

[0030] Generate a registration transaction based on the distributed digital identity document; the transaction contains all the information of the distributed digital identity document and is signed by the identity private key of the participant to ensure the authenticity of the transaction;

[0031] Submit the generated registration transaction to the distributed ledger system; the distributed ledger system will execute the transaction and store the distributed digital identity document in its distributed ledger;

[0032] After submitting the registration transaction, confirm whether the distributed digital identity document has been successfully registered through the query interface of the distributed ledger system; the query results will display the status of the distributed digital identity document and any error information.

[0033] Further, different categories of supervision data are defined including:

[0034] Project management information, including the overall project plan, budget, contract terms, personnel arrangements, and meeting minutes;

[0035] Project progress information, including construction progress, completion status of key nodes, and construction log related information;

[0036] Quality inspection report: The quality inspection report includes quality inspection results, quality accident records, and rectification suggestions and related information.

[0037] Furthermore, when a supervision participant needs to obtain supervision data, the participant needs to initiate a data authorization request to the supervision unit, including:

[0038] The construction unit determines the specific types of supervision data that need to be obtained;

[0039] The construction unit signs the request using its own private key;

[0040] The construction unit sends the signed request to the supervision unit through a secure communication channel;

[0041] The request should clearly list the specific categories and subcategories of the supervision data that need to be obtained;

[0042] The request should also include the distributed digital identity information of the requesting party;

[0043] The request should also include the public key of the requesting party so that the supervision unit can verify the signature when issuing the verifiable statement;

[0044] The request should include the timestamp of the request, the unique identifier of the requesting party, and a description of the data required;

[0045] After sending the request, the construction unit should wait for the confirmation reply from the supervision unit to ensure that the request has been received.

[0046] Furthermore, after receiving the request, the supervision unit decides whether to approve the request based on the identity authentication and data access rules of the requester, including:

[0047] After receiving the request, the supervision unit first obtains the identity public key of the requester from the distributed ledger system through the distributed digital identity information in the request;

[0048] Use the requester's identity public key to verify the request;

[0049] Based on the data categories and subcategories in the request, the supervision unit checks its preset data access rules to determine whether the requester has the authority to access the required supervision data;

[0050] If the requester's authority level is insufficient to access the requested data, the supervisory authority shall reject the request and provide reasons for the rejection.

[0051] Furthermore, if the request is approved, the supervisory unit will issue a verifiable statement using its own private key and the requester’s distributed digital identity, specifically:

[0052] The supervision unit generates a verifiable statement based on the data category and subcategory in the request. The verifiable statement contains the authorization scope, validity period and distributed digital identity information of the requester.

[0053] The supervision unit uses its own private key to sign the verifiable statement, and the signed verifiable statement is sent to the requester through a secure channel.

[0054] Further, after receiving the verifiable statement, the construction unit sends it together with the data acquisition request to the data provider specifically:

[0055] The construction unit prepares data acquisition requests according to the standardized request format;

[0056] The request should include the distributed digital identity information of the construction unit, the request timestamp, and the specific description of the required data;

[0057] The construction unit embeds the verifiable statement into the data acquisition request to ensure that the verifiable statement is closely associated with the request content;

[0058] The request should clearly indicate the existence and location of the verifiable claim so that the data provider can easily identify and extract the verifiable claim;

[0059] Use the construction unit's identity private key to sign the data acquisition request to ensure the authenticity and integrity of the request;

[0060] Encrypt the entire request to ensure data security during transmission;

[0061] The request should also include the public key of the construction unit so that the data provider can verify the validity of the verifiable statement after receiving the request;

[0062] A data retrieval request with a verifiable claim is sent to the data provider via a secure communication channel.

[0063] Further, after receiving the request, the data provider extracts the information in the verifiable statement and obtains the public key of the requester's identity from the distributed ledger system through the distributed digital identity of the requester. Specifically:

[0064] The data provider extracts the verifiable claim from the received data acquisition request;

[0065] Using the distributed digital identity of the requesting party, obtaining the identity public key of the requesting party from the distributed ledger system;

[0066] Query the distributed digital identity document of the requester through the API interface of the distributed ledger system and extract the identity public key from it;

[0067] Confirm that the requester's identity public key matches the distributed digital identity in the request.

[0068] Furthermore, the data provider uses the identity public key of the requester to verify the verifiable statement. After confirmation, the corresponding supervision data is provided according to the authorization scope in the verifiable statement.

[0069] Use the requester's public key to verify the verifiable statement.

[0070] The signature verification process includes verifying whether the signature of the verifiable statement is correct and whether the information in the verifiable statement has been tampered with;

[0071] Confirm that the authorization scopes in the verifiable claim match the data categories and subcategories in the request;

[0072] Verify whether the valid time of the verifiable claim covers the current request time;

[0073] If the verification of the verifiable claim fails, the data provider shall reject the request and provide feedback to the requesting party on the reason;

[0074] If the verifiable statement is successfully verified, the data provider shall provide the corresponding supervision data according to the authorization scope in the verifiable statement;

[0075] Retrieve the corresponding supervision data from the data storage according to the data description information in the verifiable statement;

[0076] Ensure that the data provided is consistent with the data categories and subcategories specified in the verifiable claim.

[0077] Beneficial effects: Enhanced data security: Through distributed ledger technology, decentralized data storage and management are achieved to ensure data security and immutability. The distributed digital identity system ensures that the identity of each participant is authentic and prevents data from being illegally accessed and tampered with.

[0078] Establish a trust mechanism: Through distributed digital identities and verifiable claims (VCs), a trust mechanism is established between participants. The identity and permissions of each participant can be verified on the distributed ledger to ensure the legal use and sharing of data.

[0079] Realize real-time data update: Utilize the real-time and transparency of distributed ledger technology to ensure real-time update and synchronization of data. Participants can view the latest supervision data at any time to improve the efficiency and accuracy of project decision-making.

[0080] Ensure data consistency: Through the distributed ledger technology of the distributed ledger, the consistency of data throughout the entire life cycle is ensured. All participants can access the same data source to avoid information silos and data conflicts.

[0081] Flexible permission management: By defining different categories of supervision data and their sensitivity levels, corresponding description information and access rules are created for each data category. Participants can access the required data according to their roles and permissions, ensuring the reasonable use and protection of information. BRIEF DESCRIPTION OF THE DRAWINGS

[0082] Figure 1 This is a block diagram of the multi-party supervision data management system of the present invention. DETAILED DESCRIPTION

[0083] The following will be combined with the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0084] The present application discloses a multi-party supervision data management method, comprising the steps of:

[0085] Initialization phase:

[0086] Step 1.1: Create distributed digital identities (DIDs) for all supervision participants (including construction units, supervision units, and construction units), and register these DIDs and related information (such as identity public keys) in the distributed ledger system.

[0087] Create distributed digital identities (DIDs) for all supervision participants (including construction units, supervision units, and construction units), and register these DIDs and related information (such as identity public keys) in the distributed ledger system. Specifically, the following information is included:

[0088] Creating a DID

[0089] Generate identity public and private keys:

[0090] Use an asymmetric encryption algorithm (such as RSA or ECC) to generate a pair of public and private keys for each participant. The private key is kept safe by the participant, and the public key is used in the subsequent registration and verification process.

[0091] Define the DID format:

[0092] The format of DID should follow international standards, such as the W3C DID specification. Each DID will contain a unique identifier (such as "did:example:123456789abcdefghi"), which will be registered in the distributed ledger system.

[0093] Registering a DID

[0094] Build the DID document:

[0095] Construct a DID document containing the public key, basic information of the participants (such as name, contact information), and other necessary metadata. The DID document will serve as a digital proof of the identity of the participants.

[0096] Generate a registration transaction:

[0097] Generate a registration transaction based on the DID document. The transaction contains all the information of the DID document and is signed by the identity private key of the participating party to ensure the authenticity of the transaction.

[0098] Submit to the distributed ledger system:

[0099] Submit the generated registration transaction to the distributed ledger system. The distributed ledger system will execute the transaction and store the DID document in its distributed ledger. In this way, the DID of each participant and its related information are registered in the distributed ledger system.

[0100] Confirm registration success

[0101] Query DID status:

[0102] After submitting the registration transaction, confirm whether the DID document has been successfully registered through the query interface of the distributed ledger system. The query result will show the status of the DID document and any error information.

[0103] Verify identity public key:

[0104] Through the API provided by the distributed ledger system, query and download the successfully registered DID document. Use the identity public key of the participant to verify the integrity of the document to ensure that it has not been tampered with.

[0105] Distributing DID Documents

[0106] Share the successfully registered DID document with other participants. This can be done through secure communication channels (such as encrypted email or dedicated file transfer tools) to ensure the secure transmission of information.

[0107] Establishing a mutual trust mechanism:

[0108] By sharing DID documents, all parties can verify each other's identity and establish a relationship of mutual trust. DID documents will become an important trust basis for all parties in the process of data authorization management.

[0109] Create DID to generate identity public key and private key code:

[0110] Python

[0111] 1import rsa 2

[0113] 3# Generate a pair of public and private keys for each participant

[0114] 4def generate_keys():

[0115] 5 (public_key, private_key) = rsa.newkeys(2048)

[0116] 6 return public_key, private_key 7

[0118] 8# Example: Generate the construction unit's identity public key and private key

[0119] 9construction_unit_public_key, construction_unit_private_key =generate_keys() 10

[0121] 11# Example: Generate the public and private keys of the supervision unit

[0122] 12supervision_unit_public_key, supervision_unit_private_key =generate_keys() 13

[0124] 14# Example: Generate the public and private keys of the construction unit

[0125] 15contractor_unit_public_key, contractor_unit_private_key = generate_keys();

[0126] Define the DID format:

[0127] Python

[0128] 1# Define DID format

[0129] 2def define_did(identity_type, identity_id):

[0130] 3 return f"did:example:{identity_type}:{identity_id}" 4

[0132] 5# Example: Define the DID of the construction unit

[0133] 6construction_unit_did = define_did("construction", "123456789abcdefghi") 7

[0135] 8# Example: Define the DID of the supervision unit

[0136] 9supervision_unit_did = define_did("supervision", "987654321zyxwvut") 10

[0138] 11# Example: Defining the DID of a construction unit

[0139] 12contractor_unit_did = define_did("contractor", "abcdefg123456789");

[0140] Build the DID document:

[0141] Python

[0142] 1. import json 2

[0144] 3# Build DID Document

[0145] 4def build_did_document(did, public_key):

[0146] 5 did_document = {

[0147] 6 "@context": ["https: / / www.w3.org / ns / did / v1"],

[0148] 7 "id": did,

[0149] 8 "publicKey": [

[0150] 9 {

[0151] 10 "id": f"{did}#keys-1",

[0152] 11 "controller": did,

[0153] 12 "type": "EcdsaSecp256k1VerificationKey2019",

[0154] 13 "publicKeyBase58": public_key.save_public_key_pem().decode()

[0155] 14}

[0156] 15 ],

[0157] 16 "service": [

[0158] 17 {

[0159] 18 "id": f"{did}#service-1",

[0160] 19 "type": "Email",

[0161] 20 "serviceEndpoint": "email@example.com"

[0162] twenty one} twenty two ]

[0164] twenty three}

[0165] 24 return did_document 25

[0167] 26# Example: Constructing a DID document for a construction unit

[0168] 27construction_unit_did_document=build_did_document(construction_unit_did, construction_unit_public_key) 28

[0170] 29# Example: Constructing a DID document for a supervision unit

[0171] 30supervision_unit_did_document=build_did_document(supervision_unit_did, supervision_unit_public_key) 31

[0173] 32# Example: Constructing a DID document for a construction unit

[0174] 33contractor_unit_did_document=build_did_document(contractor_unit_did, contractor_unit_public_key);

[0175] Generate a registration transaction:

[0176] Python

[0177] 1# Generate registration transaction

[0178] 2def create_registration_transaction(did_document, private_key):

[0179] 3 transaction = {

[0180] 4 "type": "RegisterDIDTransaction",

[0181] 5 "data": did_document

[0182] 6}

[0183] 7 # Sign the transaction

[0184] 8 transaction_json = json.dumps(transaction).encode()

[0185] 9 signature = rsa.sign(transaction_json, private_key, 'SHA-256')

[0186] 10 transaction["signature"] = signature.hex()

[0187] 11 return transaction 12

[0189] 13# Example: Generate a registration transaction for a construction unit

[0190] 14construction_unit_transaction= create_registration_transaction(construction_unit_did_document, construction_unit_private_key) 15

[0192] 16# Example: Generate a registration transaction for a supervision unit

[0193] 17supervision_unit_transaction= create_registration_transaction(supervision_unit_did_document, supervision_unit_private_key) 18

[0195] 19# Example: Generate a registration transaction for a construction unit

[0196] 20contractor_unit_transaction= create_registration_transaction(contractor_unit_did_document, contractor_unit_private_key);

[0197] Submit to the distributed ledger system:

[0198] Python

[0199] 1# Example: Submit to a distributed ledger system (there is a distributed ledger client API)

[0200] 2def submit_to_blockchain(transaction):

[0201] 3 # There is a distributed ledger client API

[0202] 4 blockchain_client.submit_transaction(transaction) 5

[0204] 6# Submit the construction unit's registration transaction

[0205] 7submit_to_blockchain(construction_unit_transaction) 8

[0207] 9# Submit the registration transaction to the supervision unit

[0208] 10submit_to_blockchain(supervision_unit_transaction) 11

[0210] 12# Submit the registration transaction of the construction unit

[0211] 13submit_to_blockchain(contractor_unit_transaction);

[0212] Confirm that the registration is successful and query the DID status:

[0213] Python

[0214] 1# Example: Query DID status (here is a distributed ledger client API)

[0215] 2def query_did_status(did):

[0216] 3 # There is a distributed ledger client API

[0217] 4 status = blockchain_client.query_did_status(did)

[0218] 5 return status 6

[0220] 7# Query the DID status of the construction unit

[0221] 8print(query_did_status(construction_unit_did)) 9

[0223] 10# Query the DID status of the supervision unit

[0224] 11print(query_did_status(supervision_unit_did)) 12

[0226] 13# Query the DID status of the construction unit

[0227] 14print(query_did_status(contractor_unit_did));

[0228] Verify identity public key:

[0229] Python

[0230] 1# Example: Verify identity public key (here is a distributed ledger client API)

[0231] 2def verify_public_key(did, public_key):

[0232] 3 did_document = blockchain_client.get_did_document(did)

[0233] 4 # Use the public key of the participant to verify the integrity of the document

[0234] 5 return rsa.verify(json.dumps(did_document).encode(), did_document["signature"], public_key) 6

[0236] 7# Verify the identity public key of the construction unit

[0237] 8print(verify_public_key(construction_unit_did, construction_unit_public_key)) 9

[0239] 10# Verify the public key of the supervision unit

[0240] 11print(verify_public_key(supervision_unit_did, supervision_unit_public_key)) 12

[0242] 13# Verify the identity public key of the construction unit

[0243] 14print(verify_public_key(contractor_unit_did, contractor_unit_public_key));

[0244] Distributing DID documents:

[0245] Python

[0246] 1# Example: Distributing DID documents (there is a secure communication client API)

[0247] 2def distribute_did_document(did_document):

[0248] 3 # There is a secure communication client API

[0249] 4 secure_communication_client.send_did_document(did_document) 5

[0251] 6# Distribute the DID document of the construction unit

[0252] 7distribute_did_document(construction_unit_did_document) 8

[0254] 9# Distribute the DID document of the supervision unit

[0255] 10distribute_did_document(supervision_unit_did_document) 11

[0257] 12# Distribute the DID documents of the construction unit

[0258] 13distribute_did_document(contractor_unit_did_document);

[0259] Establishing a mutual trust mechanism:

[0260] Python

[0261] 1# Example: Establishing mutual trust (here is a secure communication client API)

[0262] 2def establish_trust(did_document):

[0263] 3 # There is a secure communication client API

[0264] 4 secure_communication_client.receive_did_document(did_document) 5

[0266] 6# Receive the DID document from the construction unit

[0267] 7establish_trust(construction_unit_did_document) 8

[0269] 9# Receive the DID document from the supervision unit

[0270] 10establish_trust(supervision_unit_did_document) 11

[0272] 12# Receive the DID document from the construction unit

[0273] 13establish_trust(contractor_unit_did_document)

[0274] Please note that blockchain_client and secure_communication_client in the above code are client APIs used to interact with the distributed ledger system and secure communication system.

[0275] A multi-party supervision data management method includes step 1.2: assigning corresponding distributed digital identity information (DID document) to each participant and ensuring that the information can be accessed by all participants for identity authentication.

[0276] A multi-party supervision data management method includes the following steps: a data authorization preparation stage:

[0277] Step 2.1: Define different categories of supervision data and their sensitivity levels, including project management information, engineering progress, and quality inspection reports.

[0278] In step 2.1: define different categories of supervision data including:

[0279] Project Management Information:

[0280] Category description: Project management information mainly includes the project's overall plan, budget, contract terms, personnel arrangements, and meeting minutes.

[0281] Subcategories:

[0282] Planning documents: project plan, timeline, milestones.

[0283] Budget documents: cost estimates, financial statements.

[0284] Contract documents: contract text, supplementary agreement.

[0285] Personnel arrangements: personnel list, division of responsibilities, and training records.

[0286] Meeting minutes: meeting records and resolution documents.

[0287] Project progress information:

[0288] Category description: Project progress information mainly includes construction progress, completion status of key nodes, and construction log related information.

[0289] Subcategories:

[0290] Construction log: daily construction records and construction photos.

[0291] Key nodes: milestone completion status and acceptance records.

[0292] Progress Report: Weekly, monthly and annual progress report documents.

[0293] Change records: construction change records, adjustment plans.

[0294] Quality Inspection Report:

[0295] Category description: The quality inspection report mainly includes quality inspection results, quality accident records, and rectification suggestions and related information.

[0296] Subcategories:

[0297] Test results: laboratory test report, on-site test records.

[0298] Accident records: quality accident reports, accident handling records.

[0299] Correction suggestions: Correction notice, Correction plan.

[0300] Audit report: internal audit report, external audit report.

[0301] Step 2.2: Based on the different categories and sensitivity levels of supervision data, create corresponding description information and access rules for each data category.

[0302] Step 2.2: Based on the different categories and sensitivity levels of supervision data, create corresponding description information and access rules for each data category, specifically:

[0303] In order to ensure that different types of supervision data can be properly protected and managed, we need to define sensitivity levels for them. The specific definitions are as follows:

[0304] Level 1 (low sensitivity):

[0305] Category: General project management information, such as meeting minutes, construction logs.

[0306] Access rights: Accessible to all parties, subject to identity verification.

[0307] Authorization scope: Default authorization, no special approval required.

[0308] Level 2 (Medium Sensitive):

[0309] Category: Detailed information related to the progress of specific projects, such as progress reports and change records.

[0310] Access rights: Supervision units and construction units can access, but they must undergo identity authentication and specific authorization.

[0311] Scope of authorization: Access is authorized only after approval by the supervision unit.

[0312] Level 3 (Highly Sensitive):

[0313] Category: sensitive information related to finance, contracts, and quality accidents, such as financial statements, contract texts, and accident records.

[0314] Access rights: Access is limited to supervisory units and specific authorized personnel, and must undergo strict identity authentication and multiple authorizations.

[0315] Scope of authorization: It needs to be approved by the senior management of the supervision unit and a specific verifiable statement (VC) is issued.

[0316] A multi-party supervision data management method, comprising the steps of data authorization request and processing:

[0317] Step 3.1: When a supervision participant (such as a construction unit) needs to obtain supervision data, the participant needs to initiate a data authorization request to the supervision unit. Specifically, it includes:

[0318] The construction unit determines the specific types of supervision data that need to be obtained (such as project management information, construction progress or quality inspection reports).

[0319] The construction unit signs the request using its own identity private key to ensure the authenticity and integrity of the request.

[0320] The construction unit sends the signed request to the supervision unit through a secure communication channel (such as encrypted email or dedicated file transfer tool).

[0321] The request should clearly list the specific categories and subcategories of supervision data that need to be obtained (such as budget documents in project management information and construction logs in engineering progress).

[0322] The request should also include the DID information of the requesting party so that the supervisory unit can verify the identity.

[0323] Request attachment:

[0324] The construction unit may attach relevant supporting materials, such as construction progress reports and quality inspection applications, to explain the reasons and necessity for obtaining supervision data.

[0325] The request should also include the public key of the requesting party so that the supervision unit can verify the signature when issuing the VC.

[0326] Request format:

[0327] Requests should follow a standardized format, such as JSON or XML, to ensure that the request content is structured and parsable.

[0328] The request should include the timestamp of the request, the unique identifier of the requester (such as DID), and a description of the required data.

[0329] Request confirmation:

[0330] After sending the request, the construction unit should wait for the confirmation reply from the supervision unit to ensure that the request has been received.

[0331] Step 3.2: After receiving the request, the supervisory unit decides whether to approve the request based on the identity verification of the requester (verified by DID and public key) and data access rules. Specifically, it includes:

[0332] After receiving the request, the supervision unit first obtains the identity public key of the requester from the distributed ledger system through the DID information in the request.

[0333] The request is signed using the requester's public key to ensure the authenticity and integrity of the request.

[0334] Data access rule check:

[0335] Based on the data categories and subcategories in the request, the supervision unit checks its preset data access rules to determine whether the requester has the authority to access the required supervision data.

[0336] If the requester's authority level is insufficient to access the requested data, the supervisory authority shall reject the request and provide reasons for the rejection.

[0337] Request approval:

[0338] Step 3.3: If the request is approved, the supervisor will issue a verifiable statement (VC) using its own private key and the requester’s DID. Specifically:

[0339] The supervision unit generates VC based on the data category and subcategory in the request, which contains the authorization scope, validity period and DID information of the requester.

[0340] VCs should follow a standardized format (such as the W3C Verifiable Credentials specification) to ensure their verifiability and interoperability.

[0341] VC Signature:

[0342] The supervision unit signs the VC using its own private key to ensure the authenticity and integrity of the VC.

[0343] The signed VC is sent to the requester through a secure channel.

[0344] A multi-party supervision data management method, comprising the steps of data acquisition and verification:

[0345] Step 4.1: After receiving the VC, the construction unit sends it together with the data acquisition request to the data provider (distributed ledger system or dedicated data server).

[0346] Prepare a data retrieval request:

[0347] The construction unit prepares data acquisition requests according to a standardized request format (such as JSON or XML).

[0348] The request should include the DID information of the construction unit, the request timestamp, and the specific description information of the required data (such as data category and subcategory).

[0349] Request attachment:

[0350] If necessary, the construction unit may attach relevant supporting materials (such as construction progress report, quality inspection application) to explain the reasons and necessity for obtaining supervision data.

[0351] Combined request and VC:

[0352] The construction unit embeds VC into the data acquisition request to ensure that VC is closely associated with the request content.

[0353] The existence and location of the VC should be clearly indicated in the request so that the data provider can easily identify and extract the VC.

[0354] Encryption and Signature:

[0355] Encryption request:

[0356] The data acquisition request is signed using the construction unit's identity private key to ensure the authenticity and integrity of the request.

[0357] Use encryption technology (such as TLS / SSL protocol) to encrypt the entire request (including VC) to ensure data security during transmission.

[0358] Additional identity public key:

[0359] The request should also include the public key of the construction unit so that the data provider can verify the validity of the VC after receiving the request.

[0360] Send a request:

[0361] Select data provider:

[0362] Select the data provider, which can be a distributed ledger system or a dedicated data server.

[0363] Secure transmission:

[0364] The data acquisition request with VC is sent to the data provider through a secure communication channel (such as encrypted email or dedicated file transfer tool).

[0365] Step 4.2: After receiving the request, the data provider extracts the information in the VC and obtains the public key of the requester's identity from the distributed ledger system through the DID of the requester. Specifically:

[0366] The data provider extracts VC from the received data acquisition request.

[0367] Ensure that the VC contains necessary information, such as authorization scope, validity period, and DID of the requester.

[0368] Get the identity public key:

[0369] Use the requester's DID to obtain the requester's identity public key from the distributed ledger system.

[0370] The DID document of the requester is queried through the API interface of the distributed ledger system, and the identity public key is extracted from it.

[0371] Confirm that the requester's identity public key matches the DID in the request.

[0372] Step 4.3: The data provider uses the identity public key of the requester to verify the signature of the VC. After confirming that it is correct, it provides the corresponding supervision data according to the authorization scope in the VC.

[0373] The VC is signed using the requester's public key to ensure the authenticity and integrity of the VC.

[0374] The signature verification process includes verifying whether the VC signature is correct and whether the information in the VC has been tampered with.

[0375] Verify VC validity:

[0376] Confirm that the authorization scope in the VC matches the data category and subcategory in the request.

[0377] Verify whether the valid time of the VC covers the current request time.

[0378] If VC verification fails, the data provider should reject the request and provide feedback to the requester on the reason.

[0379] Provide supervision data:

[0380] If the VC verification is successful, the data provider provides the corresponding supervision data according to the authorization scope in the VC.

[0381] According to the data description information in VC, the corresponding supervision data is retrieved from the data storage.

[0382] Make sure the data provided is consistent with the data category and subcategory specified in the VC.

[0383] A multi-party supervision data management method, including data processing and security assurance:

[0384] Step 5.1: Before providing the supervision data, the data provider may process the data according to the instructions in the VC. Specifically:

[0385] The data provider extracts specific instructions about data processing from the VC, including data desensitization, aggregate statistics, and summary generation.

[0386] Confirm whether the processing instructions in the VC are consistent with the multi-party supervision data management rules to prevent unauthorized data processing.

[0387] Prepare the corresponding data processing tools or scripts according to the instructions in VC. For example, use Python scripts to perform data desensitization or use SQL queries to generate summary statistics.

[0388] Configure the data processing environment in a trusted execution environment (TEE) to ensure security and privacy protection during data processing.

[0389] According to the VC's instructions, sensitive information is desensitized. For example, specific financial data is replaced with interval values ​​(such as "100,000-200,000"), or personal names are replaced with code names.

[0390] Record the specific operations and results of the desensitization process for subsequent auditing and tracing.

[0391] If the VC indicates that summary statistics are required, the data provider will generate corresponding summary statistics based on the supervision data, for example, the overall percentage of project progress or the pass rate of quality inspection.

[0392] Generate summary information of supervision data according to VC instructions instead of providing complete original data. For example, generate summary report of construction log, including only key events but not detailed records.

[0393] After the processing is completed, the data provider verifies the processing results to ensure that the processing results meet the requirements of the VC instructions and that the consistency and integrity of the data are guaranteed.

[0394] The processing results are organized into a standardized format (such as JSON or XML) with processing logs and metadata information.

[0395] Step 5.2: After the processing is completed, the data provider encrypts the processing result (using the requester's identity public key) and sends it to the requester. Specifically:

[0396] The data provider processes the data according to the instructions in the VC and generates processing results.

[0397] Ensure that the processing results only contain the data categories and subcategories specified in the VC to avoid excessive exposure of information.

[0398] The data provider should verify the accuracy and completeness of the processing results to ensure that they comply with the instructions in the VC.

[0399] Use the requester's DID to obtain the requester's identity public key from the distributed ledger system.

[0400] Confirm that the requester's identity public key matches the DID in the request.

[0401] The processing result is encrypted using the requester's public key to ensure data security during transmission.

[0402] The encryption algorithm should be an asymmetric encryption algorithm (such as RSA or ECC).

[0403] Additional metadata:

[0404] Necessary metadata, such as timestamp and VC identifier, are added to the encrypted processing result.

[0405] These metadata will help the requesting party verify the origin and timeliness of the data.

[0406] Send the encrypted processing results through a secure communication channel (such as HTTPs connection encrypted by TLS / SSL protocol).

[0407] Ensure the security of the entire transmission process and prevent data from being intercepted or tampered with during transmission.

[0408] Send request confirmation:

[0409] Before sending the encryption result, a confirmation message is sent to the requester to confirm the data to be sent.

[0410] After receiving the confirmation message, the requester is ready to receive the encrypted processing result.

[0411] The requester receives the encrypted processing result through a secure channel.

[0412] Confirm that the received data has not been tampered with or lost.

[0413] The encrypted processing result is decrypted using the requester's identity private key.

[0414] The processing result after decryption should be consistent with the data category and subcategory indicated in the VC.

[0415] A multi-party supervision data management method also includes the steps of authorization revocation and management:

[0416] Step 6.1: If the supervisory unit decides to revoke the authorization, it can change the VC status information by sending a revocation request to the distributed ledger system.

[0417] The supervision unit determines the scope of authorization that needs to be revoked and the reasons for it.

[0418] Identify the specific VC being revoked (including the VC’s ID or other unique identifier).

[0419] Generate a revocation request:

[0420] The revocation request should follow a standardized format (such as JSON or XML), including the DID of the supervisory unit, the ID of the revoked VC, and the reason for revocation.

[0421] The revocation request is signed using the supervisory unit’s identity private key to ensure the authenticity and integrity of the request.

[0422] Use encryption technology (such as TLS / SSL protocol) to encrypt the revocation request to ensure data security during transmission.

[0423] Select a distributed ledger system as the target of the revocation request.

[0424] The encrypted revocation request is sent to the distributed ledger system via a secure communication channel (such as encrypted email or dedicated file transfer tool).

[0425] The distributed ledger system processes the revocation request:

[0426] After receiving the revocation request, the distributed ledger system extracts the information in the request and obtains the identity public key of the supervisory unit from the distributed ledger system through the DID of the supervisory unit.

[0427] Use the public key of the supervision unit to verify the signature of the request to ensure the authenticity and integrity of the request.

[0428] After the signature verification is successful, the distributed ledger system updates the status information of the VC and marks it as revoked.

[0429] Generate the corresponding state change transaction and record the transaction on the distributed ledger to ensure the transparency and immutability of the state change.

[0430] The supervision unit confirms whether the status of the VC has been successfully changed to revoked through the query interface of the distributed ledger system.

[0431] The query results will display the VC status information and its change time.

[0432] This application proposes a multi-party supervision data management technology, which has the following effects:

[0433] Enhanced data security: Through distributed ledger technology, decentralized data storage and management are achieved to ensure data security and immutability. The distributed digital identity system ensures that the identity of each participant is authentic and prevents data from being illegally accessed and tampered with.

[0434] Establish a trust mechanism: Through distributed digital identities and verifiable claims (VCs), a trust mechanism is established between participants. The identity and permissions of each participant can be verified on the distributed ledger to ensure the legal use and sharing of data.

[0435] Realize real-time data update: Utilize the real-time and transparency of distributed ledger technology to ensure real-time update and synchronization of data. Participants can view the latest supervision data at any time to improve the efficiency and accuracy of project decision-making.

[0436] Ensure data consistency: Through the distributed ledger technology of the distributed ledger, the consistency of data throughout the entire life cycle is ensured. All participants can access the same data source to avoid information silos and data conflicts.

[0437] Flexible permission management: By defining different categories of supervision data and their sensitivity levels, corresponding description information and access rules are created for each data category. Participants can access the required data according to their roles and permissions, ensuring the reasonable use and protection of information.

[0438] Through the above technical solutions, this application can effectively solve the problems of data sensitivity, multi-party collaboration trust, data timeliness, data consistency and authority management faced in multi-party supervision data management, and improve the security, reliability and efficiency of data management.

[0439] This application also discloses a multi-party supervision data management system, such as Figure 1 ,include:

[0440] User management module: responsible for creating and managing the distributed digital identities (DIDs) of all supervisory participants.

[0441] Distributed ledger interaction module: responsible for interaction with the distributed ledger system, including registering DID, verifying identity, and issuing and verifying verifiable claims (VC).

[0442] Data management module: responsible for the classification, storage and management of supervision data.

[0443] Permission management module: responsible for defining and managing access rules for different data categories.

[0444] Authorization request processing module: responsible for processing data authorization requests and generating VC.

[0445] Data provision module: responsible for providing corresponding supervision data according to VC.

[0446] Audit and monitoring module: responsible for recording and monitoring system operations to ensure the transparency and traceability of the system.

[0447] Security management module: responsible for the security protection of the system, including data encryption, identity authentication, etc.

[0448] Specifically, the user management module: Create DID: Generate a pair of identity public key and private key for each participant, and create a DID document.

[0449] Register DID: Submit the DID document to the distributed ledger system and confirm the registration success through the query interface.

[0450] Distribute DID documents: Share the successfully registered DID documents with other participants to establish a mutual trust mechanism.

[0451] Specifically, the distributed ledger interaction module: Register DID: generate a registration transaction, submit it to the distributed ledger system, and verify the registration result.

[0452] Identity verification: Query the DID document of the participant through the API provided by the distributed ledger system to verify the identity public key.

[0453] Release VC: Generate and sign VC, submit it to the distributed ledger system, and verify the release result.

[0454] Verify VC: Extract VC from the distributed ledger system and verify the signature using the requester’s identity public key.

[0455] Specifically, the data management module: Data classification: defines different categories of supervision data and their sensitivity levels.

[0456] Data storage: Supervision data is stored in a secure database to ensure data integrity and security.

[0457] Data retrieval: Retrieve corresponding supervision data according to the authorization scope in VC.

[0458] Specifically, the permission management module: Define access rules: Define access rules for different categories of supervision data, including sensitivity levels and access rights.

[0459] Permission allocation: Assign appropriate data access permissions based on the roles and needs of the participants.

[0460] Permission review: Regularly review and update permission allocation to ensure the rationality and security of permission management.

[0461] Specifically, the authorization request processing module: receiving request: receiving the data authorization request from the participant and verifying the authenticity and integrity of the request.

[0462] Authority check: Based on the preset access rules, check whether the requester has the authority to access the required supervision data.

[0463] Generate VC: If the request is approved, generate and sign VC and send it to the requester.

[0464] Specifically, the data providing module: processes requests: receives data acquisition requests with VCs and verifies the validity of VCs.

[0465] Data processing: Process the data according to the instructions in VC, such as desensitization, aggregate statistics, etc.

[0466] Providing data: The processed data is encrypted and sent to the requesting party.

[0467] Specifically, the audit and monitoring module: Operation records: record all system operations, including DID registration, VC release, data authorization request processing, etc.

[0468] Anomaly detection: monitor system operations, detect and record abnormal behaviors, and ensure system security.

[0469] Audit Report: Generate audit reports to provide transparency and traceability of system operations.

[0470] Specifically, the security management module: Data encryption: Use an asymmetric encryption algorithm to encrypt data to ensure the security of data during transmission and storage.

[0471] Identity verification: Authentication is performed through DID and public key to ensure the authenticity and legitimacy of the parties involved.

[0472] Secure communication: Use secure communication protocols (such as TLS / SSL) for data transmission to prevent data from being intercepted or tampered with.

Claims

1. A multi-party supervision data management method, characterized in that: Includes steps: Create distributed digital identities for all supervisory participants and register these distributed digital identities and their public keys in the distributed ledger system; Assign corresponding distributed digital identity information to each participant and ensure that this information can be accessed by all participants for identity verification; Define different categories of supervision data and their sensitivity levels, including project management information, engineering progress, and quality inspection reports; When a supervision participant needs to obtain supervision data, the participant needs to initiate a data authorization request to the supervision unit; After receiving the request, the supervision unit decides whether to approve the request based on the identity authentication and data access rules of the requester; If the request is approved, the supervisor will issue a verifiable statement using its own private key and the requester’s distributed digital identity; After receiving the verifiable statement, the construction unit sends it to the data provider together with the data acquisition request; After receiving the request, the data provider extracts the information in the verifiable statement and obtains the public key of the requester's identity from the distributed ledger system through the requester's distributed digital identity; The data provider uses the requester's identity public key to verify the verifiable statement, and after confirming that it is correct, provides the corresponding supervision data according to the authorization scope in the verifiable statement; Create distributed digital identities for all supervisory participants and register these distributed digital identities and their public keys in the distributed ledger system. Specifically include: Generate identity public and private keys: Use an asymmetric encryption algorithm to generate a pair of public and private keys for each participant. The private key is kept properly by the participant, and the public key is used in the subsequent registration and verification process. Construct a distributed digital identity document containing the public key and basic information of the participants; the distributed digital identity document will serve as a digital proof of the identity of the participants; Generate a registration transaction based on the distributed digital identity document; the transaction contains all the information of the distributed digital identity document and is signed by the identity private key of the participant to ensure the authenticity of the transaction; Submit the generated registration transaction to the distributed ledger system; the distributed ledger system will execute the transaction and store the distributed digital identity document in its distributed ledger; After submitting the registration transaction, confirm whether the distributed digital identity document has been successfully registered through the query interface of the distributed ledger system; the query result will show the status of the distributed digital identity document and any error information; The different categories that define supervision data include: Project management information, including the overall project plan, budget, contract terms, personnel arrangements, and meeting minutes; Project progress information, including construction progress, completion status of key nodes, and construction log related information; Quality inspection report, which includes quality inspection results, quality accident records, and rectification suggestions; After receiving the request, the supervision unit decides whether to approve the request based on the identity authentication and data access rules of the requester, including: After receiving the request, the supervision unit first obtains the identity public key of the requester from the distributed ledger system through the distributed digital identity information in the request; Use the requester's identity public key to verify the request; Based on the data categories and subcategories in the request, the supervision unit checks its preset data access rules to determine whether the requester has the authority to access the required supervision data; If the requesting party’s authority level is not sufficient to access the requested data, the supervisory authority shall reject the request and provide reasons for the rejection; If the request is approved, the supervisor will issue a verifiable statement using its own private key and the requester’s distributed digital identity, specifically: The supervision unit generates a verifiable statement based on the data category and subcategory in the request. The verifiable statement contains the authorization scope, validity period and distributed digital identity information of the requester. The supervision unit signs the verifiable statement using its own private key, and the signed verifiable statement is sent to the requesting party through a secure channel; After receiving the verifiable statement, the construction unit sends it together with the data acquisition request to the data provider. The construction unit prepares data acquisition requests according to the standardized request format; The request should include the distributed digital identity information of the construction unit, the request timestamp, and the specific description of the required data; The construction unit embeds the verifiable statement into the data acquisition request to ensure that the verifiable statement is closely associated with the request content; The request should clearly indicate the existence and location of the verifiable claim so that the data provider can easily identify and extract the verifiable claim; Use the construction unit's identity private key to sign the data acquisition request to ensure the authenticity and integrity of the request; Encrypt the entire request to ensure data security during transmission; The request should also include the public key of the construction unit so that the data provider can verify the validity of the verifiable statement after receiving the request; A data retrieval request with a verifiable claim is sent to the data provider via a secure communication channel.

2. A multi-party supervision data management method according to claim 1, characterized in that: It also includes that the data provider can process the data according to the instructions in the verifiable declaration before providing the supervision data; it also includes that after the processing is completed, the data provider will encrypt the processing results and send them to the requesting party; it also includes that if the supervision unit decides to revoke the authorization, it can change the status information of the verifiable declaration by sending a revocation request to the distributed ledger system.

3. A multi-party supervision data management method according to claim 1, characterized in that: When a supervision participant needs to obtain supervision data, the participant needs to initiate a data authorization request to the supervision unit, including: The construction unit determines the specific types of supervision data that need to be obtained; The construction unit signs the request using its own private key; The construction unit sends the signed request to the supervision unit through a secure communication channel; The request should clearly list the specific categories and subcategories of the supervision data that need to be obtained; The request should also include the distributed digital identity information of the requesting party; The request should also include the public key of the requesting party so that the supervision unit can verify the signature when issuing the verifiable statement; The request should include the timestamp of the request, the unique identifier of the requesting party, and a description of the data required; After sending the request, the construction unit should wait for the confirmation reply from the supervision unit to ensure that the request has been received.

4. A multi-party supervision data management method according to claim 1, characterized in that: After receiving the request, the data provider extracts the information in the verifiable statement and obtains the public key of the requester's identity from the distributed ledger system through the distributed digital identity of the requester. Specifically: The data provider extracts the verifiable claim from the received data acquisition request; Using the distributed digital identity of the requesting party, obtaining the identity public key of the requesting party from the distributed ledger system; Query the distributed digital identity document of the requester through the API interface of the distributed ledger system and extract the identity public key from it; Confirm that the requester's identity public key matches the distributed digital identity in the request.

5. A multi-party supervision data management method according to claim 1, characterized in that: The data provider uses the requester's identity public key to verify the verifiable statement. After confirmation, the data provider provides the corresponding supervision data according to the authorization scope in the verifiable statement. Use the requester's public key to verify the verifiable statement. The signature verification process includes verifying whether the signature of the verifiable statement is correct and whether the information in the verifiable statement has been tampered with; Confirm that the authorization scopes in the verifiable claim match the data categories and subcategories in the request; Verify whether the valid time of the verifiable claim covers the current request time; If the verification of the verifiable claim fails, the data provider shall reject the request and provide feedback to the requesting party on the reason; If the verifiable statement is successfully verified, the data provider provides the corresponding supervision data according to the authorization scope in the verifiable statement; according to the data description information in the verifiable statement, the corresponding supervision data is retrieved from the data storage; Ensure that the data provided is consistent with the data categories and subcategories specified in the verifiable claim.

Images