A multi-domain environment access control method based on alliance chain

Abstract

The present invention discloses a multi-domain environment access control method based on a consortium chain, comprising: all users registering DIDs and public-private key pairs on the consortium chain; a first user creating a resource-class CPT on the consortium chain; a second user publishing a resource by issuing an electronic resource credential on the consortium chain; the electronic resource credential being a VC that complies with the resource-class CPT; a third user creating a permission-class CPT on the consortium chain; a fourth user applying for an electronic permission credential through the consortium chain to obtain user permissions; the electronic permission credential being a VC that complies with the permission-class CPT; and a fifth user initiating a resource access request to the consortium chain, triggering a first smart contract to verify the validity of the user's DID, electronic permission credential, and the electronic resource credential to be accessed, and granting access to the fifth user upon successful verification. In the context of a multi-domain environment, the present invention controls the operational behavior of members from different domains, thereby better protecting the security of information resources.

Description

Technical Field

[0001] The present invention belongs to the field of access control, and in particular relates to a multi-domain environment access control method based on alliance chain. Background Art

[0002] In recent years, with the rapid development of information technology, the scenarios and methods for data access and information sharing have become increasingly complex. Multi-domain environments are a widely used and complex scenario, requiring the provision of information access, interaction, and management services for members from different domains. In a multi-domain environment, users reside in different domains, with complex and diverse permissions. These users need to share or access resources across domains. For example, if two universities establish a sister partnership and share online electronic resources, a student from University A who wishes to take an online course from University B must verify their identity and provide proof of course enrolment. This verification process is known as access control.

[0003] The Trusted Computer Security Evaluation Criteria (TCSEC) was proposed by the U.S. Defense Science Board in 1970 and published by the U.S. Department of Defense in 1985. TCSEC defines access control as providing protection and control for computer resources when they encounter threats from unauthorized operations, protecting information integrity and confidentiality within the system. Access control consists of three basic components: subject, object, and access policy. The process is that the subject accesses the object according to the access policy. The subject is an active entity, a requester of access, such as a user or device within the system; the object is a passive entity, an object requested during access, such as a file, data, or process within the system; and the access policy specifies the rules governing the subject's operational permissions over the object. The subject and object are relative; a subject can also become an object, for example, when a process calls another process during operation.

[0004] Offline access control in a multi-domain environment is relatively easy, generally using paper-based authentication, which is easy to verify using anti-counterfeiting technologies and is relatively convenient. However, online access control within a multi-domain environment, such as the web, client, and app, faces the following challenges:

[0005] Heterogeneous data structure definitions in different domains: Each domain in a multi-domain environment may use different data structures and definitions, which requires addressing data consistency and compatibility issues when implementing resource sharing and access control.

[0006] Identity and permissions are easy to forge and tamper with: Since identity and permission certificates may come from different domains, this provides opportunities for proof forgery and tampering, increasing security risks;

[0007] Personal privacy and resource leakage: In a multi-domain environment, the system needs to process a large number of users and data, which may lead to personal privacy and resource leakage issues;

[0008] High degree of centralization of access control: Traditional access control processes and data storage are usually centralized, which may lead to data security issues such as single point failure and hacker attacks.

[0009] Therefore, in the context of a multi-domain environment, how to control the operational behaviors of members from different domains to better protect the security of information resources is an urgent problem to be solved. Summary of the Invention

[0010] In order to solve the above problems existing in the prior art, the present invention provides a multi-domain environment access control method based on alliance chain.

[0011] The technical problem to be solved by the present invention is achieved through the following technical solutions:

[0012] A multi-domain environment access control method based on alliance chain, comprising:

[0013] All users in a multi-domain environment register DID and public-private key pairs on the consortium chain;

[0014] The first user who manages resources creates a resource-type CPT on the consortium chain with his or her own DID and public-private key pair;

[0015] The second user holding the resource publishes the resource by issuing an electronic resource certificate on the consortium chain using his or her own DID and public-private key pair; the electronic resource certificate is a verifiable certificate that complies with the CPT of the resource type;

[0016] A third user who manages user permissions creates a permission-based CPT on the consortium chain using their own DID and public-private key pair;

[0017] The fourth user who wants to obtain user rights applies for an electronic permission certificate through the consortium chain with his or her DID and public-private key pair to obtain user rights; the electronic permission certificate is a verifiable certificate that complies with the permission type CPT;

[0018] The fifth user who has obtained user permissions and wants to access resources initiates a resource access request to the alliance chain, triggering the first smart contract on the alliance chain to verify the validity of the fifth user's DID, electronic permission certificate, and the electronic resource certificate that the fifth user wants to access, and allows the fifth user to access the resources he wants to access after the verification is passed.

[0019] Optionally, each user registers a DID and public-private key pair on the consortium chain, including:

[0020] The user initiates a user registration request to the consortium chain;

[0021] The sixth user who manages user registration reviews the user information in the user registration request. After the review is passed, the sixth user generates a digital summary based on the user information and signs the digital summary with the private key to obtain a digital signature. The sixth user uploads their own DID, public key, and digital signature to the consortium chain, triggering the second smart contract on the consortium chain to register the DID and public-private key pair for the user who initiated the user registration request.

[0022] The content of the second smart contract includes:

[0023] Obtaining a DID document of the sixth user according to the DID of the sixth user;

[0024] Checking whether the public key of the sixth user is in the public key list of its DID document;

[0025] If the check passes, verify the digital signature using the public key of the sixth user;

[0026] If the verification is successful, a public-private key pair and DID are created for the user who initiated the user registration request, and the user information is encrypted using the user's public key;

[0027] The created DID, public-private key pair, and encrypted user information are recorded in the consortium chain, and the hash value of the DID, public-private key pair, and user information is returned to the user who initiated the user registration request.

[0028] Optionally, a first user who manages resources creates a resource-class CPT on the consortium chain using his or her DID and public-private key pair, including: the first user initiates a CPT creation request to the consortium chain, triggering a third smart contract on the consortium chain to create a resource-class CPT for the first user;

[0029] A third user who manages user rights creates a permission-based CPT on the consortium chain using his or her DID and public-private key pair, including: the third user uploads a CPT creation request to the consortium chain, triggering the third smart contract to create a permission-based CPT for the third user;

[0030] The CPT creation request includes the DID of the user initiating the request, the public-private key pair, and the Claim structure of the CPT to be created;

[0031] The content of the third smart contract includes:

[0032] Obtain the DID document of the user who initiated the CPT creation request based on the DID of the user;

[0033] Check if the user's public key is in the public key list of its DID document;

[0034] If the check passes, the random string is encrypted using the user's public key, and the encrypted result is decrypted using the user's private key;

[0035] If the decryption is successful, a CPT is created for the user according to the Claim structure, the created CPT is signed using the user's private key, and the created CPT is returned to the user who initiated the CPT creation request and recorded in the consortium chain.

[0036] Optionally, the second user holding the resource can publish the resource by issuing an electronic resource certificate on the consortium chain using his or her own DID and public-private key pair, including:

[0037] The second user initiates a CPT query request to the consortium chain, triggering the fourth smart contract on the consortium chain to query the CPT for the second user; the CPT query request includes the DID of the user initiating the request, the public-private key pair, and the CPT identifier corresponding to the resource to be published;

[0038] The second user obtains the Claim structure of the resource class CPT to which the resource to be released belongs based on the query result of the fourth smart contract;

[0039] The second user initiates a resource release request to the alliance chain according to the Claim structure, triggering the fifth smart contract on the alliance chain to enable the second user to release the electronic resource certificate on the alliance chain; wherein, the resource release request includes the second user's DID, public-private key pair and the resource to be released.

[0040] Optionally, the content of the fourth smart contract includes:

[0041] Get the DID document of the user who initiated the CPT query request based on the DID of the user;

[0042] Check if the user's public key is in the public key list of its DID document;

[0043] If the check passes, the random string is encrypted using the user's public key, and the encrypted result is decrypted using the user's private key;

