A method and system for generating verifiable credentials for distributed digital identities

Abstract

The present application discloses a method and system for generating verifiable credentials for distributed digital identities, which relates to the field of digital identity technology. The method includes: after the notary committee receives a webpage identity data authentication application sent by a user, it elects a notary sub-committee; the user performs a TLS protocol handshake with the notary and the website server, the website server obtains a session key, and the user and the notary respectively obtain two shared session key shares; based on the two shared session key shares, the user, the notary and the website server perform data interaction to obtain a webpage response containing identity data; the notary verifies the webpage identity data generated during the data interaction process, and sends the webpage identity data certificate to the user after passing the verification; 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. The present application realizes the trusted conversion of existing digital identity information into verifiable credentials in distributed digital identities.

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, online application services have gradually emerged. Digital identity, as a user's identifier in online services, aggregates the owner's online activity data and identity attributes to address the identification, authorization, and trust issues of digital entities. Existing identity management systems, mostly centralized or federated, face numerous risks and challenges in both data security and service models. User identity data is controlled by centralized institutions, leading to high risks of identity data leakage due to centralized storage, unclear data usage rights, and difficulties in cross-domain data interoperability. Furthermore, users lack control over their personal digital identities, leading to challenges such as imperfect user authorization mechanisms, difficulty in accountability after data leaks, and data misuse.

[0003] To better meet users' needs for identity data privacy protection, the Decentralized Identity (DID) system has evolved from traditional centralized digital identity. This system offers features such as self-controllability, portability, and interoperability. By leveraging distributed infrastructure, it shifts the focus from centralized digital identity control to the user, fundamentally addressing many of the shortcomings of existing identity management systems and satisfying users' demand for self-controllable identity.

[0004] In a typical distributed system framework, distributed digital identity holders (i.e., users) use distributed infrastructure based on technologies such as blockchain and distributed ledgers as a "trust bridge" to establish connections with credential issuers and credential verifiers. Verifiable Credentials (VCs) serve as trusted carriers of user identity attributes and flow between different components to achieve the transmission 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 from user identity information generated and stored by existing service providers. For example, email addresses, educational background information, account balances, and credit records are all stored in the databases of service providers like email service providers, the Ministry of Education, and banks. While users can query and access this information by logging into their accounts, they must verify the authenticity of all information with the help of the corresponding service provider. In DID systems, credential issuance still largely relies on users' verified identity information in existing traditional identity management systems, such as those maintained by providers like banks, governments, and businesses. However, these providers have high requirements for maintaining the security and functional stability of existing systems and data, making it difficult for them to proactively integrate into DID systems and provide credential issuance services in the early stages of the development of distributed digital identity systems. This results in a lack of effectiveness for issuing institutions within the DID system and creates barriers to the transformation and aggregation of universal identity information into DID distributed identity credentials.

[0006] At the same time, as the internet ecosystem becomes increasingly diverse, users are registering their identities across an increasing number of online applications, resulting in the dispersal of personal data across the databases of various service providers. Due to the potential value and storage risks inherent in user information resources, competition for interests and a lack of trust among different service providers have created silos of user data. This makes it difficult for users to independently extract the high-value, trusted identity attribute information generated by their online applications and use it as identity credentials, making the generation of VCs in distributed digital identities difficult.

[0007] Most current research focuses on the application of DID systems in various fields, with less research on the verification and issuance of DID identity attributes. For example, Soltani et al. verify user identity attributes based on financial institutions (such as banks), which then issue reusable credentials. Users can directly present these credentials to other financial institutions to complete identity authentication, avoiding the complex conventional proof process. Gilani et al. require users to publish credentials 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 and credibility of the credentials. However, all of these solutions require the service provider to cooperate in verifying user attributes to achieve the conversion of existing identity attributes into credentials in the DID system. The issue of user credential issuance has become a bottleneck in the implementation of distributed digital identity. 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, which realizes the trusted conversion of existing digital identity information into verifiable credentials in distributed digital identities.

[0009] To achieve the above objectives, this 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 request to the Notary Committee, and the Notary Committee selects an authentication template that matches the webpage to be authenticated; the authentication template is generated by the Notary Committee based on the request data framework and the user's identity attributes;

[0011] After receiving the webpage identity data authentication application sent by the user, the Notary Committee elects 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] Each member of the notary subcommittee 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;

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

[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] This 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 submits a webpage identity data authentication application to the notary committee, and selects an authentication template from the notary committee that matches the webpage to be authenticated; the authentication template is generated by the notary committee based on the request data framework and the user's identity attributes;

[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] Each member of the notary subcommittee 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;

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

[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 uses a verifiable random function to elect a notary sub-committee from the notary committee. Each member of the notary sub-committee is a notary. Each notary verifies the interaction data between the user and the website server. After verifying that the webpage identity data is valid and the assertion is correct, it issues a verifiable credential to the user. This ensures that the service provider does not need to provide verification support during the conversion of the user's existing identity attributes to DID verifiable credentials. In other words, the user can independently control the conversion and use of all identity attributes. At the same time, it ensures that the disclosure of user information is minimized during the conversion process, that is, the user will not leak additional information to third parties 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 following briefly introduces the drawings required for use in the embodiments. 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 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 Schematic diagram of the authentication template generation phase and initialization phase provided in the embodiment of the present application;

[0029] Figure 4 A schematic diagram of the three-way handshake 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 for generating a verifiable credential according to an embodiment of the present application. DETAILED DESCRIPTION

[0033] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts 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, which realizes the conversion of existing digital identity information into verifiable credentials in distributed digital identities.

[0035] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below with reference to 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 knowledge 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 a verifiable random function to interact with the user. The web identity data after certification is selectively disclosed, while ensuring the correctness and integrity of the attributes, protecting user privacy and minimizing the disclosure of user data. The attributes disclosed by the user are verified for validity by the Certificate Distribution Committee (IC) provided by the DID system, and the issuance of a verifiable certificate containing the corresponding user attributes is completed.

[0038] Since the user's identity attributes to be issued are derived from the data correctly displayed on the web page by the authority that owns the attributes, the authority is considered 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 attributes are as follows: (1) Malicious users cannot be verified through web identity data with unknown or incorrect sources, that is, the data source must be a recognized and trusted authority; (2) Malicious users cannot be verified through tampered web identity data, that is, the web identity data that the user has verified is entirely derived from the web data obtained during the interaction with the IS. (3) The attributes contained in the verifiable credentials that the user finally obtains are derived from the authenticated web data and cannot be tampered with by the user.

[0039] This application involves four parties: the Identity Information Source (IS), the Issuance Committee (IC), the Notary Committee (NC), and the user. The IS and user are both servers or terminals, while the IC and NC are both composed of servers or terminals. The IS represents the source of identity information provided by the service provider, displaying the user's identity attributes. This identity information originates from the service provider that currently possesses the corresponding user attributes, such as the account balance inquiry webpage provided by a bank or the student status inquiry webpage provided by the Ministry of Education. These are the source of user identity information. The user's interaction with the Notary Committee remains undetected by the IS, which responds to web data requests in a normal manner. The NC is composed of nodes with a certain level of computing power and trustworthiness. When a user requests web data attestation, a subcommittee is randomly selected. Each of these nodes acts as a notary and establishes a three-party TLS protocol with the user and the IS to authenticate the web data. The IC is composed of a series of highly trustworthy nodes, such as institutions with a certain level of public credibility. The credential issuance service can be customized based on the requirements of credential generation in the DID system. As a special type of trusted issuer within a DID, the IC verifies the attributes and certifications submitted by users and issues VCs. NCs and ICs differ in their functions. NCs are primarily responsible for establishing links with users and participating in proving their identity attribute data. ICs, on the other hand, are primarily responsible for verifying the validity of users' identity attributes and then issuing corresponding credentials. In practice, the functions of both NCs and ICs can be performed by a single committee. However, for clarity in this application, two committees are established to achieve these functions.

[0040] The privacy-preserving transformation of a user's existing attributes is a primary security goal of this application. Therefore, the scope of privacy protection is explained as follows: When the user, the IS, and the notary establish an authentication protocol, the notary does not know the specific web page data accessed by the user. However, it does have access to information such as the message length, the URLs visited by the user, and the X.509 certificate chain provided by the IS. This information is proactively sent by the user to the notary for verification. When a user selectively discloses evidence of their attributes to the IC, the IC obtains the user's identity and assertions generated based on the credentials presented on the web page, but does not obtain the specific web page identity data or identity attributes.

[0041] This embodiment only describes a single-round interaction between the user and the IS. Multiple-round interactions 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 * The request frame mainly determines the webpage URL, the request method, and the label of the user's input data. The user's account name, password, etc. are not included in the request frame. The purpose is to ensure that the user accesses the designated 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.

[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 Represents 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 standard assertions θ 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 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 To prove.

[0053] c) A subcommittee is selected based on the VRF results, and then the nodes in each subcommittee establish links with users to 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 based on the highest version supported by both parties. There are some differences between TLS 1.2 and TLS 1.3 during the handshake phase. Version negotiation is completed in the Hello messages exchanged between the two parties. For ease of description, the negotiated TLS version will be pre-determined.

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

[0058] The user first sends the first random number r c , generating a first handshake message based on the first random number, and negotiating 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 certificate is valid and identical, it generates a second temporary public-private key pair (s n ,Yn ), and the second temporary public key Y n Sent to the user.

[0065] The user also generates a third temporary public-private key pair (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 temporary private key share. 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 computations to verify all messages received in the handshake phase so far. u And the hash value h of all messages received in the handshake phase so far, 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 subsequently 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 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 Sent to the user.

[0071] The user first sends the first random number r c, the 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 the notary public.

[0073] The user and the notary jointly run a secure two-party computation protocol under a malicious model, each sending 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 party 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 computation 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 encrypted response resq from IS 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, the user can now recover the complete session key The response information resp=Dec(k session ,resp Enc ), and verify whether the data summary is correct.

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

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

[0085] a)req Enc ,resp Enc Is req and resq using 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 completely.

[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 own private key to generate a Claim for the user: = (template, req Enc ,resp Enc ,com) statement for subsequent generation of credentials.

[0091] 6) Credential generation stage:

[0092] a) The user creates a template based on the R * Retrieve the decrypted req and find the one that covers R * 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 contained in the data block set B, and the assertion θ(M) completed by the identity attribute M contained in R is correct.

