Verifiable certificate generation method and system for distributed digital identity

Abstract

The invention discloses a verifiable certificate generation method and system for distributed digital identities, and relates to the technical field of digital identities, and the method comprises the steps: a notarization party committee selects a notarization party sub-committee after receiving a webpage identity data authentication application sent by a user; the user carries out TLS protocol handshake with the notarization party and the website server, the website server obtains the session key, and the user and the notarization party respectively obtain two shared session key shares; based on the two shared session key shares, the user, the notarization party and the website server perform data interaction to obtain a webpage response containing identity data; the notarization party verifies the webpage identity data generated in the data interaction process, and sends a webpage identity data proof to the user after passing the verification; and the voucher distribution committee issues a verifiable voucher to the user after verifying that the webpage identity data proof is valid and assertion proof is correct. According to the invention, the credible conversion of the existing digital identity information to the verifiable certificate in the distributed digital identity is realized.

Description

Technical Field

[0001] The present application relates to the field of digital identity technology, and in particular to a method and system for generating verifiable credentials for distributed digital identities. Background Art

[0002] With the development and popularization of the Internet, network application services have gradually emerged. Digital identity, as the identification of users in network services, aggregates the network activity data and identity attributes of its owner to solve the problems of identification, authorization and trust of digital space entities. Most of the existing identity management systems are centralized identity and alliance identity management models, facing many risks and challenges in data security and service models. User identity data is controlled by centralized institutions, resulting in high risk of leakage of identity data in centralized storage, unclear ownership of data usage rights, and difficulty in cross-domain data interoperability. At the same time, users lack control over their personal digital identities, and face difficulties such as imperfect user authorization mechanisms, difficulty in post-data leakage accountability, and data abuse.

[0003] In order to better meet the needs of users for identity data privacy protection, the decentralized digital identity (DID) system has evolved and derived from the traditional centralized digital identity. The distributed digital identity system has the characteristics of digital identity autonomy, controllability, portability, and interoperability. It uses distributed infrastructure to change the existing central agency control of digital identity mode, and returns the right to control and manage identity to users. It fundamentally solves many drawbacks of the existing identity management system and meets users' demands for identity autonomy and control.

[0004] In a typical distributed system framework, distributed digital identity holders (i.e., users) use distributed infrastructure based on blockchain, distributed ledgers and other technologies as a "trust bridge" to establish connections with credential issuers and credential verifiers. Verifiable Credentials (VC) flow between different components as a trusted carrier of user identity attributes to achieve the transfer and establishment of trust. A holder can hold multiple VCs, and different VCs can endorse one or more different attributes of the user. Based on different application requirements, the holder can provide one or more VCs to the verifier for identity and authority proof, and selectively disclose some attributes in the VC.

[0005] Verifiable credentials are mostly generated by user identity information generated and stored by existing service providers. For example, email addresses, education, account balances, and credit records are all stored in the databases of service providers such as email service providers, the Ministry of Education, and banks. Although users can query and access information by logging into their accounts, they need to prove the authenticity of all information with the help of the corresponding service providers. In the DID system, credential issuance mostly still relies on the user's verified identity information in the existing traditional identity management system, such as user identity information maintained by providers such as banks, governments, and enterprises. However, these providers have high requirements for maintaining the security and functional stability of existing systems and data, which makes it difficult for them to actively access the DID system and provide credential issuance services in the early stages of the development of distributed digital identity systems. This makes the issuing agency in the DID system ineffective, and also creates certain barriers to the transformation and aggregation of general identity information into DID distributed identity credentials.

[0006] At the same time, as the Internet ecosystem becomes increasingly rich, users register their identities in more and more network applications, resulting in personal data being scattered in the databases of different service providers. Due to the potential value and storage risks inherent in user information resources, there is competition for interests and lack of trust among different service providers, resulting in user data islands. It is difficult for users to independently extract the high-value, trusted identity attribute information generated when using network applications as identity credentials, making it difficult to generate VCs in distributed digital identities.

[0007] Most current research focuses on the application of DID systems in different fields, and there are fewer studies on the verification and issuance of DID identity attributes. For example, Soltani et al. verified the user's identity attributes based on financial institutions (such as banks), and then the institution issued a reusable certificate. The user can directly present the certificate to other financial institutions to complete the identity authentication to avoid the complicated conventional proof process. Gilani et al. require users to publish the certificate containing the required identity attributes on the blockchain, calculate the corresponding oracle proof (Oracle Proof) through a specific smart contract, and send it to the service provider for verification to ensure the authenticity of the certificate. However, the above solutions all require the service provider to cooperate in verifying the user's attributes to realize the conversion of existing identity attributes to the certificate in the DID system. The issue of user credential issuance has become one of the bottlenecks in the deployment of distributed digital identities. Summary of the invention

[0008] The purpose of this application is to provide a method and system for generating verifiable credentials for distributed digital identities, thereby realizing the trusted conversion of existing digital identity information into verifiable credentials in distributed digital identities.

[0009] To achieve the above objectives, the present application provides the following solution: a method for generating verifiable credentials for distributed digital identities, comprising:

[0010] The user submits a webpage identity data authentication application to the notary committee, and selects an authentication template matching the webpage to be authenticated from the notary committee; the authentication template is generated by the notary committee according to the request data framework and the identity attributes of the user;

[0011] After receiving the webpage identity data authentication application sent by the user, the notary committee selects a notary sub-committee from the notary committee through a verifiable random function; each member of the notary committee is a node on the oracle network;

[0012] Traverse each member of the notary subcommittee, and use each traversed member as a notary to interact with the user in turn, and issue a verifiable credential to the user; for each traversed member: the user, the notary and the website server perform a TLS protocol handshake through three-party negotiation, the website server obtains a session key, the user obtains a first shared session key share, and the notary obtains a second shared session key share; the first shared session key share and the second shared session key share are both shared shares of the session key;

[0013] The user obtains a web page request of a web page response containing user identity information according to the request data frame in the authentication template; the user and the notary party encrypt the web page request according to the first shared session key share and the second shared session key share, and send the encrypted web page request to the website server, and then the user, the notary party and the website server perform data exchange;

[0014] The notary verifies the data generated during the data interaction between the user and the website server, and sends the webpage identity data certificate to the user after the verification is passed;

[0015] After receiving the web page identity data certificate and assertion certificate sent by the user, the credential distribution committee verifies that the web page identity data certificate is valid and the assertion certificate is correct, and then issues a verifiable credential to the user; the assertion certificate is a certificate generated based on the assertion related to the user's identity.

[0016] The present application also provides a verifiable credential generation system for distributed digital identity, including: a user, a notary committee, a credential distribution committee, and a website server;

[0017] The user is used to submit a webpage identity data authentication application to the notary committee, and selects an authentication template matching the webpage to be authenticated from the notary committee; the authentication template is generated by the notary committee according to the request data framework and the identity attributes of the user;

[0018] The notary committee is used to select a notary sub-committee from the notary committee through a verifiable random function after receiving the webpage identity data authentication application sent by the user; each member of the notary committee is a node on the oracle network;

[0019] Traverse each member of the notary subcommittee, and use each traversed member as a notary to interact with the user in turn, and issue a verifiable credential to the user; for each traversed member: the user, the notary and the website server perform a TLS protocol handshake through three-party negotiation, the website server obtains a session key, the user obtains a first shared session key share, and the notary obtains a second shared session key share; the first shared session key share and the second shared session key share are both shared shares of the session key;

[0020] The user obtains a web page request of a web page response containing user identity information according to the request data frame in the authentication template; the user and the notary party encrypt the web page request according to the first shared session key share and the second shared session key share, and send the encrypted web page request to the website server, and then the user, the notary party and the website server perform data exchange;

[0021] The notary verifies the data generated during the data interaction between the user and the website server, and sends the webpage identity data certificate to the user after the verification is passed;

[0022] The credential distribution committee is used to receive the web page identity data certificate and assertion certificate sent by the user, verify that the web page identity data certificate is valid and the assertion certificate is correct, and then issue a verifiable credential to the user; the assertion certificate is a certificate generated based on the assertion related to the user's identity.

[0023] According to the specific embodiments provided in this application, this application discloses the following technical effects:

[0024] This application elects a notary sub-committee from the notary committee through a verifiable random function. Each member of the notary sub-committee is a notary. Each notary verifies the interactive data between the user and the website server. After verifying that the web page identity data is valid and the assertion is correct, it issues a verifiable certificate to the user, realizing that in the process of converting the user's existing identity attributes to DID verifiable credentials, there is no need for the service provider to provide verification support, that is, the user can independently control the conversion and use of all identity attributes. At the same time, it ensures the minimum disclosure of user information during the conversion process, that is, the user will not leak additional information to a third party except for the attributes to be verified. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0026] Figure 1 A flowchart of a method for generating verifiable credentials for distributed digital identities provided in an embodiment of the present application;

[0027] Figure 2 A schematic diagram of the overall process of a method for generating verifiable credentials for distributed digital identities provided in an embodiment of the present application;

[0028] Figure 3 A schematic diagram of the authentication template generation phase and the initialization phase provided in the embodiment of the present application;

[0029] Figure 4 A schematic diagram of the three-way handshake phase process provided in an embodiment of the present application;

[0030] Figure 5 A schematic diagram of the data interaction phase flow provided in an embodiment of the present application;

[0031] Figure 6 A schematic diagram of the network data proof generation process provided in an embodiment of the present application;

[0032] Figure 7 A schematic diagram of the process flow of the verifiable credential generation phase provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0034] The purpose of this application is to provide a method and system for generating verifiable credentials for distributed digital identities, thereby realizing the transformation of existing digital identity information into verifiable credentials in distributed digital identities.

[0035] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0036] Example 1

[0037] This application builds a link between the identity information source IS that currently stores user data, the user and a trusted notary (Notary) based on the web identity data certification scheme of the TLS protocol security. The user can prove to the notary that the source of the web identity data is correct and has not been tampered with without the perception of the Web server controlled by the identity information source IS. The trusted notary comes from the Notary Committee (NC), which is composed of nodes with certain computing power and credibility. Several notary nodes are selected through verifiable random functions to interact with users. Selective disclosure of the web identity data after certification is achieved, while protecting user privacy while ensuring the correctness and integrity of the attributes, and minimizing the disclosure of user data. The validity of the attributes disclosed by the user is verified by the Certificate Distribution Committee (IC) provided by the DID system, and the issuance of verifiable certificates containing the corresponding user attributes is completed.

[0038] Since the user's identity attribute to be issued is derived from the data correctly displayed on the web page by the authority that owns the attribute. The authority is considered to be trustworthy, and the user cannot collude with the authority or break into the authority's server to tamper with the relevant data. Therefore, the correctness and integrity of the attribute are manifested as follows: (1) Malicious users cannot be verified through web page identity data of unknown or incorrect origin, that is, the data source must be a recognized and trusted authority; (2) Malicious users cannot be verified through tampered web page identity data, that is, the web page identity data verified by the user is completely derived from the web page data obtained during the interaction with the IS. (3) The attributes contained in the verifiable credential finally obtained by the user are derived from the authenticated web page data and cannot be tampered by the user.

[0039] This application includes four participants: Identity Information Source (IS), Issuance Committee (IC), Notary Committee (NC) and users. IS and users are servers or terminals, and IC and NC are composed of servers or terminals. IS represents the source of identity information provided by the service provider to display the user's identity attributes. These identity information come from the service provider that currently has the corresponding user attributes, such as the account balance inquiry webpage provided by the bank, the student status inquiry webpage provided by the Ministry of Education, etc., which are the information sources of the user's identity attributes. The process of interaction between the user and the notary will not be detected by IS, and IS will proceed according to the normal web data request response process. NC is composed of nodes with certain computing power and credibility. When the user requests to prove the web data, a subcommittee is randomly selected. Each node in it acts as a notary to build a three-party TLS protocol with the user and IS to realize the authentication of web data. IC is composed of a series of nodes with strong credibility, such as institutions with certain credibility. The credential issuance service can be customized according to the needs of DID system credential generation. As a special type of trusted issuer in DID, IC verifies the attributes and proofs submitted by users and issues VC. NC and IC are different in function. NC is mainly responsible for establishing links with users and participating in the user's identity attribute data proof. IC is mainly responsible for verifying the validity of the user's identity attributes and then issuing the corresponding credentials. The functions of NC and IC can be completed by one committee in actual implementation, but in this application, the corresponding functions are implemented by setting up two committees to make the process clearer.

[0040] The privacy protection transformation of the user's existing attributes is a major security goal achieved by this application, so the scope of privacy protection is explained as follows: When the user, IS and the notary establish an authentication protocol, the notary does not know the specific web page data visited by the user, but can obtain the message length, the URL visited by the user, the X.509 certificate chain provided by the IS, etc. These data are actively sent by the user to the notary for verification. When the user selectively discloses evidence of the relevant attributes to the IC, the IC will obtain the user's identity and the assertion generated by the user based on the web page display credentials, but will not obtain the specific web page identity data and identity attributes.

[0041] This embodiment only describes a single-round interaction between the user and the IS, and multiple rounds of interaction can be achieved by simply repeating the operations of a single-round interaction.

[0042] This embodiment includes six stages, namely, an authentication template preparation stage, an initialization stage, a three-party handshake stage, a data interaction stage, a web page data proof generation stage, and a credential generation stage.

[0043] 1) Certification template preparation stage:

[0044] a) NC selects the authoritative web page that the user usually uses to access and determines whether the web page supports TLS1.2 or TLS1.3 protocol, that is, determines the request framework req to access the correct web page * .

[0045] b) Determine the request framework req to access the correct web page based on the actual request method of the target web page * , mainly determines the webpage URL, request method, and the label of the user's input data, while the user's account name, password, etc. are not included in the request frame. The purpose is to ensure that the user accesses the specified authoritative webpage.

[0046] c) Request website certificate chain cert * (First website certificate chain), for cert * The validity of the webpage is verified and saved to ensure the reliability of the authoritative webpage's identity.

[0047] d) View the response source code of the web page containing the key identity attribute and select the smallest globally unique string containing the key identity attribute in the web page in The data type of the key identity attribute (such as integer, floating point number, etc.), M p and M s They represent the prefix and suffix of the identity attribute in R. R is a complete string containing the identity attribute data.

[0048] e) Generate a standard assertion θ based on the identity attributes displayed on the web page. If a web page data contains multiple identity attributes, multiple assertions can be generated.

[0049] f) NC storage authentication template: = (req * ,cert * ,R * ,θ) and upload it to the chain for storage.

[0050] 2) Initialization phase:

[0051] a) The user submits a web page identity data authentication application to the NC and selects an authentication template that matches the web page to be authenticated.

[0052] b) Each node in NC uses its own private key Run VRF with the public seed generated in each election round Evalueate (seed,sk i )Generate a random number and the corresponding proof (value i ,π i), value i is a random number, π i For proof.

[0053] c) The sub-committee is selected based on the results of VRF, and then the nodes in each sub-committee establish links with the users and collaborate with them to complete subsequent proof work.

[0054] d) The user needs to establish interaction with each node in the sub-committee and complete the subsequent three-party handshake phase, data interaction phase, and data proof generation phase.

[0055] 3) Three-party handshake phase:

[0056] a) The TLS version negotiated between the user and the IS should be determined based on the highest version supported by both parties. There are some differences between TLS1.2 and TLS1.3 in the handshake phase. The version negotiation between the two parties is completed in the Hello message sent to each other. For the convenience of description, the TLS version negotiated by the two parties will be pre-determined in the following.