[0044] If the decryption is successful, the corresponding CPT is determined based on the CPT identifier in the CPT query request, and the DID of the target user who created the CPT is determined;

[0045] Obtain the DID document of the target user according to the DID of the target user;

[0046] Check whether the target user's public key is in the public key list of its DID document;

[0047] If the check passes, the Claim structure of the CPT corresponding to the CPT identifier is returned.

[0048] Optionally, the content of the fifth smart contract includes:

[0049] Obtaining a DID document of the second user according to the DID of the second user;

[0050] Check whether the second user's public key is in the public key list of its DID document;

[0051] If the check passes, encrypt the random string using the second user's public key, and decrypt the encrypted result using the second user's private key;

[0052] If decryption is successful, obtain the DID document of the first user based on the DID of the first user who created the Claim structure; check whether the public key of the first user is in the public key list of its DID document;

[0053] If the check passes, the second user creates an electronic resource certificate according to the claim structure, generates an ID for the electronic resource certificate, and signs the claim part of the electronic resource certificate using his own private key;

[0054] Record the created electronic resource certificate to the alliance chain;

[0055] Notify the first user who created the Claim structure to store the electronic resource credential in his / her credential registry;

[0056] The ID of the created electronic resource credential is returned to the second user.

[0057] Optionally, a fourth user who wants to obtain user rights can apply for an electronic permission certificate through the consortium chain with his or her own DID and public-private key pair to obtain user rights, including:

[0058] The fourth user initiates a CPT query request to the consortium chain based on the user rights they wish to obtain, triggering the fourth smart contract on the consortium chain to query the CPT for the fourth user; the CPT query request includes the fourth user's DID, public-private key pair, and the CPT identifier corresponding to the user rights they wish to obtain;

[0059] The fourth user obtains the Claim structure of the permission class CPT to which the user permission to be obtained belongs based on the query result of the fourth smart contract;

[0060] The fourth user initiates a user rights application to the consortium chain according to the Claim structure; the user rights application includes the fourth user's DID, public-private key pair, and rights application information;

[0061] The third user who created the Claim structure reviews the permission application information, and after the review is passed, signs the DID and permission application information of the fourth user to obtain a digital signature; uploads his own DID, public key and the digital signature to the alliance chain, triggering the sixth smart contract on the alliance chain to create an electronic permission certificate for the fourth user.

[0062] Optionally, the content of the sixth smart contract includes:

[0063] Obtaining the fourth user's DID document based on the fourth user's DID; checking whether the fourth user's public key is in the public key list of its DID document; if the check passes, encrypting the random string using the fourth user's public key and decrypting the encrypted result using the fourth user's private key;

[0064] Obtaining the DID document of the third user based on the DID of the third user who created the Claim structure; checking whether the third user's public key is in the public key list of its DID document; if the check passes, encrypting the random string using the third user's public key and decrypting the encrypted result using the third user's private key;

[0065] If both decryptions are successful, the digital signature is verified using the public key of the third user who created the Claim structure;

[0066] If the verification is successful, an electronic rights certificate is created for the fourth user according to the Claim structure, an ID is generated for the electronic rights certificate, and the claim portion of the electronic rights certificate is signed using the private key of the third user who created the Claim structure;

[0067] Recording the electronic permission certificate created for the fourth user into the alliance chain;

[0068] Notifying all parties having management rights over the electronic authorization certificate of the fourth user to store the electronic authorization certificate in their respective certificate registries;

[0069] The ID of the created electronic authorization certificate is returned to the fourth user.

[0070] Optionally, the resource access request includes the DID, public-private key pair, and ID of the electronic authority certificate of the fifth user, and also includes the ID and domain name of the electronic resource certificate to be accessed by the fifth user;

[0071] The content of the first smart contract includes:

[0072] Obtaining the DID document of the fifth user based on the DID of the fifth user; checking whether the public key of the fifth user is in the public key list of its DID document; if the check passes, encrypting the random string using the public key of the fifth user, and decrypting the encrypted result using the private key of the fifth user;

[0073] If the decryption is successful, requesting the credential information of the electronic authorization certificate from the credential registry where the electronic authorization certificate is located according to the ID of the electronic authorization certificate of the fifth user;

[0074] Verifying the validity of the electronic permission certificate of the fifth user based on the obtained credential information, including: checking whether the electronic permission certificate is on the consortium chain, checking whether the electronic permission certificate is within the validity period, and verifying the digital signature portion of the electronic permission certificate using the public key of the third user who created the electronic permission certificate;

[0075] If the electronic authorization certificate of the fifth user is valid, determining whether the fifth user has the user authorization to access the electronic resource to be accessed according to the business logic;

[0076] If the judgment is yes, requesting the credential information of the electronic resource credential to be accessed by the fifth user from the credential registry of the domain where the domain name is located according to the ID of the electronic resource credential to be accessed by the fifth user;

[0077] Verifying the validity of the electronic resource credential to be accessed by the fifth user based on the acquired credential information, including: checking whether the electronic resource credential is located on the consortium chain, checking whether the electronic resource credential is within the validity period, and verifying the digital signature portion of the electronic resource credential using the public key of the second user who created the electronic resource credential;

[0078] If the electronic resource certificate that the fifth user wants to access is valid, the electronic resource certificate is returned to the fifth user.

[0079] Optionally, the method further includes:

[0080] After verifying the validity of the fifth user's DID, electronic authority certificate, and the electronic resource certificate that the fifth user wants to access, the seventh smart contract is triggered to generate an access log.

[0081] In the multi-domain access control method based on a consortium chain provided by the present invention, all users in a multi-domain environment register their DID and public-private key pairs on the consortium chain, thereby resolving the issue of easily forged identities and permissions in a multi-domain environment. The first user who manages resources creates a resource-class CPT on the consortium chain using their DID and public-private key pair. Correspondingly, the second user who holds the resource publishes the resource by issuing an electronic resource certificate on the consortium chain using their DID and public-private key pair. This electronic resource certificate is a verifiable certificate that complies with the resource-class CPT, thereby resolving data consistency and compatibility issues in a multi-domain environment. The third user who manages user rights creates a permission-type CPT on the alliance chain with his own DID and public-private key pair. The fourth user who wants to obtain user rights applies for an electronic permission certificate through the alliance chain with his own DID and public-private key pair to obtain user rights. The electronic permission certificate is a verifiable certificate that complies with the permission-type CPT; the fifth user who has obtained user rights and wants to access resources initiates a resource access request to the alliance chain, triggering the first smart contract on the alliance chain to verify the validity of the fifth user's DID, electronic permission certificate, and the electronic resource certificate that the fifth user wants to access. After the verification is passed, the fifth user is allowed to access the resources he wants to access, thereby solving the problems of personal privacy and easy resource leakage in a multi-domain environment and the problem of high degree of centralization of access control.

[0082] In summary, the present invention solves problems such as data heterogeneity, easy forgery of identities and permissions, easy leakage of personal privacy and resources, and high degree of centralization of access control in multi-domain environments. It can effectively control the operational behaviors of members from different domains, thereby better protecting the security of information resources.

[0083] The present invention will be further described in detail below with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0084] Figure 1 The hierarchical system of the access control architecture based on the multi-domain environment access control method based on the alliance chain provided by the embodiment of the present invention is shown;

[0085] Figure 2 A flow chart illustrating the use of verifiable credentials;

[0086] Figure 3 This is a flowchart of a multi-domain environment access control method based on alliance chain provided by an embodiment of the present invention;

[0087] Figure 4 The specific process of user registration of DID and public-private key pair in an embodiment of the present invention is shown;

[0088] Figure 5 The specific process of creating a CPT in an embodiment of the present invention is shown;

[0089] Figure 6 The specific process of publishing resources in an embodiment of the present invention is shown;

[0090] Figure 7 The specific process of applying for user permissions in an embodiment of the present invention is shown;

[0091] Figure 8 The specific process of access control in an embodiment of the present invention is shown;