[0095] d) The 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 webpage identity data authentication application to the notary committee, and selects an authentication template that matches the webpage 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 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.

[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 certificate to the user.

[0102] 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 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 notary is any member of the notary subcommittee.

[0104] Step 1032: The user obtains a web page request containing a web page response with identity information according to the request data frame in the authentication template. Based on the web page request, the user and the notary party 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 webpage 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 following figure, during the authentication template preparation phase, the NC needs to generate a template for the process of obtaining key identity attributes for the user in advance. Key identity attributes refer to identity attributes such as educational information, bank balance, etc. that are included in the identity data of a specified web page. The 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 * This includes the webpage URL and the parameters that need to be submitted. After obtaining the corresponding response data, the webpage response data containing key identity attributes is analyzed 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 Represents M *In order 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 attributes, which can describe the key identity attributes, 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 a verifiable credential for a distributed digital identity further comprises: the notary committee generates a verifiable credential based on the request data frame req of the web page to be authenticated. * 、First website certificate chain cert * , the globally unique string R where the key identity attribute is located * An authentication template matching the web page to be authenticated is generated based on assertions θ related to key identity attributes. The key identity attributes are identity attributes in the web page identity data.

[0111] During the initialization phase, the user submits a webpage identity data authentication request to the NC and selects a template that matches the webpage to be authenticated. The NC then runs a verifiable random function to elect a subcommittee, each of which acts as a notary to establish a connection with the user for subsequent verification interactions. This involves the subsequent three-way handshake phase, data exchange phase, and webpage identity data proof generation phase, during which the user must conduct verification interactions with each notary node in the subcommittee.

[0112] During the initialization phase of this application, a verifiable pseudo-random function is used to select the notary sub-committee, ensuring the randomness of the notary node and reducing the possibility of collusion between users and the notary. A verifiable pseudo-random function (VRF) is a cryptographic primitive that maps inputs to verifiable pseudo-random outputs, and the returned values ​​are evenly distributed within a range. The steps of the VRF algorithm based on the DDH hypothesis on the elliptic curve are as follows:

[0113] 1) Coefficient parameter and key initialization: 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, 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 ), 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 parameter 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 Value = H2(h sk ).

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