[0057] b) Both parties interact using the TLS 1.2 protocol:

[0058] The user first sends the first random number r c , generate a first handshake message according to the first random number, and negotiate related parameters such as the cipher suite, compression method, etc. The first handshake message includes the first random number, the cipher suite, and the compression method.

[0059] The user receives the second random number r sent by IS s , as well as the selected cipher suite and compression method, etc., the second handshake message includes a second random number, the cipher suite and the compression method.

[0060] The user receives the website certificate chain cert (second website certificate chain) sent by IS, and the first temporary public key Y in the first temporary public-private key generated by IS s and signature σ.

[0061] The user verifies the validity of cert and σ.

[0062] If the verification is passed, (r c ,r s ,Y s ,cert) is sent to the notary.

[0063] The notary verifies the validity of the webpage certificate cert and whether it is the same as the certificate cert stored in the template * same.

[0064] After the notary verifies that the certificates are valid and identical, it generates a second temporary public-private key pair (s n ,Yn ), and the second temporary public key Y n Send to user.

[0065] The user also generates a third temporary public-private key pair according to the key exchange algorithm (s u ,Y u ), sends the third handshake message ClientKeyEx(Y u +Y n ).

[0066] At this point, the user and the notary each have a share of the temporary public and private keys. Both parties jointly run a secure two-party computing protocol under a malicious model, and each sends their own share of the temporary private key. The protocol can execute the key derivation function and output the master key share MS u and MS n , session key share and And send it to the user and the notary respectively, is the first shared session key share, is the second shared session key share.

[0067] The user and the notary jointly run a secure two-party computation protocol under a malicious model, which can perform verification calculations on all messages received during the handshake phase so far. The user sends MS u and the hash value h of all messages received so far in the handshake phase, the notary sends MS n , calling the protocol to calculate The user sends a Client Finished message to the IS. The website server then sends a ServerFinished message to the user and the notary.

[0068] The user and the notary verify the ServerFinished message sent by IS. If successful, the three parties complete the TLS handshake protocol and respond according to the standard TLS process.

[0069] b) Both parties use TLS 1.3 to communicate

[0070] Before interacting with the notary, the user and the notary first generate a first temporary public-private key pair (s u ,Y u ) and the second temporary public-private key pair (s n ,Y n ), the notary public will use the second temporary public-private key Y n Send to user.

[0071] The user first sends the first random number r c、First temporary public key Y u and the second temporary public key Y n , and negotiate related parameters such as the cipher suite and the use of elliptic curves.

[0072] The user receives the second random number r sent by IS s , the third temporary public key Y in the third temporary public-private key pair s As well as the selected cipher suite and the selected elliptic curve, the user will use the third temporary public key Y s Send to notary public.

[0073] The user and the notary jointly run a secure two-party computing protocol under a malicious model, and each sends their own temporary private key share. The protocol can execute the key derivation function and output the first handshake key share in the handshake phase. and the second handshake key share Because the data encryption in the subsequent session phase will regenerate the key, the notary can use the second handshake key share Sent to the user so that the user has the complete handshake key k hk , the subsequent handshake phase interaction has been completed.

[0074] The notary verifies the IS's website certificate chain cert (the second website certificate chain).

[0075] The user and the notary re-run a secure two-party computation protocol under a malicious model, which can execute the key derivation function and output the share of the session key and And send it to the user and the notary respectively, is the first shared session key share, is the second shared session key share.

[0076] The user and the notary jointly run a secure two-party computing protocol under a malicious model to verify the Finished verification data sent by the IS, and at the same time generate the user's Finished verification data and send it to the IS.

[0077] 4) Data interaction stage

[0078] a) The user requests the template req given in template * Construct a complete web page request req. req:=buildreq(req * ), access the web page URL specified in the authentication template according to the web page request.

[0079] b) The user and the notary jointly run a secure two-party computing protocol under a malicious model. The symmetric encryption algorithm negotiated by the protocol encrypts the complete request req constructed by the user and outputs reqEnc .

[0080] c) The user sends a request to IS Enc , waiting for the IS encrypted response resq Enc .

[0081] d) The session key owned by the user The encrypted request and request response generate a promise com, and then (req Enc ,resp Enc ,com) is sent to the notary as a commitment message for this interaction.

[0082] e) The notary receives the commitment and sends to the user, who can then recover the complete session key The response information resp = Dec (k session ,resp Enc ), and verify the correctness of the data summary.

[0083] 5) Web page identity data proof generation stage

[0084] The user generates a zero-knowledge proof to prove to the notary:

[0085] a)req Enc ,resp Enc Is req and resq use k session As the key, it is encrypted by the negotiated symmetric encryption algorithm, and the HMAC value contained in it can be verified.

[0086] b) Request according to the req in the template * Construct req.

[0087] The notary then verifies the following based on the data obtained during the interaction process:

[0088] a) Check whether the entire web page identity data acquisition process is completed.

[0089] b) The certificate chain cert sent by the user and the cert in the template * Are they consistent?

[0090] After verification, the notary uses his private key to generate a Claim for the user: = (template, request Enc ,resp Enc ,com) statement for subsequent generation of credentials.

[0091] 6) Credential generation phase:

[0092] a) The user creates a template based on the R * Retrieve the decrypted req and find the * All data blocks are represented as B = (B1, ...B l ). A Claim may contain multiple R * . Satisfy R * The complete string containing the identity attribute data is in the format The identity attribute data is M, which is kept confidential to IC.

[0093] b) The user completes the assertion θ in the tamplate based on M and obtains θ(M).

[0094] c) The user constructs a zero-knowledge proof π2 to prove that the complete string R is included in the data block set B, and the assertion θ(M) completed by the identity attribute M contained in R is correct.

[0095] d) User sends Claim and π2 to IC.

[0096] e) The IC verifies whether the Claim submitted by the user is issued by the nodes in the sub-committee and whether the quantity is consistent.

[0097] f) After IC verifies that Claim is valid and π2=1, it issues a verifiable credential VC to the user, which contains the user did and assertion θ(M).

[0098] like Figure 1 and Figure 2 As shown, a method for generating verifiable credentials for distributed digital identity in this embodiment includes the following steps.

[0099] Step 101: The user submits a web page identity data authentication application to the notary committee, and selects an authentication template that matches the web page to be authenticated from the notary committee; the authentication template is generated by the notary committee based on the request data framework and the user's identity attributes.

[0100] Step 102: After the notary committee receives the webpage identity data authentication application sent by the user, a notary sub-committee is selected from the notary committee through a verifiable random function; each member of the notary committee is a node on the oracle network.

[0101] Step 103: traverse each member of the notary sub-committee, and use each traversed member as a notary to interact with the user in turn, and issue a verifiable credential to the user.

[0102] Among them, in step 103, steps 1031 to 1034 are executed for each traversed committee member.

[0103] Step 1031: The user, the notary and the website server perform a TLS protocol handshake through three-party negotiation, the website server obtains a session key, the user obtains a first shared session key share, and the notary obtains a second shared session key share; the first shared session key share and the second shared session key share are both shared shares of the session key, and the notary is any member of the notary subcommittee;

[0104] Step 1032: The user obtains a web page request for a web page response containing identity information according to the request data frame in the authentication template, and based on the web page request, the user and the notary public interact with the website server according to the first shared session key share and the second shared session key share.

[0105] Step 1033: The notary verifies the data generated during the data interaction between the user and the website server, and sends the web page identity data certificate to the user after the verification is passed.

[0106] Step 1034: After the credential distribution committee receives the web page identity data certificate and assertion certificate sent by the user, it verifies that the web page identity data certificate is valid and the assertion certificate is correct, and then issues a verifiable credential to the user; the assertion certificate is a certificate generated based on the assertion related to the user's identity.

