CN113271211B

CN113271211B - Digital identity verification system, method, electronic device and storage medium

Info

Publication number: CN113271211B
Application number: CN202110542095.XA
Authority: CN
Inventors: 王挺
Original assignee: Netease Hangzhou Network Co Ltd
Current assignee: Netease Hangzhou Network Co Ltd
Priority date: 2021-05-18
Filing date: 2021-05-18
Publication date: 2023-03-24
Anticipated expiration: 2041-05-18
Also published as: CN113271211A

Abstract

The present application relates to the field of block chaining technologies, and in particular, to a digital identity verification system, a digital identity verification method, an electronic device, and a storage medium. The digital identity verification system comprises a block chain network end, a holder end, an issuer end and a verifier end, wherein the block chain network end is provided with a plurality of block chain intelligent contracts used for data storage and authority management, and the holder end, the issuer end and the verifier end interact with different block chain intelligent contracts arranged in the block chain network end respectively, so that the validity of various data storage and the separation of data storage can be effectively guaranteed, the authority of various roles can be verified, and the safety and the trust of the block chain network are further improved.

Description

Digital identity verification system, method, electronic device and storage medium

Technical Field

The present application relates to the field of block chaining technologies, and in particular, to a digital identity verification system, a digital identity verification method, an electronic device, and a storage medium.

Background

Blockchains are a term of art in information technology. In essence, the system is a shared database, and the data or information stored in the shared database has the characteristics of 'unforgeability', 'trace in the whole process', 'traceability', 'public transparency', 'collective maintenance' and the like. Based on the characteristics, the block chain technology lays a solid 'trust' foundation, creates a reliable 'cooperation' mechanism and has wide application prospect.

Since blockchain techniques provide a way to manage the root of trust without a centralized authority, blockchain techniques can be applied in identity management systems and verifiable claims systems. However, the block chain distributed identity architecture is still imperfect, digital identity authentication technologies based on decentralization are in search and start stages, and system definition, on-chain data storage and authority control of various roles are imperfect, so that a complete digital identity authentication system for realizing decentralization does not exist in practice.

Disclosure of Invention

In view of this, embodiments of the present application provide at least a digital identity verification system, a digital identity verification method, an electronic device, and a storage medium, which can not only effectively ensure that various data stores are valid and data stores are separated, but also verify the authority of various roles, thereby improving the security and the trust level of a block chain network.

The application mainly comprises the following aspects:

in a first aspect, an embodiment of the present application provides a digital identity verification system, where the digital identity verification system includes a blockchain network end, a holder end, an issuer end, and a verifier end, where the blockchain network end is deployed with a plurality of blockchain intelligent contracts used for data storage and rights management; wherein:

the holder end is used for registering DID data to the block chain network end to obtain a DID document and sending an obtaining request of a verifiable statement to the issuer end;

the issuer terminal is used for registering DID data to the blockchain network terminal to enable a user of the issuer terminal to become an issuer, and issuing a verifiable statement to the holder terminal after receiving the acquisition request sent by the holder terminal;

and the verifier end is used for verifying the user identity of the holder end, the user identity of the issuer end and the user signature of the issuer end by calling a block chain intelligent contract of the block chain network end after receiving the service request sent by the holder end, and providing target service matched with the service request for the user of the holder end after the verification is passed.

In one possible implementation, the block chain network end comprises a data contract module, a permission contract module, a role contract module and a control contract module; wherein,

the data contract module is used for storing and managing DID data, DID documents, issuer data and certificate subject data;

the authority contract module is used for managing the calling authority of various target roles, and the target roles comprise issuers and contract managers;

the role contract module is used for managing role data of various target roles;

and the control contract module is used for calling the data contract module to provide corresponding proxy service.

In one possible implementation, the blockchain network side is configured to deploy each blockchain intelligent contract according to the following steps:

deploying the role contract in the role contract module on a target block chain network, and setting an initialized target role to obtain a contract address of the role contract;

deploying the authority control contract and the calling control contract in the authority contract module on the target blockchain network, and setting the target role in the authority control contract and the calling control contract;

deploying DID data contracts, issuer contracts and credential topic contracts in the data contract module on the target blockchain network to obtain contract addresses of the DID data contracts, the issuer contracts and the credential topic contracts;

deploying DID proxy contracts, issuer proxy contracts, credential topic proxy contracts, and signature proxy contracts in the control contract module on the target blockchain network, resulting in contract addresses for the DID proxy contracts, the issuer proxy contracts, the credential topic proxy contracts, and the signature proxy contracts.

In a possible implementation manner, the blockchain network side is further configured to upgrade a blockchain intelligent contract in the control contract module according to the following steps:

when the target service is detected to be changed, deploying the intelligent block chain contract in the control contract module on the target block chain network again to obtain a contract address of the intelligent block chain contract in the control contract module;

and writing the updated contract address of the block chain intelligent contract in the control contract module into the calling control contract in the authority contract module.

In one possible implementation, the holder side is configured to store DID data according to the following steps:

calling a DID proxy contract in the control contract module to judge whether the user of the holder terminal is repeatedly registered or not through the DID proxy contract;

if not, calling a DID data contract in the data contract module, and judging whether a contract address of the DID proxy contract is consistent with a contract address of a first appointed calling contract or not through a calling control contract in the authority contract module;

and if so, obtaining and storing DID data of the user at the holder end from the DID data contract in the data contract module.

In one possible embodiment, the issuer side is configured to add new credential topic data according to the following steps:

calling a credential theme proxy contract in the control contract module to judge whether the credential theme of the user of the issuer side is repeatedly registered or not through the credential theme proxy contract;

if not, a certificate subject contract in the data contract module is called, whether the certificate subject contract is consistent with a second specified calling contract or not is judged through a calling control contract in the authority contract module, and whether the user of the issuer has the authority to add the certificate subject data or not is judged through an authority control contract in the authority contract module;

