CN113271211A - Digital identity verification system, method, electronic device and storage medium - Google Patents

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

Info

Publication number
CN113271211A
CN113271211A CN202110542095.XA CN202110542095A CN113271211A CN 113271211 A CN113271211 A CN 113271211A CN 202110542095 A CN202110542095 A CN 202110542095A CN 113271211 A CN113271211 A CN 113271211A
Authority
CN
China
Prior art keywords
contract
issuer
data
module
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202110542095.XA
Other languages
Chinese (zh)
Other versions
CN113271211B (en
Inventor
王挺
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Netease Hangzhou Network Co Ltd
Original Assignee
Netease Hangzhou Network Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Netease Hangzhou Network Co Ltd filed Critical Netease Hangzhou Network Co Ltd
Priority to CN202110542095.XA priority Critical patent/CN113271211B/en
Publication of CN113271211A publication Critical patent/CN113271211A/en
Application granted granted Critical
Publication of CN113271211B publication Critical patent/CN113271211B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

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, the decentralized digital identity authentication technology is in the exploration and starting stage, and the system definition, the on-chain data storage and the authority control of various roles are imperfect, so that a complete digital identity authentication system for realizing decentralized identity 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 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;
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, 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 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;
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 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 the machine-readable instructions are executed by the processor to perform the steps of the digital 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 structure of a network end of a blockchain according to an embodiment of the present disclosure;
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. Additionally, it should be understood that the schematic drawings are not necessarily 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 method, system, electronic device or computer-readable storage medium described 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 using the digital identity authentication method and system provided in the embodiments of the present application is within the scope 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, not only can it be effectively ensured that various data stores are effective and data stores are separated, but also authority of various roles can be verified, and further security and trust of the block chain network are improved.
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-chain 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 so that a user of the issuer 130 becomes 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 blockchain network end 110, a holder end 120, an issuer end 130, and a verifier end 140, wherein, a plurality of block chain intelligent contracts are deployed in the block chain network terminal 110 in advance, the uses of different block chain intelligent contracts are different, the blockchain intelligent contracts referred to herein are primarily for data storage and rights management, e.g., storage of DID data, issuer data, credential topic data, rights management for various target roles (issuer, contract administrator), through the interaction of the holder end 120, the issuer end 130 and the verifier end 140 with different blockchain intelligent contracts deployed in the blockchain network end 110, the method can effectively ensure that various data are effectively stored and separated, and the authority of various roles is verified, so that the safety and the trust degree of the block chain network are improved.
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 block chain intelligent contract (Smart contract) is a computer protocol that aims to propagate, verify or execute contracts in an informational manner. 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 contract module 112 ensures the authority verification of various roles and the management of contract addresses; 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 over 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 subject 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 lower-layer 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 voucher theme contract is used for newly adding and changing the voucher theme, such as newly adding the voucher 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; control contract module 114 may be upgraded to redeploy due to a business change or the like, and to reassign a new contract may 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 general DID (common 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 subjects (adding and modifying certificate subjects), registering and authorizing common issuers, and issuing appointed primary certificates. Operations that a generic issuer can perform: it possesses the issue-appointed general 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 a DID proxy contract in the control contract module 114 to determine whether the user of the holder side 120 is repeatedly registered through the DID proxy contract; 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 of the user of the issuer 130 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 whether the credential theme is repeatedly registered through the credential theme proxy contract, invoke the credential theme contract, determine whether the invoked credential theme proxy contract is a formulated credential theme proxy contract (a second specified invocation contract) through invoking a control contract, if so, determine whether the invoked user may add the credential theme through a permission control contract, and after the approval passes, store 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, the issuer contract in the data contract module 111 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 112, and whether the user of the issuer 130 has authority to add issuer data is judged 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 includes 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, and other simple business logic is verified through a signature proxy contract, the issuer contract is called for registration, the issuer contract is continuously called, whether the called issuer contract is a specified issuer contract (a third specified calling contract) is judged through a calling control contract, if yes, whether the issuer can be added to a calling user is judged through an authority control contract, and 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; 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 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 both the user's DID and the issuer DID at the holder end 120 are valid, the user at the verifier end 140 can verify VC according to 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 since 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 repeated details are not described.
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 terminal 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, 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, each blockchain intelligence contract is deployed 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 one possible implementation, the blockchain intelligent contract in the control contract module is upgraded 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 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, 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 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, 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, and whether the user of the issuer side 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 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;
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;
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:
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 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 a holder end, a distributor end, and a verifier end and different intelligent block chain contracts deployed in a block chain network end, not only can effective storage and separation of various data be effectively ensured, but also authority of various roles can be verified, and further security and trust of the block chain network can be 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 conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by 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 (12)

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; 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.
2. The digital identity verification system of claim 1, wherein the blockchain network side comprises a data contract module, a rights 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.
3. The digital identity verification system of claim 2, wherein 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.
4. The digital identity authentication system of claim 3, wherein 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.
5. The digital identity verification system of claim 2, 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 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 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;
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.
6. The digital identity verification system of claim 2, wherein the issuer is configured to add 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.
7. The digital identity verification system of claim 2, wherein 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, 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.
8. The digital identity verification system of claim 2, wherein the issuer end is configured to issue the verifiable claim 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.
9. The digital identity verification system of claim 2, wherein the verifier end is configured to verify the verifiable claim 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;
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.
10. A digital identity authentication method, which is applied to the network side of the blockchain in the digital identity authentication system according to any one of claims 1 to 9, the digital identity authentication method comprising:
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.
11. 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 10.
12. 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 10.
CN202110542095.XA 2021-05-18 2021-05-18 Digital identity verification system, method, electronic device and storage medium Active CN113271211B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110542095.XA CN113271211B (en) 2021-05-18 2021-05-18 Digital identity verification system, method, electronic device and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110542095.XA CN113271211B (en) 2021-05-18 2021-05-18 Digital identity verification system, method, electronic device and storage medium

Publications (2)

Publication Number Publication Date
CN113271211A true CN113271211A (en) 2021-08-17
CN113271211B CN113271211B (en) 2023-03-24

Family

ID=77231466

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110542095.XA Active CN113271211B (en) 2021-05-18 2021-05-18 Digital identity verification system, method, electronic device and storage medium

Country Status (1)

Country Link
CN (1) CN113271211B (en)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113642048A (en) * 2021-09-17 2021-11-12 安徽高山科技有限公司 Contract transmission signature method for protecting privacy
CN113709138A (en) * 2021-08-25 2021-11-26 网易（杭州）网络有限公司 Multimedia file acquisition method, entertainment method, system and electronic equipment
CN113743921A (en) * 2021-09-09 2021-12-03 网易（杭州）网络有限公司 Digital asset processing method, device, equipment and storage medium
CN113761597A (en) * 2021-09-17 2021-12-07 安徽高山科技有限公司 Contract signing method based on verifiable certificate VC and block chain signature
CN113779604A (en) * 2021-09-13 2021-12-10 网易（杭州）网络有限公司 Business service implementation method, device, equipment and storage medium based on block chain
CN113935072A (en) * 2021-09-26 2022-01-14 网易（杭州）网络有限公司 Issuer registration method, issuer registration device, computer equipment and storage medium
CN113992406A (en) * 2021-10-27 2022-01-28 杭州云象网络技术有限公司 Authority access control method for alliance chain cross-chain
CN114157447A (en) * 2021-10-22 2022-03-08 北京航空航天大学 Unmanned equipment safety communication method based on block chain technology
CN114282270A (en) * 2021-12-17 2022-04-05 网易（杭州）网络有限公司 Method, device, terminal and storage medium for managing certificates in block chain
CN114448639A (en) * 2021-12-15 2022-05-06 电子科技大学 Decentralized identity system with uniqueness and secret key safety and implementation method
CN114978668A (en) * 2022-05-19 2022-08-30 中国人民大学 Cross-link data entity identity management and authentication method and system
CN115549969A (en) * 2022-08-29 2022-12-30 广西电网有限责任公司电力科学研究院 Intelligent contract data service method and system
CN116070183A (en) * 2023-03-27 2023-05-05 布比（北京）网络技术有限公司 Method, device, equipment and medium for legal identity management and control based on blockchain

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9992022B1 (en) * 2017-02-06 2018-06-05 Northern Trust Corporation Systems and methods for digital identity management and permission controls within distributed network nodes
CN108234515A (en) * 2018-01-25 2018-06-29 中国科学院合肥物质科学研究院 A kind of Self-certified digital identity management system and its method based on intelligent contract
CN109587154A (en) * 2018-12-14 2019-04-05 金蝶软件（中国）有限公司 Digital identity verification method, device, computer equipment and storage medium
CN110336813A (en) * 2019-07-02 2019-10-15 北京启迪区块链科技发展有限公司 A kind of access control method, device, equipment and storage medium
CN110941679A (en) * 2019-12-05 2020-03-31 腾讯科技（深圳）有限公司 Contract data processing method, related equipment and medium
CN111316303A (en) * 2019-07-02 2020-06-19 阿里巴巴集团控股有限公司 System and method for block chain based cross entity authentication
CN111797374A (en) * 2020-07-21 2020-10-20 浙江同善人工智能技术有限公司 Supply chain access control system and method based on public chain intelligent contract
CN112291245A (en) * 2020-10-30 2021-01-29 北京华弘集成电路设计有限责任公司 Identity authorization method, identity authorization device, storage medium and equipment
CN112395570A (en) * 2020-10-30 2021-02-23 迅鳐成都科技有限公司 Alliance chain intelligent contract calling authority control method, system and storage medium
CN112580102A (en) * 2020-12-29 2021-03-30 郑州大学 Multi-dimensional digital identity authentication system based on block chain
EP3814948A1 (en) * 2019-07-02 2021-05-05 Advanced New Technologies Co., Ltd. System and method for blockchain-based cross-entity authentication

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9992022B1 (en) * 2017-02-06 2018-06-05 Northern Trust Corporation Systems and methods for digital identity management and permission controls within distributed network nodes
CN108234515A (en) * 2018-01-25 2018-06-29 中国科学院合肥物质科学研究院 A kind of Self-certified digital identity management system and its method based on intelligent contract
CN109587154A (en) * 2018-12-14 2019-04-05 金蝶软件（中国）有限公司 Digital identity verification method, device, computer equipment and storage medium
CN110336813A (en) * 2019-07-02 2019-10-15 北京启迪区块链科技发展有限公司 A kind of access control method, device, equipment and storage medium
CN111316303A (en) * 2019-07-02 2020-06-19 阿里巴巴集团控股有限公司 System and method for block chain based cross entity authentication
EP3814948A1 (en) * 2019-07-02 2021-05-05 Advanced New Technologies Co., Ltd. System and method for blockchain-based cross-entity authentication
CN110941679A (en) * 2019-12-05 2020-03-31 腾讯科技（深圳）有限公司 Contract data processing method, related equipment and medium
CN111797374A (en) * 2020-07-21 2020-10-20 浙江同善人工智能技术有限公司 Supply chain access control system and method based on public chain intelligent contract
CN112291245A (en) * 2020-10-30 2021-01-29 北京华弘集成电路设计有限责任公司 Identity authorization method, identity authorization device, storage medium and equipment
CN112395570A (en) * 2020-10-30 2021-02-23 迅鳐成都科技有限公司 Alliance chain intelligent contract calling authority control method, system and storage medium
CN112580102A (en) * 2020-12-29 2021-03-30 郑州大学 Multi-dimensional digital identity authentication system based on block chain

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113709138B (en) * 2021-08-25 2023-08-15 网易（杭州）网络有限公司 Multimedia file acquisition method, entertainment method, system and electronic equipment
CN113709138A (en) * 2021-08-25 2021-11-26 网易（杭州）网络有限公司 Multimedia file acquisition method, entertainment method, system and electronic equipment
CN113743921A (en) * 2021-09-09 2021-12-03 网易（杭州）网络有限公司 Digital asset processing method, device, equipment and storage medium
CN113743921B (en) * 2021-09-09 2024-01-23 网易（杭州）网络有限公司 Digital asset processing method, device, equipment and storage medium
CN113779604A (en) * 2021-09-13 2021-12-10 网易（杭州）网络有限公司 Business service implementation method, device, equipment and storage medium based on block chain
CN113761597A (en) * 2021-09-17 2021-12-07 安徽高山科技有限公司 Contract signing method based on verifiable certificate VC and block chain signature
CN113642048B (en) * 2021-09-17 2023-09-26 安徽高山科技有限公司 Contract transmission signature method for protecting privacy
CN113642048A (en) * 2021-09-17 2021-11-12 安徽高山科技有限公司 Contract transmission signature method for protecting privacy
CN113761597B (en) * 2021-09-17 2024-01-19 安徽高山科技有限公司 Contract signing method based on verifiable certificate VC and blockchain signature
CN113935072A (en) * 2021-09-26 2022-01-14 网易（杭州）网络有限公司 Issuer registration method, issuer registration device, computer equipment and storage medium
CN113935072B (en) * 2021-09-26 2024-04-30 网易（杭州）网络有限公司 Issuer registration method, issuer registration device, computer device, and storage medium
CN114157447A (en) * 2021-10-22 2022-03-08 北京航空航天大学 Unmanned equipment safety communication method based on block chain technology
CN114157447B (en) * 2021-10-22 2023-03-14 北京航空航天大学 Unmanned equipment safety communication method based on block chain technology
CN113992406A (en) * 2021-10-27 2022-01-28 杭州云象网络技术有限公司 Authority access control method for alliance chain cross-chain
CN114448639A (en) * 2021-12-15 2022-05-06 电子科技大学 Decentralized identity system with uniqueness and secret key safety and implementation method
CN114282270B (en) * 2021-12-17 2022-07-26 网易（杭州）网络有限公司 Method, device, terminal and storage medium for managing certificates in block chain
CN114282270A (en) * 2021-12-17 2022-04-05 网易（杭州）网络有限公司 Method, device, terminal and storage medium for managing certificates in block chain
CN114978668B (en) * 2022-05-19 2023-05-02 中国人民大学 Cross-chain data entity identity management and authentication method and system
CN114978668A (en) * 2022-05-19 2022-08-30 中国人民大学 Cross-link data entity identity management and authentication method and system
CN115549969A (en) * 2022-08-29 2022-12-30 广西电网有限责任公司电力科学研究院 Intelligent contract data service method and system
CN116070183A (en) * 2023-03-27 2023-05-05 布比（北京）网络技术有限公司 Method, device, equipment and medium for legal identity management and control based on blockchain

Also Published As

Publication number Publication date
CN113271211B (en) 2023-03-24

Similar Documents

Publication Publication Date Title
CN113271211B (en) Digital identity verification system, method, electronic device and storage medium
US20200119904A1 (en) Tamper-proof privileged user access system logs
CN110147994B (en) Instant execution method of block chain based on homomorphic encryption
US10587413B1 (en) Decentralized identities for cross-enterprise authentication and/or authorization
Omar et al. Identity management in IoT networks using blockchain and smart contracts
US20180343126A1 (en) System and method for utilizing connected devices to enable secure and anonymous electronic interaction in a decentralized manner
US8015596B2 (en) Shared credential store
CN113438088B (en) Social network credit monitoring method and device based on blockchain distributed identity
US11238170B2 (en) Delegation using pairwise decentralized identifier
EP3867849B1 (en) Secure digital wallet processing system
CN113271311B (en) Digital identity management method and system in cross-link network
CN113966597B (en) Resolving a dispersion identifier using multiple resolvers
US20210306151A1 (en) Deauthorization of private key of decentralized identity
CN112712372B (en) Alliance chain cross-chain system and information calling method
US11587084B2 (en) Decentralized identification anchored by decentralized identifiers
GB2431746A (en) Authorising a computing entity using path label sequences
CN113569298A (en) Identity generation method and identity system based on block chain
CN114944937A (en) Distributed digital identity verification method, system, electronic device and storage medium
US20230179402A1 (en) Device asserted verifiable credential
Kyriakidou et al. Decentralized identity with applications to security and privacy for the internet of things
Kersic et al. Orchestrating digital wallets for on-and off-chain decentralized identity management
EP4018614B1 (en) Did delegation/revocation to another did
Durán et al. An architecture for easy onboarding and key life-cycle management in blockchain applications
WO2010012721A1 (en) Propagating information from a trust chain processing
CN113994630A (en) Presentation interruption for DID attestation

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant