Service invocation permission verification method and device, medium and apparatus

Abstract

The application discloses a service calling permission verification method and device, a medium and equipment, relates to the technical field of service calling, and the method comprises the following steps: a second service receives a first service identity certificate sent by a first service; reference verification data of a reference permission structure tree corresponding to the first service in an extension field of the first service identity certificate is determined; the reference permission structure tree is a binary tree representation result of a first declaration document recorded by a consensus node of a block chain, and the first declaration document indicates that the first service is granted a calling permission; a verifiable credential and a verification path are received; the verifiable credential indicates that the first service has the calling permission for the second service, and the verification path is used for verifying the existence of the verifiable credential in the reference permission structure tree; target verification data is calculated according to the verifiable credential and the verification path; and a calling permission verification result is determined based on the target verification data and the reference verification data. The application realizes the decentralized verification of the service calling permission.

Description

Technical Field

[0001] This application relates to the field of service invocation technology, specifically to methods, apparatus, media, and devices for verifying service invocation permissions. Background Technology

[0002] In a microservices architecture, calls between services require authentication to ensure that only services with the necessary permissions can call other services.

[0003] In related technologies, authentication information and authentication are generally managed and performed through a centralized authentication server. Services rely on communication with the authentication server to complete authentication. On the one hand, this method has the risk of centralization, and on the other hand, it lacks protection for authentication information between services, which can lead to the leakage of call relationships between services and also pose a danger to the system. Summary of the Invention

[0004] To achieve decentralized verification of service invocation permissions, this application provides a method, apparatus, medium, and device for verifying service invocation permissions. The technical solution is as follows:

[0005] Firstly, this application provides a method for verifying service invocation permissions, applied to a second service, the method comprising:

[0006] Receive the first service identity certificate sent by the first service, and verify the identity of the first service based on the first service identity certificate;

[0007] Determine the reference verification data of the reference permission structure tree corresponding to the first service in the extended fields of the first service identity certificate; the reference permission structure tree is the binary tree representation of the first declaration document recorded by the consensus node of the blockchain, the first declaration document corresponds to the decentralized identity identifier of the first service, and the first declaration document indicates the calling permissions granted to the first service;

[0008] After successful authentication of the first service, the system receives a verifiable credential sent by the first service and a verification path for the verifiable credential in the reference permission structure tree. The verifiable credential indicates that the first service has the permission to call the second service, and the verification path is used to verify the existence of the verifiable credential in the reference permission structure tree.

[0009] The target verification data is calculated based on the verifiable credentials and the verification path.

[0010] Based on the target verification data and the reference verification data, a call permission verification result is determined, and the call permission verification result indicates whether the first service has the right to call the second service.

[0011] In one embodiment of this application, the verification path includes node verification data corresponding to each node in at least one node, and the node verification data corresponding to each node is arranged from low to high hierarchy according to the corresponding node. The step of calculating the target verification data based on the verifiable credential and the verification path includes:

[0012] Traverse the node verification data corresponding to each node in the verification path. When traversing to the node verification data corresponding to each node, perform the following steps:

[0013] The node verification data corresponding to the currently traversed node is merged with the current first verification data to obtain the current merged data; when the currently traversed node is the first node in the verification path, the current first verification data is the verifiable credential; when the currently traversed node is not the first node in the verification path, the current first verification data is the current second verification data corresponding to the previous node of the currently traversed node.

[0014] Based on a preset hash function, the current merged data is hashed to obtain the current second verification data corresponding to the current traversed node;

[0015] At the end of the traversal, the current second verification data corresponding to the last node in the verification path is taken as the target verification data.

[0016] In one embodiment of this application, determining the call permission verification result based on the target verification data and the reference verification data includes:

[0017] The target verification data and the reference verification data are compared to obtain the comparison result;

[0018] If the comparison result indicates that the target verification data and the reference verification data are the same, the call permission verification result indicating that the first service has the right to call the second service is obtained;

[0019] If the comparison result indicates that the target verification data and the reference verification data are different, a call permission verification result indicating that the first service does not have the right to call the second service is obtained.

[0020] In one embodiment of this application, the step of receiving the verifiable credentials sent by the first service and the verification path of the verifiable credentials in the reference permission structure tree after successful authentication of the first service includes:

[0021] After successful authentication of the first service, receive the encrypted credentials and the verification path sent by the first service;

[0022] Obtain the public key from the asymmetric key corresponding to the first service from the first service ID book;

[0023] Based on the public key, the encrypted credential is decrypted to obtain the verifiable credential.

[0024] In one embodiment of this application, the method further includes:

[0025] Obtain the second service identity certificate from a trusted certificate authority.

[0026] The second service identity certificate is sent to the first service so that the first service can authenticate the second service.

[0027] In one embodiment of this application, the method further includes:

[0028] If the access permission verification result indicates that the first service has access to the second service, verifiable declaration information is generated; the verifiable declaration information includes declaration attribute information, declaration content information, and the digital signature of the second service.

[0029] Based on the smart contract of the blockchain, the verifiable declaration information is written into the first declaration document.

[0030] Secondly, this application provides a method for verifying service invocation permissions, applied to a first service, the method comprising:

[0031] From the synchronization nodes of the blockchain, a verifiable credential and its verification path in the reference permission structure tree corresponding to the first service are obtained. The verifiable credential indicates that the first service has the right to call the second service. The reference permission structure tree is a binary tree representation of the first declaration document recorded by the consensus nodes of the blockchain. The first declaration document corresponds to the decentralized identity identifier of the first service and indicates the calling permission granted to the first service. The verification path is used to verify the existence of the verifiable credential in the reference permission structure tree.

[0032] Obtain the first service identity certificate of the first service from a trusted certificate authority, wherein the extended field of the first service identity certificate contains reference verification data of the reference permission structure tree;

[0033] The first service identity certificate is sent to the second service so that the second service can authenticate the first service and obtain the reference verification data.

[0034] After the second service successfully authenticates the first service, it sends the verifiable credentials and the verification path to the second service, so that the second service can calculate the target verification data based on the verifiable credentials and the verification path, and determine the call permission verification result based on the target verification data and the reference verification data. The call permission verification result indicates whether the first service has the right to call the second service.

[0035] In one embodiment of this application, the step of sending the verifiable credential and the verification path to the second service after the second service has successfully authenticated the first service includes:

[0036] Determine the private key in the asymmetric key pair corresponding to the first service;

[0037] Based on the private key, the verifiable credential is encrypted to obtain an encrypted credential;

[0038] After the second service successfully authenticates the first service, it sends the encrypted credentials and the verification path to the second service.

[0039] In one embodiment of this application, the step of sending the verifiable credential and the verification path to the second service after the second service has successfully authenticated the first service includes:

[0040] Receive the second service identity certificate sent by the second service;

[0041] The second service is authenticated based on its identity certificate.

[0042] After successful authentication of the second service, the verifiable credentials and the authentication path are sent to the second service.

[0043] Thirdly, this application provides a service invocation permission verification device, applied to a second service, the device comprising:

[0044] The first identity certificate receiving and verification module is used to receive the first service identity certificate sent by the first service, and to verify the identity of the first service based on the first service identity certificate;

[0045] The reference verification data determination module is used to determine the reference verification data of the reference permission structure tree corresponding to the first service in the extended field of the first service identity certificate; the reference permission structure tree is a binary tree representation of the first declaration document recorded by the consensus node of the blockchain, the first declaration document corresponds to the decentralized identity identifier of the first service, and the first declaration document indicates the calling permission granted to the first service.