and if the verification is passed, newly adding and saving the credential theme data of the user at the issuer end.

In one possible embodiment, the issuer terminal is configured to register an identity according to the following steps:

invoking an issuer proxy contract in the control contract module to determine whether the identity of the user at the issuer side is checked repeatedly through the issuer proxy contract;

if not, verifying the signature data of the user at the issuer end;

if the verification is passed, invoking an issuer contract in the data contract module, judging whether the issuer contract is consistent with a third specified invoking contract through an invoking control contract in the authority contract module, and judging whether a user at the issuer end has authority to add issuer data through an authority control contract in the authority contract module;

if the verification is passed, the issuer data is registered and saved.

In one possible embodiment, the issuer terminal is configured to issue the verifiable claims according to the following steps:

calling a DID proxy contract in the control contract module to forward the acquisition request to a DID data contract in the data contract module through the DID proxy contract so that the DID data contract can judge whether DID data of a user sending the acquisition request exists or not;

and if so, issuing a verifiable statement to the holder side sending the acquisition request.

In one possible implementation, the verifier end is configured to verify the verifiable statement according to the following steps:

calling a DID proxy contract in the control contract module, forwarding the service request to a DID data contract in the data contract module through the DID proxy contract, and judging whether DID data of a user sending the service request exists through the DID data contract;

if yes, invoking an issuer proxy contract in the control contract module, forwarding the service request to an issuer contract in the data contract module through the issuer proxy contract, and judging whether an issuer of a verifiable statement provided for a user sending the service request is registered or not and whether the issuer has authority to issue the verifiable statement or not through the issuer contract;

if the issuer of the verifiable claim is registered and authorized to issue the verifiable claim, then it is determined that the verifiable claim of the user who sent the service request passed the audit.

In a second aspect, an embodiment of the present application further provides a digital identity authentication method, which is applied to a block chain network end in a digital identity authentication system, where the digital identity authentication method includes:

after receiving a registration request of a holder end for DID data, distributing the DID data and DID documents for a user of the holder end;

after receiving a registration request of a publisher end for DID data, enabling a user of the publisher end to become a publisher, so that the publisher end provides a verifiable statement for the holder end after receiving a verifiable statement acquisition request sent by the holder end;

after receiving a verification request aiming at the identity of the holder end and sent by a verifier end, calling a block chain intelligent contract to verify the user identity of the holder end, the user identity of the distributor end and the user signature of the distributor end, so that the verifier end provides target service matched with the service request for the user of the holder end after verification is passed.

In a third aspect, an embodiment of the present application further provides an electronic device, including: a processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device runs, the processor and the memory communicate with each other through the bus, and when the processor runs, the machine-readable instructions perform the steps of the digital identity authentication method according to the first aspect or any one of the possible implementation manners of the first aspect.

In a fourth aspect, this embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and the computer program is executed by a processor to perform the steps of the digital identity authentication method described in the first aspect or any one of the possible implementation manners of the first aspect.

The digital identity verification system, the digital identity verification method, the electronic device and the storage medium provided by the embodiment of the application have the advantages that through interaction of the holder end, the issuer end and the verifier end with different intelligent block chain contracts deployed in the block chain network end, compared with the prior art that the stored contracts are not clearly defined and the contract architecture is not universal and unified, the digital identity verification system, the digital identity verification method, the electronic device and the storage medium not only can effectively guarantee validity and separation of data storage, but also can verify the authority of various roles, and further improve the safety and the trust degree of the block chain network.

Further, the block chain network end in the digital identity verification system provided by the embodiment of the present application includes a data contract module, an authority contract module, a role contract module and a control contract module; the data contract module is used for storing and managing DID data, DID documents, issuer data and certificate subject data; the authority contract module is used for managing the calling authority of various target roles, and the target roles comprise issuers and contract managers; the role contract module is used for managing role data of various target roles; the control contract module is used for calling the data contract module to provide corresponding proxy service. Therefore, storage of DID data, issuer data and certificate subject data can be effectively guaranteed to be effective, data storage is separated, authority of various roles can be verified, and safety of block chain service is improved.

In order to make the aforementioned objects, features and advantages of the present application more comprehensible, preferred embodiments accompanied with figures are described in detail below.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained from the drawings without inventive effort.

Fig. 1 is a schematic structural diagram illustrating a digital identity verification system provided in an embodiment of the present application;

fig. 2 is a schematic diagram illustrating a block chain network end according to an embodiment of the present application;

fig. 3 is a flowchart illustrating a digital identity verification method provided in an embodiment of the present application;

fig. 4 shows a schematic structural diagram of an electronic device provided in an embodiment of the present application.

Description of the main element symbols:

in the figure: 100-digital identity verification system; 110-blockchain network end; 111-a data contract module; 112-rights contract module; 113-a role contract module; 114-a control contract module; 120-holder end; 130-issuer side; 140-verifier end; 400-an electronic device; 410-a processor; 420-a memory; 430-bus.

Detailed Description

To make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it should be understood that the drawings in the present application are for illustrative and descriptive purposes only and are not used to limit the scope of protection of the present application. Further, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of the present application. It should be understood that the operations of the flow diagrams may be performed out of order, and that steps without logical context may be performed in reverse order or concurrently. One skilled in the art, under the guidance of this application, may add one or more other operations to, or remove one or more operations from, the flowchart.

In addition, the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. The components of the embodiments of the present application, generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present application, presented in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present application without making any creative effort, shall fall within the protection scope of the present application.

To enable those skilled in the art to utilize the present disclosure, the following embodiments are presented in conjunction with a specific application scenario "application of blockchain network," and it will be apparent to those skilled in the art that the general principles defined herein may be applied to other embodiments and application scenarios without departing from the spirit and scope of the present disclosure.