[0127] In this application, cryptographic commitments are used to ensure the confidentiality and immutability of user identity data when accessing a webpage, providing proof for the subsequent generation of credentials. Cryptographic commitments are 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 uses zero-knowledge proof to achieve selective disclosure of user identity attributes and correct encryption of web page identity data. Non-Interactive Zero-Knowledge Proof (NIZK) is a cryptographic protocol used to prove the truth of a statement without revealing any other information about the statement, while allowing the prover to send only a single message to the verifier without further interaction. The expression formula of this application is as follows:

[0132] NIZK{(,y,…):statements about x,y,…}# indicates 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 requires specific implementation for different TLS protocol versions and negotiated cipher suites. Considering that many web pages currently support TLS 1.2 connections, this example is implemented based on the TLS 1.2 interaction process. The symmetric encryption and authentication algorithms use the AES-GCM symmetric encryption method, which is supported in both TLS 1.2 and TLS 1.3. The handshake protocol uses the ECDHE key negotiation algorithm, which is supported in both TLS 1.2 and TLS 1.3, with SHA256 as the key extension component. Specifically, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is selected 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, E p (E,b) is the Abelian group formed by E adding to 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, respectively, used to run VRF.

[0141] (value i ,π i ): Represents the random value and corresponding proof generated by the VRF running on the node in the 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 the IS during the TLS handshake phase.

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

[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-private key pair generated by the user during the TLS handshake phase.

[0148] PMS,PMS u ,PMS n : Represents 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 used to generate the pre-master key in the TLS protocol.

[0151] Represents a secure two-party computation protocol that performs 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 initialization vector input when performing AES-GCM symmetric encryption on data, including cwi, which is used to encrypt messages sent by the user, and swi, which is 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 shares owned by the user and the notary party respectively.

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

[0157] req Enc , resp Enc : Represents the encrypted request req and response resp respectively.

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

[0159] Step 102 limits the output range. The notary nodes corresponding to the outputs that fall 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-way 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 the complete handshake phase key and can complete the handshake quickly.

[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 independently, 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 the TLS protocol handshake, 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 based on the second random number, and sends the user a second website certificate chain, the first temporary public key in the first temporary public-private key pair, and a signature. 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.

[0166] The notary party verifies whether the second website certificate chain is valid and 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 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 TLS 1.2, 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 s ,σ). Where cert represents the IS webpage certificate, Y s represents the first temporary public key in the key exchange algorithm of the IS party, σ represents the private key pair associated with cert used by the 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 certificate is valid and identical, a second temporary public-private key pair (s) is generated according to the key exchange algorithm. n ,Y n ), and the second temporary public key Y n Sent to the 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 preliminary master key share 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 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 the key exchange message that is 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 This is the client finished message.