[0107] The first stage is the authentication template preparation stage before step 101. Figure 3 As shown in the figure, during the authentication template preparation phase, NC needs to generate a template for the process of obtaining key identity attributes for users in advance. Key identity attributes refer to identity attributes such as education information and bank balance that are included in the specified web page identity data. NC needs to confirm the correct process for obtaining key identity attributes, including the correct website certificate chain cert * , the corresponding web page URL and request parameters. Request data frame req * Including web page URL and parameters that need to be submitted, etc. After obtaining the corresponding response data, analyze the web page response data containing key identity attributes to ensure that the data subsequently selectively disclosed by the user meets the contextual integrity, that is, the meaning of the data meets the expected assumptions.

[0108] NC selects the globally unique string R containing the key identity attribute in the web page, and extracts the corresponding key identity attribute M from R. * . Parse string R, R = Among them, M p and M s Respectively represent M *To generate a universal string template that can confirm key identity attributes, extract M * The data type (such as integer, floating point, etc.) is and replace M * And retain the prefix and suffix to form the attribute template

[0109] θ represents the assertion generated based on the key identity attribute, which can describe the key identity attribute, such as the user has an account balance of m in Bank A. balance , the key identity attribute is the account balance m balance , asserting that θ is the balance greater than or equal to a certain value or less than a certain value, and thus NC generates an authentication template represented as template:=(req * ,cert * ,R * ,θ). After the authentication template is generated, it is uploaded to the blockchain for storage.

[0110] In summary, the method for generating verifiable credentials for distributed digital identity further includes: the notary committee generates a request data frame req of the web page to be authenticated according to the request data frame req of the web page to be authenticated. * 、First website certificate chain cert * , the globally unique string R containing the key identity attribute * The authentication template template matching the web page to be authenticated is generated by using the assertion θ related to the key identity attribute. The key identity attribute is the identity attribute in the web page identity data.

[0111] In the initialization phase, the user submits a web page identity data authentication application to NC and selects an authentication template that matches the web page to be authenticated. NC elects a subcommittee by running a verifiable random function, and each node in the subcommittee will establish a link with the user as a notary to complete subsequent verification interactions. That is, in the subsequent three-party handshake phase, data interaction phase, and web page identity data proof generation phase, the user needs to perform verification interactions with each notary node in the subcommittee.

[0112] In the initialization phase of this application, a verifiable pseudo-random function is used to select the notary sub-committee to ensure the randomness of the notary node and reduce the possibility of collusion between the user and the notary. A verifiable pseudo-random function (VRF) is a cryptographic primitive that maps input to a verifiable pseudo-random output, and the returned value is evenly distributed within the value range. The steps of the VRF algorithm based on the DDH assumption on the elliptic curve are as follows:

[0113] 1) Initialization of coefficient parameters and key: Setup→(sk,pk).

[0114] a) Input security parameters and generate system parameters Where q is a large prime number, the group The order is q, and g is the group The generator of , H1, H2 are cryptographic hash functions.

[0115] b) Each member of the notary committee randomly selects And calculate the public key y = g sk .

[0116] c) Public key pk of the notary is made public and private key sk is kept secret.

[0117] 2) Random Number and Evidence Generation: VRF Evalueat (s,sk)→(value,π)

[0118] Input the public random number seed s, calculate the parameter h = H1(s), calculate the parameter γ = h sk .

[0119] Randomly select any Calculation parameters c = H2(g,h,g sk ,h sk ,g sk ,h sk ).

[0120] Calculate the parameter t = kc·sk mod q.

[0121] Output random number Value = H2(h sk ), and output evidence π = (γ, c, t).

[0122] 3) Evidence Verification: VRF Verify (pk,π)→0 / 1

[0123] Calculation parameter u=(g sk ) c ·g t , calculate the parameters h = H1(s) and v = (γ) c ·h t .

[0124] Verify the parameters c = H2(g,H1(s),g sk ,γ,u,v)=H2(g,H1(s),g sk ,γ,(g sk ) c ·g t ,v=(γ) c ·h t ).

[0125] Verify that Value = H2(h sk ).

[0126] If both b) and c) are equal, output 1; otherwise, output 0.

[0127] In this application, cryptographic commitment is used to achieve the confidentiality and immutability of user identity data for web page access, providing proof for the subsequent generation of credentials. Cryptographic commitment is used to ensure the confidentiality and immutability of certain information. The commitment algorithm consists of three parts: Comm = (Setup, Commit, Open), which generates a commitment for message m:

[0128] Setup(λ)→pp comm : Generate a public parameter pp comm .

[0129] Commit(pp comm ,m,r)→cm: Generate a commitment cm for message m and provide a random number r.

[0130] Open(pp comm ,m,r,cm)→π: Output a verification result π, proving that the commitment cm is indeed a commitment to the message m.

[0131] This application realizes the selective disclosure of user identity attributes and the correct encryption proof of web page identity data through zero-knowledge proof. Non-Interactive Zero-Knowledge Proof (NIZK) is a cryptographic protocol used to prove the authenticity of a statement without revealing any other information about the statement, while allowing the prover to send only one message to the verifier without further interaction. The expression formula of this application is as follows:

[0132] NIZK{(,y,…):statements about x,y,…}# means that the secret value (x,y,…) satisfies the statement formula after the colon through zero-knowledge proof, while the other values ​​appearing in the formula are public.

[0133] This application needs to be implemented specifically for different versions of TLS protocols and negotiated cipher suites. Considering that there are many web pages that currently support TLS1.2 links, this example is implemented according to the interaction process of TLS1.2. The symmetric encryption algorithm and authentication algorithm select the AES-GCM symmetric encryption method supported by both TLS1.2 and TLS1.3. The handshake protocol selects the ECDHE key negotiation algorithm supported by both TLS1.2 and TLS1.3 protocols, and SHA256 as the key extension component. That is, select TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the cipher suite during negotiation.

[0134] The public parameters used in the ECDHE key exchange algorithm are defined as follows: E is a finite field The elliptic curve used by ECDHE is E p (E,b) is the Abelian group formed by E on the elliptic curve, which is E p Points in (a,b) with large prime order n.

[0135] The meaning of the symbol information designed in this example is as follows:

[0136] req,req * : Respectively represent the web page acquisition request sent by the user to the IS and the web page acquisition request authentication template specified by the NC.

[0137] cert,cert * : Respectively represent the certificate chain obtained by the user from the IS and the certificate chain specified by the NC for accessing the web page.

[0138] R * : Indicates the global minimum string template containing user identity attributes specified by NC.

[0139] θ: Assertions related to user identity attributes.

[0140] They represent the private key and public key of the node in NC, which are used to run VRF.

[0141] (value i ,π i ): represents the random value and corresponding proof generated by the node running VRF in NC.

[0142] r u : Indicates the Client Random generated by the user during the TLS handshake phase.

[0143] r s : Indicates the Server Random generated by IS during the TLS handshake phase.

[0144] σ: Indicates that IS uses the signature of the private key corresponding to the public key contained in cert.

[0145] Y s : Indicates the temporary public key sent by IS.

[0146] (s n ,Y n ): represents the temporary public-private key pair generated by the notary during the TLS handshake phase.

[0147] (s u ,Y u ): represents the temporary public and private key pair generated by the user during the TLS handshake phase.

[0148] PMS,PMS u ,PMS n : Respectively represent the complete pre-master key, the pre-master key share owned by the user, and the pre-master key share owned by the notary.

[0149] MS,MS u ,MS n : Indicates the complete master key, the master key share owned by the user, and the master key share owned by the notary.

[0150] Represents the secure two-party computation protocol for generating the pre-master key algorithm in the TLS protocol.

[0151] Represents a secure two-party computation protocol that implements the key derivation algorithm in the TLS protocol.

[0152] Represents a secure two-party computation protocol that implements the AES-GCM encryption algorithm.