The following method, system, electronic device, or computer-readable storage medium in the embodiments of the present application may be applied to any scenario that requires DID data storage and rights management, and the embodiments of the present application do not limit specific application scenarios, and any scheme that uses the digital identity authentication method and system provided in the embodiments of the present application is within the scope of protection of the present application.

It is worth noting that before the present application is proposed, a block chain distributed identity architecture in the existing scheme is still imperfect, digital identity authentication technologies based on decentralization are all in exploration and starting stages, system definition, on-chain data storage and authority control of various roles are imperfect, and therefore, a set of complete digital identity authentication system for realizing decentralization does not exist in practice.

In view of the above problems, the digital identity verification system in the embodiment of the present application includes a block chain network end, a holder end, a distributor end, and a verifier end, where the block chain network end is deployed with a plurality of block chain intelligent contracts for data storage and authority management, and through interaction between the holder end, the distributor end, and the verifier end and different block chain intelligent contracts deployed in the block chain network end, it is not only possible to effectively ensure validity of various data storage and separation of data storage, but also to implement verification of authority of various roles, and further improve security and trust of the block chain network.

It should be noted that distributed digital identities are not just people, including organizations, but even items in the future. These people, organizations, and items simply do not rely on an original centralized authority, cannot be removed or deleted, and are life-long identities.

Distributed identity Identifiers (DID) are Identifiers composed of character strings, are used for representing a digital identity, are Decentralized verifiable digital Identifiers, can realize global uniqueness without a central registration authority, and have the characteristics of distribution, autonomous controllability, cross-link multiplexing and the like. Typically, an entity may possess multiple identities, each assigned a unique DID value, and an asymmetric key associated therewith. The DID is specifically parsed into a DID Document (DID Document) including a unique identification code of the DID, a list of public keys and detailed information of the public keys (holder, encryption algorithm, key status, etc.), and other attribute descriptions of the DID holder.

Verifiable Statements (VCs) provide a specification to describe certain attributes that an entity has, enabling evidence-based trust. The DID holder, through a verifiable claim, can prove to other entities (individuals, organizations, things, etc.) that certain attributes of himself are trustworthy. Meanwhile, by combining the cryptographic technologies such as digital signature and zero knowledge proof, the statement can be safer and more credible, and the privacy of the user can be further guaranteed against being invaded.

For the convenience of understanding of the present application, the technical solutions provided in the present application will be described in detail below with reference to specific embodiments.

Fig. 1 is a schematic structural diagram of a digital identity verification system 100 according to an embodiment of the present disclosure. As shown in fig. 1, a digital identity verification system 100 provided by the embodiment of the present application includes a blockchain network end 110, a holder end 120, an issuer end 130, and a verifier end 140, where the blockchain network end 110 is deployed with a plurality of blockchain intelligent contracts for data storage and rights management; wherein:

the holder 120 is configured to register DID data with the blockchain network 110 to obtain a DID document, and send an obtaining request of a verifiable statement to the issuer 130;

the issuer 130 is configured to register DID data with the blockchain network 110 to make a user of the issuer 130 become an issuer, and issue a verifiable statement to the holder 120 after receiving the acquisition request sent by the holder 120;

the verifier end 140 is configured to verify, after receiving the service request sent by the holder end 120, the user identity of the issuer end 130, and the user signature of the issuer end 130 by invoking a blockchain intelligent contract of the blockchain network end 110, and provide a target service matching the service request for the user of the holder end 120 after the verification is passed.

In a specific implementation, the digital identity verification system 100 includes a block chain network end 110, a holder end 120, an issuer end 130, and a verifier end 140, where a plurality of block chain intelligent contracts are deployed in the block chain network end 110 in advance, and different block chain intelligent contracts have different uses, and the block chain intelligent contracts related here are mainly used for data storage and rights management, for example, storage of DID data, issuer data, and credential theme data, rights management of various target roles (issuer, contract administrator), and interaction between the holder end 120, the issuer end 130, and the verifier end 140 and different block chain intelligent contracts deployed in the block chain network end 110 can effectively ensure validity of various data storage, separation of data storage, and verification of rights of various roles, thereby improving security and trust of the block chain network.

It should be noted that, in the VC architecture for digital identity verification, there are the following participants:

issuers (issuers), entities that have subscriber data and can offer VCs, such as agencies and organizations like governments, banks, universities, etc., can revoke the owner's VC.

Here, the issuer may be divided into three levels of role architectures, namely, root issuer (rootAdmin), primary issuer (primaryIssuer), and general issuer (generic issuer), to design the issuer's registration and credential authorization, but may be set to other levels of role architectures, and is not limited to the three levels of role architectures.

The Holder (Holder), namely the user, the user requests, receives and holds the VC from the issuer, and presents the VC to the verifier, and the VC which is opened can be self-stored and is convenient for reuse later. The holder may transfer one or more VCs to others, and the holder may present the one or more VCs to a verifier. The holder can delete its own VC.

The Verifier (Verifier) receives and verifies the VC of the holder, and can provide the holder who presents the VC with a certain type of service.

The identifier registration mechanism (veriable Data Registry) is required to maintain a database of DIDs, such as a blockchain and a distributed book, for the application, the blockchain network, because a verifier needs to verify a VC issued by a holder, verify a DID of an issuer issuing the VC, and the like.

The workflow of the digital identity verification system 100 is set forth below and includes the following steps:

1) The holder 120 applies for registration of the DID data to the blockchain network 110, and after the registration is completed, a DID document is generated according to the DID data, and the DID data and the DID document of the user of the holder 120 are stored in the blockchain network;

the issuer 130 applies for registration of the DID data to the blockchain network 110, and after registration, generates a DID document according to the DID data, the DID data and the DID document of the user of the issuer 130 are stored in the blockchain network, the user of the issuer 130 becomes an issuer, and the issuer has the authority to issue VCs for the holder;

2) The holder 120 sends an acquisition request of VC for own DID data to the issuer 130;

3) After receiving the acquisition request, the issuer 130 queries whether the block chain network has the DID data of the user of the holder 120 registered therein, to verify the validity and validity of the user identity of the holder 120, and after the verification is passed, sends the VC of the DID data of the holder user to the holder 120;

4) The user of the holder end 120 holds the own DID data and VC and sends a service request to the verifier end 140 (service provider end);

5) After receiving the service request, the verifier end 140 verifies the user identity of the holder end 120, the user identity of the issuer end 130 issuing the VC to the holder end 120, and the user signature of the issuer end 130 through the blockchain network, and provides a target service matching the service request to the user of the holder end 120 after the verification is passed.

Here, the holder may be an individual, the issuer may be a public security agency, and the verifier may be a shopping site.

A blockchain intelligent contract (Smart contract) is a computer protocol that aims to propagate, verify or execute contracts in an informative way. Smart contracts allow trusted transactions to be conducted without third parties, which transactions are traceable and irreversible.

The existing storage (DID, issuer, and certificate subject) of DID and VC model technology can be stored on media such as blockchain, distributed database, etc., if storage is performed in blockchain, how to store the contract definition, the contract architecture has no general and uniform model, and belongs to a more new immature technology in the industry. In this regard, the present application designs a contract architecture based on DID data storage and rights management, that is, a four-layer hierarchical mechanism, and fig. 2 shows a schematic structural diagram of a blockchain network end 110 provided in an embodiment of the present application, where the blockchain network end 110 includes a data contract module 111, a rights contract module 112, a role contract module 113, and a control contract module 114; wherein, the data contract module 111 is used for storing and managing DID data, DID documents, issuer data and certificate subject data; the permission contract module 112 is used for managing the invoking permission of various target roles, wherein the target roles comprise an issuer and a contract administrator; the role contract module 113 is configured to manage role data of various target roles; and a control contract module 114 for calling the data contract module 111 to provide the corresponding proxy service.

In particular implementations, data and rights functions of DID, issuers, credential topics may be managed and stored by data contract module 111, rights contract module 112, role contract module 113, and control contract module 114 in blockchain network 110. Here, through a 4-layer architecture in the blockchain network 110, each level of responsibility is distinct, and DID data, issuer data, and configuration subject data can be effectively stored and rights controlled. The contract service logic architecture can be ensured to be continuously upgraded by controlling the contract module 114; the data contract module 111 ensures that DID data, distributor data and configuration subject data are effectively stored and different types of data are stored and separated; the authority verification of various roles and the management of contract addresses are ensured through an authority contract module 112; management of issuer roles, contract administrator roles are guaranteed by role contract module 113.

Further, the blockchain network end 110 is configured to deploy each blockchain intelligent contract according to the following steps:

deploying the role contract in the role contract module 113 on a target block chain network, and setting an initialized target role to obtain a contract address of the role contract; deploying the authority control contract and the call control contract in the authority contract module 112 on the target blockchain network, and setting the target role in the authority control contract and the call control contract; deploying DID data contracts, issuer contracts and credential topic contracts in the data contract module 111 on the target blockchain network, resulting in contract addresses for the DID data contracts, the issuer contracts and the credential topic contracts; the DID proxy contract, issuer proxy contract, credential topic proxy contract, and signature proxy contract in the control contract module 114 are deployed on the target blockchain network, resulting in contract addresses for the DID proxy contract, the issuer proxy contract, the credential topic proxy contract, and the signature proxy contract.

Here, DID proxy contract (didprox), issuer proxy contract (IssuerProxy), credential topic proxy contract (CredentialSubjectProxy), and signature proxy contract (SignProxy) are deployed in control contract module 114, and control contract module 114 provides an external interface, performs logical service processing on data, and calls underlying data contract module 111, so that the control contract can be continuously upgraded.

The control contract module 114 mainly includes the judgment of the upper layer service (such as the judgment of black and white list, the judgment of issuer name format, configuration subject format, the judgment of DID format, etc.), and signature verification (such as multiple signatures, group ring signature, etc. to verify the new issuer).

The DID agent contract is an agent layer of the DID data contract, and the functions mainly comprise the steps of registering the DID, obtaining the DID details and obtaining the DID version, such as the step of registering the DID: and performing service judgment, and calling a DID data contract to create.

The issuer contract is an agent layer of the issuer contract, and the functions mainly comprise issuer addition, change and inquiry, for example, the issuer addition is used for carrying out service judgment, signature verification and issuer contract invoking for registration.

The voucher subject agent contract is an agent layer of the voucher subject contract, and the functions mainly comprise the addition, the change and the query of the voucher subject, for example, the addition of the voucher subject is firstly carried out with service judgment, and then the voucher subject contract is called to be established.

The signature proxy contract is used for signature verification, and since the new creation of the issuer needs to pass the authorization of the alliance, organization and organization, the signature verification is needed.

The DID agent contract, the issuer agent contract, the certificate subject agent contract and the signature agent contract can be redeployed due to the change of the service, and can be upgraded by calling the control contract.

Here, a DID data contract (didiconctrdata), an issuer contract (IssuerData), and a credential topic contract (CredentialSubjectData) are deployed in the data contract module 111, each contract holding a rights control sub-contract and invoking the controls sub-contract; data contract module 111 focuses on the definition of data structures, the storage of data content, and the direct interface of data reads and writes.

The authority control subcontract is used for controlling issuer modification of issuer data and credential theme data and verifying authority of credential theme modification; the call control subcontracts are used for DID data contracts, issuer data contracts, and credential theme contracts to specify whether contract address callers have permission to call.