[0046] The verifiable credential and verification path receiving module is used to receive, after the authentication of the first service is successful, a verifiable credential sent by the first service and a verification path of the verifiable credential in the reference permission structure tree; the verifiable credential indicates that the first service has the right to call the second service, and the verification path is used to verify the existence of the verifiable credential in the reference permission structure tree.

[0047] The target verification data calculation module is used to calculate the target verification data based on the verifiable credential and the verification path.

[0048] The access control module is invoked to determine the access control verification result based on the target verification data and the reference verification data. The access control verification result indicates whether the first service has access control to the second service.

[0049] Fourthly, this application provides a service access permission verification device, applied to a first service, the device comprising:

[0050] The verifiable credential and verification path acquisition module is used to acquire verifiable credentials and the verification path of the verifiable credential in the reference permission structure tree corresponding to the first service from the synchronization nodes of the blockchain; the verifiable credential indicates that the first service has the right to call the second service, the reference permission structure tree is a binary tree representation of the first declaration document recorded by the consensus nodes of the blockchain, the first declaration document corresponds to the decentralized identity identifier of the first service, and the first declaration document indicates the calling permission granted to the first service; the verification path is used to verify the existence of the verifiable credential in the reference permission structure tree.

[0051] The first identity certificate acquisition module is used to obtain the first service identity certificate of the first service from a trusted certificate authority, wherein the extended fields of the first service identity certificate contain reference verification data of the reference permission structure tree.

[0052] The first identity certificate sending module is used to send the first service identity certificate to the second service, so that the second service can authenticate the first service and obtain the reference verification data;

[0053] The verifiable credentials and verification path sending module is used to send the verifiable credentials and the verification path to the second service after the second service has successfully authenticated the first service, so that the second service can calculate the target verification data based on the verifiable credentials and the verification path and determine the call permission verification result based on the target verification data and the reference verification data. The call permission verification result indicates whether the first service has the right to call the second service.

[0054] Fifthly, this application provides a computer-readable storage medium storing at least one instruction or at least one program, which is loaded and executed by a processor to implement the service access permission verification method as described in the first or second aspect.

[0055] In a sixth aspect, this application provides a computer device including a processor and a memory, wherein the memory stores at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the service call permission verification method as described in the first or second aspect.

[0056] In a seventh aspect, this application provides a computer program product, the computer program product including computer instructions, which, when executed by a processor, implement the service access permission verification method as described in the first or second aspect.

[0057] The service access permission verification method, apparatus, medium, and equipment provided in this application have the following technical effects:

[0058] In the solution provided in this application, the first service obtains a verifiable credential and its verification path in the reference permission structure tree corresponding to the first service from the blockchain's synchronization nodes. The verifiable credential indicates that the first service has the authority to call the second service. The reference permission structure tree is a binary tree representation of the first declaration document recorded by the blockchain's consensus nodes. The first declaration document corresponds to the decentralized identity identifier of the first service and indicates the grantable calling authority to the first service. The first service also obtains its first service identity certificate from a trusted certificate authority. The extended fields of the first service identity certificate contain reference verification data from the aforementioned reference permission structure tree. The first service sends its first service identity certificate to the second service. The second service authenticates the first service based on the first service identity certificate and determines the reference verification data in the extended fields of the first service identity certificate corresponding to the first service in the reference permission structure tree. After the second service successfully authenticates the first service, the first service sends the verifiable credential and verification path to the second service. The second service calculates the target verification data based on the verifiable credential and verification path. Based on the target verification data and the reference verification data, the second service determines the calling authority verification result indicating whether the first service has the authority to call the second service.

[0059] In the solution provided in this application, by using a first declaration document corresponding to the decentralized identity of the first service, the granting access permissions to the first service are recorded on the consensus nodes of the blockchain and synchronized to the synchronization nodes of the blockchain. The first declaration document is then encrypted in the form of a reference permission structure tree, achieving distributed recording and encrypted storage of the granting access permissions to the first service on the blockchain. When the first service needs to call the second service, it can decentralizedly obtain the aforementioned verifiable credentials and their verification paths from the reference permission structure tree from the synchronization nodes of the blockchain, without relying on a centralized node managing permission data, thus avoiding the risk of centralization.

[0060] In the solution provided in this application, when the first service needs to call the second service, the second service uses the first identity certificate issued by a trusted certificate authority to authenticate the first service and determine the reference verification data of the reference permission structure tree corresponding to the first service in the extended field of the first identity certificate. That is, the first identity certificate can be used to achieve accurate identity verification and trusted transmission of reference verification data, ensuring the accuracy of subsequent verification.

[0061] In the solution provided in this application, after the second service successfully authenticates the first service, the second service calculates the target verification data based on the verifiable credentials and verification path sent by the first service, and determines the call permission verification result based on the target verification data and reference verification data. That is, the call permission is reliably verified between services without relying on a centralized node for verifying permission data, thus avoiding the risk of centralization and also keeping the verification relationship and verification data confidential.

[0062] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

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

[0064] Figure 1 This is a schematic diagram of the implementation environment of a service call permission verification method provided in an embodiment of this application;

[0065] Figure 2 This is a flowchart illustrating a service call permission verification method provided in an embodiment of this application;

[0066] Figure 3 This is a schematic diagram of a decentralized identity identifier provided in an embodiment of this application;

[0067] Figure 4 This is a schematic diagram of a reference permission structure tree corresponding to a first declaration document provided in an embodiment of this application;

[0068] Figure 5 This is a schematic diagram of a process for calculating target verification data provided in an embodiment of this application;

[0069] Figure 6 This is a schematic diagram of a decentralized authentication architecture provided in an embodiment of this application;

[0070] Figure 7 This is a schematic diagram of the functional modules of a consensus node on a blockchain provided in an embodiment of this application;

[0071] Figure 8 This is a schematic diagram of a data structure provided in an embodiment of this application;

[0072] Figure 9This is a schematic diagram of a service call permission verification device for a second service provided in an embodiment of this application;

[0073] Figure 10 This is a schematic diagram of a service call permission verification device applied to a first service, provided in an embodiment of this application;

[0074] Figure 11 This is a schematic diagram of the hardware structure of a device for implementing a service call permission verification method provided in an embodiment of this application. Detailed Implementation

[0075] To achieve decentralized verification of service invocation permissions, embodiments of this application provide a method, apparatus, medium, and device for verifying service invocation permissions. The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout.

[0076] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0077] To facilitate understanding of the technical solutions and their effects described in the embodiments of this application, the relevant technical terms are explained in the embodiments of this application:

[0078] Decentralized Identity (DID) is a type of autonomous, distributed, verifiable, and persistent identity identifier that can be used by any entity, including people, organizations, goods, and services. Compared to traditional identity systems based on public key infrastructure, blockchain-based distributed identity systems offer advantages such as decentralization, autonomous and controllable identity, and trusted data exchange.

[0079] Merkle Tree: A Merkle Tree is a cryptographic data structure, often referred to as a hash tree. It's a binary tree structure where each leaf node represents the hash value of a data segment, and each non-leaf node is a cryptographic hash of the hash values ​​of its child nodes. This structure allows the integrity of the entire dataset to be verified by checking the hash value of the root node. Any tiny change to the data will cause a change in the hash value of the root node, effectively detecting whether the data has been tampered with.

[0080] A certificate is proof of identity for a public key holder in a Public Key Infrastructure (PKI) system, issued by a Certificate Authority (CA). PKI enables asymmetric encryption and digital signatures for information.

[0081] Decentralized Identity (DID): Compared to traditional PKI-based identity systems, blockchain-based DID digital identity systems offer advantages such as ensuring data authenticity and reliability, protecting user privacy and security, and strong portability. Its strengths include:

[0082] Decentralization: Based on blockchain, it avoids identity data being controlled by a single centralized authority;

[0083] Self-controlled identity: Based on DPKI (Distributed Public Key Infrastructure), each user's identity is not controlled by a trusted third party, but by its owner, and individuals can manage their own identities autonomously;

[0084] Trusted data exchange: Identity-related data is anchored on the blockchain, and the authentication process does not depend on the application providing the identity.

[0085] It is understood that in the specific implementation of this application, data related to service identity certificates, decentralized identity identifiers, public keys or private keys, etc., are involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from users, platforms, applications, etc. is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of relevant countries and regions.

[0086] Please see Figure 1 This is a schematic diagram illustrating the implementation environment of a service call permission verification method provided in this application embodiment, as shown below. Figure 1 As shown, the implementation environment may include at least a decentralized network, a first service 201, a second service 202, and a certificate authority 301.

[0087] Specifically, a decentralized network / blockchain refers to a system used for data processing between nodes. This network may include multiple consensus nodes 101 and multiple synchronization nodes 102. Consensus nodes 101 are used to register decentralized identity identifiers (DIDs) for each service and can generate related claim documents according to smart contracts. The smart contracts are responsible for reading and updating the decentralized identity identifiers and claim documents on the blockchain. The smart contracts on consensus nodes 101 are primarily responsible for binding the actual entity identity of the service to the DID on the blockchain and managing the service's claim documents.

[0088] Specifically, there can be multiple synchronization nodes 102, each capable of independently providing information access services for different services. In response to a service's information retrieval request, a synchronization node can obtain the service's decentralized identity identifier and corresponding declaration document from the consensus node 101, or the synchronization node 102 can periodically synchronize the decentralized identity identifiers and corresponding declaration documents of all services from the consensus node 101.

[0089] Specifically, Certificate Authority 301 is primarily responsible for issuing service identity certificates for various services. When issuing a service identity certificate, the Certificate Authority mainly performs the following processes: verifying the source of the service applying for the certificate and verifying whether the IP address indicating the source is authorized; after the source verification is successful, obtaining the service's claim document from consensus node 101 of the blockchain to obtain the service's trusted identity claim; verifying whether the trusted identity claim matches the verifiable identity commitment provided by the service; after confirming that the visitor is a genuine service, issuing a service identity certificate for the service, and writing the node reference verification data of the root node of the reference permission structure tree of the service's corresponding claim document obtained from consensus node 101 of the blockchain into the extended field of the service's service identity certificate to ensure the consistency between the public key certificate identity and the on-chain DID identity.

[0090] Specifically, the first service 201 and the second service 202 can be business systems, applications, or device nodes that implement business systems and applications under a traditional service architecture or microservice architecture.

[0091] Each of the aforementioned nodes can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Nodes may include network communication units, processors, and memory, etc. Servers can be connected directly or indirectly via wired or wireless communication, and this application does not impose any restrictions on this.

[0092] The following describes a method for verifying service access permissions provided in this application. Figure 2 This is a flowchart illustrating a service access permission verification method provided in an embodiment of this application. This application provides the operational steps described in the embodiments or flowchart, but based on conventional or non-inventive methods, more or fewer operational steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or server product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Please refer to... Figure 2 The service call permission verification method provided in this application embodiment may include the following steps:

[0093] S210: The first service obtains the verifiable credentials and the verification path of the verifiable credentials in the reference permission structure tree corresponding to the first service from the synchronization node of the blockchain.

[0094] In this embodiment, the verifiable credential indicates that the first service has the authority to call the second service. The reference permission structure tree is a binary tree representation of the first declaration document recorded by the consensus node of the blockchain. The first declaration document corresponds to the decentralized identity identifier of the first service and indicates the calling authority granted to the first service. The verification path is used to verify the existence of the verifiable credential in the reference permission structure tree.

[0095] In the embodiments of this application, the first service and the second service can be business systems or applications under a traditional service architecture or a microservice architecture, or device nodes that implement business systems or applications.

[0096] Before implementing the method provided in this application embodiment, a decentralized identity (DID) can be registered on the blockchain for the first service, and a first declaration document of the first service can be generated based on the consensus nodes of the blockchain. An index relationship can also be established between the decentralized identity of the first service and the first declaration document of the first service. The blockchain synchronization nodes can synchronously obtain information such as the decentralized identity of the first service and the first declaration document of the first service from the blockchain consensus nodes.

[0097] In this embodiment of the application, the decentralized identity identifier of the first service is a string with a preset format, used to represent the digital identity of the first service. For example... Figure 3 As shown, the first part, `did`, is a fixed string indicating that this string is a decentralized identity (DID); the second part, `example`, is called the DID method (DIDMethod), which represents the method used to define and operate this DID. The method can be custom and registered on the W3C (World Wide Web Consortium) website; the third part, `123456789abcdefghijk`, is the unique identifier string under the DID method.

[0098] In this embodiment, the first declaration document (DID Document) of the first service may include public information and verifiable information. Public information is information stored in plaintext within the first declaration document, which can be read arbitrarily by external parties. It mainly consists of basic information that the first service entity can publicly disclose, including but not limited to the public key, the DID protocol used, the service request address, the service type, and the business direction and scope. Verifiable information is information stored in encrypted form within the first declaration document, i.e., plaintext without any information. It may be a hash representation of the information, referred to in this embodiment as a credential (or token) or commitment value. The original text of the credential or commitment value cannot be obtained externally. The credential in the verifiable information may include identity credentials and authorization credentials. The authorization credential can indicate the calling permissions granted to the first service; that is, the first declaration document can indicate the calling permissions granted to the first service. The aforementioned verifiable credential is the credential in the verifiable information of the first declaration document that indicates the first service has the right to call the second service. The original plaintext corresponding to the verifiable credential can indicate some or all of the information such as the service subject (caller and callee), the calling permission level, the data usage type, and the data usage scope.

[0099] In this embodiment, the reference permission structure tree is a binary tree representation of the first declaration documents recorded by the consensus nodes of the blockchain. The reference permission structure tree can be a Merkle tree. Specifically, each node at the bottom of the reference permission structure tree corresponds to a credential of the first declaration document, which is the node verification data of the bottom-level node in this embodiment. Adjacent nodes at the bottom are paired, and the hash value of the sum of their node verification data is calculated to obtain the node at the next higher level (i.e., the parent node of the adjacent nodes) and the node verification data of the node at the next higher level. This process of pairing nodes and calculating node verification data is iterated until the root node and its node verification data are obtained. The root node's node verification data is the reference verification data in this embodiment. In one embodiment, the bottom-level node can also be called a leaf node, the top-level node a root node, and the nodes between the bottom and top levels can be called non-leaf nodes or internal nodes.

[0100] In this embodiment of the application, the verifiable credential corresponds to a node at the bottom of the reference permission structure tree and its node verification data. The verification path of the verifiable credential in the reference permission structure tree refers to the hash path from the node corresponding to the verifiable credential to the root node of the reference permission structure tree, which can also be called the Merkle path. The verification path can be represented by the nodes it passes through and their node verification data. Merkle proof processing can be performed based on the verification path. Figure 4 This diagram illustrates a reference permission structure tree built upon verifiable information from a first declaration document. At the bottom four leaf nodes, H(auth1) represents the identity credential indicating the legal entity information of the first service, H(auth2) represents the identity credential indicating the capital information of the first service, H(auth3) represents the permission credential indicating that the first service can invoke the second service, and H(auth4) represents the permission credential indicating that the first service can invoke the third service. In the middle nodes, H1 is the parent node of H(auth1) and H(auth2), and H2 is the parent node of H(auth3) and H(auth4). The root node ROOT is the parent node of H1 and H2. For credential H(auth3), the corresponding verification path is: {H(auth4), H1}.

[0101] In this embodiment, by using a first declaration document corresponding to the decentralized identity of the first service, the calling permissions granted to the first service are recorded on the consensus node of the blockchain and synchronized to the synchronization node of the blockchain. The first declaration document is encrypted in the form of a reference permission structure tree, realizing the distributed recording and encrypted storage of the calling permissions granted to the first service on the blockchain. When the first service needs to call the second service, the first service can obtain the verifiable credentials and the verification path of the verifiable credentials in the reference permission structure tree in a decentralized manner from the synchronization node of the blockchain, without relying on a centralized node that manages permission data, thus avoiding the risk of centralization.

[0102] S220: The first service obtains its first service identity certificate from a trusted certificate authority. The extended fields of the first service identity certificate contain reference verification data from the reference permission structure tree.

[0103] In this embodiment, the trusted certificate authority can be a Certificate Authority (CA) within a PKI (Public Key Infrastructure) system, responsible for issuing service identity certificates for services. In this embodiment, the first service identity certificate can be a public key certificate, which may include public key information, owner identity information (service subject), and a digital signature from the certificate authority to ensure the overall correctness of the document.

[0104] In this embodiment, the extended field of the first service identity certificate includes reference verification data of the reference permission structure tree. Specifically, before issuing a certificate to the first service, the certificate authority verifies the source address of the first service, obtains the identity credential from the first claim document corresponding to the first service on the blockchain, and verifies the identity of the first service. After the identity verification of the first service is successful, it confirms that the first service applying for the certificate is authentic and trustworthy, and can issue a public key certificate to the first service. The reference verification data of the reference permission structure tree corresponding to the first claim document obtained from the blockchain (i.e., the node verification data of the root node of the tree) is written into the extended field of the public key certificate to obtain the first service identity certificate of the first service, and is returned to the first service.

[0105] In the embodiments of this application, steps S210 and S220 can be performed in any order.

[0106] S230: The first service sends its identity certificate to the second service.

[0107] In one embodiment of this application, the first service may first initiate a communication connection request to the second service based on protocols such as SSL (Secure Sockets Layer) or TSL (Transport Layer Security). During the communication establishment process between the first service and the second service, the first service sends its identity certificate to the second service.

[0108] S240: The second service receives the first service identity certificate sent by the first service, and performs identity verification on the first service based on the first service identity certificate.

[0109] In one embodiment of this application, the second service uses the public key of the certificate authority to verify the authenticity of the first service's identity certificate. Specifically, the first service's identity certificate issued by the certificate authority includes the public key corresponding to the first service, the subject information of the first service, the organization information of the certificate authority, the validity period of the certificate, the certificate serial number, and a digital signature. The digital signature is ciphertext obtained by encrypting a message digest composed of the subject information of the first service, the organization information of the certificate authority, and the validity period using the private key of the certificate authority. Therefore, the second service can use the public key of the certificate authority to decrypt the digital signature in the first service's identity certificate to obtain the message digest, thereby verifying the authenticity and integrity of the subject information, organization information, and validity period.

[0110] In one embodiment of this application, in addition to the second service verifying the identity of the first service, the above method may further include:

[0111] S410: The second service obtains its second service identity certificate from a trusted certificate authority.

[0112] S420: The second service sends its identity certificate to the first service.

[0113] S430: The first service receives the identity certificate of the second service sent by the second service.

[0114] S440: The first service authenticates the second service based on the second service's identity certificate.

[0115] The authentication process of the first service for the second service can be referred to the aforementioned embodiments, and will not be repeated here.

[0116] In one specific embodiment, the first service and the second service engage in a handshake interaction based on the TSL protocol, exchanging service identity certificates and performing authentication during multiple handshake phases. Furthermore, encryption algorithms or session keys can be exchanged or generated during the handshake interaction.

[0117] In the above embodiments, the first service and the second service can perform two-way authentication based on the communication protocol to establish a secure and reliable communication connection.

[0118] S250: The second service determines the reference verification data in the extended field of the first service's identity certificate, which corresponds to the reference permission structure tree of the first service.

[0119] S260: After the second service successfully authenticates the first service, the first service sends the verifiable credentials and authentication path to the second service.

[0120] In one embodiment of this application, after the two-way authentication between the first service and the second service is successful, the first service sends the verifiable credentials and authentication path to the second service so that the second service can verify the service call permission of the first service.

[0121] S270: The second service receives the verifiable credentials and the verification path of the verifiable credentials in the reference permission structure tree sent by the first service.

[0122] In one embodiment of this application, the first service corresponds to an asymmetric key pair. The private key in the asymmetric key pair is private to the first service, and the public key in the asymmetric key pair can be recorded in the public information of the first declaration document. Steps S260 and S270 in the above method can be implemented as follows:

[0123] S310: The first service determines the private key in the asymmetric key pair corresponding to the first service.

[0124] S320: The first service encrypts the verifiable credential based on the private key to obtain the encrypted credential.

[0125] S330: After the second service successfully authenticates the first service, the first service sends the encrypted credentials and verification path to the second service.

[0126] S340: The second service receives the encrypted credentials and verification path sent by the first service.

[0127] S350: The second service obtains the public key from the asymmetric key corresponding to the first service in the identity book of the first service.

[0128] S360: The second service uses a public key to decrypt encrypted credentials and obtain verifiable credentials.

[0129] In another embodiment of this application, the first service may also use the private key in the asymmetric key pair to encrypt the verifiable credential and the verification path to obtain the encrypted credential and the encrypted path, and the second service may use the public key in the ID card of the first service to decrypt the encrypted credential and the encrypted path to obtain the verifiable credential and the verification path.

[0130] In another embodiment of this application, the session key agreed upon during the handshake interaction phase based on the TSL protocol can also be used to encrypt and decrypt verifiable credentials and verification paths for transmission and acquisition.

[0131] In the above embodiments, the security of information transmission can be improved by using the asymmetric key corresponding to the first service to encrypt and decrypt verifiable credentials or verification paths.

[0132] S280: The second service calculates the target verification data based on the verifiable credentials and verification path.

[0133] In this embodiment, the target verification data is the node verification data corresponding to the root node of the target permission structure tree calculated based on the verifiable credential and the verification path. The target permission structure tree is the permission structure tree corresponding to the first service inferred from the second service. Combining the structural characteristics of a Merkle tree (a change in the node verification data of any leaf node will cause a change in the node verification data of the root node), the node verification data corresponding to the root node of the target permission structure tree can be compared with the reference verification data corresponding to the root node of the reference permission structure tree recorded and synchronized on the chain. This allows verification of whether the verifiable credential exists in the reference permission structure tree, or, in other words, verification of whether the verifiable credential is a fabricated credential.