[0153] IV session : Represents the initial vector input when performing AES-GCM symmetric encryption on data, including cwi used to encrypt messages sent by the user and swi used to encrypt data sent by the IS.

[0154] k session : Indicates the session key used when performing AES-GCM symmetric encryption on data.

[0155] They represent the session key share owned by the user and the session key share owned by the notary party respectively.

[0156] resp: indicates the response data sent by IS.

[0157] req Enc , resp Enc : Respectively represent the encrypted request req and response resp.

[0158] Step 102 specifically includes: each member of the notary committee uses a private key and a public seed generated in each round of election to run a verifiable random function to generate a first verifiable random function output and a corresponding certificate. The members corresponding to the first verifiable random function output within a set range form the notary sub-committee.

[0159] Step 102 limits the range of outputs. The notary nodes corresponding to the outputs within the specified range form a verification subcommittee to interact with the user. The notary establishes a link with the user and verifies the user's DID identity.

[0160] Step 1031 is the three-way handshake phase. Figure 4 As shown in the figure, in the three-party handshake phase, the user, the notary and the IS jointly negotiate to complete the TLS protocol handshake phase. For the TLS1.2 protocol, the data in the handshake phase is transmitted in plain text. For the TLS1.3 protocol, after the first round of interaction between ISIS and the user, the negotiated handshake key k hk The information sent during the handshake phase is encrypted. Therefore, in the TLS 1.3 protocol, the user and the notary need to negotiate k hk , due to k hk It is only used for data encryption in the handshake phase. To save costs, the notary can send the share it owns to the user after the negotiation is completed, so that the user has a complete handshake phase key and can quickly complete the handshake.

[0161] At the end of the handshake, IS obtains the session key k for encrypting the data in the session phase normally. session , the user and the notary jointly negotiate to obtain the shared share of the session key through a secure two-party computing protocol and At this point, neither the user nor the notary can complete data interaction with ISIS alone, because both parties only have part of the session key.

[0162] Among them, in step 1031, when the TLS protocol adopts the TLS1.2 protocol, such as Figure 5 As shown, the user, the notary and the website server perform a TLS protocol handshake through three-party negotiation, through which the website server obtains a session key, the user obtains a first shared session key share, and the notary obtains a second shared session key share, specifically including:

[0163] The user generates a first random number, and sends a first handshake message to the website server according to the first random number.

[0164] After receiving the first handshake message, the website server generates a second random number and a second temporary public-private key pair, sends a second handshake message to the user according to the second random number, and sends the second website certificate chain, the first temporary public key in the first temporary public-private key pair, and a signature to the user. The signature is a signature issued by the public key in the second website certificate chain.

[0165] The user verifies the received second website certificate chain and signature, and after the verification is passed, sends the first random number, the second random number, the first temporary public key and the second website certificate chain to the notary party.

[0166] The notary verifies whether the second website certificate chain is valid, and verifies whether the second website certificate chain is the same as the first website certificate chain in the authentication template. If the second website certificate chain is valid and the second website certificate chain is the same as the first website certificate chain in the authentication template, a second temporary public-private key pair is generated according to the key exchange algorithm, and the second temporary public key in the second temporary public-private key pair is sent to the user.

[0167] The user generates a temporary public-private key pair and a third temporary public-private key pair according to the key exchange algorithm, and sends a third handshake message to the website server according to the first temporary public key and the third temporary public key in the third temporary public-private key pair.

[0168] Based on the first temporary public-private key pair, the second temporary public-private key pair and the third temporary public-private key pair, the user and the notary party jointly run a secure two-party computing protocol under a malicious model to generate the first shared session key share and the second shared session key share.

[0169] The website server generates the session key according to the third handshake message, and sends a first Finished message.

[0170] After receiving the first Finished message, the user and the notary verify the first Finished message sent by the website server. If the verification is successful, the TLS1.2 protocol handshake is completed, otherwise the program terminates.

[0171] More specifically, when the TLS protocol adopts the TLS 1.2 protocol, step 1031 includes:

[0172] a) The user generates a first random number r u ←{0,1} 256 , sends the first handshake message ClientHello(r u ) starts the handshake protocol.

[0173] b) The user receives the second handshake message ServerHello (r s ), where r s Indicates the second random number generated by the IS party.

[0174] c) The user receives the cert and message ServerKeyEx(y) sent by IS s ,σ). Where cert represents the IS webpage certificate, Y s represents the first temporary public key in the IS key exchange algorithm, σ represents the private key pair associated with cert used by IS (r u ,r s ,curve info ,Y s ) signature. The user verifies whether the webpage certificate cert is valid. If it is correct, (r c ,r s ,Y s ,cert) is sent to the notary.

[0175] d) The notary verifies the validity of the webpage certificate cert and whether it is the same as the certificate cert stored in the template * same.

[0176] e) After the notary verifies that the certificates are valid and identical, a second temporary public-private key pair (s n ,Y n ), and the second temporary public key Y n Send to user.

[0177] f) The user also generates a third temporary public-private key pair according to the key exchange algorithm (s u ,Y u ), sends the third handshake message ClientKeyEx(Y u +Y n ).

[0178] g) The user calculates the first secret value Q u :=s u ·Y s , the notary party calculates the second secret value Q n :=s n ·Y s , the user and the notary send Q u and Q n Give Output PMS u and PMS n . The user obtains the share of the preliminary master key PMS u , the notary obtains the share of the preliminary master key PMS n , satisfying the relationship PMS is a complete preparation master key.

[0179] h) User sends PMS u , the notary sends PMS n , call Waiting for output

[0180] To users, where MS u Indicates the master key share obtained by the user. Indicates the session key share obtained by the user, IV session Represents the complete initial vector. The notary also obtains these three data That is, the current user and the notary share the master key Ms and the session key SK session , and both parties have a complete initialization vector IV session .

[0181] i) The user calculates the hash value h of all messages received so far in the handshake phase (including the first handshake message, the second handshake message, the third handshake message, the second certificate chain, and key exchange messages that are not explicitly stated, etc.), and sends Ms u and h, the notary sends MS n , call and run the 2PC-PRF calculation User sends to IS The client has completed the message (client finished).

[0182] j) Waiting to receive the IS The notary and the user run 2PC-PRF verification If not, give up. This is the first Finished message, that is, the message that the website server has completed (serverfinished).

[0183] Otherwise, the three parties complete the TLS handshake protocol and respond according to the standard TLS process.

[0184] When the TLS protocol adopts the TLS1.3 protocol, the user, the notary party and the website server perform a TLS protocol handshake through three-party negotiation, through which the website server obtains a session key, the user obtains a first shared session key share, and the notary party obtains a second shared session key share, specifically including:

[0185] The user generates a first random number and a first temporary public-private key pair, the notary generates a second temporary public-private key pair, and the user sends a first handshake message to the website server based on the first random number and the first temporary public key in the first temporary public-private key pair and the second temporary public key in the second temporary public-private key pair.

[0186] After receiving the first handshake message, the website server generates a second random number and a third temporary public-private key pair, sends a second handshake message to the user according to the second random number and the third temporary public key in the third temporary public-private key pair, and sends the first temporary public key, the second website certificate chain, the signature and the third Finished message to the user.

[0187] The website server generates the session key according to the first handshake message.

[0188] The user verifies the received second website certificate chain and signature, and after the verification is passed, sends the first temporary public key, the first random number, the second random number, the second website certificate chain and signature, and a fourth Finished message to the notary party.

[0189] The user and the notary jointly run a secure two-party computing protocol under a malicious model to output a first handshake key share of the user and a second handshake key share of the notary;

[0190] The user discloses a first handshake key share to the notary, and the notary discloses a second handshake key share to the user, so that both the user and the notary obtain a complete handshake key consisting of the first handshake key share and the second handshake key share;

[0191] The notary verifies whether the second website certificate chain is valid, and verifies whether the second website certificate chain is the same as the first website certificate chain in the authentication template. If the second website certificate chain is invalid or the second website certificate chain is not the same as the first website certificate chain in the authentication template, the procedure terminates;