The core function of the DID data contract is used for DID registration and DID document storage, including registering DID, obtaining DID details, obtaining DID version, etc., such as registering DID: and judging whether the calling contract is the appointed DID proxy contract address by calling the control contract, and storing the DID data.

An issuer contract issuer data contract includes additions, modifications, and changes to the issuer. If the issuer is registered, whether the invoking contract is a designated issuer contract is judged through invoking the control contract, whether the invoking user can add the issuer is judged through the authority control contract, and after the auditing is passed, issuer information is saved, and an issuer address is saved through invoking a role contract.

The certificate theme contract is used for the newly adding and changing of the certificate theme, such as the newly adding of the certificate theme: and judging whether the calling contract is an appointed voucher theme proxy contract or not by calling the control contract, judging whether the user can add a voucher theme or not by the authority control contract, and storing the voucher theme after the audit is passed.

Here, a permission control contract (permissiontrolled) and a call control contract (CallController) are deployed in the permission contract module 112, and the permission contract module 112 may manage the call permissions of various roles, manage the contract addresses of the data contract module 111 and the control contract module 114, and control the call permissions of the contracts.

The authority control contract is used for definition of issuer authority and verification of authority, and a core method authority detection method (access address) is as follows: and inputting a parameter block chain address and an authority type, wherein the authority type comprises a change common issuer, a change primary issuer, a change root issuer, a change primary theme certificate and a change common theme certificate, and is respectively invoked when the issuer of a data contract-issuer contract is changed and invoked when the certificate of a certificate theme contract is changed. And (3) permission definition: the root issuer can add a primary issuer and a primary certificate theme; the primary issuer can add a common issuer and a common certificate subject. The calling process of the authority detection method is to judge what role the addr is by calling a role contract, and then judge whether the authority of the current authority class exists according to the role class so as to determine whether the authority of a certain operation exists.

The calling control contract is used for storing the control contract and the data contract address and verifying the authority of the control contract calling data contract. Since the contracts of the control contract layer in the framework can be dynamically updated at a certain time (if the business is changed or upgraded), the calling of the control contracts needs to control who has the authority to update the contracts (the contract administrator has the authority), and which control contracts can call the data contracts. The deployment of data contract addresses and the change of control contract addresses in the calling control contracts are operated by contract managers in role contracts; the control contract module 114 calls the data contract authority, the data contract needs to hold the call control contract for judging whether the stored call control contract address exists, if so, the current call control contract can call the data contract.

Wherein, the data contract module 111 can not upgrade, DID, issuer, bottom data of the configuration theme that keep; the control contract module 114 may be upgraded to allow redeployment due to a business change or the like, and to reassign a new contract to invoke a data contract. Core method one register (string _ name, address _ address), update (string _ name, address _ address): registering a control contract/data contract, modifying the control contract, entering parameters: contract name (such as DID data contract and DID agent contract), contract address, wherein, the operation step includes judging whether the current operator is a contract administrator, and storing and updating the contract address corresponding to the contract name; a second lookup method (string _ name) is used for inputting a contract name and acquiring a contract address of a specified contract name, for example: when the DID proxy contract calls the DID data contract, the appointed DID proxy contract address is obtained by calling the lookup method, so that the DID data contract can be called.

Here, a role contract (role) is deployed in the role contract module 113, and the role contract module 113 can manage all roles, including an issuer and a contract administrator (contract admin), wherein the contract administrator can add contract management by itself for controlling contract deployment upgrade.

In one example, a root issuer may register the identity credential topic, register a public security agency issuer, and authorize the public security agency to issue an identity VC; the public security organization can issue identity VC identity certificates, which are proof of identity cards, for general DIDs (common users). The root issuer can register university certification configuration subject, register the issuer of education bureau, and authorize the education bureau to issue university certification VC; the education bureau can register universities such as university degree certification configuration subjects, university issuers and the like and authorize the universities to issue university degree certification VC; a university may issue a university credit VC for a general DID (general user).

In one example, if the issuer is a three-tier role architecture, the root issuer may perform the following operations: managing the primary certificate subject (adding and modifying certificate subject), registering and authorizing the primary issuer. Operations the primary issuer may perform: managing common certificate theme (adding and modifying certificate theme), registering and authorizing common issuers, and issuing specified primary certificate. Operations that a generic issuer can perform: possesses the issue of the common voucher. It should be noted that the core functions of the role contract include adding a role and deleting a role. The new role includes but is not limited to a new root issuer, a primary issuer and a contract administrator, and the specific operation is to input parameters of an address and a role number to realize the new addition of the role, wherein the root issuer and the primary issuer can be added when being added by an issuer contract in a data contract; the contract administrator can directly add the contracts by the roles; the specific operation of deleting the role is to input parameters of an address and a role number to delete the role, wherein the deletion can be called when the deletion and the primary issuer are unregistered by an issuer contract issuer in the data contract, and a contract administrator can delete the role directly through the role contract.

Further, the blockchain network end 110 is further configured to upgrade a blockchain intelligent contract in the control contract module 114 according to the following steps:

when the target service is detected to be changed, deploying the block chain intelligent contract in the control contract module 114 on the target block chain network again to obtain a contract address of the block chain intelligent contract in the control contract module 114; writing the updated contract address of the block chain smart contract in the control contract module 114 into the invoking control contract in the permission contract module 112.

In a specific implementation, if the actual service of the user is changed, the control contract module 114 may be upgraded, and specifically, the user redeploys the DID proxy contract, the issuer proxy contract, the credential topic proxy contract, and the signature proxy contract and obtains the addresses of the respective contracts, and then the contract administrator writes the contract address of the contract in the new control contract module 114 into the invocation control contract, so far, the invocation control contract may control that only the contract in the new control contract module 114 can invoke the contract in the data contract module 111.