[0134] In this embodiment of the application, the verification path includes node verification data corresponding to each node in at least one node. The node verification data corresponding to each node is arranged from low to high according to the hierarchy of the corresponding node, such as... Figure 5 As shown, step S280 can be implemented as follows:

[0135] S281: Traverse the node verification data corresponding to each node in the verification path.

[0136] S282: When traversing to the node verification data corresponding to each node, merge the node verification data corresponding to the currently traversed node with the current first verification data to obtain the current merged data.

[0137] Specifically, when the current traversed node is the first node in the verification path, the current first verification data is the verifiable credential; when the current traversed node is not the first node in the verification path, the current first verification data is the current second verification data corresponding to the previous node of the current traversed node.

[0138] Feasibly, the hash values ​​of the node verification data corresponding to the current traversed node and the current first verification data are added together to obtain the current merged data.

[0139] S283: Based on the preset hash function, perform hash calculation on the current merged data to obtain the current second verification data corresponding to the current traversed node.

[0140] It is feasible. The preset hash function used by the second service can be obtained from the blockchain's synchronization node or from the first service's identity document. This preset hash function is the same as the function used by the blockchain's consensus node or synchronization node to generate the reference permission structure tree corresponding to the first declaration document.

[0141] S284: At the end of the traversal, the current second verification data corresponding to the last node in the verification path is taken as the target verification data.

[0142] That is, when traversing to the last node in the verification path, the node verification data corresponding to the last node is merged with the current first verification data and the current merged data is hashed. The resulting current second verification data corresponding to the last node is the node verification data of the root node of the target permission structure tree, which is the target verification data mentioned above.

[0143] by Figure 4 Taking the credential H(auth3) and the corresponding verification path {H(auth4), H1} as an example, the node verification data CommitmentX4 corresponding to the first node H(auth4) is added to the current first verification data H(auth3) and hashed to obtain node H2 and its node verification data H(H(auth3)+H(auth4)). The node verification data of node H2 is used as the current second verification data corresponding to the first node H(auth4). The node verification data corresponding to the second node H1 is added to the node verification data of node H2 and hashed to obtain the current second verification data H(H1+H2) corresponding to the second node H1. The second node H1 is also the last node of the verification path, so H(H1+H2) is also the node verification data of the root node ROOT of the target permission structure tree, which is the target verification data mentioned above.

[0144] In the above embodiments, by traversing the nodes of the verification path and iteratively processing the traversed nodes and verifiable credentials, the target verification data of the root node of the target permission structure tree of the second service can be inferred. As the data to be compared with the reference verification data, it can be verified whether the verifiable credentials have been tampered with or whether they exist in the reference permission structure tree.

[0145] S290: The second service determines the call permission verification result based on the target verification data and the reference verification data. The call permission verification result indicates whether the first service has the right to call the second service.

[0146] In this embodiment, the target verification data is the node verification data corresponding to the root node of the target permission structure tree inferred from the verifiable credentials and verification path. It can be compared with the reference verification data corresponding to the root node of the reference permission structure tree to verify whether the verifiable credentials have been tampered with or exist in the reference permission structure tree.

[0147] In one embodiment of this application, step S290 can be implemented as follows:

[0148] S291: Compare the target verification data and the reference verification data to obtain the comparison results.

[0149] It is feasible to compare the target verification data and reference verification data of hash value type bit by bit. If the values ​​at the same position are different, the comparison result indicates that the target verification data and reference verification data are different.

[0150] S292: If the comparison result indicates that the target verification data and the reference verification data are the same, a call permission verification result indicating that the first service has the right to call the second service is obtained.

[0151] S293: If the comparison result indicates that the target verification data and the reference verification data are different, a call permission verification result indicating that the first service does not have the right to call the second service is obtained.

[0152] In the above embodiments, if the comparison result indicates that the target verification data and the reference verification data are different, it can be determined that the verifiable credentials for the calculated target verification data have been tampered with or that the verification path corresponding to the verifiable credentials does not exist in the reference permission structure tree. The verifiable credentials are untrustworthy. For the security of service calls, it can be determined that the first service does not have the permission to call the second service.

[0153] In one embodiment of this application, the above method may further include:

[0154] S510: If the call permission verification result indicates that the first service has the right to call the second service, the second service generates verifiable declaration information; the verifiable declaration information includes declaration attribute information, declaration content information, and the digital signature of the second service.

[0155] Specifically, such as Figure 8 As shown, the verifiable declaration information is a descriptive declaration issued by the second service to endorse the first service's service invocation authority over the second service. The declaration attribute information, also known as metadata, mainly includes information such as the issuer (second service), issuance date, and declaration type, as well as the declaration content information (i.e.,...). Figure 8The verifiable declaration is a detailed description of the service invocation permissions that the first service possesses over the second service. It may include information such as the priority of the service invocation permissions of the first service, the time and space scope of the service invocation, and the scope of data usage. The verifiable declaration also includes the digital signature of the second service (i.e.,...). Figure 8 The verifiable statement (evidence) ensures that the verifiable statement information can be verified and prevents the content of the verifiable statement information from being tampered with.

[0156] S520: Based on the smart contract of the blockchain, the second service writes verifiable declaration information into the first declaration document.

[0157] In one embodiment of this application, after the verifiable declaration information is written into the first declaration document, the blockchain's synchronization node updates the first declaration document synchronously.

[0158] In the above embodiments, the second service generates a verifiable declaration for the first service, which can provide a quick basis for permission verification for subsequent calls by the first service to the second service.

[0159] This application also provides a decentralized authentication architecture, such as... Figure 6 As shown, the decentralized authentication architecture includes a first service, a second service, a certificate authority, consensus nodes of the blockchain, and synchronization nodes 1 and 2 of the blockchain, wherein:

[0160] (1) Figure 7 This is a schematic diagram of the functional modules of a consensus node on a blockchain provided in an embodiment of this application, such as... Figure 7As shown, the consensus nodes of the blockchain are used to register decentralized identity identifiers (DIDs) for various services and can generate related declaration documents according to smart contracts. The smart contracts are responsible for reading and updating the decentralized identity identifiers and declaration documents on the blockchain. The smart contracts on the consensus nodes of the blockchain are mainly responsible for binding the actual entity identity of the service with the DID on the blockchain and managing the service's declaration documents. The declaration documents are divided into two parts: public information and verifiable information. Public information is information stored in plaintext in the declaration documents, which can be read arbitrarily by external parties. It mainly consists of basic information that the service entity can disclose, including but not limited to public keys, the DID protocol used, service request addresses, service types, business directions and scopes, etc. Verifiable information is information stored in encrypted form in the declaration documents, that is, plaintext without information. It can be the hash representation of information (such as some or all of the information of the service entity (caller and callee), calling permission level, data usage type, data usage scope, etc.). In this application implementation, it is referred to as the credential (or token) or commitment value corresponding to the information. The original text of the credential or commitment value cannot be obtained externally. The credentials in the verifiable information can include identity credentials and permission credentials. Permission credentials can indicate the access permissions granted to a service; that is, the declaration document can indicate the access permissions granted to the corresponding service. In this embodiment, the verifiable credentials indicating that the first service has access permissions to the second service can be written by the second service or an authorized administrator into the first declaration document corresponding to the first service. The consensus nodes of the blockchain can also generate a reference permission structure tree for each service based on the declaration documents corresponding to each service. Figure 8 A schematic diagram of a data structure is shown, in which the metadata in the first declaration document includes public information and verifiable information. The verifiable information may include verifiable statements and verifiable expressions. Verifiable statements may be constructed based on credentials, and verifiable expressions may be selective disclosures of verifiable statements.