[0192] The notary verifies whether the signature is valid, and terminates the procedure if the signature is invalid; the user and the notary jointly run a secure two-party computing protocol under a malicious model to generate the first shared session key share and the second shared session key share;

[0193] The user sends a second Finished message to the website server according to the complete handshake key, and the website server verifies the second Finished message. If the verification is successful, the TLS1.3 protocol handshake is completed, otherwise the program terminates.

[0194] Step 1032 is the data interaction stage, in which the user, the notary and ISIS interact using the previously negotiated session key.

[0195] The user requests the template req given in template * Construct a request req and access the webpage URL specified by the authentication template.

[0196] The user and the notary need to jointly run the secure two-party computation protocol under the malicious model (the user sends (cwk u ,cwi), the notary sends cwk n ), encrypt req using the negotiated session key to obtain the encrypted web page request req Enc =Enc(k session ,req).

[0197] The user sends an encrypted web page request req to IS Enc , waiting for the encrypted response resp Enc .

[0198] The user receives the request response resp sent by IS Enc After that, the session key (first shared session key share) generates a commitment Then (req Enc ,resp Enc ,com) is sent to the notary as a commitment message for this interaction.

[0199] After receiving the commitment, the notary sends (Second shared session key share) to the user, at which point the user can recover the complete session key Get the decrypted request response resp = Dec (k session ,resp Enc ).

[0200] Wherein, step 1032 specifically includes: the user obtains a web page request containing a web page response of identity information according to the request data frame in the authentication template.

[0201] The user and the notary jointly run a secure two-party computing protocol under a malicious model, and use the symmetric encryption algorithm in the secure two-party computing protocol to encrypt the web page request to obtain an encrypted web page request.

[0202] The user sends an encrypted web page request to the website server.

[0203] After receiving the encrypted web page request, the website server sends a request response to the user. The request response uses the session key k session Encrypted request response.

[0204] After receiving the request response, the user generates a commitment to own the first shared session key share, and sends commitment information including the encrypted web page request, the request response and the commitment to the notary party.

[0205] After receiving the commitment information, the notary sends the second shared session key share to the user.

[0206] The user obtains a session key according to the first shared session key share and the received second shared session key share, and uses the obtained session key to decrypt the request response to obtain response data after data interaction.

[0207] Among them, step 1033 is the web page identity data proof generation stage, such as Figure 6 As shown, at this stage, the notary verifies the data generated during the interaction between the user and the IS. After the user verifies that the webpage response is valid and contains the correct identity attributes, the user provides the zero-knowledge proof evidence π to the IS. The IS verifies the following data based on π and the interaction:

[0208] Whether the entire process of obtaining web page identity data is complete and correct.

[0209] The certificate chain cert and cert sent by the user * Are they consistent?

[0210] Whether the request sent by the user meets the requirements specified in the template * Here, compliance refers to whether the request format sent by the user complies with the request format specified in the template. * Format.

[0211] The user's promise Enc and resp Enc Whether Used as the key for encryption.

[0212] Among them, step 1033 specifically includes: the user generates a first zero-knowledge proof evidence.

[0213] The notary party verifies whether the second website certificate chain sent by the user is consistent with the first website certificate chain in the authentication template. If they are consistent, the first zero-knowledge proof evidence is used to verify whether the encrypted web page request sent by the user is consistent with the web page request in the authentication template. If they are consistent, the notary party verifies whether the session key used by the user to decrypt the request response and the session key used to decrypt the encrypted web page request are both session keys generated during the TLS protocol handshake process. If so, the notary party generates a web page identity data certificate based on the notary party private key.

[0214] This step more specifically includes: a) the user generates the first zero-knowledge proof evidence π1=(x1,w1), where w1 represents hidden information, x1 represents public information,

[0215] π1 outputs 1 if and only if: req Enc ,resq Enc Is req and resq use k session ,IV session As the calculation result of the key and initial vector under AES-GCM.

[0216] Request according to the authentication template req * Construct req: = buildreq(req * ).

[0217] b) The notary first verifies the following based on the data obtained during the interaction process:

[0218] Check whether the entire web page identity data acquisition process is completed.

[0219] The certificate chain cert sent by the user and the cert in the template * Are they consistent?

[0220] c) The notary then verifies π, determining the following:

[0221] The request sent by the user Enc Whether it meets the requirements specified in the template * .

[0222] The user's promise Enc and resq Enc Whether Used as the key for encryption.

[0223] After the verification is completed, the notary uses his own private key to sign and generate a claim for the user containing Claim: = (template, request Enc,resp Enc ,com) and sent to the user for subsequent credential generation. The Claim should also include the user's DID identifier did and the timestamp of the issuance time. The Claim cannot be transferred and cannot be used by another user, and has a certain validity period.

[0224] Step 1034 is the credential generation stage, such as Figure 7 As shown in the figure, in this stage, users need to prove their identity attributes to IC and generate VC. IC exists as a public credential issuer in a DID system and is composed of some highly trusted and stable nodes. IC is registered in the DID system and has a DID identifier and a DID document. A Claim may contain multiple identity attributes. Users can use Claim to apply for VC from different DID systems, or use one Claim to apply for multiple VCs. When users provide their own identity attributes, they can follow the string template R in template. * , selectively disclose the data block containing identity attributes to minimize the disclosure of web page identity data. After the node in IC verifies that the Claim submitted by the user is valid and the disclosed data block is correct, it can issue a VC containing assertion θ for the user.

[0225] Step 1034 specifically includes: the user authenticates the user according to the globally unique string R containing the key identity attribute in the authentication template. * , retrieve the decrypted response resq, and replace the decrypted request response with the globally unique string R containing the key identity attribute * All data blocks constitute a data block set, and the data block set is expressed as B = (B1, ...B l ). Satisfy R * The complete string containing the identity attribute data is in the format The identity attribute data is M.

[0226] The user completes the assertion θ in the authentication template according to the identity attribute data M to obtain a completed assertion θ(M).

[0227] The user constructs a second zero-knowledge proof evidence π2 to prove that the complete string containing the identity attribute data is contained in the data block set, and that the assertion that the identity attribute data is completed contained in the complete string containing the identity attribute data is correct.

[0228] The user sends the web page identity data proof and the second zero-knowledge proof evidence (Claim, π2) to the notary committee.

[0229] The notary committee verifies that each of the web page identity data certificates is signed by a member of the notary sub-committee, and the number of the web page identity data certificates is the same as the number of members of the notary sub-committee, and the second zero-knowledge proof evidence = 1, then a verifiable credential is issued to the user; the verifiable credential includes a user id identifier and a completed assertion.

[0230] This application provides a method for generating verifiable credentials for distributed digital identities, which uses web identity data proof technology based on secure two-party computing to enable users to achieve trusted conversion of identity information from different sources. At the same time, the conversion process does not require the cooperation of the service provider, avoiding external restrictions that affect the user's right to legally use their own identity attributes. By introducing zero-knowledge proof technology, it ensures that user data is minimized in the process of trusted identity conversion, credential issuance and verification, and credential use, and maximizes the privacy and security of user data throughout the entire circulation process. By setting up two committees to provide support for third-party verification in the information aggregation process, the flexibility of applying for VC is increased. VRF is used in NC to elect a sub-committee to participate in verification, avoiding corruption in advance when users know the identity of the notary. Threshold signatures are used in IC to issue VC to avoid single point failures and single point corruption.

[0231] The advantages of this application are described in detail below:

[0232] 1) Trusted transformation: This application is based on the security of the TLS protocol and selects web page identity data certification technology to realize the trusted transformation of user data scattered in different service providers. The integrity of user interaction data is guaranteed by adding a notary during the TLS protocol handshake phase. The notary shares the TLS session key with the user. Before the notary finally shares its share of the session key, neither party can modify or forge the session data. The integrity of the web page identity data is guaranteed. NC verifies the source web page of the user's identity attributes to be proved in advance, and verifies the certificate chain of the web page and its ownership of the certificate during the interaction process to ensure the credibility of the data source.