[0092] Figure 9 The control logic of the multi-domain environment access control method based on alliance chain provided by an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0093] The present invention will be further described in detail below with reference to specific examples, but the embodiments of the present invention are not limited thereto.

[0094] In order to control the operational behaviors of members from different domains in a multi-domain environment, thereby better protecting the security of information resources, an embodiment of the present invention provides a multi-domain environment access control method based on a consortium chain.

[0095] Figure 1 The hierarchical system of the access control architecture based on the multi-domain environment access control method based on the alliance chain provided by the embodiment of the present invention is shown, including four layers: data layer, blockchain layer, business layer and user layer.

[0096] The data layer is primarily responsible for storing the data required for access control mechanisms, which is divided into two categories: blockchain data and verifiable data. Blockchain data includes smart contracts, DIDs (distributed identities), CPTs (claim protocol types), and access logs, all of which are recorded or deployed on the blockchain. Verifiable data includes electronic resource certificates that store resource data and user electronic permission certificates. Electronic resource certificates are resources published by users through the issuance of verifiable certificates (VCs). Each resource or piece of data is a certificate, and its authenticity can be verified using the public key of the resource publisher. Electronic permission certificates, on the other hand, serve as proof of user authorization. Users can present these certificates to demonstrate their identity, and verifiers can verify their authenticity. After an electronic permission certificate is issued to a user, the user can store it in their own private registry, a public registry, or directly in the domain registry of the issuing domain. Electronic resource certificates are typically stored in a domain registry. Registries are typically stored using cloud storage, IPFS (InterPlanetary File System), or private blockchains. Furthermore, verifiable data is backed up on the blockchain.

[0097] DID stands for Distributed Identity, also known as decentralized identity. It can be used as a unique identifier for an entity within a system. The World Wide Web Consortium (W3C) defines DID as a new type of verifiable, distributed digital identity that can identify any entity, including individuals, organizations, objects, data models, and abstract entities. A DID is essentially a simple text string consisting of a Uniform Resource Identifier (URI) scheme, a DID method name, and a specific identifier. Its structure is as follows:

[0098] did:method-name:123456789abcdef;

[0099] In this structure, the URI (Uniform Resource Identifier) ​​scheme uses the fixed characters "did" to indicate that the string is a DID; the method-name represents the method by which the DID is generated. Different DID agencies may use different generation methods, but DIDs are universal and interoperable as long as they are stored on the same blockchain network. The final part is a globally unique hexadecimal string that forms the specific identifier.

[0100] Each DID can be parsed into a DID Document, which records a series of data, including verification methods (such as public key information) and services related to the DID subject's interaction. In addition, each DID has at least one public-private key pair, which the DID holder uses to operate within the system. DID holders can apply for any number of public-private key pairs to prevent private key loss. Each public key can also be used for different purposes, enabling more granular authentication and authorization. However, each DID will only be parsed into a unique DID Document.

[0101] Verifiable credentials transform traditional physical credentials into verifiable electronic credentials. These credentials can be displayed and used on the web, featuring cryptographic security, privacy protection, and machine verifiability. Verifiable credentials primarily consist of two structures: Claim and Proof. A Claim is the declarative portion of a verifiable credential. A verifiable credential can contain one or more Claims, which declare information about the subject. A Claim structure is subject-property-value. For example, Jack's electronic student credential contains two Claims: Jack-Alumni-A University and Jack-Birthday-1 December, 2000. CPT can pre-define various Claim combinations based on different business scenarios, such as electronic graduation certificates and electronic driver's licenses. Proof is the credential authentication mechanism, recording the digital signature of the Verifiable Credential Issuer on the Claim. During credential verification, signature verification can be performed to detect tampering.

[0102] The Issuer is the issuing authority or issuer of a verifiable credential, for example, the issuer of a student ID card is a school. The Holder is the holder of a verifiable credential and is responsible for obtaining, storing, and presenting the verifiable credential. The Verifier is the verifier of the verifiable credential and can verify the verifiable credential presented by the holder. The flowchart of the use of verifiable credentials is as follows: Figure 2 As shown in the figure, in this process, a verifiable credential is issued by the issuer to the credential holder. After obtaining the verifiable credential, the holder stores it in the credential data registry. The holder can then present the verifiable credential to the verifier, who can verify the credential presented by the holder to ensure that the presenter is the holder of the credential and that the credential has not been tampered with.

[0103] The blockchain layer primarily provides blockchain services for the access control architecture, serving as the core of interaction between various components. The distributed ledger defines the blockchain's data storage structure and is responsible for maintaining blockchain data. The blockchain network utilizes a peer-to-peer network, responsible for broadcasting blockchain data between network nodes. The consensus mechanism ensures data consistency across blockchain nodes through a consensus algorithm. Smart contracts are responsible for the logical processing of the entire access control architecture. All access control operations performed by users or administrators, such as issuing DIDs and verifiable credentials, access control management, and resource uploads, are handled through smart contracts. Smart contracts are typically triggered by the business layer. Once generated by smart contracts, DIDs and verifiable credentials provide user identity authentication and permission granting. Both DIDs and verifiable credentials are recorded on the blockchain.

[0104] Blockchain integrates peer-to-peer networks, distributed ledgers, consensus algorithms, smart contracts, and cryptography. Essentially, blockchain is a distributed data storage technology. Participating nodes in a blockchain form a mutually communicative peer-to-peer network, jointly maintaining blockchain data and ensuring data consistency across nodes through consensus algorithms. This foundation enables trusted storage in untrusted environments. The block structure consists of a header and a body. To prevent blockchain data leakage, a hash value is generated using a cryptographic algorithm before data is packaged into the blockchain. The body records a Merkle tree of transaction data hashes over a period of time, while the header stores relevant information about the block, such as timestamps, the root hash of the Merkle tree, and the hash values ​​of previous blocks. Because each block records the hash values ​​of its predecessors, blocks form a chain structure, forming a blockchain. Thanks to its unique network and storage structure, blockchain is decentralized, immutable, and traceable.

[0105] Smart contracts are computer programs written based on the logic of real-world protocols. They automatically execute and produce outputs based on input parameters and pre-set conditions. However, due to technical limitations, smart contracts remained a concept for a long time until the emergence of blockchain technology, which provided a practical environment for their implementation. Smart contracts can be deployed and run on blockchains, enabling the management of distributed ledger data and the automated execution of business logic. With the help of smart contracts, the application areas of blockchain have been greatly expanded.

[0106] The business layer provides functional services to the user layer through web and client-side interfaces to meet business needs. For administrators, this includes issuing verifiable credentials to users to obtain permissions, requesting identity and permission verification when users access resources, defining CPTs, uploading resources, and viewing historical logs. For users (individuals or devices), this includes requesting DIDs and verifiable credentials, accessing and uploading resources, etc. For the Consortium Chain Committee, its responsibilities primarily focus on blockchain governance, including deploying and maintaining smart contracts, verifying verifiable credentials, and authenticating identities.

[0107] The user layer includes administrators, individual users, devices, and consortium chain committees. Depending on the domain's needs, a domain can have administrators to manage its business operations, or opt out of administrators and use smart contracts to automatically process business operations. Individuals and devices are users within a domain, serving as publishers or requesters of system resources. In a multi-domain environment, multiple domains can form a consortium chain committee, with each domain acting as a node to jointly govern the consortium chain.

[0108] based on Figure 1The access control architecture shown in FIG. 1 and the multi-domain environment access control method based on the alliance chain provided by the embodiment of the present invention are shown in FIG. Figure 3 Shown, including:

[0109] A. All users in a multi-domain environment register DID and public-private key pairs on the consortium chain.

[0110] Consortium blockchains are a type of blockchain that are more suitable for multi-domain environments. Users in a multi-domain environment include user-level personnel, devices, and administrators. These users are required to register a DID and public-private key pair upon first entering a multi-domain environment.

[0111] The way each user registers a DID and public-private key pair on the consortium chain includes:

[0112] A1. The user initiates a user registration request to the consortium chain;