[0161] (2) The Certificate Authority is mainly responsible for issuing service identity certificates for each service. When issuing a service identity certificate, the Certificate Authority mainly performs the following processes: verifying the source of the service applying for the certificate and verifying whether the IP address that can indicate the source is authorized; after the source is verified, obtaining the service's declaration document from the consensus node of the blockchain to obtain the service's trusted identity declaration; verifying whether the trusted identity declaration matches the verifiable identity commitment provided by the service; after confirming that the visitor is a real service, issuing a service identity certificate for the service, and writing the node reference verification data of the root node of the reference permission structure tree of the service corresponding declaration document obtained from the consensus node of the blockchain into the extended field of the service's service identity certificate to ensure the consistency between the public key certificate identity and the on-chain DID identity.

[0162] (3) There can be multiple synchronization nodes in a blockchain, each capable of independently providing information access services for different services. In response to a service's information retrieval request, a synchronization node can obtain the service's decentralized identity identifier and corresponding claim document from the consensus node, or the synchronization node can periodically synchronize the decentralized identity identifiers and corresponding claim documents of all services from the consensus node. In this embodiment, synchronization node 1 helps the first service obtain the aforementioned verifiable credentials and the verification path of the aforementioned verifiable credentials in the reference permission structure tree corresponding to the first service. Furthermore, the synchronization node can generate a reference permission structure tree corresponding to the service based on the synchronized claim document, and generate a corresponding verification path for each credential in the claim document.

[0163] (4) First service and second service, wherein both the first service and the second service can be integrated into a verifiable computing module in the form of an SDK (Software Development Kit). The verifiable computing module of the first service and the verifiable computing module of the second service can execute the service call permission verification method provided in the embodiments of this application, which will not be elaborated here.

[0164] As can be seen from the above embodiments, in the service call permission verification method provided in this application, the first service obtains a verifiable credential and the verification path of the verifiable credential in the reference permission structure tree corresponding to the first service from the synchronization node of the blockchain. The verifiable credential indicates that the first service has the right to call the second service. The reference permission structure tree is a binary tree representation of the first declaration document recorded by the consensus node of the blockchain. The first declaration document corresponds to the decentralized identity identifier of the first service and indicates the call permission granted to the first service. The first service also obtains its first service identity certificate from a trusted certificate authority. The extended field contains reference verification data of the aforementioned reference permission structure tree; the first service sends its identity certificate to the second service, the second service authenticates the first service based on the first service's identity certificate, and determines the reference verification data of the reference permission structure tree corresponding to the first service in the extended field of the first service's identity certificate; after the second service successfully authenticates the first service, the first service sends the verifiable credentials and verification path to the second service, the second service calculates the target verification data based on the verifiable credentials and verification path; based on the target verification data and the reference verification data, the second service determines the call permission verification result indicating whether the first service has the right to call the second service.

[0165] That is, by using the first declaration document corresponding to the decentralized identity of the first service, the calling permissions granted to the first service are recorded on the consensus node of the blockchain and synchronized to the synchronization node of the blockchain. The first declaration document is encrypted in the form of a reference permission structure tree, thereby realizing the distributed recording and encrypted storage of the calling permissions granted to the first service on the blockchain. When the first service needs to call the second service, it can obtain the verifiable credentials and their verification paths from the reference permission structure tree in a decentralized manner from the blockchain's synchronization nodes, without relying on a centralized node managing permission data, thus avoiding centralization risks. When the first service needs to call the second service, the second service uses a first identity certificate issued by a trusted certificate authority to authenticate the first service and determines the reference verification data in the extended fields of the first identity certificate corresponding to the first service within the reference permission structure tree. This means that the first identity certificate can be used to accurately verify identity and ensure the reliable transmission of reference verification data, guaranteeing the accuracy of subsequent verifications. After the second service successfully authenticates the first service, it calculates the target verification data based on the verifiable credentials and verification paths sent by the first service. Based on the target verification data and the reference verification data, it determines the call permission verification result. This means that reliable verification of call permissions is performed between services without relying on a centralized node verifying permission data, avoiding centralization risks and allowing the verification relationships and data to remain confidential.

[0166] This application embodiment also provides a service call permission verification device 900, applied to a second service, such as... Figure 9 As shown, the device 900 may include:

[0167] The first identity certificate receiving and verification module 910 is used to receive the first service identity certificate sent by the first service, and to verify the identity of the first service based on the first service identity certificate;

[0168] The reference verification data determination module 920 is used to determine the reference verification data of the reference permission structure tree corresponding to the first service in the extended field of the first service identity certificate; the reference permission structure tree is a binary tree representation of the first declaration document recorded by the consensus node of the blockchain, the first declaration document corresponds to the decentralized identity identifier of the first service, and the first declaration document indicates the calling permission granted to the first service.

[0169] The verifiable credential and verification path receiving module 930 is used to receive a verifiable credential sent by the first service and a verification path of the verifiable credential in the reference permission structure tree after the authentication of the first service is successful; the verifiable credential indicates that the first service has the right to call the second service, and the verification path is used to verify the existence of the verifiable credential in the reference permission structure tree.

[0170] The target verification data calculation module 940 is used to calculate the target verification data based on the verifiable credential and the verification path.

[0171] The access control module 950 is invoked to determine the access control verification result based on the target verification data and the reference verification data. The access control verification result indicates whether the first service has access control to the second service.

[0172] In one embodiment of this application, the verification path includes node verification data corresponding to each node in at least one node, and the node verification data corresponding to each node is arranged from low to high according to the hierarchy of the corresponding node. The target verification data calculation module 940 may include:

[0173] The traversal unit is used to traverse the node verification data corresponding to each node in the verification path. When traversing to the node verification data corresponding to each node, the following steps are performed:

[0174] The merging unit is used to merge the node verification data corresponding to the current traversed node with the current first verification data to obtain the current merged data; when the current traversed node is the first node in the verification path, the current first verification data is the verifiable credential; when the current traversed node is not the first node in the verification path, the current first verification data is the current second verification data corresponding to the previous node of the current traversed node.

[0175] The calculation unit is used to perform hash calculation on the current merged data based on a preset hash function to obtain the current second verification data corresponding to the current traversed node;

[0176] The target verification data determination unit is used to take the current second verification data corresponding to the last node in the verification path as the target verification data when the traversal ends.

[0177] In one embodiment of this application, the call permission verification module 950 may include:

[0178] The comparison unit is used to compare the target verification data and the reference verification data to obtain the comparison result;

[0179] The first indication unit is configured to obtain the call permission verification result indicating that the first service has the right to call the second service when the comparison result indicates that the target verification data and the reference verification data are the same;

[0180] The second indication unit is used to obtain the call permission verification result indicating that the first service does not have the right to call the second service when the comparison result indicates that the target verification data and the reference verification data are different.

[0181] In one embodiment of this application, the verifiable credential and verification path receiving module 930 may include:

[0182] An encrypted credential and verification path receiving unit is configured to receive the encrypted credential and verification path sent by the first service after the authentication of the first service is successful.