[0233] 2) Transparent proof: In the process of data proof, the notary and the user can be seen as a whole client interacting with the service provider. The data sent to the service provider is indistinguishable from the normal interaction data, and the service provider cannot detect that the user is performing web page data proof operations. Through this application, users can choose to convert the identity attributes displayed on the web page into VC without the support of the service provider, realizing the information aggregation of users in DID.

[0234] 3) Minimize information disclosure: A web page identity data certificate issued by a notary may contain identity information that can generate multiple VCs. This application decouples the web page identity data certificate from the VC issuance step, allowing users to use the same data certificate to apply for different VCs from the IC by disclosing different data, or to apply for VCs from ICs in different DID systems, thereby achieving efficient use of information. At the same time, this application uses zero-knowledge proof technology, so that users can only prove to the IC that the identity attributes in the web page identity data satisfy an assertion without revealing specific attributes.

[0235] 4) Distributed trust: This application sets up two committees to undertake the verification functions of the two stages of web identity data proof generation and credential generation, respectively, to avoid single point corruption on the verifier and achieve distributed trust. At the same time, because the interactive process of web identity data proof is complicated, in order to improve the user experience, NC uses VRF to elect a sub-committee to participate in the verification, reducing the number of times users link with the notary node. IC uses threshold signatures to issue VC to avoid single point failure and single point corruption.

[0236] In this application, NC is a committee composed of nodes on the blockchain. When a user issues an authentication request, it interacts with the user by selecting a subcommittee. The user needs to interact completely and correctly with all members of the subcommittee and obtain a statement. IC is a special committee in the DID system, composed of multiple nodes. IC is responsible for issuing the user's VC. The issuance of VC by nodes in IC depends on the threshold signature algorithm. Only when the threshold number of nodes in the committee in IC verify and sign the identity attribute certificate submitted by the user can the user's VC be correctly issued. Users should register their identities in a DID system in advance.

[0237] This application provides a method for generating verifiable credentials for distributed digital identities, which realizes that in the process of converting the user's existing identity attributes into DID verifiable credentials, there is no need for the service provider to provide verification support, that is, the user can independently control the conversion and use of all identity attributes. At the same time, it ensures that the user's information is minimized during the conversion process, that is, the user will not disclose additional information to a third party except for the attributes to be verified.

[0238] The present application discloses a method for generating verifiable credentials for distributed digital identities, which is specifically a distributed identity solution that is compatible with existing digital identities and realizes reliable information aggregation. It breaks down the barriers between DID and existing identity management systems, aggregates users' trusted identity information scattered in various identity management application agencies and application service providers, realizes the conversion of existing digital identity information into verifiable credentials in distributed digital identities, and completes the construction of users' on-demand autonomous and controllable digital identities.

[0239] Embodiment 2, the present application provides a verifiable credential generation system for distributed digital identity, including: users, notary committee members, credential distribution committee members and website servers; users, notary committee members and website servers are all communicatively connected.

[0240] The user is used to submit a web page identity data authentication application to the notary committee, and select an authentication template matching the web page to be authenticated from the notary committee; the authentication template is generated by the notary committee according to the request data framework and the user's identity attributes.

[0241] After receiving the webpage identity data authentication application sent by the user, the notary committee is used to select a notary sub-committee from the notary committee through a verifiable random function; each member of the notary committee is a node on the oracle network.

[0242] Each member of the notary sub-committee is traversed, and each traversed member is used as a notary to interact with the user in turn, and a verifiable credential is issued to the user; for each traversed member: the user, the notary and the website server perform a TLS protocol handshake through three-party negotiation, the website server obtains a session key, the user obtains a first shared session key share, and the notary obtains a second shared session key share; the first shared session key share and the second shared session key share are both shared shares of the session key.

[0243] The user obtains a web page request for a web page response containing user identity information according to the request data frame in the authentication template; the user and the notary party encrypt the web page request according to the first shared session key share and the second shared session key share, and send the encrypted web page request to the website server, and then the user, the notary party and the website server interact with data.

[0244] The notary verifies the data generated during the data interaction between the user and the website server, and sends a web page identity data certificate to the user after the verification is passed.

[0245] The credential distribution committee is used to receive the web page identity data certificate and assertion certificate sent by the user, verify that the web page identity data certificate is valid and the assertion certificate is correct, and then issue a verifiable credential to the user; the assertion certificate is a certificate generated based on the assertion related to the user's identity.

[0246] The technical features of the above embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0247] The present application uses specific examples to illustrate the principles and implementation methods of the present application. The above examples are only used to help understand the method and core ideas of the present application. At the same time, for those skilled in the art, according to the ideas of the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as limiting the present application.

Claims

1. A method for generating verifiable credentials for distributed digital identities, characterized in that: include: The user submits a webpage data authentication application to the notary committee, and selects an authentication template matching the webpage to be authenticated from the notary committee; the authentication template is generated by the notary committee according to the request data framework and the identity attributes of the user; After receiving the webpage identity data authentication application sent by the user, the notary committee selects a notary sub-committee from the notary committee through a verifiable random function; each member of the notary committee is a node on the oracle network; Traversing each member of the notary subcommittee, and using each traversed member as a notary to interact with the user in turn, and issuing a verifiable credential to the user; for each traversed member: the user, the notary and the website server perform a TLS protocol handshake through three-party negotiation, the website server obtains a session key, the user obtains a first shared session key share, and the notary obtains a second shared session key share, wherein the website server is used to provide a web page response containing user identity information; the first shared session key share and the second shared session key share are both shared shares of the session key; The user obtains a web page request of a web page response containing user identity information according to the request data frame in the authentication template; the user and the notary party encrypt the web page request according to the first shared session key share and the second shared session key share, and send the encrypted web page request to the website server, and then the user, the notary party and the website server perform data exchange; The notary verifies the data generated during the data interaction between the user and the website server, and sends the webpage identity data certificate to the user after the verification is passed; After receiving the web page identity data certificate and assertion certificate sent by the user, the credential distribution committee verifies the web page identity data, and after the certificate is valid and the assertion certificate is correct, issues a verifiable credential to the user; the assertion certificate is a certificate generated based on the assertion related to the user's identity.

2. The method for generating verifiable credentials for distributed digital identity according to claim 1, characterized in that: The method for generating verifiable credentials for distributed digital identity also includes: The notary committee generates an authentication template matching the web page to be authenticated based on the request data frame of the web page to be authenticated, the first website certificate chain, the globally unique string containing the key identity attribute, and the assertion related to the key identity attribute; the key identity attribute is the identity attribute in the web page identity data.

3. The method for generating verifiable credentials for distributed digital identity according to claim 2, characterized in that: After receiving the webpage identity data authentication application sent by the user, the notary committee selects a notary sub-committee from the notary committee through a verifiable random function, which specifically includes: Each member of the notary committee uses a private key and a public seed generated in each round of election to run a verifiable random function to generate a first verifiable random number and a corresponding certificate; The notary sub-committee is composed of the committee members corresponding to the first verifiable random number within the set range.