[0113] A2. The sixth user who manages user registration reviews the user information in the user registration request. After the review is passed, the sixth user generates a digital summary based on the user information and signs the digital summary with the private key to obtain a digital signature. The sixth user uploads their own DID, public key, and digital signature to the consortium chain, triggering the second smart contract on the consortium chain to register the DID and public-private key pair for the user who initiated the user registration request.

[0114] Among them, the content of the second smart contract includes:

[0115] (2-a) Obtaining the DID document of the sixth user based on the DID of the sixth user;

[0116] (2-b) Check whether the public key of the sixth user is in the public key list of its DID document;

[0117] (2-c) If the check passes, verify the digital signature using the public key of the sixth user;

[0118] (2-d) If the verification is successful, a public-private key pair and a DID are created for the user who initiated the user registration request, and the user information is encrypted using the user's public key;

[0119] (2-e) The created DID, public-private key pair, and encrypted user information are recorded in the consortium chain, and the hash value of the DID, public-private key pair, and user information is returned to the user who initiated the user registration request.

[0120] Figure 4 The specific process of user registration of DID and public-private key pair is shown in Figure 1, including:

[0121] User->Blockchain:registerReq(userInfo), user( Figure 4The User in the blockchain initiates a user registration request registerReq to the consortium chain Blockchain, which contains the user information userInfo.

[0122] Administrator:sig:=Sign(sk a ,Hash(userInfo)), passes the user information submitted by the user to the administrator through the alliance chain. The administrator is the sixth user. After receiving the information, if the administrator agrees to register, he will generate a digital summary of the user information and then use his own private key sk a Signing the digital summary indicates approval of the user's registration. If the administrator agrees to the registration, the administrator returns the DID, signature public key, and digital signature to the consortium chain. Hash() represents the hash operation, Sign() represents the signature algorithm, and sig represents the digital signature.

[0123] Blockchain:did u ,pk u ,sk u ,userInfoHash:=registerUser(did a ,sig,userInfo), the second smart contract on the alliance chain is triggered, thereby registering DID and public-private key pairs for User. a is the DID of the sixth user; u 、pk u ,sk u They are the User's DID, public key, and private key; userInfoHash is the hash value of the user information.

[0124] For example, the specific algorithm implementation of the second smart contract may include the following algorithm 1:

[0125]

[0126]

[0127] In the algorithm 1, the administrator's DID ( Figure 4 did a ) maps out its DID Document and verifies whether the signature public key exists in the public key list of the DID Document. If it exists, the digital signature is verified using the public key. If the verification is incorrect, the registration fails. If the verification is correct, the user's public-private key pair is first generated, and then the user's DID is formed according to the rules, and the user information userInfo is encrypted using the user's public key pku. u 、pk u,sk u And the encrypted user information is recorded in the alliance chain for evidence storage.

[0128] Blockchain->User:registerRes(did u ,pk u ,sk u ,userInfoHash), the alliance chain sends registerRes to the user and creates the completed did u 、pk u ,sk u The hash value of the encrypted user information is returned to the user, thereby completing the registration of the DID and public-private key pair.

[0129] B. The first user who manages resources creates a resource-type CPT on the consortium chain with his or her own DID and public-private key pair.

[0130] Specifically, the first user initiates a CPT creation request to the consortium chain, triggering the third smart contract on the consortium chain to create a resource-type CPT for the first user;

[0131] The CPT creation request includes the DID of the user initiating the request, the public and private key pairs, and the Claim structure of the CPT to be created;

[0132] The contents of the third smart contract include:

[0133] (3-a) Obtain the DID document of the user who initiated the CPT creation request based on the DID of the user;

[0134] (3-b) Check whether the user's public key is in the public key list of its DID document;

[0135] (3-c) If the check passes, the random string is encrypted using the user's public key, and the encrypted result is decrypted using the user's private key. This is done to prove that the DID user is the DID holder and there is no fraudulent use.

[0136] (3-d) If the decryption is successful, a CPT is generated for the user according to the Claim structure of the CPT that the user wants to create. The generated CPT is signed with the user's private key and returned to the user who initiated the CPT creation request and recorded in the consortium chain.

[0137] Figure 5 The specific process of creating a CPT is shown in Figure 1, including:

[0138] Administrator->Blockchain:createCptReq(did a,pk a ,sk a , claimStruct), the user initiates a CPT creation request createCptReq to the alliance chain, and the request contains the DID of the user who initiated the application ( Figure 5 did a ) and the public-private key pair ( Figure 5 PK in a ,sk a ,) and the predefined Claim structure ( Figure 5 The user who initiates the CPT creation request is in Figure 5 In the example, Administrator is used to represent the first user in step B.

[0139] Blockchain:cpt:=createCpt(did a ,pk a ,sk a ,claimStruct), the third smart contract on the alliance chain is triggered, thereby creating CPT for the user who initiated the application.

[0140] For example, the specific algorithm implementation of the third smart contract may include the following algorithm 2:

[0141]

[0142] In Algorithm 2, the user who wishes to create a CPT is first authenticated. This authentication process involves mapping the user's DID to their DID Document. Successful mapping indicates that the DID is valid. The user's provided public key is then verified to be in the public key list of the mapped DID Document. If the public key exists, a random string is encrypted using it, and then decrypted using the user's provided private key. Successful decryption proves that the user presenting the DID is the DID's holder. The CPT is then constructed, including generating a CPT identifier, obtaining the current timestamp as the creation time, and signing the CPT with the user's private key. Finally, all of this information is serialized into a CPT, which is then recorded in the consortium blockchain for storage.

[0143] Blockchain->Administrator:createCptRes(cpt), the consortium chain sends createCptRes to the user who initiated the CPT creation request, and returns the created CPT to the user who initiated the CPT creation request.

[0144] In this embodiment of the present invention, the Claim portion of a verifiable credential records the actual business data of a credential. In practice, the Claim structure of various CPT types can be predefined to meet different business needs (e.g., electronic graduation certificates, electronic driver's licenses, etc.). When issuing a credential, business data can be directly populated based on the Claim structure defined in the CPT, thereby facilitating credential issuance.

[0145] C. The second user holding the resource publishes the resource by issuing an electronic resource certificate on the consortium chain with his or her own DID and public-private key pair; the electronic resource certificate is a verifiable certificate that complies with the resource-type CPT.

[0146] It is understood that resources are objects in access control. In embodiments of the present invention, resource publishers publish resources by issuing verifiable credentials, which are referred to as electronic resource credentials. When publishing a resource, a resource publisher selects a resource-related CPT and, based on the claim structure predefined in the CPT, issues a verifiable credential to publish the resource.

[0147] Specifically, the second user holding the resource publishes the resource by issuing an electronic resource certificate on the consortium chain with his or her own DID and public-private key pair, including:

[0148] C1. The second user initiates a CPT query request to the consortium chain, triggering the fourth smart contract on the consortium chain to query the CPT for the second user. The CPT query request contains the DID of the user initiating the request, the public-private key pair, and the CPT identifier corresponding to the resource to be published.

[0149] C2. The second user obtains the Claim structure of the resource type CPT to which the resource to be released belongs based on the query results of the fourth smart contract;

[0150] C3. The second user initiates a resource release request to the alliance chain according to the Claim structure in step C2, triggering the fifth smart contract on the alliance chain to enable the second user to release the electronic resource certificate on the alliance chain; wherein, the resource release request includes the second user's DID, public-private key pair, and the resource to be released.

[0151] The contents of the fourth smart contract include:

[0152] (4-a) Obtain the DID document of the user who initiated the CPT query request based on the DID of the user;

[0153] (4-b) Check whether the user's public key is in the public key list of its DID document;

[0154] (4-c) If the check passes, the random string is encrypted using the user's public key, and the encrypted result is decrypted using the user's private key;

[0155] (4-d) If the decryption is successful, the corresponding CPT is determined based on the CPT identifier in the CPT query request, and the DID of the target user who created the CPT is determined;

[0156] (4-e) obtaining the DID document of the target user according to the DID of the target user;

[0157] (4-f) Check whether the target user's public key is in the public key list of its DID document;

[0158] (4-g) If the check passes, return the Claim structure of the CPT corresponding to the CPT identifier.

[0159] It can be understood that in step C, the user initiating the CPT query request is the second user, and the target user is the first user, specifically the first user who created the CPT corresponding to the CPT identifier in the CPT query request.

[0160] The contents of the fifth smart contract include:

[0161] (5-a) Obtaining the DID document of the second user based on the DID of the second user;

[0162] (5-b) Check whether the second user's public key is in the public key list of its DID document;

[0163] (5-c) If the check passes, encrypt the random string using the second user's public key, and decrypt the encrypted result using the second user's private key;

[0164] (5-d) If decryption is successful, the DID document of the first user is obtained based on the DID of the first user who created the above-mentioned claim structure (i.e., the claim structure of the CPT found using the fourth smart contract). The public key of the first user is checked to see if it is in the public key list of its DID document.

[0165] (5-e) If the check passes, the second user creates an electronic resource certificate according to the claim structure, generates an ID for the electronic resource certificate, and signs the claim portion of the electronic resource certificate using his or her own private key;

[0166] (5-g) Record the created electronic resource certificate to the alliance chain;

[0167] (5-g) notifying the first user who created the Claim structure to store the electronic resource certificate in his / her own certificate registry;

[0168] (5-h) Return the ID of the electronic resource voucher to the second user.

[0169] Figure 6 The specific process of publishing resources is shown in Figure 1, including:

[0170] User->Blockchain:queryCptReq(cptId), second user ( Figure 6 Before publishing resources, first use the CPT identifier ( Figure 6 cptId in the consortium chain) initiates a CPT query request queryCptReq to the consortium chain to obtain the Claim structure of the resource class CPT to which the resource to be released belongs by querying the CPT.

[0171] Blockchain:isValid,cpt:=queryCpt(did u ,pk u ,sk u ,cptId), the fourth smart contract on the alliance chain is triggered to query CPT for the second user. u is the DID of the second user, pk u and sk u is the public-private key pair of the second user, and isValid is used to indicate whether the queried CPT is valid.

[0172] For example, the specific algorithm implementation of the fourth smart contract may include the following Algorithm 3:

[0173]

[0174]

[0175] In Algorithm 3, the user requesting the CPT is first authenticated, a process similar to that in Algorithm 2. After successful authentication, the CPT is retrieved from the consortium chain using the CPT identifier. The CPT is then queried to obtain the DID of the user who created the CPT and mapped to the corresponding DID document. After obtaining the DID document, the public key list within it is traversed. If a public key exists in the list that can verify the CPT signature, the CPT has not been tampered with.

[0176] Blockchain->User:queryCptRes(isValid,cpt[claimStruct]). After the CPT is verified, the consortium chain sends queryCptRes to the user who requested to query the CPT, and returns the Claim structure recorded in the CPT to the user who requested to query the CPT.

[0177] User->Blockchain:releaseReq(did u ,pk u ,sk u ,resourceInfo), the second user forms the resource resourceInfo into a Claim according to the CPT template, and initiates a resource release request releaseReq to the alliance chain, and submits his own DID and public-private key pair for use in creating credentials.

[0178] Blockchain:resourceCredential:=createResource(did u ,pk u ,sk u ,resourceInfo), the fifth smart contract on the alliance chain is triggered, thereby creating an electronic resource certificate for the second user.

[0179] For example, the specific algorithm implementation of the fifth smart contract may include the following Algorithm 4:

[0180]

[0181]

[0182] In this algorithm 4, the resource publisher, i.e., the second user, is first authenticated. The authentication process is similar to the authentication part in algorithm 2. After the identity authentication is passed, the validity of the CPT is verified. The verification process is similar to the acquisition method of isValid in algorithm 3. After the CPT is verified, the electronic resource certificate is constructed according to its predefined structure, including using the hash value of the Claim as the ID of the electronic resource certificate, generating a Proof (using the publisher's private key to sign the Claim), obtaining the current timestamp as the release time, and recording the information submitted by the publisher. Finally, all kinds of information are serialized into an electronic resource certificate, which is recorded in the alliance chain for evidence storage. In addition, in order to save space in the alliance chain, the hash value of the electronic resource certificate can be recorded in the alliance chain for evidence storage.

[0183] Blockchain->Registry:storageResource(resourceCredential), runs the storageResource algorithm on the consortium chain, notifies the administrator Registry of the second user's domain (i.e., the first user who created the resource class CPT) to store the electronic resource credential in its own credential registry, so that users inside and outside the domain can access the resource at any time and search in the registry.

[0184] Blockchain->User:releaseRes(resourceCredential), the alliance chain sends releaseRes to the second user and returns the ID of the created electronic resource credential to the second user.

[0185] D. A third user who manages user permissions creates a permission-based CPT on the consortium chain using his or her own DID and public-private key pair.

[0186] Specifically, the third user uploads a CPT creation request to the consortium chain to trigger the third smart contract to create a permission-type CPT for the third user.

[0187] Here, the contents of the CPT creation request and the third smart contract refer to the relevant contents of creating the resource-type CPT in step B above, which will not be repeated here.

[0188] E. The fourth user who wants to obtain user permissions uses his or her DID and public-private key pair to apply for an electronic permission certificate through the alliance chain to obtain user permissions; the electronic permission certificate is a verifiable certificate that complies with the permission-type CPT.

[0189] The embodiment of the present invention authorizes the user by issuing a verifiable certificate to the user, which is called an electronic authorization certificate. When the user accesses a resource, the electronic authorization certificate can be presented to prove that the user has a certain identity.

[0190] Specifically, a fourth user who wants to obtain user rights can apply for an electronic permission certificate through the consortium chain with his or her own DID and public-private key pair to obtain user rights, including:

[0191] E1. The fourth user initiates a CPT query request to the consortium chain based on the user rights they wish to obtain, triggering the fourth smart contract on the consortium chain to query the CPT for the fourth user. The CPT query request contains the fourth user's DID, public-private key pair, and the CPT identifier corresponding to the user rights they wish to obtain.

[0192] E2. The fourth user obtains the Claim structure of the permission class CPT to which the user permission to be obtained belongs based on the query result of the fourth smart contract in step E1;

[0193] E3. The fourth user initiates a user rights application to the consortium chain according to the Claim structure in step E2. The user rights application includes the fourth user's DID, public-private key pair, and rights application information.

[0194] E4. The third user who created the Claim structure in step E2 reviews the permission application information. After the review is passed, the third user signs the fourth user's DID and permission application information to obtain a digital signature; uploads his own DID, public key, and digital signature to the alliance chain, triggering the sixth smart contract on the alliance chain to create an electronic permission certificate for the fourth user.

[0195] Among them, the contents of the sixth smart contract include:

[0196] (6-a) Obtain the DID document of the fourth user based on the DID of the fourth user; check whether the public key of the fourth user is in the public key list of its DID document; if the check passes, encrypt the random string using the public key of the fourth user, and decrypt the encrypted result using the private key of the fourth user;

[0197] (6-b) Based on the DID of the third user who created the Claim structure in step E2, obtain the DID document of the third user; check whether the public key of the third user is in the public key list of its DID document; if the check passes, encrypt the random string using the public key of the third user, and decrypt the encrypted result using the private key of the third user;

[0198] (6-c) If both decryptions are successful, that is, if both steps (6-a) and (6-b) are decrypted successfully, the digital signature in step E4 is verified using the public key of the third user who created the Claim structure;

[0199] (6-d) If the verification is successful, create an electronic authorization certificate for the fourth user according to the Claim structure, generate an ID for the electronic authorization certificate, and sign the claim portion of the electronic authorization certificate using the private key of the third user who created the Claim structure;

[0200] (6-e) Recording the electronic permission certificate created for the fourth user into the alliance chain;

[0201] (6-f) notifying all parties having management rights over the electronic authorization certificate of the fourth user to store the electronic authorization certificate in their respective certificate registries;

[0202] (6-g) Return the ID of the created electronic authorization certificate to the fourth user.

[0203] Figure 7 The specific process of applying for user permissions is shown in Figure 1, including:

[0204] User->Blockchain:authorizeReq(did u ,pk u ,sk u ,authorityInfo), is similar to the process of publishing resources, the fourth user ( Figure 7 The first step is to query CPT to obtain the Claim structure of the electronic authority certificate. Then fill in the authority application information authorityInfo according to the structure and initiate the user authority application authorizeReq to the alliance chain. Figure 6 similar, Figure 7 This is omitted in the Figure 7 did u 、pk u ,sk u Represent the DID, public key, and private key of the fourth user respectively.

[0205] Administrator:sig:=Sign(sk a ,Hash(did u ||authorityInfo)), the administrator Administrator is a third user who created the permission class CPT of the user permission that the fourth user wants to obtain. The third user obtains the permission application information authorityInfo in the user permission application through the alliance chain and evaluates it. If the third user agrees to the authorization, the third user uses his own private key sk a The fourth user’s DID and permission application information are digitally signed. The digital signature value is then submitted to the alliance chain, and the third user’s DID ( Figure 7 did a ), public-private key pair (pk a ,sk a ) is also submitted to the consortium chain for use in creating credentials.

[0206] Blockchain:authorityCredential:=authorize(did a ,pk a ,sk a ,did u ,pk u ,sk u ,sig,

[0207] authorityInfo), the sixth smart contract on the alliance chain is triggered, thereby creating an electronic authority credential authorityCredential for the fourth user.

[0208] In the actual algorithm implementation of the sixth smart contract, the algorithm authorize is included. In this algorithm, when authenticating the user (credential holder, i.e., the fourth user) and the administrator (credential issuer, i.e., the third user), the authentication process can refer to the identity authentication part in Algorithm 2. After the identity authentication is passed, the digital signature submitted by the administrator is verified to be correct. The signature verification process can refer to the signature verification part in Algorithm 1. If the digital signature verification is passed, the construction of a verifiable credential begins. The process of constructing a verifiable credential can refer to Algorithm 4. The difference is that in the sixth contract, the private key of the credential issuer (the third user) is used to sign the Claim part, while in Algorithm 4, the private key of the resource holder (the second user) is used to sign the Claim part of the electronic resource credential.

[0209] Blockchain->Registry:storageCredential(authorityCredential) runs the storageCredential algorithm on the consortium chain, notifying all parties with management rights to the fourth user's electronic authority credential to store it in a private, public, or domain-specific credential registry. The registry manages the fourth user's electronic authority credential. This can be the third user who issued the credential or the administrator of the fourth user's domain, depending on the user's needs or domain regulations.

[0210] Blockchain->User:authorizeRes(authorityCredential). After the electronic authority credential is created, the consortium chain sends authorizeRes to the fourth user and returns the ID number of the credential to the fourth user. As a result, the fourth user can query and use their authority credential at any time.

[0211] F. The fifth user who has obtained user permissions and wants to access resources initiates a resource access request to the alliance chain, triggering the first smart contract on the alliance chain to verify the validity of the fifth user's DID, electronic permission certificate, and the electronic resource certificate that the fifth user wants to access, and allows the fifth user to access the resources he wants to access after the verification is passed.

[0212] The resource access request includes the fifth user's DID, public-private key pair, and ID of the electronic authority certificate, as well as the ID and domain name of the electronic resource certificate that the fifth user wants to access.

[0213] Access control is a critical step when users request resource access, whether in cross-domain or local domain scenarios. Access control involves two main aspects: first, verifying the legitimacy of the user's identity through identity authentication. Second, performing permission assessment to determine whether the user has the appropriate access rights. In this embodiment of the present invention, access control is fully automated by smart contracts, eliminating errors caused by human intervention. Furthermore, the access control process generates logs for review and tracing.

[0214] Specifically, the contents of the first smart contract include:

[0215] (1-a) Obtaining the DID document of the fifth user based on the DID of the fifth user; checking whether the public key of the fifth user is in the public key list of its DID document; if the check passes, encrypting the random string using the public key of the fifth user, and decrypting the encrypted result using the private key of the fifth user;

[0216] (1-b) If the decryption is successful, requesting the certificate information of the electronic authorization certificate from the certificate registry where the electronic authorization certificate is located based on the ID of the electronic authorization certificate of the fifth user;

[0217] (1-c) verifying the validity of the electronic permission certificate of the fifth user based on the obtained credential information, including: checking whether the electronic permission certificate is on the consortium chain, checking whether the electronic permission certificate is within the validity period, and verifying the digital signature portion of the electronic permission certificate using the public key of the third user who created the electronic permission certificate;

[0218] (1-d) if the electronic authorization certificate of the fifth user is valid, determining whether the fifth user has the user authorization to access the electronic resource to be accessed according to the business logic;

[0219] (1-e) If the judgment is yes, based on the ID of the electronic resource certificate that the fifth user wants to access, request the certificate registry of the domain where the domain name is located to obtain the certificate information of the electronic resource certificate;

[0220] (1-f) verifying the validity of the electronic resource certificate to be accessed by the fifth user based on the obtained certificate information, including: checking whether the electronic resource certificate is located on the alliance chain, checking whether the electronic resource certificate is within the validity period, and verifying the digital signature portion of the electronic resource certificate using the public key of the second user who created the electronic resource certificate;

[0221] (1-g) If the electronic resource certificate that the fifth user wants to access is valid, return the electronic resource certificate to the fifth user.

[0222] In addition, after verifying the validity of the fifth user's DID, electronic permission certificate, and the electronic resource certificate that the fifth user wants to access, the multi-domain environment access control method based on the alliance chain provided by the embodiment of the present invention can also include: triggering the seventh smart contract to generate an access log.

[0223] Figure 8 The specific process of access control is shown, including:

[0224] User->Blockchain:accessReq(did u ,pk u ,sk u ,credentialId,resourceId,domain), when the fifth

[0225] user( Figure 8 When the fifth user (DID) accesses system resources, it first initiates a resource access request to the alliance chain. The request contains the DID (did u ) and the public-private key pair (pk u ,sk) for identity authentication, and also includes the ID of the fifth user's electronic authorization certificate ( Figure 8 credentialId in 8) in order to determine the authority of the fifth user; in addition, the request also includes the ID of the electronic resource credential that the fifth user wants to access (resourceId in 8) and the domain name (domain).

[0226] Blockchain:authenticateResult:=authenticate(did u ,pk u ,sk u ), the authenticate algorithm is run on the consortium chain to authenticate the fifth user. If authentication fails, the fifth user's access request is denied, and the fifth user's DID may also be frozen. authenticateResult represents the authentication result of the fifth user.

[0227] Blockchain->Registry:queryCredential(credentialId). If the identity authentication is successful, the queryCredential algorithm is run on the consortium chain to request the credential information from the credential registry where the fifth user's electronic permission certificate is located. Registry represents the user who holds the credential registry.

[0228] Blockchain:authorityResult:=verifyAuthority(did u After obtaining the credential information, the verifyAuthority algorithm is run on the consortium chain to verify the credential through a smart contract to determine the fifth user's permissions. If the fifth user does not have the corresponding permissions, their access request is denied, and the fifth user's electronic permission certificate can also be frozen.

[0229] For example, the verifyAuthority algorithm may be as shown in Algorithm 5:

[0230]

[0231]

[0232] In Algorithm 5, the fifth user's electronic permission certificate is first checked to see if it is stored on the consortium chain and is within its validity period. Next, the public key of the certificate issuer (the second user who created the fifth user's electronic resource certificate) is used to verify the digital signature to determine if the electronic permission certificate has been tampered with. Finally, according to business logic, a determination is made as to whether the electronic permission certificate grants access to the resource, that is, whether the user possesses the claimed permission.

[0233] Blockchain->Registry:queryResource(resourceId). After the permission is verified, the queryResource algorithm is run on the consortium chain based on the resourceId to request the credential information from the credential registry where the electronic resource credential is located. Note that the Registry here refers to the user holding the credential registry where the electronic resource credential is located, which is different from the user holding the credential registry where the fifth user's electronic permission credential is located.

[0234] Blockchain:resource,accessResult:=verifyResource(resourceId,resource). After obtaining the credential information, the verifyResource algorithm is run on the consortium chain to verify the validity of the electronic resource credential. If there is a problem with the electronic resource credential, the fifth user's access is denied. The verifyResource algorithm verifies the authenticity of the electronic resource credential and whether it has been tampered with. The verification process is similar to Algorithm 5.

[0235] The above algorithms authenticate, queryCredential, verifyAuthority, queryResource, and verifyResource running on the consortium chain are all included in the fifth smart contract.

[0236] Blockchain:generateLog(did u ,credentialId,resourceId,accessResult). Regardless of whether the fifth user is allowed to access this time, the seventh smart contract generateLog will be run on the alliance chain to generate access logs for archiving, so as to facilitate the tracing of user behavior in the future.

[0237] For example, the specific algorithm implementation of the seventh smart contract may include the following Algorithm 6:

[0238]

[0239] Blockchain->User:accessRes(resource). If there is no problem with the electronic resource certificate, the fifth user is allowed to access the resource. The alliance chain sends accessRes to the fifth user and returns the resource to the fifth user.

[0240] Based on the detailed description of each step above, Figure 9 The control logic of the multi-domain environment access control method based on the alliance chain provided by the embodiment of the present invention is comprehensively shown in FIG. Among them, the user registers identity, authorizes and publishes resources in the domain where he is located. The user (such as Figure 4 A user in domain A in the multi-domain environment) enters a multi-domain environment and first registers an identity in a certain domain by applying for a DID. When a user applies for a DID, he or she also has at least a set of public and private key pairs, which can be used when issuing electronic resource certificates. If a user wants to access resources in the local domain A or across domain B, he or she needs to have the corresponding permissions, so an electronic permission certificate needs to be issued to the user for authorization. After obtaining the DID and electronic permission certificate, the user can store it in his or her own private registry and use it at any time. If the user does not have a private registry, it can also be stored in an operating public registry. In addition, in some domains (such as schools, etc.), the electronic permission certificates of users in the domain will be stored in the registry within the domain. Administrators (such as Figure 4 Domain administrators (in Domain A) can define the CPTs required within the domain based on business needs. Users can issue electronic resource credentials based on the corresponding CPTs and sign the resources using their private keys. Furthermore, after publishing resources, the publishing process is logged and uploaded to the blockchain.

[0241] Secondly, the user will request cross-domain authorization and cross-domain access to resources. Cross-domain authorization is issued by the requesting domain to the user. For cross-domain access to resources, the user first requests the domain where the resource is located (such as Figure 4 A resource access request is made from a user (domain B in the Context context), requiring the user to provide a DID and electronic permission certificate. The smart contract verifies the user's DID and electronic permission certificate and performs a permissions check to determine whether the certificate has the permissions claimed by the user. After identity authentication and permission checks are successful, the smart contract further verifies the electronic resource certificate and, if verified, returns the resource to the user. The deployment and maintenance of smart contracts are the responsibility of the consortium chain's nodes. User access records are also logged and recorded on the blockchain. Even if a user makes an illegal access, the log can be retrieved at any time for evidence.

[0242] In the multi-domain access control method based on the consortium chain provided by the embodiments of the present invention, all users in the multi-domain environment register their DID and public-private key pairs on the consortium chain; this solves the problem of easily forged identities and permissions in a multi-domain environment. The first user who manages resources creates a resource-class CPT on the consortium chain using their own DID and public-private key pair. Correspondingly, the second user who holds the resource publishes the resource on the consortium chain using their own DID and public-private key pair by issuing an electronic resource certificate. This electronic resource certificate is a verifiable certificate that complies with the resource-class CPT. This solves the data consistency and compatibility issues in a multi-domain environment. The third user who manages user rights creates a permission-type CPT on the alliance chain with his own DID and public-private key pair. The fourth user who wants to obtain user rights applies for an electronic permission certificate through the alliance chain with his own DID and public-private key pair to obtain user rights. The electronic permission certificate is a verifiable certificate that complies with the permission-type CPT. The fifth user who has obtained user rights and wants to access resources initiates a resource access request to the alliance chain to trigger the first smart contract on the alliance chain to verify the validity of the fifth user's DID, electronic permission certificate, and the electronic resource certificate that the fifth user wants to access. After the verification is passed, the fifth user is allowed to access the resource he wants to access, thereby solving the problem of easy leakage of personal privacy and resources in a multi-domain environment and the problem of high degree of centralization of access control. In summary, the embodiment of the present invention solves the problems of data heterogeneity, easy forgery of identities and permissions, easy leakage of personal privacy and resources, and high degree of centralization of access control in a multi-domain environment. It can effectively control the operation behavior of members from different domains, thereby better protecting the security of information resources, playing an important role in information security, and making the access control process more convenient.

[0243] It's worth noting that in existing related research, using blockchain accounts as identifiers makes it difficult to record more user information, using IBS as an identifier exposes user identity details, and using certificates as identifiers requires reliance on trusted institutions. However, the embodiments of the present invention use DIDs to identify users and electronic permission certificates to implement user permissions. This allows for recording more user information in electronic permission certificates without exposing user identity details, and the distributed nature of DIDs eliminates the need for reliance on trusted institutions. Therefore, the methods provided in the embodiments of the present invention are suitable for multi-domain scenarios with a large number of users or devices.

[0244] It should be noted that the terms "first," "second," and the like are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of devices and methods consistent with some aspects of the present disclosure.

[0245] In the description of this specification, the reference terms "one embodiment," "some embodiments," "example," "specific example," or "some examples" mean that the specific features or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features or characteristics described can be combined in any suitable manner in one or more embodiments or examples. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification.

[0246] Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art may understand and implement other variations of the disclosed embodiments by reviewing the drawings and the disclosed content. In the description of the present invention, the word "comprising" does not exclude other components or steps, "one" or "a" does not exclude multiple situations, and "multiple" means two or more, unless otherwise clearly and specifically limited. In addition, certain measures are recorded in different embodiments, but this does not mean that these measures cannot be combined to produce good results.

[0247] The above is a further detailed description of the present invention in conjunction with specific preferred embodiments, and the specific implementation of the present invention should not be considered to be limited to these descriptions. For those skilled in the art of the present invention, without departing from the concept of the present invention, several simple deductions or substitutions can be made, which should be considered to fall within the scope of protection of the present invention.

Claims

1. A multi-domain environment access control method based on alliance chain, characterized in that: include: All users in a multi-domain environment register DID and public-private key pairs on the consortium chain; The first user who manages resources creates a resource-type CPT on the consortium chain with his or her DID and public-private key pair. The claim structure of resource-type CPTs defined by different business needs is different. The second user holding the resource publishes the resource by issuing an electronic resource certificate on the consortium chain using his or her own DID and public-private key pair; the electronic resource certificate is a verifiable certificate that complies with the CPT of the resource type; A third user who manages user permissions creates a permission-based CPT on the consortium chain using their own DID and public-private key pair; The fourth user who wants to obtain user rights initiates a CPT query request to the alliance chain according to the user rights he wants to obtain, triggering the fourth smart contract on the alliance chain to query CPT for the fourth user; the CPT query request includes the DID, public-private key pair of the fourth user and the CPT identifier corresponding to the user rights he wants to obtain; the fourth user obtains the Claim structure of the permission class CPT to which the user rights he wants to obtain belong based on the query result of the fourth smart contract; initiates a user rights application to the alliance chain according to the Claim structure; the user rights application includes the DID, public-private key pair and permission application information of the fourth user; the third user who created the Claim structure reviews the permission application information, and after the review is passed, signs the DID and permission application information of the fourth user to obtain a digital signature, uploads the DID, public key and the digital signature of the third user to the alliance chain, triggering the sixth smart contract on the alliance chain to create an electronic permission certificate for the fourth user; the electronic permission certificate is a verifiable certificate that complies with the permission class CPT; A fifth user who has obtained user rights and wants to access resources initiates a resource access request to the alliance chain, triggering the first smart contract on the alliance chain to verify the validity of the fifth user's DID, electronic permission certificate, and the electronic resource certificate that the fifth user wants to access. After the verification is passed, the fifth user is allowed to access the resource. The resource access request includes the DID, public-private key pair, and ID of the electronic authorization certificate of the fifth user, and also includes the ID and domain name of the electronic resource certificate to be accessed by the fifth user; The content of the first smart contract includes: Obtaining the DID document of the fifth user based on the DID of the fifth user; checking whether the public key of the fifth user is in the public key list of its DID document; if the check passes, encrypting the random string using the public key of the fifth user, and decrypting the encrypted result using the private key of the fifth user; If the decryption is successful, requesting the credential information of the electronic authorization certificate from the credential registry where the electronic authorization certificate is located according to the ID of the electronic authorization certificate of the fifth user; Verifying the validity of the electronic permission certificate of the fifth user based on the obtained credential information, including: checking whether the electronic permission certificate is on the consortium chain, checking whether the electronic permission certificate is within the validity period, and verifying the digital signature portion of the electronic permission certificate using the public key of the third user who created the electronic permission certificate; If the electronic authorization certificate of the fifth user is valid, determining whether the fifth user has the user authorization to access the electronic resource to be accessed according to the business logic; If the judgment is yes, requesting the credential information of the electronic resource credential to be accessed by the fifth user from the credential registry of the domain where the domain name is located according to the ID of the electronic resource credential to be accessed by the fifth user; Verifying the validity of the electronic resource credential to be accessed by the fifth user based on the acquired credential information, including: checking whether the electronic resource credential is located on the consortium chain, checking whether the electronic resource credential is within the validity period, and verifying the digital signature portion of the electronic resource credential using the public key of the second user who created the electronic resource credential; If the electronic resource certificate that the fifth user wants to access is valid, the electronic resource certificate is returned to the fifth user.

2. The multi-domain environment access control method based on alliance chain according to claim 1 is characterized in that: The way each user registers a DID and public-private key pair on the consortium chain includes: The user initiates a user registration request to the consortium chain; The sixth user who manages user registration reviews the user information in the user registration request. After the review is passed, the sixth user generates a digital summary based on the user information and signs the digital summary with the private key to obtain a digital signature. The sixth user uploads their own DID, public key, and digital signature to the consortium chain, triggering the second smart contract on the consortium chain to register the DID and public-private key pair for the user who initiated the user registration request. The content of the second smart contract includes: Obtaining a DID document of the sixth user according to the DID of the sixth user; Checking whether the public key of the sixth user is in the public key list of its DID document; If the check passes, verify the digital signature using the public key of the sixth user; If the verification is successful, a public-private key pair and DID are created for the user who initiated the user registration request, and the user information is encrypted using the user's public key; The created DID, public-private key pair, and encrypted user information are recorded in the consortium chain, and the hash value of the DID, public-private key pair, and user information is returned to the user who initiated the user registration request.

3. The multi-domain environment access control method based on alliance chain according to claim 1 is characterized in that: The first user who manages resources creates a resource-type CPT on the consortium chain using his or her DID and public-private key pair, including: the first user initiates a CPT creation request to the consortium chain, triggering a third smart contract on the consortium chain to create a resource-type CPT for the first user; A third user who manages user rights creates a permission-based CPT on the consortium chain using his or her DID and public-private key pair, including: the third user uploads a CPT creation request to the consortium chain, triggering the third smart contract to create a permission-based CPT for the third user; The CPT creation request includes the DID of the user initiating the request, the public-private key pair, and the Claim structure of the CPT to be created; The content of the third smart contract includes: Obtain the DID document of the user who initiated the CPT creation request based on the DID of the user; Check if the user's public key is in the public key list of its DID document; If the check passes, the random string is encrypted using the user's public key, and the encrypted result is decrypted using the user's private key; If the decryption is successful, a CPT is created for the user according to the Claim structure, the created CPT is signed using the user's private key, and the created CPT is returned to the user who initiated the CPT creation request and recorded in the consortium chain.

4. The multi-domain environment access control method based on alliance chain according to claim 1 is characterized in that: The second user holding the resource publishes the resource by issuing an electronic resource certificate on the consortium chain with his or her own DID and public-private key pair, including: The second user initiates a CPT query request to the consortium chain, triggering the fourth smart contract on the consortium chain to query the CPT for the second user; the CPT query request includes the DID of the user initiating the request, the public-private key pair, and the CPT identifier corresponding to the resource to be published; The second user obtains the Claim structure of the resource class CPT to which the resource to be released belongs based on the query result of the fourth smart contract; The second user initiates a resource release request to the alliance chain according to the Claim structure, triggering the fifth smart contract on the alliance chain to enable the second user to release the electronic resource certificate on the alliance chain; wherein, the resource release request includes the second user's DID, public-private key pair and the resource to be released.

5. The multi-domain environment access control method based on alliance chain according to claim 4 is characterized in that: The content of the fourth smart contract includes: Get the DID document of the user who initiated the CPT query request based on the DID of the user; Check if the user's public key is in the public key list of its DID document; If the check passes, the random string is encrypted using the user's public key, and the encrypted result is decrypted using the user's private key; If the decryption is successful, the corresponding CPT is determined based on the CPT identifier in the CPT query request, and the DID of the target user who created the CPT is determined; Obtain the DID document of the target user according to the DID of the target user; Check whether the target user's public key is in the public key list of its DID document; If the check passes, the Claim structure of the CPT corresponding to the CPT identifier is returned.

6. The multi-domain environment access control method based on alliance chain according to claim 4 is characterized in that: The contents of the fifth smart contract include: Obtaining a DID document of the second user according to the DID of the second user; Check whether the second user's public key is in the public key list of its DID document; If the check passes, encrypt the random string using the second user's public key, and decrypt the encrypted result using the second user's private key; If decryption is successful, obtain the DID document of the first user based on the DID of the first user who created the Claim structure; check whether the public key of the first user is in the public key list of its DID document; If the check passes, the second user creates an electronic resource certificate according to the claim structure, generates an ID for the electronic resource certificate, and signs the claim part of the electronic resource certificate using his own private key; Record the created electronic resource certificate to the alliance chain; Notify the first user who created the Claim structure to store the electronic resource credential in his / her credential registry; The ID of the created electronic resource credential is returned to the second user.

7. The multi-domain environment access control method based on alliance chain according to claim 1 is characterized in that: The contents of the sixth smart contract include: Obtaining the fourth user's DID document based on the fourth user's DID; checking whether the fourth user's public key is in the public key list of its DID document; if the check passes, encrypting the random string using the fourth user's public key and decrypting the encrypted result using the fourth user's private key; Obtaining the DID document of the third user based on the DID of the third user who created the Claim structure; checking whether the third user's public key is in the public key list of its DID document; if the check passes, encrypting the random string using the third user's public key and decrypting the encrypted result using the third user's private key; If both decryptions are successful, the digital signature is verified using the public key of the third user who created the Claim structure; If the verification is successful, an electronic rights certificate is created for the fourth user according to the Claim structure, an ID is generated for the electronic rights certificate, and the claim portion of the electronic rights certificate is signed using the private key of the third user who created the Claim structure; Recording the electronic permission certificate created for the fourth user into the alliance chain; Notifying all parties having management rights over the electronic authorization certificate of the fourth user to store the electronic authorization certificate in their respective certificate registries; The ID of the created electronic authorization certificate is returned to the fourth user.

8. The multi-domain environment access control method based on alliance chain according to claim 1 is characterized in that: The method further comprises: After verifying the validity of the fifth user's DID, electronic authority certificate, and the electronic resource certificate that the fifth user wants to access, the seventh smart contract is triggered to generate an access log.

Images