[0183] The public key acquisition unit is used to obtain the public key from the asymmetric key corresponding to the first service from the first service ID book;

[0184] The decryption unit is used to decrypt the encrypted credential based on the public key to obtain the verifiable credential.

[0185] In one embodiment of this application, the device 900 further includes:

[0186] The second service identity certificate acquisition unit is used to obtain the second service identity certificate of the second service from a trusted certificate authority.

[0187] The second service identity certificate sending unit is used to send the second service identity certificate to the first service so that the first service can authenticate the second service.

[0188] In one embodiment of this application, the device 900 further includes:

[0189] A verifiable declaration information generation unit is used to generate verifiable declaration information when the call permission verification result indicates that the first service has the right to call the second service; the verifiable declaration information includes declaration attribute information, declaration content information, and the digital signature of the second service;

[0190] The declaration writing unit is used to write the verifiable declaration information into the first declaration document based on the smart contract of the blockchain.

[0191] This application embodiment also provides a service call permission verification device 1000, applied to a first service, such as... Figure 10 As shown, the device 1000 may include:

[0192] The verifiable credential and verification path acquisition module 1010 is used to acquire a verifiable credential and its verification path in a reference permission structure tree corresponding to the first service from the synchronization nodes of the blockchain. The verifiable credential indicates that the first service has the right to call the second service. The reference permission structure tree is a binary tree representation of the first declaration document recorded by the consensus nodes of the blockchain. The first declaration document corresponds to the decentralized identity identifier of the first service and indicates the calling permission granted to the first service. The verification path is used to verify the existence of the verifiable credential in the reference permission structure tree.

[0193] The first identity certificate acquisition module 1020 is used to obtain the first service identity certificate of the first service from a trusted certificate authority, wherein the extended field of the first service identity certificate contains reference verification data of the reference permission structure tree.

[0194] The first identity certificate sending module 1030 is used to send the first service identity certificate to the second service, so that the second service can authenticate the first service and obtain the reference verification data;

[0195] The verifiable credential and verification path sending module 1040 is used to send the verifiable credential and the verification path to the second service after the second service has successfully authenticated the first service, so that the second service can calculate the target verification data based on the verifiable credential and the verification path and determine the call permission verification result based on the target verification data and the reference verification data. The call permission verification result indicates whether the first service has the right to call the second service.

[0196] In one embodiment of this application, the verifiable credential and verification path sending module 1040 may include:

[0197] A private key determination unit is used to determine the private key in the asymmetric key pair corresponding to the first service;

[0198] Encryption is performed using the private key to encrypt the verifiable credential, resulting in an encrypted credential.

[0199] The first sending unit is configured to send the encryption credential and the verification path to the second service after the second service has successfully authenticated the first service.

[0200] In one embodiment of this application, the verifiable credential and verification path sending module 1040 may include:

[0201] The second service identity certificate receiving unit is used to receive the second service identity certificate sent by the second service.

[0202] The second service authentication unit is used to authenticate the second service based on the second service identity certificate;

[0203] The second sending unit is used to send the verifiable credential and the verification path to the second service after the authentication of the second service is successful.

[0204] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0205] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0206] This application provides a computer device including a processor and a memory. The memory stores at least one instruction or at least one program, which is loaded and executed by the processor to implement the service call permission verification method provided in the above method embodiments.

[0207] Figure 11 A schematic diagram of the hardware structure of a device for implementing a service access permission verification method provided in an embodiment of this application is shown. This device may constitute or include the apparatus or system provided in the embodiment of this application. Figure 11As shown, device 10 may include one or more processors 1002 (shown as 1002a, 1002b, ..., 1002n in the figure) 1002 (processor 1002 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 1004 for storing data, and a transmission device 1006 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 11 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, device 10 may also include a... Figure 11 The more or fewer components shown, or having the same Figure 11 The different configurations shown.

[0208] It should be noted that the aforementioned one or more processors 1002 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be wholly or partially integrated into any other element within device 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0209] The memory 1004 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method described in the embodiments of this application. The processor 1002 executes various functional applications and data processing by running the software programs and modules stored in the memory 1004, thereby implementing the above-mentioned service call permission verification method. The memory 1004 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1004 may further include memory remotely located relative to the processor 1002, and these remote memories can be connected to the device 10 via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0210] The transmission device 1006 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of device 10. In one example, the transmission device 1006 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 1006 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0211] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows a user to interact with the user interface of device 10 (or a mobile device).

[0212] This application embodiment also provides a computer-readable storage medium, which can be disposed in a server to store at least one instruction or at least one program related to implementing a service call permission verification method in the method embodiment. The at least one instruction or the at least one program is loaded and executed by the processor to implement the service call permission verification method provided in the above method embodiment.

[0213] Optionally, in this embodiment, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0214] This invention also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform a service access permission verification method provided in the various optional embodiments described above.

[0215] As can be seen from the embodiments of the service call permission verification method, apparatus, medium, and device provided in this application, the first service obtains a verifiable credential and its verification path in the reference permission structure tree corresponding to the first service from the synchronization node of the blockchain. The verifiable credential indicates that the first service has the right to call the second service. The reference permission structure tree is a binary tree representation of the first declaration document recorded by the consensus node of the blockchain. The first declaration document corresponds to the decentralized identity identifier of the first service and indicates the call permission granted to the first service. The first service also obtains its first service identity certificate from a trusted certificate authority. The extended fields contain reference verification data of the aforementioned reference permission structure tree; the first service sends its identity certificate to the second service, the second service authenticates the first service based on the first service's identity certificate, and determines the reference verification data of the reference permission structure tree corresponding to the first service in the extended fields of the first service's identity certificate; after the second service successfully authenticates the first service, the first service sends the verifiable credentials and verification path to the second service, the second service calculates the target verification data based on the verifiable credentials and verification path; based on the target verification data and the reference verification data, the second service determines the call permission verification result indicating whether the first service has the right to call the second service.

[0216] That is, by using the first declaration document corresponding to the decentralized identity of the first service, the calling permissions granted to the first service are recorded on the consensus node of the blockchain and synchronized to the synchronization node of the blockchain. The first declaration document is encrypted in the form of a reference permission structure tree, thereby realizing the distributed recording and encrypted storage of the calling permissions granted to the first service on the blockchain. When the first service needs to call the second service, it can obtain the verifiable credentials and their verification paths from the reference permission structure tree in a decentralized manner from the blockchain's synchronization nodes, without relying on a centralized node managing permission data, thus avoiding centralization risks. When the first service needs to call the second service, the second service uses a first identity certificate issued by a trusted certificate authority to authenticate the first service and determines the reference verification data in the extended fields of the first identity certificate corresponding to the first service within the reference permission structure tree. This means that the first identity certificate can be used to accurately verify identity and ensure the reliable transmission of reference verification data, guaranteeing the accuracy of subsequent verifications. After the second service successfully authenticates the first service, it calculates the target verification data based on the verifiable credentials and verification paths sent by the first service. Based on the target verification data and the reference verification data, it determines the call permission verification result. This means that reliable verification of call permissions is performed between services without relying on a centralized node verifying permission data, avoiding centralization risks and allowing the verification relationships and data to remain confidential.