[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 subsequently respond according to the standard TLS process.

[0184] When the TLS protocol adopts the TLS 1.3 protocol, the user, the notary, and the website server perform a TLS protocol handshake through three-party negotiation. Through the TLS protocol handshake, 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:

[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, 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 based on 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. After the verification is passed, the user 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.

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

[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 whether the second website certificate chain is identical to the first website certificate chain in the authentication template. If the second website certificate chain is invalid or the second website certificate chain is different from the first website certificate chain in the authentication template, the procedure terminates.

[0192] The notary verifies whether the signature is valid, and terminates the process if the signature is invalid; the user and the notary jointly run a secure two-party computation 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. The website server verifies the second Finished message. If the verification is successful, the TLS 1.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 webpage request for a webpage response containing 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 is encrypted using 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.

[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 based on 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 in Figure 2, at this stage, the notary verifies the data generated during the user's interaction with the IS. After the user verifies that the webpage response is valid and contains the correct identity attributes, they provide the IS with a zero-knowledge proof of evidence π. Based on π and the interaction, the IS verifies the following data:

[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 specified in the template. * Format.

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

[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 notary party uses the first zero-knowledge proof evidence 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 the 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 using 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 completely.

[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 promised req Enc and resq Enc Whether Used as the encryption key.

[0223] After completing the verification, the notary uses his own private key to sign and generates a Claim:=(template,req Enc,resp Enc ,com) is 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 or 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 Figure 1, in this stage, users need to prove their identity attributes to the IC and generate VC. IC exists as a public certificate issuer in the 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 the 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 the 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 the 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 contained in the complete string containing the identity attribute data is complete is correct.

[0228] The user sends the webpage 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. It 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 flow 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, preventing users from knowing the identity of the notary in advance and engaging in corruption. Threshold signatures are used in IC to issue VC to avoid single point failure 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 party during the TLS protocol handshake phase. The notary party shares the TLS session key with the user. Before the notary party finally shares its own 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, ensuring the credibility of the data source.

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

[0234] 3) Minimized Information Disclosure: A webpage identity data certificate issued by a notary may contain identity information that can generate multiple VCs. This application decouples the webpage identity data certificate from the VC issuance process, 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, achieving efficient use of information. Furthermore, this application utilizes zero-knowledge proof technology, allowing users to simply prove to the IC that the identity attributes in the webpage identity data satisfy a single assertion, without revealing the specific attributes.

[0235] 4) Distributed Trust: This application establishes two committees to verify the web identity data proof and credential generation, respectively, to avoid single points of corruption on the verifier side and achieve distributed trust. Furthermore, due to the complex interactive process of web identity data proof, to enhance the user experience, the NC uses VRF to elect a subcommittee to participate in verification, reducing the number of connections between users and the notary node. The IC uses threshold signatures to issue VCs, avoiding single points of failure and corruption.

[0236] In this application, the NC is a committee composed of nodes on the blockchain. When a user issues an authentication request, a subcommittee is selected to interact with the user. The user must fully and correctly interact with all subcommittee members to obtain a declaration. The IC is a special committee within the DID system, composed of multiple nodes. The IC is responsible for issuing the user's VC. This issuance of VC by IC nodes relies on a threshold signature algorithm. Only after a threshold number of nodes in the IC committee have successfully verified and signed the user's identity attribute proof can the user's VC be correctly issued. Users should have registered their identity in a DID system in advance.

[0237] This application provides a method for generating verifiable credentials for distributed digital identities. This method eliminates the need for verification support from service providers during the conversion of a user's existing identity attributes into DID-verifiable credentials, allowing users to independently control the conversion and use of all identity attributes. Furthermore, it ensures minimal disclosure of user information during the conversion process, meaning that no additional information other than the attributes to be verified is leaked to third parties.

[0238] The present application provides 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 the barrier 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] In Example 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 submits a webpage identity data authentication application to the notary committee, and selects an authentication template that matches the webpage 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.

[0241] 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.

[0242] Each member of the notary subcommittee 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 based on the request data frame in the authentication template; the user and the notary party encrypt the web page request based on 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 the 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 can be combined arbitrarily. 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] This application uses specific examples to illustrate the principles and implementation methods of this application. The description of the above examples is only intended to help understand the method and core concept of this application. At the same time, for those skilled in the art, based on the concept of this application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as limiting this application.

Claims

1. A method for generating verifiable credentials for distributed digital identities, characterized in that: include: The user submits a webpage data authentication request to the Notary Committee, and the Notary Committee selects an authentication template that matches the webpage to be authenticated; the authentication template is generated by the Notary Committee based on the request data framework and the user's identity attributes; After receiving the webpage identity data authentication application sent by the user, the Notary Committee elects 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; Each member of the notary subcommittee 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, wherein the website server is used to provide a webpage 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 webpage request containing a webpage response of user identity information according to the request data frame in the authentication template; the user and the notary encrypt the webpage request according to the first shared session key share and the second shared session key share, and send the encrypted webpage request to the website server; and then the user, the notary, and the website server exchange data; 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. If the certificate is valid and the assertion certificate is correct, it 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 identities according to claim 1, characterized in that: The method for generating a verifiable credential for a distributed digital identity further includes: The notary committee generates an authentication template that matches 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 identities 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, specifically including: Each member of the notary committee uses his private key and the public seed generated in each election round to run a verifiable random function to generate a first verifiable random number and a corresponding certificate; The notary sub-committee is composed of members corresponding to the first verifiable random number within the set range.

4. The method for generating verifiable credentials for distributed digital identities according to claim 3, characterized in that: When the TLS protocol adopts the TLS 1.2 protocol, the user, the notary, and the website server perform a TLS protocol handshake through three-party negotiation, wherein 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: 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 based on the second random number, and sends the user a second website certificate chain, the first temporary public key in the first temporary public-private key pair, and a signature; 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 passing the verification, 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 verifies whether the second website certificate chain is valid and whether the second website certificate chain is identical to the first website certificate chain in the authentication template. If the second website certificate chain is valid and the second website certificate chain is identical to the first website certificate chain in the authentication template, a second temporary public-private key pair is generated according to a key exchange algorithm, and the second temporary public key in the second temporary public-private key pair is sent 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 based on 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 computation 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 identities according to claim 3, characterized in that: When the TLS protocol adopts the TLS 1.3 protocol, the user, the notary, and the website server perform a TLS protocol handshake through three-party negotiation, wherein 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: 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, 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 based on 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 a 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 verification, 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 computation protocol under a malicious model to output the user's first handshake key share and the notary's second handshake key share; 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 whether the second website certificate chain is identical to the first website certificate chain in the authentication template. If the second website certificate chain is invalid or the second website certificate chain is different from the first website certificate chain in the authentication template, the procedure terminates. 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 computation 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. The website server verifies the second Finished message. If the verification is successful, the TLS 1.3 protocol handshake is completed; otherwise, the program terminates.

6. The method for generating verifiable credentials for distributed digital identities according to claim 2, characterized in that: The user obtains a webpage request for a webpage response including user identity information according to the request data frame in the authentication template; the user and the notary party encrypt the webpage request according to the first shared session key share and the second shared session key share, and send the encrypted webpage request to the website server. Then, the user, the notary party, and the website server perform data exchange, specifically including: The user obtains a webpage request containing identity information in response to a webpage 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, the request, and the request response, and sends the commitment information including the encrypted web page request, the request response, and the commitment to a notary; After receiving the commitment information, the notary sends the second shared session key share to the user; The user obtains a session key based on 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 identities 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 notary party uses the first zero-knowledge proof evidence 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 the 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 identities 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 based on the globally unique string containing the key identity attribute in the authentication template, and forms a data block set from all data blocks in the decrypted request response that contain the globally unique string containing the key identity attribute; 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 included in the data block set, and that the assertion that the identity attribute data is completed in the complete string containing the identity attribute data 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 Public Committee, Certificate Distribution Committee and Website Server; The user submits a webpage identity data authentication application to the notary committee, and selects an authentication template from the notary committee that matches the webpage to be authenticated; the authentication template is generated by the notary committee based on the request data framework and the user's identity attributes; 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; Each member of the notary subcommittee 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; The user obtains a webpage request containing a webpage response of user identity information according to the request data frame in the authentication template; the user and the notary encrypt the webpage request according to the first shared session key share and the second shared session key share, and send the encrypted webpage request to the website server; and then the user, the notary, and the website server exchange data; 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