4. The method for generating verifiable credentials for distributed digital identity according to claim 3, characterized in that: When the TLS protocol adopts the TLS1.2 protocol, the user, the notary party and the website server perform a TLS protocol handshake through three-party negotiation, the website server obtains a session key, the user obtains a first shared session key share, and the notary party obtains a second shared session key share, specifically including: The user generates a first random number, and sends a first handshake message to the website server according to the first random number; After receiving the first handshake message, the website server generates a second random number and a first temporary public-private key pair, sends a second handshake message to the user according to the second random number, and sends a second website certificate chain, a first temporary public key in the first temporary public-private key pair, and a signature to the user; the signature is a signature issued by the public key in the second website certificate chain; The user verifies the received second website certificate chain and signature, and after the verification is passed, sends the first random number, the second random number, the first temporary public key and the second website certificate chain to the notary; The notary party verifies whether the second website certificate chain is valid, and verifies whether the second website certificate chain is the same as the first website certificate chain in the authentication template; if the second website certificate chain is valid, and the second website certificate chain is the same as the first website certificate chain in the authentication template, generates a second temporary public-private key pair according to the key exchange algorithm, and sends the second temporary public key in the second temporary public-private key pair to the user; The user generates a third temporary public-private key pair according to the key exchange algorithm, and sends a third handshake message to the website server according to the second temporary public key and the third temporary public key in the third temporary public-private key pair; Based on the first temporary public-private key pair, the second temporary public-private key pair, and the third temporary public-private key pair, the user and the notary jointly run a secure two-party computing protocol under a malicious model to generate the first shared session key share and the second shared session key share; The website server generates the session key according to the third handshake message, and sends a first Finished message to the user and the notary; After receiving the first Finished message, the user and the notary verify the first Finished message sent by the website server. If the verification is successful, the TLS1.2 protocol handshake is completed, otherwise the program terminates.

5. The method for generating verifiable credentials for distributed digital identity according to claim 3, characterized in that: When the TLS protocol adopts the TLS1.3 protocol, the user, the notary party and the website server perform a TLS protocol handshake through three-party negotiation, the website server obtains a session key, the user obtains a first shared session key share, and the notary party obtains a second shared session key share, specifically including: The user generates a first random number and a first temporary public-private key pair, the notary generates a second temporary public-private key pair, and the user sends a first handshake message to the website server according to the first random number and the first temporary public key in the first temporary public-private key pair and the second temporary public key in the second temporary public-private key pair; After receiving the first handshake message, the website server generates a second random number and a third temporary public-private key pair, sends a second handshake message to the user according to the second random number and the third temporary public key in the third temporary public-private key pair, and sends the first temporary public key, the second website certificate chain and the signature to the user; the signature is the signature of the second website certificate chain; The website server generates the session key according to the first handshake message; The user verifies the received second website certificate chain and the signature, and after the verification is passed, sends the first temporary public key, the first random number, the second random number, the second website certificate chain and the signature to the notary; The user and the notary jointly run a secure two-party computing protocol under a malicious model to output a first handshake key share of the user and a second handshake key share of the notary; The user discloses a first handshake key share to the notary, and the notary discloses a second handshake key share to the user, so that both the user and the notary obtain a complete handshake key consisting of the first handshake key share and the second handshake key share; The notary verifies whether the second website certificate chain is valid, and verifies whether the second website certificate chain is the same as the first website certificate chain in the authentication template. If the second website certificate chain is invalid or the second website certificate chain is not the same as the first website certificate chain in the authentication template, the procedure terminates; The notary verifies whether the signature is valid, and the procedure is terminated if the signature is invalid; The user and the notary jointly run a secure two-party computing protocol under a malicious model to generate the first shared session key share and the second shared session key share; The user sends a second Finished message to the website server according to the complete handshake key, and the website server verifies the second Finished message. If the verification is successful, the TLS1.3 protocol handshake is completed, otherwise the program terminates.

6. The method for generating verifiable credentials for distributed digital identity according to claim 2, characterized in that: The user obtains a web page request of a web page response containing user identity information according to the request data frame in the authentication template; the user and the notary party encrypt the web page request according to the first shared session key share and the second shared session key share, and send the encrypted web page request to the website server, and then the user, the notary party and the website server perform data interaction, specifically including: The user obtains a web page request containing identity information according to the request data frame in the authentication template; The user and the notary jointly run a secure two-party computing protocol under a malicious model, and use a symmetric encryption algorithm in the secure two-party computing protocol to encrypt the web page request to obtain an encrypted web page request; The user sends an encrypted web page request to the website server; After receiving the encrypted web page request, the website server sends a request response to the user; After receiving the request response, the user generates a commitment to possess the first shared session key share and the request and request response, and sends the commitment information including the encrypted web page request, the request response and the commitment to the notary party; After receiving the commitment information, the notary sends the second shared session key share to the user; The user obtains a session key according to the first shared session key share and the received second shared session key share, and uses the obtained session key to decrypt the request response to obtain response data after data interaction.

7. The method for generating verifiable credentials for distributed digital identity according to claim 5, characterized in that: The notary verifies the data generated during the data interaction between the user and the website server, and sends the webpage identity data certificate to the user after the verification is passed, specifically including: The user generates a first zero-knowledge proof evidence; The notary party verifies whether the second website certificate chain sent by the user is consistent with the first website certificate chain in the authentication template. If they are consistent, the first zero-knowledge proof evidence is used to verify whether the encrypted web page request sent by the user is consistent with the web page request in the authentication template. If they are consistent, the notary party verifies whether the session key used by the user to decrypt the request response and the session key used to decrypt the encrypted web page request are both session keys generated during the TLS protocol handshake process. If so, the notary party generates a web page identity data certificate based on the notary party private key.

8. The method for generating verifiable credentials for distributed digital identity according to claim 6, characterized in that: After receiving the webpage identity data certificate and assertion certificate sent by the user, the credential distribution committee verifies that the webpage identity data certificate is valid and the assertion certificate is correct, and then issues a verifiable credential to the user, specifically including: The user retrieves the decrypted request response according to the globally unique string where the key identity attribute is located in the authentication template, and forms a data block set with all data blocks in the decrypted request response that contain the globally unique string where the key identity attribute is located; The user completes the assertion in the authentication template according to the identity attribute data to obtain a completed assertion; The user constructs a second zero-knowledge proof to prove that the complete string containing the identity attribute data is contained in the data block set, and the assertion that the identity attribute data contained in the complete string containing the identity attribute data is complete is correct; The user sends the webpage identity data proof and the second zero-knowledge proof evidence to the credential distribution committee; The credential distribution committee verifies that each of the web page identity data certificates is signed by a member of the notary sub-committee, and the number of the web page identity data certificates is the same as the number of members of the notary sub-committee, and the second zero-knowledge proof evidence = 1, then a verifiable credential is issued to the user; the verifiable credential includes a user ID and a completed assertion.

9. A verifiable credential generation system for distributed digital identity, characterized in that: include: Users, Notary Committee, Credential Distribution Committee and Website Servers; The user is used to submit a webpage identity data authentication application to the notary committee, and selects an authentication template matching the webpage to be authenticated from the notary committee; the authentication template is generated by the notary committee according to the request data framework and the identity attributes of the user; The notary committee is used to select a notary sub-committee from the notary committee through a verifiable random function after receiving the webpage identity data authentication application sent by the user; each member of the notary committee is a node on the oracle network; Traverse each member of the notary subcommittee, and use each traversed member as a notary to interact with the user in turn, and issue a verifiable credential to the user; for each traversed member: the user, the notary and the website server perform a TLS protocol handshake through three-party negotiation, the website server obtains a session key, the user obtains a first shared session key share, and the notary obtains a second shared session key share; the first shared session key share and the second shared session key share are both shared shares of the session key; The user obtains a web page request of a web page response containing user identity information according to the request data frame in the authentication template; the user and the notary party encrypt the web page request according to the first shared session key share and the second shared session key share, and send the encrypted web page request to the website server, and then the user, the notary party and the website server perform data exchange; The notary verifies the data generated during the data interaction between the user and the website server, and sends the webpage identity data certificate to the user after the verification is passed; The credential distribution committee is used to receive the web page identity data certificate and assertion certificate sent by the user, verify that the web page identity data certificate is valid and the assertion certificate is correct, and then issue a verifiable credential to the user; the assertion certificate is a certificate generated based on the assertion related to the user's identity.

Images