[0217] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired results. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0218] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device, equipment, and storage medium embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0219] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0220] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for verifying service call permissions, applied to a second service, characterized in that, The method includes: Receive the first service identity certificate sent by the first service, and verify the identity of the first service based on the first service identity certificate; Determine the reference verification data of the reference permission structure tree corresponding to the first service in the extended fields of the first service identity certificate; the reference permission structure tree is the binary tree representation of the first declaration document recorded by the consensus node of the blockchain, the first declaration document corresponds to the decentralized identity identifier of the first service, and the first declaration document indicates the calling permissions granted to the first service; After successful authentication of the first service, the system receives a verifiable credential sent by the first service and a verification path for the verifiable credential in the reference permission structure tree. The verifiable credential indicates that the first service has the permission to call the second service, and the verification path is used to verify the existence of the verifiable credential in the reference permission structure tree. The target verification data is calculated based on the verifiable credentials and the verification path. Based on the target verification data and the reference verification data, a call permission verification result is determined, and the call permission verification result indicates whether the first service has the right to call the second service.

2. The method according to claim 1, characterized in that, The verification path includes node verification data corresponding to each node in at least one node. The node verification data corresponding to each node is arranged from low to high hierarchy according to the corresponding node. The step of calculating the target verification data based on the verifiable credential and the verification path includes: Traverse the node verification data corresponding to each node in the verification path. When traversing to the node verification data corresponding to each node, perform the following steps: The node verification data corresponding to the currently traversed node is merged with the current first verification data to obtain the current merged data; when the currently traversed node is the first node in the verification path, the current first verification data is the verifiable credential; when the currently traversed node is not the first node in the verification path, the current first verification data is the current second verification data corresponding to the previous node of the currently traversed node. Based on a preset hash function, the current merged data is hashed to obtain the current second verification data corresponding to the current traversed node; At the end of the traversal, the current second verification data corresponding to the last node in the verification path is taken as the target verification data.

3. The method according to claim 1, characterized in that, The step of determining the access permission verification result based on the target verification data and the reference verification data includes: The target verification data and the reference verification data are compared to obtain the comparison result; If the comparison result indicates that the target verification data and the reference verification data are the same, the call permission verification result indicating that the first service has the right to call the second service is obtained; If the comparison result indicates that the target verification data and the reference verification data are different, a call permission verification result indicating that the first service does not have the right to call the second service is obtained.

4. The method according to claim 1, characterized in that, After successful authentication of the first service, receiving the verifiable credentials sent by the first service and the verification path of the verifiable credentials in the reference permission structure tree includes: After successful authentication of the first service, receive the encrypted credentials and the verification path sent by the first service; Obtain the public key from the asymmetric key corresponding to the first service from the first service ID book; Based on the public key, the encrypted credential is decrypted to obtain the verifiable credential.

5. The method according to claim 1, characterized in that, The method further includes: Obtain the second service identity certificate from a trusted certificate authority. The second service identity certificate is sent to the first service so that the first service can authenticate the second service.

6. The method according to claim 1, characterized in that, The method further includes: If the access permission verification result indicates that the first service has access to the second service, verifiable declaration information is generated; the verifiable declaration information includes declaration attribute information, declaration content information, and the digital signature of the second service. Based on the smart contract of the blockchain, the verifiable declaration information is written into the first declaration document.

7. A method for verifying service call permissions, applied to a first service, characterized in that, The method includes: From the synchronization nodes of the blockchain, a verifiable credential and its verification path in the reference permission structure tree corresponding to the first service are obtained. The verifiable credential indicates that the first service has the right to call the second service. The reference permission structure tree is a binary tree representation of the first declaration document recorded by the consensus nodes of the blockchain. The first declaration document corresponds to the decentralized identity identifier of the first service and indicates the calling permission granted to the first service. The verification path is used to verify the existence of the verifiable credential in the reference permission structure tree. Obtain the first service identity certificate of the first service from a trusted certificate authority, wherein the extended field of the first service identity certificate contains reference verification data of the reference permission structure tree; The first service identity certificate is sent to the second service so that the second service can authenticate the first service and obtain the reference verification data. After the second service successfully authenticates the first service, it sends the verifiable credentials and the verification path to the second service, so that the second service can calculate the target verification data based on the verifiable credentials and the verification path, and determine the call permission verification result based on the target verification data and the reference verification data. The call permission verification result indicates whether the first service has the right to call the second service.

8. The method according to claim 7, characterized in that, After the second service successfully authenticates the first service, sending the verifiable credentials and the verification path to the second service includes: Determine the private key in the asymmetric key pair corresponding to the first service; Based on the private key, the verifiable credential is encrypted to obtain an encrypted credential; After the second service successfully authenticates the first service, it sends the encrypted credentials and the verification path to the second service.

9. The method according to claim 7, characterized in that, After the second service successfully authenticates the first service, sending the verifiable credentials and the verification path to the second service includes: Receive the second service identity certificate sent by the second service; The second service is authenticated based on its identity certificate. After successful authentication of the second service, the verifiable credentials and the authentication path are sent to the second service.

10. A service access permission verification device, applied to a second service, characterized in that, The device includes: The first identity certificate receiving and verification module is used to receive the first service identity certificate sent by the first service, and to verify the identity of the first service based on the first service identity certificate; The reference verification data determination module is used to determine the reference verification data of the reference permission structure tree corresponding to the first service in the extended field of the first service identity certificate; the reference permission structure tree is a binary tree representation of the first declaration document recorded by the consensus node of the blockchain, the first declaration document corresponds to the decentralized identity identifier of the first service, and the first declaration document indicates the calling permission granted to the first service. The verifiable credential and verification path receiving module is used to receive, after the authentication of the first service is successful, a verifiable credential sent by the first service and a verification path of the verifiable credential in the reference permission structure tree; the verifiable credential indicates that the first service has the right to call the second service, and the verification path is used to verify the existence of the verifiable credential in the reference permission structure tree. The target verification data calculation module is used to calculate the target verification data based on the verifiable credential and the verification path. The access control module is invoked to determine the access control verification result based on the target verification data and the reference verification data. The access control verification result indicates whether the first service has access control to the second service.

11. A service call permission verification device, applied to a first service, characterized in that, The device includes: The verifiable credential and verification path acquisition module is used to acquire verifiable credentials and the verification path of the verifiable credential in the reference permission structure tree corresponding to the first service from the synchronization nodes of the blockchain; the verifiable credential indicates that the first service has the right to call the second service, the reference permission structure tree is a binary tree representation of the first declaration document recorded by the consensus nodes of the blockchain, the first declaration document corresponds to the decentralized identity identifier of the first service, and the first declaration document indicates the calling permission granted to the first service; the verification path is used to verify the existence of the verifiable credential in the reference permission structure tree. The first identity certificate acquisition module is used to obtain the first service identity certificate of the first service from a trusted certificate authority, wherein the extended fields of the first service identity certificate contain reference verification data of the reference permission structure tree. The first identity certificate sending module is used to send the first service identity certificate to the second service, so that the second service can authenticate the first service and obtain the reference verification data; The verifiable credentials and verification path sending module is used to send the verifiable credentials and the verification path to the second service after the second service has successfully authenticated the first service, so that the second service can calculate the target verification data based on the verifiable credentials and the verification path and determine the call permission verification result based on the target verification data and the reference verification data. The call permission verification result indicates whether the first service has the right to call the second service.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction or at least one program, which is loaded and executed by a processor to implement the service access permission verification method as described in any one of claims 1 to 9.

13. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the service call permission verification method as described in any one of claims 1 to 9.

Images