Further, the holder side 120 is configured to store DID data according to the following steps:

invoking DID proxy contracts in the control contract module 114 to determine whether the user of the holder side 120 is repeatedly registered by the DID proxy contracts; if not, the DID data contract in the data contract module 111 is called, and whether the contract address of the DID proxy contract is consistent with the contract address of the first appointed calling contract is judged through the calling control contract in the authority contract module 112; if yes, the DID data of the user of the holder end 120 is acquired from the DID data contract in the data contract module 111 and stored.

In a specific implementation, a user of the holder side 120 may obtain and store the DID data by calling a DID proxy contract, wherein the user of the holder side 120 stores data such as the DID document, the creation time, the DID method, and the DID public key, in addition to the DID data, and specifically, the holder side user calls the DID proxy contract, makes a simple judgment as to whether the user is repeatedly registered by the DID proxy contract, then calls the DID data contract, judges whether an address of the DID proxy contract coincides with an address of a first designated calling contract (designated DID proxy contract) by calling a control contract, and if so, obtains and stores the DID document.

Further, the issuer end 130 is configured to add new credential topic data according to the following steps:

invoking a credential topic proxy contract in the control contract module 114 to determine whether a credential topic for the issuer 130 user is repeatedly registered via the credential topic proxy contract; if not, a credential theme contract in the data contract module 111 is called, whether the credential theme contract is consistent with a second specified calling contract is judged through a calling control contract in the permission contract module 112, and whether the user of the issuer 130 has permission to add credential theme data is judged through a permission control contract in the permission contract module 112; if the audit is passed, the credential theme data of the user of the issuer 130 is newly added and saved.

In a specific implementation, a user of the issuer 130 may add a credential theme by invoking a credential theme proxy contract, where the added content of the credential theme includes information such as a credential theme name, a credential type, and a credential format, specifically, invoke the credential theme proxy contract, determine, by the credential theme proxy contract, whether the credential theme is repeatedly registered, invoke the credential theme contract, determine, by invoking a control contract, whether the invoked credential theme proxy contract is a formulated credential theme proxy contract (second specified invocation), if yes, determine, by the permission control contract, whether the invoking user may add the credential theme, and after the approval passes, save the credential theme.

Here, if the issuer is a three-level role architecture, the root issuer may register a primary credential theme of the primary issuer, and the primary issuer may register a general credential theme of the general issuer.

It should be noted that, a root issuer may create an identity VC credential topic, a credential topic contract controls the contract by invoking a permission, and a permission detection method (checkPermission) is used to determine whether a user is the root issuer by invoking a role data contract, if so, an identity VC credential topic may be created, and the credential topic contract saves details of the identity VC credential.

Further, the issuer end 130 is configured to register an identity according to the following steps: invoking an issuer proxy contract in the control contract module 114 to determine from the issuer proxy contract whether the identity of the user of the issuer 130 is double checked; if not, checking the signature data of the user of the issuer 130; if the verification is passed, invoking an issuer contract in the data contract module 111, and judging whether the issuer contract is consistent with a third specified invocation contract through an invocation control contract in the authority contract module 112, and judging whether a user of the issuer 130 has authority to add issuer data through an authority control contract in the authority contract module 112; if the verification is passed, the issuer data is registered and saved.

In specific implementation, an issuer performs identity registration by calling an issuer contract, wherein issuer registration content comprises an issuer DID, a credential theme to be found by the issuer and signature information of the issuer, specifically, the issuer contract is called, whether the issuer is repeatedly checked is performed, whether the credential theme is newly added or not is judged, simple business logic such as signature is checked through a signature proxy contract, the issuer contract is called for registration, an issuer contract is continuously called, whether the called issuer proxy contract is a specified issuer (a third specified calling contract) is judged through a calling control contract, if yes, whether a calling user can add the issuer contract is judged through an authority control contract, after the verification is passed, the issuer information is saved, and an issuer address is saved through a calling role contract.

Here, if the issuer is a three-tier role architecture, the root issuer may add a tier issuer, and the root issuer may register the tier issuer and the tier issuer may register a common issuer.

It should be noted that, a root issuer may create an identity issuer (a public security organization, a primary issuer), an issuer contract controls a contract by invoking an authority, and when an authority detection method is invoked, it is determined whether a user is the root issuer by invoking a role contract, if the user is the root issuer, the identity issuer may be created; an issuer contract maintains identity issuer details, and an identity issuer address is maintained by invoking a role contract.

Further, the issuer end 130 is configured to issue the verifiable claims according to the following steps:

invoking a DID proxy contract in the control contract module 114 to forward the acquisition request to a DID data contract in the data contract module 111 through the DID proxy contract, so that the DID data contract judges whether DID data of the user who sent the acquisition request exists; if so, a verifiable claim is issued to the holder 120 that sent the acquisition request.

In a specific implementation, a publisher may publish a VC, specifically, the publisher publishes the VC, first determines whether a user DID exists, if so, invokes a DID proxy contract, and the DID proxy contract forwards a request to a DID data contract, and the DID data contract determines whether the user DID exists, and returns a result, and if the user DID is valid, the publisher may publish the VC according to an actual situation.

Further, the verifier end 140 is configured to verify the verifiable statement according to the following steps:

invoking a DID proxy contract in the control contract module 114, forwarding the service request to a DID data contract in the data contract module 111 through the DID proxy contract to determine whether DID data of the user sending the service request exists through the DID data contract; if so, invoking an issuer proxy contract in the control contract module 114, forwarding the service request to an issuer contract in the data contract module 111 via the issuer proxy contract, to determine via the issuer contract whether an issuer of a verifiable claim provided to a user sending the service request is registered, and if so, has authority to issue the verifiable claim; if the issuer of the verifiable claim is registered and authorized to issue the verifiable claim, then it is determined that the verifiable claim of the user who sent the service request passed the audit.

In specific implementation, the verifier end 140 may verify the user VC of the holder end 120, specifically, when verifying VC, the verifier end 140 first needs to verify whether the DID and the issuer of the user are valid, needs to invoke a DID proxy contract and an issuer proxy contract, forwards the request to a DID data contract by invoking the DID proxy contract, determines whether the DID exists according to the DID data contract, and returns a result if the DID exists; the method comprises the steps of calling an issuer proxy contract, transmitting a forwarding request to the issuer contract, and judging whether an issuer is registered or not and whether the issuer has the authority to issue a current certificate theme or not by the issuer contract; if the DID of the user at the owner side 120 and the issuer DID are both valid, the user at the verifier side 140 can verify the VC based on the actual request.

In the embodiment of the application, the digital identity verification system comprises a block chain network end, a holder end, a distributor end and a verifier end, wherein the block chain network end is provided with a plurality of block chain intelligent contracts for data storage and authority management, and through interaction between the holder end, the distributor end and the verifier end and different block chain intelligent contracts arranged in the block chain network end, not only can effective data storage and data storage separation be effectively ensured, but also authority verification of various roles can be realized, and further the safety and the trust degree of the block chain network are improved.

Based on the same application concept, the embodiment of the present application further provides a digital identity authentication method corresponding to the digital identity authentication system provided in the above embodiment, and as the principle of solving the problem of the method in the embodiment of the present application is similar to that of the digital identity authentication system in the above embodiment of the present application, the implementation of the method can refer to the implementation of the system, and the repeated parts are not described again.

Fig. 3 is a flowchart illustrating a digital identity verification method provided in an embodiment of the present application; a digital identity authentication method is applied to a block chain network end in a digital identity authentication system, and comprises the following steps:

s301: after receiving a registration request of a holder end for DID data, distributing the DID data and DID documents for a user of the holder end;

s302: after receiving a registration request of a publisher end for DID data, enabling a user of the publisher end to become a publisher, so that the publisher end provides a verifiable statement for the holder end after receiving a verifiable statement acquisition request sent by the holder end;

s303: after receiving a verification request aiming at the identity of the holder end and sent by a verifier end, calling a block chain intelligent contract to verify the user identity of the holder end, the user identity of the distributor end and the user signature of the distributor end, so that the verifier end provides target service matched with the service request for the user of the holder end after verification is passed.

In one possible implementation, each blockchain intelligence contract is deployed according to the following steps:

In one possible implementation, the blockchain intelligent contract in the control contract module is upgraded according to the following steps:

In one possible embodiment, DID data is stored according to the following steps;

receiving a calling request of the holder end aiming at a DID agent contract in the control contract module, and judging whether a user of the holder end is repeatedly registered;

if not, calling a DID data contract in the data contract module, and judging whether the contract address of the DID agent contract is consistent with the contract address of a first appointed calling contract or not;

and if so, acquiring and storing the DID data of the user at the holder side from the DID data contract in the data contract module.

In one possible implementation, the voucher topic data is added according to the following steps:

receiving a calling request of the issuer terminal for a credential theme proxy contract in the control contract module, and judging whether a credential theme of a user of the issuer terminal is repeatedly registered;

if not, calling a certificate subject contract in the data contract module, judging whether the certificate subject contract is consistent with a second specified calling contract or not, and judging whether a user at the issuer end has the authority to add the certificate subject data or not through an authority control contract in the authority contract module;

In one possible embodiment, the identity is registered according to the following steps:

receiving a calling request of the issuer terminal for an issuer proxy contract in the control contract module, and judging whether the identity of a user of the issuer terminal is checked repeatedly;

if not, verifying the signature data of the user at the issuer end;

if the verification is passed, the issuer contract in the data contract module is called, whether the issuer contract is consistent with a third specified calling contract is judged through a calling control contract in the authority contract module, and whether the user of the issuer has the authority to add issuer data is judged through an authority control contract in the authority contract module;

if the verification is passed, the issuer data is registered and saved.

In one possible implementation, the verifiable claim is issued according to the following steps:

receiving a call request of the distributor terminal for a DID proxy contract in the control contract module, forwarding the acquisition request to a DID data contract in the data contract module through the DID proxy contract, and judging whether DID data of a user sending the acquisition request exists or not;

and if the verification request exists, the issuer side issues a verifiable declaration to the holder side which sends the acquisition request.

In one possible implementation, the verifiable assertion is verified according to the following steps:

receiving a call request of the verifier end aiming at a DID proxy contract in the control contract module, forwarding the service request to a DID data contract in the data contract module through the DID proxy contract, and judging whether DID data of a user sending the service request exists through the DID data contract;

and if the issuer of the verifiable statement is registered and has the authority to issue the verifiable statement, determining that the verifiable statement of the user sending the service request passes the audit.

In the embodiment of the application, through interaction between the holder end, the issuer end and the verifier end and different block chain intelligent contracts deployed in the block chain network end, not only can effective and separate data storage be effectively guaranteed, but also authority of various roles can be verified, and further security and trust of the block chain network are improved.

Based on the same application concept, referring to fig. 4, a schematic structural diagram of an electronic device 400 provided in the embodiment of the present application includes: a processor 410, a memory 420 and a bus 430, wherein the memory 420 stores machine-readable instructions executable by the processor 410, the processor 410 and the memory 420 communicate via the bus 430 when the electronic device 400 is operated, and the machine-readable instructions are executed by the processor 410 to perform the steps of the digital authentication method according to any of the above embodiments.

In particular, the machine readable instructions, when executed by the processor 410, may perform the following:

In the embodiment of the application, through interaction between the holder end, the issuer end and the verifier end and different block chain intelligent contracts deployed in the block chain network end, effective data storage and data storage separation can be effectively guaranteed, authority of various roles can be verified, and safety and trust of the block chain network are improved.

Based on the same application concept, embodiments of the present application further provide a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the digital identity authentication method provided in the foregoing embodiments are performed.

Specifically, the storage medium can be a general storage medium, such as a mobile disk, a hard disk, and the like, when a computer program on the storage medium is run, the digital identity authentication method can be executed, and through interaction between the holder end, the issuer end, and the verifier end and different block chain intelligent contracts deployed in the block chain network end, not only can various data storage be effectively guaranteed to be effective and data storage separated, but also authority of various roles can be verified, so that security and trust of the block chain network are improved.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the system and the apparatus described above may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again. In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and there may be other divisions when actually implemented, and for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of devices or units through some communication interfaces, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a non-volatile computer-readable storage medium executable by a processor. Based on such understanding, the technical solutions of the present application may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think of the changes or substitutions within the technical scope of the present application, and shall cover the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A digital identity verification system is characterized by comprising a block chain network end, a holder end, an issuer end and a verifier end, wherein the block chain network end is provided with a plurality of block chain intelligent contracts for data storage and authority management; the block chain network end comprises a data contract module, a permission contract module, a role contract module and a control contract module; the data contract module is used for storing and managing DID data, DID documents, issuer data and certificate subject data; the authority contract module is used for managing the calling authority of various target roles, and the target roles comprise issuers and contract managers; the role contract module is used for managing role data of various target roles; the control contract module is used for calling the data contract module to provide corresponding proxy service; wherein:

the issuer end is used for registering DID data to the blockchain network end to enable a user of the issuer end to become an issuer, and issuing a verifiable statement to the holder end after receiving the acquisition request sent by the holder end;

the verifier end is used for verifying the user identity of the holder end, the user identity of the issuer end and the user signature of the issuer end by calling a block chain intelligent contract of the block chain network end after receiving the service request sent by the holder end, and providing target service matched with the service request for the user of the holder end after the verification is passed;

the verifier end is further configured to verify the verifiable claims while verifying the identity of the user at the holder end, the identity of the user at the issuer end, and the user signature at the issuer end, the verifiable claims being verified based on a DID proxy contract at a control contract module, a DID data contract at a data contract module, and an issuer proxy contract at a control contract module.

2. The digital identity verification system of claim 1, wherein the blockchain network side is configured to deploy individual blockchain intelligent contracts according to the following steps:

deploying DID proxy contracts, issuer proxy contracts, credential topic proxy contracts, and signature proxy contracts in the control contract module over the target blockchain network to obtain contract addresses for the DID proxy contracts, the issuer proxy contracts, the credential topic proxy contracts, and the signature proxy contracts.

3. The digital identity authentication system of claim 2, wherein the blockchain network side is further configured to upgrade a blockchain intelligent contract in the control contract module according to the following steps:

4. The digital authentication system of claim 1, wherein the holder side is configured to store DID data according to the following steps:

calling a DID proxy contract in the control contract module to judge whether the user of the holder side is repeatedly registered or not through the DID proxy contract;

if not, calling a DID data contract in the data contract module, and judging whether a contract address of the DID agent contract is consistent with a contract address of a first appointed calling contract or not through a calling control contract in the authority contract module;

5. The digital identity verification system of claim 1, wherein the issuer is configured to add credential topic data according to the following steps:

calling a certificate subject proxy contract in the control contract module to judge whether the certificate subject of the user at the issuer end is repeatedly registered or not through the certificate subject proxy contract;

if not, a certificate subject contract in the data contract module is called, whether the certificate subject contract is consistent with a second specified calling contract is judged through a calling control contract in the authority contract module, and whether a user at the issuer end has authority to add certificate subject data is judged through an authority control contract in the authority contract module;

6. The digital identity verification system of claim 1, wherein the issuer terminal is configured to register an identity according to the following steps:

if not, verifying the signature data of the user at the issuer end;

if the verification is passed, the issuer data is registered and saved.

7. The digital identity verification system of claim 1, wherein the issuer end is configured to issue the verifiable claim according to the following steps:

if so, a verifiable statement is issued to the holder that sent the acquisition request.

8. The digital identity verification system of claim 1, wherein the verifier end is configured to verify the verifiable claim in accordance with the following steps:

9. A digital identity authentication method, which is applied to a blockchain network end in the digital identity authentication system of any one of claims 1 to 8, wherein the blockchain network end comprises a data contract module, a permission contract module, a role contract module and a control contract module; the data contract module is used for storing and managing DID data, DID documents, issuer data and certificate subject data; the authority contract module is used for managing the calling authority of various target roles, and the target roles comprise issuers and contract managers; the role contract module is used for managing role data of various target roles; the control contract module is used for calling the data contract module to provide corresponding proxy service; the digital identity authentication method comprises the following steps:

after receiving a verification request for the identity of the holder side sent by a verifier side, invoking a blockchain intelligent contract to verify the user identity of the holder side, the user identity of the distributor side and the user signature of the distributor side so that the verifier side provides a target service matched with the service request for the user of the holder side after the verification is passed, and verifying the user identity of the holder side, the user identity of the distributor side and the user signature of the distributor side at the same time, wherein the verifiable statement is verified based on a DID proxy contract in a control contract module, a DID data contract in a data contract module and a distributor proxy contract in a control contract module.

10. An electronic device, comprising: a processor, a memory and a bus, the memory storing machine-readable instructions executable by the processor, the processor and the memory communicating over the bus when the electronic device is operating, the machine-readable instructions when executed by the processor performing the steps of the digital authentication method of claim 9.

11. A computer-readable storage medium, characterized in that the computer-readable storage medium has stored thereon a computer program which, when being executed by a processor, carries out the steps of the digital authentication method according to claim 9.