Verifiable claim processing method and processing device

Abstract

The present application provides a method and device for processing a verifiable statement. In the technical solution proposed in the present application, when a user uses a third-party application, he can send relevant information to the corresponding service provider through the end-side wallet according to the instruction information of the third-party application to apply for or present the corresponding verifiable statement. The service provider issues or verifies the verifiable statement based on the received information and sends the verification result to the third-party application, thereby ensuring that the third-party application will not access the user's information and improving the security of the user's information.

Description

Technical Field

[0001] The present application relates to the field of smart terminal technology, and in particular to a method and device for processing verifiable claims. Background Art

[0002] At present, when users use third-party applications (Application, APP), they need to fill in personal information, such as name, ID number, mobile phone number, etc. to register or verify login. This information will be retained on the APP server, resulting in the risk of leakage of users' personal information. Therefore, how to ensure the security of users' information when using APP has become a technical problem that needs to be solved urgently. Summary of the invention

[0003] The present application provides a method and device for processing verifiable declarations, which can ensure the security of user information when users use third-party APPs.

[0004] In a first aspect, the present application provides a method for processing a verifiable statement, including: a digital wallet obtains relevant information of a first user; the digital wallet sends the relevant information to a service provider, the relevant information is used to generate a target VC, and the target VC is a verification statement of the first user using a first business function through a third-party application.

[0005] Among them, a digital wallet refers to a software program located in a terminal device (such as a mobile phone or computer), which can realize online payment functions and can also be used to store the user's distributed identity (Decentralized Identifier, DID) information (such as private keys) and verifiable credentials (Verifiable Credential, VC) such as driver's licenses, health cards, and membership cards.

[0006] Service providers are divided into DID service providers and VC service providers. Among them, DID service providers are used to provide DID services, including the registration and issuance of DID, the issuance and verification methods of the public and private keys corresponding to the DID, and other related information queries. VC service providers are used to provide VC services, including the issuance and verification of VC.

[0007] When a user uses a third-party application, he or she needs to present the corresponding VC before using the functional services provided by the third-party application. If the user does not have the corresponding VC, he or she needs to apply for VC from the corresponding service provider.

[0008] Optionally, the user may send relevant information required to apply for VC to the service provider through the digital wallet to request the service provider to issue VC.

[0009] In this technical solution, the digital wallet sends the user's relevant information directly to the service provider without going through a third-party application, thereby improving the security of user information.

[0010] In combination with the first aspect, in a possible implementation, the service provider includes a basic service provider and a business service provider, and the target VC includes a first VC and a second VC; wherein the digital wallet sends relevant information of the first user to the service provider, including: the digital wallet sends business information required for the first user to use the first business function to the business service provider, and the business information is used for the business service provider to generate a first VC; the digital wallet sends personal information required for the first user to use the first business function to the basic service provider, and the personal information is used for the basic service provider to generate a second VC.

[0011] Among them, business service providers can be provided by application service providers, including business DID service providers and business VC service providers, which are used to provide business-related services to users based on their application information. Basic service providers are endorsed by authoritative institutions, including basic DID service providers and basic VC service providers, which are used to provide personal-related services to users based on their personal information.

[0012] Optionally, the user sends the relevant information required to apply for VC to the service provider through the digital wallet. In the process of requesting the service provider to issue VC, if the service provider includes a business service provider, the relevant information sent by the user to the business service provider may include the user's application information. If the service provider includes a basic service provider, the relevant information sent by the user to the basic service provider may include the user's personal information.

[0013] Among them, the VC issued by the service provider to the user can be saved in the digital wallet.

[0014] In this implementation, by stratifying service providers according to the importance of user information, the operating pressure of service providers is alleviated, and business service providers are prevented from accessing user personal information, thereby improving the security of user personal information.

[0015] In combination with the first aspect, in a possible implementation, the method includes: the digital wallet receives the first VC from the business service provider; the digital wallet receives the second VC from the basic service provider; the digital wallet sends a first verification request to the business service provider, the first verification request is used to request the business service provider to verify the first VC; and sends a second verification request to the basic service provider, the second verification request is used to request the basic service provider to verify the second VC.

[0016] In this implementation, after the service provider issues VC for the user, the issued VC can be returned to the digital wallet, and the digital wallet can present the issued VC to the service provider for verification.

[0017] If the service provider includes a business service provider, the digital wallet may present the business VC to the business service provider. If the service provider includes a basic service provider, the digital wallet may present the personal VC to the basic service provider.

[0018] In combination with the first aspect, in a possible implementation manner, the personal information is also used by the basic service provider to verify the second VC; wherein the method includes: the digital wallet receives the first VC from the business service provider, and the first VC is generated by the business service provider when the basic service provider successfully verifies the second VC; the digital wallet sends a first verification request to the business service provider, and the first verification request is used to request the business service provider to verify the first VC.

[0019] In this implementation, when the business service provider needs to verify the user's personal information during the process of issuing a business VC for the user, the business service provider can instruct the user to present the personal VC to the basic service provider. When the basic service provider successfully verifies the personal VC presented by the user, the business service provider will issue the personal VC to the user if the personal VC verification is successful.

[0020] In combination with the first aspect, in a possible implementation manner, the method further includes: the digital wallet receiving a verification response from the third-party application, the verification response being used to indicate whether the target VC is successfully verified.

[0021] In this implementation, after the service provider verifies the VC presented by the user, the verification result may be returned to the digital wallet.

[0022] Optionally, if the verification is successful, information indicating the verification success may be returned to the digital wallet; otherwise, information indicating that the verification failed or the presented VC does not meet the requirements may be returned.

[0023] In a second aspect, the present application provides a method for processing a verifiable statement, including: a service provider receives relevant information of a first user from a digital wallet, the relevant information is used to generate a target VC, and the target VC is a verification statement of the first user using a first business function through a third-party application; the service provider generates the target VC based on the relevant information.

[0024] In this technical solution, when a user needs to apply for VC from a service provider, the user sends the information required for applying for VC to the service provider through a digital wallet. After the basic service provider receives the relevant information required for applying for VC, it verifies the application information. If the verification is successful, VC is issued to the user.

[0025] As an example, before the service provider issues a VC for a user based on the filled-in information, the VC service provider may first verify whether the filled-in information meets the requirements, for example, whether the filled-in information is complete, etc., and issue the VC if the requirements are met.

[0026] In combination with the second aspect, in a possible implementation manner, the service provider is a business service provider, the relevant information includes business information required by the first user to use the first business function, and the target VC includes a first VC; the business service provider sends the first VC to the digital wallet; the business service provider receives a first verification request from the digital wallet, and the first verification request is used to request the business service provider to verify the first VC.

[0027] In this implementation, if the service provider is a business service provider, the relevant information sent by the user to the business service provider may include the user's application information. The business service provider issues a business VC for the user based on the application information sent by the user, and returns the issued business VC to the digital wallet for storage. The business service provider may also receive and respond to the verification request sent by the user. The verification request includes the business VC presented by the user.

[0028] In combination with the second aspect, in a possible implementation, the method further includes: the business service provider verifies the first VC; the business service provider sends a verification response to the third-party application or the digital wallet, and the verification response is used to indicate whether the first VC is successfully verified.

[0029] In this implementation, after verifying the service VC in the verification request sent by the user, the business service provider may return the verification result to the third-party application.

[0030] Optionally, after verifying the business VC in the verification request sent by the user, the business service provider may directly return the verification result to the digital wallet.

[0031] In combination with the second aspect, in a possible implementation, before the service provider receives relevant information of the first user from the digital wallet, the method also includes: the business service provider receives first configuration information from the third-party application, the first configuration information is used to indicate the business information required to generate the first VC and the verification method of the first VC; the business service provider sends first prompt information to the digital wallet, the first prompt information is used to instruct the user to enter the business information; wherein, the business service provider verifies the first VC, including: the business service provider verifies the first VC using the verification method.

[0032] In this implementation, before a third-party application provides functional services to users, it can communicate with the business service provider to register with the business service provider what kind of relevant information the business VC depends on, set the verification method of the business VC and / or register the callback interface of the verification result.

[0033] Among them, the relevant information that the business VC relies on can be understood as the application information required to generate or issue the business VC; the verification method of the business VC can be understood as the method of verifying whether the received business VC meets the requirements; the verification result can include verification success or verification failure; the callback interface of the verification result can be understood as the interface for the business service provider to indicate the verification result to the third-party application.

[0034] Exemplarily, when a third-party application requires a user to present a business VC, an instruction message may also be sent to the user. The instruction message includes the address of the business service provider. The user may apply for a business VC from the business service provider through the address in the instruction message. The business service provider instructs the user on the information required to fill in when applying for the business VC based on the information of the business VC registered by the third-party application, and issues the business VC.

[0035] Accordingly, when the user presents the service VC to the service provider through the address in the indication information, the service provider may verify the service VC presented by the user according to the service VC verification method set by the third-party application, and return the verification result.

[0036] In combination with the second aspect, in a possible implementation method, the verification method also includes verifying the first VC relying on the verification result of the second VC by the basic service provider, the second VC being a VC generated by the basic service provider based on the personal information required by the first user to use the first business function; wherein the verification of the first VC by the business service provider includes: the business service provider receiving a verification response of the second VC from the basic service provider, the verification response of the second VC being used to indicate whether the basic service provider has successfully verified the second VC; the business service provider verifies the first VC based on the verification response of the second VC.

[0037] In this implementation, before the business service provider issues a business VC that depends on the user's personal information to the user, it can communicate with the basic service provider to register with the basic service provider what kind of relevant information the business VC depends on, set the verification method of the personal VC and / or register the callback interface of the verification result.

[0038] Among them, the relevant information that the business VC relies on can be understood as the personal information required to generate or issue the business VC; the verification method of the personal VC can be understood as the method of verifying whether the received personal VC meets the requirements; the verification result can include verification success or verification failure; the callback interface of the verification result can be understood as the interface for the basic service provider to indicate the verification result to the business VC service provider.

[0039] Exemplarily, while the business VC service provider instructs the user on the information that needs to be filled in when applying for the business VC, the address of the basic service provider can also be sent to the user. The user can present the personal VC to the basic service provider through the address information. The basic service provider verifies the personal VC presented by the user according to the personal VC verification method set by the business service provider and returns the verification result.

[0040] In combination with the second aspect, in a possible implementation manner, the service provider is a basic service provider, the relevant information includes personal information required for the first user to use the first business function, and the target VC includes a second VC; the basic service provider sends the second VC to the digital wallet; the basic service provider receives a second verification request from the digital wallet, and the second verification request is used to request the basic service provider to verify the second VC; the basic service provider sends a verification response of the second VC to the digital wallet or business service provider, and the verification response is used to indicate whether the second VC is successfully verified.

[0041] In this implementation, if the service provider is a basic service provider, the relevant information sent by the user to the basic service provider may include the user's personal information. The basic service provider issues a personal VC for the user based on the personal information sent by the user, and returns the issued personal VC to the digital wallet for storage. The basic service provider can also receive and respond to the verification request sent by the user. The verification request includes the personal VC presented by the user.

[0042] Optionally, after verifying the personal VC in the verification request sent by the user through the digital wallet, the basic service provider may return the verification result to the business service provider.

[0043] Optionally, after verifying the personal VC in the verification request sent by the user through the digital wallet, the basic service provider may directly return the verification result to the digital wallet.

[0044] In combination with the second aspect, in a possible implementation, before the service provider receives relevant information of the first user from the digital wallet, the method also includes: the basic service provider receives second configuration information from the third-party application or business service provider, the second configuration information is used to indicate the personal information required to generate the second VC and the verification method of the second VC; the basic service provider sends second prompt information to the digital wallet, the second prompt information is used to instruct the user to enter the personal information; wherein, the basic service provider verifies the second VC, including: the basic service provider verifies the second VC using the verification method.

[0045] In this implementation, before the third-party application provides functional services to the user, it can communicate with the basic service provider to register with the basic service provider what kind of relevant information the personal VC depends on, set the verification method of the personal VC and / or register the callback interface of the verification result.

[0046] Among them, the relevant information that the personal VC relies on can be understood as the information required to generate or issue the personal VC; the verification method of the personal VC can be understood as the method of verifying whether the received personal VC meets the requirements; the verification result can include verification success or verification failure; the callback interface of the verification result can be understood as the interface for the business service provider to indicate the verification result to the third-party application.

[0047] The specific implementation method is similar to the communication between the third-party application and the business service provider, and will not be repeated here.

[0048] Accordingly, before the business service provider issues a business VC that depends on the user's personal information to the user, it can communicate with the basic service provider to register with the basic service provider what kind of personal information the business VC depends on, set the verification method of the personal VC and / or register the callback interface of the verification result.

[0049] Therefore, when the user presents the personal VC to the basic service provider, the basic service provider may verify the personal VC presented by the user according to the personal VC verification method set by the business service provider, and return the verification result.

[0050] In combination with the second aspect, in a possible implementation manner, the method further includes: the basic service provider receiving an information request from a trusted application, the information request being used to request personal information; and the basic service provider sending the personal information to the trusted application.

[0051] In this implementation, when a user violates the rules by making inappropriate comments while using a third-party application, the third-party application can send a request message to the trusted application to query the user's real-name information, and the request message contains evidence of the user's violation. After receiving the request message from the third-party application, the trusted application reviews the user's violation evidence. If it is determined that the user has violated the rules, it sends a request message to the basic service provider to obtain the user's real-name information. After the basic service provider retrieves the user's real-name information, it returns it to the third-party application through the trusted application. The third-party application can restrict the user's behavior based on the user's real-name information, thereby improving the level of supervision of third-party applications.

[0052] In a third aspect, the present application provides a processing device for verifiable claims, the device comprising modules for implementing the method in the first aspect or any one of the implementations thereof, and each module can be implemented in the form of hardware and / or software.

[0053] For example, the device may include: an acquisition module and a sending module. The acquisition module is used to acquire relevant information of the first user; the sending module is used to send the relevant information to the service provider, and the relevant information is used to generate a target VC, which is a verification statement of the first user using the first service function through a third-party application.

[0054] In a possible implementation, the sending module is specifically used to send the business information required by the first user to use the first business function to the business service provider, and the business information is used by the business service provider to generate a first VC; the sending module is also used to send the personal information required by the first user to use the first business function to the basic service provider, and the personal information is used by the basic service provider to generate a second VC.

[0055] In a possible implementation, the device may further include: a receiving module. The receiving module is used to receive the first VC from the business service provider; the receiving module is also used to receive the second VC from the basic service provider; the sending module is also used to send a first verification request to the business service provider, the first verification request is used to request the business service provider to verify the first VC; the sending module is also used to send a second verification request to the basic service provider, the second verification request is used to request the basic service provider to verify the second VC.

[0056] In a possible implementation, the receiving module is further used to receive the first VC from the business service provider, where the first VC is generated by the business service provider when the basic service provider successfully verifies the second VC; the sending module is further used to send a first verification request to the business service provider, where the first verification request is used to request the business service provider to verify the first VC.

[0057] In a possible implementation, the receiving module is further configured to receive a verification response from the third-party application, where the verification response is used to indicate whether the target VC is successfully verified.

[0058] In a fourth aspect, the present application provides a processing device for verifiable claims, the device comprising modules for implementing the method in the second aspect or any one of the implementations thereof, and each module can be implemented in the form of hardware and / or software.

[0059] For example, the device may include: a receiving module and a generating module. The receiving module is used to receive relevant information of the first user from the digital wallet, and the relevant information is used to generate a target VC, where the target VC is a verification statement of the first user using the first business function through a third-party application; and the generating module is used to generate the target VC based on the relevant information.

[0060] In a possible implementation, the device may further include: a sending module, which is used to send the first VC to the digital wallet; and a receiving module, which is further used to receive a first verification request from the digital wallet, wherein the first verification request is used to request the business service provider to verify the first VC.

[0061] In a possible implementation, the device may further include: a verification module. The verification module is used to verify the first VC; the sending module is also used to send a verification response to the third-party application or the digital wallet, and the verification response is used to indicate whether the first VC is successfully verified.

[0062] In a possible implementation, the receiving module is further used to receive first configuration information from the third-party application, where the first configuration information is used to indicate the business information required to generate the first VC and the verification method of the first VC; the sending module is further used to send first prompt information to the digital wallet, where the first prompt information is used to instruct the user to enter the business information; the verification module is specifically used to verify the first VC using the verification method.

[0063] In a possible implementation, the verification module is also used to verify the first VC relying on the verification result of the second VC by the basic service provider, where the second VC is a VC generated by the basic service provider based on the personal information required by the first user to use the first business function; the receiving module is also used to receive a verification response of the second VC from the basic service provider, where the verification response of the second VC is used to indicate whether the basic service provider has successfully verified the second VC; the verification module is specifically used to verify the first VC based on the verification response of the second VC.

[0064] In a possible implementation, the sending module is further used to send the second VC to the digital wallet; the receiving module is further used to receive a second verification request from the digital wallet, the second verification request being used to request the basic service provider to verify the second VC; the sending module is further used to send a verification response of the second VC to the digital wallet or the business service provider, the verification response being used to indicate whether the second VC is successfully verified.

[0065] In a possible implementation, the receiving module is further used to receive second configuration information from the third-party application or business service provider, where the second configuration information is used to indicate the personal information required to generate the second VC and the verification method of the second VC; the sending module is further used to send second prompt information to the digital wallet, where the second prompt information is used to instruct the user to enter the personal information; and the verification module is further used to verify the second VC using the verification method.

[0066] In a possible implementation, the receiving module is further configured to receive an information request from a trusted application, where the information request is used to request the personal information; and the sending module is further configured to send the personal information to the trusted application.

[0067] In a fifth aspect, the present application provides a processing device for verifiable declarations, comprising at least one processor and a communication interface, wherein the communication interface and the at least one processor are interconnected via a line, and the at least one processor is used to run a computer program or instructions to execute the method described in the first aspect or any possible implementation method thereof.

[0068] In a sixth aspect, the present application provides a device comprising at least one processor and a communication interface, wherein the communication interface and the at least one processor are interconnected via a line, and the at least one processor is used to run a computer program or instructions to execute the method described in the second aspect or any possible implementation method thereof.

[0069] In a seventh aspect, the present application provides a computer-readable medium storing a program code for execution by a device, wherein the program code includes a method for executing the method described in the first aspect, the second aspect, or any possible implementation method thereof.

[0070] In an eighth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the method described in the first aspect, the second aspect, or any possible implementation thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] Figure 1 A flowchart of a method for a user to log in to a third-party APP and verify the user's identity through a digital wallet;

[0072] Figure 2 A schematic diagram of the structure of a service system provided for one embodiment of the present application;

[0073] Figure 3 A flowchart of a method for processing VC provided by an embodiment of the present application;

[0074] Figure 4 A schematic diagram of a third-party application registration process provided for an embodiment of the present application;

[0075] Figure 5 A schematic diagram of the process of applying for and verifying a VC provided in one embodiment of the present application;

[0076] Figure 6 A schematic diagram of a VC application and verification process provided by another embodiment of the present application;

[0077] Figure 7 A flowchart of a method for processing VC provided in yet another embodiment of the present application;

[0078] Figure 8 A schematic diagram of a process for registering a business service provider according to an embodiment of the present application;

[0079] Fig. 9 A schematic diagram of a process for a business service provider to issue a business VC that relies on personal information, provided in one embodiment of the present application;

[0080] Fig.10A schematic diagram of a process for a business service provider to issue a business VC that relies on personal information, provided in yet another embodiment of the present application;

[0081] Fig.11 A schematic diagram of a process for obtaining user real-name information provided in an embodiment of the present application;

[0082] Fig.12 A schematic diagram of a process for obtaining user real-name information provided in yet another embodiment of the present application;

[0083] Fig.13 A schematic diagram of a structure of a device for processing verifiable claims provided by one embodiment of the present application;

[0084] Fig.14 A structural schematic diagram of a device for processing verifiable claims provided in yet another embodiment of the present application;

[0085] Fig.15 A structural diagram of a device for processing verifiable claims provided in accordance with yet another embodiment of the present application.

[0086] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0087] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0088] When using an APP on a terminal device, you often need to log in or even authenticate your identity. One method for logging into an APP is as follows: the terminal device records user information, and when logging into the APP, you directly call this user information to log in; further, you can call this user information for identity authentication. Among them, the functional module that records user information can be called a digital wallet, and the logged-in APP can be called a third-party APP.

[0089] Figure 1 A flowchart of a method for a user to log in to a third-party APP and verify the user's identity through a digital wallet.

[0090] S101, the client wallet sends a DID request to the DID service provider, where the DID request carries first user information.

[0091] An end-to-end wallet is an example of a digital wallet. It can be a software program located in a terminal device (such as a mobile phone or computer) that can implement online payment functions and can also be used to store users' DID information (such as private keys) and verifiable credentials (VC) such as driver's licenses, health cards, and membership cards.

[0092] DID is a distributed identity (Decentralized Identifier, DID), which can be used to identify the identity of an entity. Entities can include individuals, organizations, etc. An entity can have multiple DIDs. For example, an individual's DID can be a DID as a mother, a DID as a photography enthusiast, and a DID as an engineer, but a DID can only correspond to one entity. In addition, each DID corresponds to a DID document, which is used to store information such as the public key and encryption method of the DID.

[0093] DID service providers are used to provide DID services. DID services include the registration and issuance of DIDs, the issuance of public and private keys corresponding to DIDs, and the query of related information such as verification methods.

[0094] For example, the end-side wallet sends a DID request to the DID service provider. The DID request carries some user information recorded in the end-side wallet. The user information used to apply for the DID can be called the first user information. After receiving the DID request, the DID service provider issues a DID to the user, which is used to identify the user's identity.

[0095] It is understandable that when the DID service provider issues the first DID, it also generates a pair of public and private keys corresponding to the first DID. This pair of public and private keys is used to verify the identity of the first DID holder.

[0096] S102, the DID service provider returns the first DID issued for the user and the private key information corresponding to the first DID to the end-side wallet.

[0097] The public key corresponding to the first DID may be stored in a place accessible to the DID service provider. As an example, the public key corresponding to the first DID may be stored in a distributed system.

[0098] After receiving the first DID and the corresponding private key information, the end-side wallet stores the first DID and the corresponding private key information.

[0099] S103: The client wallet sends a login request to the third-party APP, where the login request carries the first DID.

[0100] The third-party APP can be an APP located in the terminal device, an Internet (World Wide Web, Web) application, etc. The third-party APP supports users to log in with a DID identity.

[0101] S104, the third-party APP requests the DID resolution service provider to resolve the address of the issuer of the first DID. The DID resolution service provider is used to resolve the address of the issuer of the DID according to the DID.

[0102] For example, after receiving the login request, the third-party APP initiates a resolution request to the DID resolution service provider, which carries the user's first DID to obtain the address of the issuer of the first DID. It can be understood that the first DID issuer is the DID service provider in S101 and S102.

[0103] S105, the DID resolution service returns the address of the issuer of the first DID to the third-party APP.

[0104] The address received by the third-party APP from the DID resolution service provider is the address of the DID service provider in S101 and S102.

[0105] S106, the third-party APP requests the public key corresponding to the first DID from the DID service provider.

[0106] For example, the third-party APP sends a public key request message to the DID service provider, where the message carries the first DID, to obtain the public key of the first DID.

[0107] S107, the DID service provider returns the public key of the first DID to the third-party APP.

[0108] As an example, when the public key corresponding to the first DID is stored in a distributed system, the DID service provider can obtain the public key corresponding to the first DID from the distributed system.

[0109] S108, the third-party APP generates a verification value and encrypts the verification value using the public key corresponding to the first DID to obtain the encrypted verification value.

[0110] For example, the third-party APP generates a random value as a verification value used for login, and encrypts the verification value using the public key corresponding to the first DID to obtain the encrypted verification value.

[0111] S109, the third-party APP sends the encrypted verification value to the client wallet.

[0112] S110, the end-side wallet uses the private key corresponding to the first DID to decrypt the encrypted verification value, and returns the decrypted verification value to the third-party APP.

[0113] S111, the third-party APP verifies the verification value from the end-side wallet.

[0114] For example, the third-party APP determines whether the verification value received from the end-side wallet is consistent with the unencrypted verification value generated by itself in S108.

[0115] S112, the third-party APP returns the login result to the client wallet.

[0116] For example, if the verification value received from the end-side wallet is consistent with the unencrypted verification value generated by itself, a successful login is returned; otherwise, an incorrect verification value or a failed login may be returned.

[0117] S113, the client wallet sends a VC request to the third-party APP.

[0118] VC is a digital credential. DID holders can use VC to prove some of their attributes to other entities. For example, they can use VC to prove that their academic qualifications are credible.

[0119] When using some functions in a third-party APP, users need to show the corresponding VC to the third-party APP. For example, when a user performs a recharge service in a third-party APP, he / she needs to show the relevant proof of adulthood to the third-party APP. If there is no VC, you need to apply for VC.

[0120] S114, the third-party APP forwards the VC request to the VC service provider.

[0121] In this embodiment, the VC service provider and the DID service provider may be collectively referred to as a service provider.

[0122] S115, the VC service provider returns the information required for applying for VC to the third-party APP.

[0123] S116, the third-party APP forwards the information required for applying for VC to the client wallet.

[0124] S117, the client wallet receives the information filled in by the user.

[0125] The information filled in by the user may be referred to as second user information.

[0126] S118, the client wallet sends the second user information required for applying for VC to the third-party APP.

[0127] S119, the third-party APP forwards the second user information to the VC service provider.

[0128] S120, the VC service provider verifies the second user information and issues a VC.

[0129] For example, if the second user information received by the VC service provider meets the requirements, the verification is qualified and a corresponding first VC is generated.

[0130] S121, the VC service provider sends a first VC to a third-party APP.

[0131] S122, the third-party APP forwards the first VC to the end-side wallet. After receiving the first VC, the end-side wallet stores the first VC.

[0132] S123, the client wallet presents the first VC to the third-party APP.

[0133] For example, when a user uses a third-party APP through an end-side wallet, the end-side wallet can send a first VC to the third-party APP to verify the user's identity.

[0134] S124, the third-party APP forwards the first VC to the VC service provider.

[0135] S125: The VC service provider verifies the first VC.

[0136] S126, the VC service provider sends the verification result to the third-party APP.

[0137] S127, the third-party APP forwards the verification result to the client wallet.

[0138] Furthermore, if the verification result is successful, the third-party APP provides corresponding functions to the user.

[0139] From the above content, it can be seen that the end-side wallet needs to apply for VC and present VC for users through a third-party APP, which will increase the risk of user information leakage on the third-party APP, thereby reducing the security of user information.

[0140] In response to the above problems, this application proposes a new technical solution to reduce the risk of user information leakage on third-party APPs and improve the security of user information.

[0141] Figure 2 This is a schematic diagram of the structure of a service system provided by an embodiment of the present application. Figure 2 As shown, the service system 20 includes: a terminal wallet 21, a third-party application 22, a service provider 23, a DID resolution service provider 24 and a distributed system 25. The service provider 23 may include a basic service provider 231 and a business service provider 232. The basic service provider 231 may include a basic DID service provider 231-1 and a basic VC service provider 231-2. The business service provider 232 may include a business DID service provider 232-1 and a business VC service provider 232-2.

[0142] The end-side wallet 21 can be an APP on the mobile phone or a software application on the computer. The end-side wallet 21 can be used to store user information, such as the user's DID identity information (and corresponding private key information), VC certificates issued by various VC issuers, etc.

[0143] As an example, the user information may include information such as a graduation certificate, a driver's license, or an ID card number.

[0144] The third-party application 22 can be an APP or web application on a mobile phone or computer. The third-party application 22 can support users to log in through DID, and verify the user's DID when the user logs in through DID to ensure the legitimacy of the identity.

[0145] When the third-party application 22 provides functional services to users, all or part of the functions require VC verification of the user, and the user is allowed to use them only if the verification is successful.

[0146] The service provider 23 is used to provide DID services and VC services. It can be understood that in this embodiment, the service provider 23 is divided into a basic service provider 231 and a business service provider 232 for only an example.

[0147] In some other examples, the service providers 23 may not distinguish between the basic service providers 231 and the business service providers 232. For example, the service providers 23 include DID service providers and VC service providers.

[0148] The basic service provider 231 may be endorsed by an authority to provide DID services and VC services to users based on the user's personal information. An example of an authority is an education system.

[0149] As an example, the user information based on which the basic service provider 231 is based may include important information of the user, which may also be understood as private information or information that one does not want to disclose. For example, the important information may include the user's ID card information, address, education information, etc.

[0150] The business service provider 232 may be provided by an application service provider to provide DID services and VC services to users based on user information. As an example, the user information based on which the business service provider is based may include relatively unimportant information. For example, the user information based on which the business service provider is based may include information such as the user's age and gender.

[0151] The DID resolution service provider 24 provides DID resolution services. For example, the DID resolution service provider 24 can resolve the DID to obtain the address of the DID service provider that issued the DID.

[0152] The distributed system 25 may be used to store a DID document, which may include a public key and a verification method that are mapped to the user's DID. Optionally, the DID document may also store a mapping relationship between the DID and the DID service provider.

[0153] Optionally, the distributed system 25 may use blockchain technology or a distributed file system to store DID documents.

[0154] Optionally, the components in the verification system 20 may exchange information through a unified SDK or API interface.

[0155] As an example, the address mentioned in the service system of this embodiment may be a Uniform Resource Locator (URL), which is also called a web page address or URL for short.

[0156] Figure 3 The following is a flow chart of a method for processing VC provided by an embodiment of the present application. Figure 3 As shown, in S31, the third-party application communicates with the VC service provider, registers with the service provider what kind of relevant information the VC depends on, sets the verification method of the VC and / or registers a callback interface for the verification result.

[0157] Among them, the relevant information that VC relies on can be understood as the information required to generate or issue VC; the verification method of VC can be understood as the method of verifying whether the received VC meets the requirements; the verification result can include verification success or verification failure; the callback interface of the verification result can be understood as the interface for the service provider to indicate the verification result to the third-party application.

[0158] In some examples, VC service providers may include business VC service providers and infrastructure VC service providers.

[0159] If the VC service provider includes a business VC service provider, the relevant information may optionally include business information. Accordingly, the third-party application indicates to the business VC service provider the business information required by the business VC, the verification method of the business VC, and the callback interface of the verification result of the business VC.

[0160] If the VC service provider includes the basic VC service provider, the relevant information may optionally include personal information. Accordingly, the third-party application indicates to the basic VC service provider the personal information required for the personal VC, the verification method of the personal VC, and the callback interface of the verification result of the personal VC.

[0161] In S32, the client-side wallet sends the relevant information required by the VC to the VC service provider.

[0162] If the VC service provider includes a business VC service provider, optionally, the end-side wallet sends the business information required by the business VC to the business VC service provider.

[0163] If the VC service provider includes a basic VC service provider, optionally, the client-side wallet sends personal information required for the personal VC to the basic VC service provider.

[0164] In S33, the VC service provider issues VC to the end-side wallet.

[0165] If the VC service provider includes a business VC service provider, optionally, the business VC service provider issues a business VC for the user corresponding to the end-side wallet based on the business information.

[0166] If the VC service provider includes a basic VC service provider, optionally, the basic VC service provider issues a personal VC for the user corresponding to the end-side wallet based on the personal information.

[0167] In S34, the third-party application instructs the end-side wallet to present VC.

[0168] In S35 , the client-side wallet sends the VC to the VC service provider, requesting the VC service provider to verify the VC.

[0169] If the VC service provider includes a business VC service provider, optionally, the end-side wallet sends the business VC to the business VC service provider, and the business VC service provider verifies the business VC sent by the end-side wallet based on the verification method registered by the third-party application.

[0170] If the VC service provider includes a basic VC service provider, optionally, the end-side wallet sends the personal VC to the basic VC service provider, and the basic VC service provider verifies the personal VC sent by the end-side wallet based on the verification method registered by the third-party application.

[0171] In S36 , the VC service provider sends the VC verification result to the third-party application.

[0172] If the VC service provider includes a business VC service provider, optionally, the business VC service provider indicates the business VC verification result to the third-party application according to a callback interface of the business VC verification result set by the third-party application.

[0173] If the VC service provider includes a basic VC service provider, optionally, the basic VC service provider indicates the verification result of the personal VC to the third-party application according to a callback interface of the verification result of the personal VC set by the third-party application.

[0174] In S37, the third-party application sends the verification result of the VC to the end-side wallet.

[0175] As an example, the verification result of the VC may include the verification result of the business VC and the verification result of the personal VC.

[0176] Optionally, in some embodiments of the present application, part or all of the relevant information of VC dependency, VC verification method and verification result callback interface may be pre-set on the VC service provider instead of being indicated by a third-party application.

[0177] Optionally, in some embodiments of the present application, the third-party application may not need to set a callback interface for the verification result at the VC service provider. In this embodiment, the VC service provider may not send the verification result directly to the third-party application through the callback interface.

[0178] Optionally, in some embodiments of the present application, the business VC service provider and the basic VC provider may be the same provider.

[0179] Optionally, before the third-party application communicates with the VC service provider, the third-party application and / or the VC service provider may first apply for a DID and establish a trust channel based on the DID. In this way, on the one hand, the communication security between the third-party application and the VC service provider can be improved, and on the other hand, login-free communication can be achieved.

[0180] Combine the following Figure 4 , Figure 5 and Figure 6 , a schematic flowchart of a method for a third-party application and a VC service provider to perform VC processing when applying for a DID and establishing a mutual trust channel based on the DID is introduced.

[0181] Figure 4 A schematic diagram of a third-party application registration process provided by an embodiment of the present application. Figure 4 As shown, it includes the process of each role registering DID and third-party applications registering VC-related content with the VC service provider.

[0182] S41a, the DID service provider registers a DID for itself.

[0183] Before issuing DIDs to other entities, the DID service provider can first register a DID for itself so that when the DID resolution service provider resolves the DID of other entities, it can determine the issuance address of the other entity's DID based on the DID of the DID service provider, that is, the address of the DID service provider that issued the DID to the other entity.

[0184] Among them, the DID service provider can be a basic DID service provider or a business DID service provider.

[0185] S41b, the VC service provider applies to the DID service provider for DID registration.

[0186] S41c, the DID service provider returns the DID and private key issued by the DID service provider to the VC service provider.

[0187] In the case where the VC service provider includes a business VC service provider and a basic VC service provider, the DID service provider may optionally include a business DID service provider and a basic DID service provider. In this case, the basic DID service provider may issue a DID and a private key for the basic VC service provider, and the business DID service provider may issue a DID and a private key for the business VC service provider.

[0188] S41d, the third-party application applies to the DID service provider for DID registration.

[0189] S41e, the DID service provider returns the DID and private key issued by the DID service provider to the third-party application to the third-party application.

[0190] In the case where the VC service provider includes a business VC service provider and a basic VC service provider, optionally, the business DID service provider may issue a DID and a private key for a third-party application.

[0191] S42a, the third-party application sends a channel establishment request message and signature information of the channel establishment request message to the VC service provider. The signature information of the channel establishment request message is obtained by signing the private key of the third-party application. The channel establishment request message includes the DID of the third-party application.

[0192] For example, the third-party application signs the channel establishment request information with the private key corresponding to its own DID, and sends the signature information, DID and channel establishment request information together to the VC service provider to request to establish a mutual trust channel with the VC service provider.

[0193] Among them, VC service providers may include basic VC service providers and business VC service providers.

[0194] S42b, the VC service provider requests the DID resolution service provider to resolve the DID of the third-party application.

[0195] After receiving the channel establishment request information sent by the third-party application, the VC service provider sends a DID resolution request information to the DID resolution service provider, and the DID resolution request information carries the DID of the third-party application to obtain the address of the issuer of the DID of the third-party application.

[0196] S42c, the DID resolution service returns the address of the issuer of the DID of the third-party application to the VC service provider.

[0197] S42d, the VC service provider requests the public key of the third-party application from the DID service provider based on the address of the issuer.

[0198] For example, the VC service provider can determine that the issuer is the aforementioned DID service provider based on the address returned by the DID resolution service provider, and send a public key request message to the DID service provider, which carries the DID of the third-party application to obtain the public key corresponding to the DID of the third-party application.

[0199] S42e, the DID service provider returns the public key of the third-party application to the VC service provider.

[0200] For example, after receiving the public key request information sent by the VC service provider, the DID service provider can obtain the DID document associated with the DID from the distributed system according to the DID of the third-party application, and obtain the public key corresponding to the DID from the DID document.

[0201] S42f, the VC service provider uses the public key of the third-party application to verify the signature information of the channel establishment request information.

[0202] For example, the VC service provider uses the public key of the third-party application to sign the channel establishment request information, and compares the signature with the signature information received from the third-party application; if they are consistent, it can be determined that the signature information is successfully signed, otherwise it can be determined that the signature information verification fails.

[0203] S42g: The VC service provider indicates to the third-party application that a trustworthy communication channel has been established between the VC service provider and the third-party application.

[0204] After this step is executed, it indicates that the communication channel between the third-party application and the VC service provider is mutually trustworthy.

[0205] S43a, the third-party application indicates to the VC service provider the relevant information required by the VC, and sets a verification method for the VC.

[0206] Optionally, the VC may be a VC required for using a corresponding business function through a third-party application.

[0207] For example, when a third-party application provides a user with a function that is only available to members, the user is required to present a member certificate. In this example, the VC is a member VC, the relevant information is the relevant information that the user needs to provide to register for a member VC, and the VC verification method is the method of verifying whether the VC provided by the user is a member VC of the third-party application.

[0208] S43b, the VC service provider returns the setting result to the third-party application.

[0209] For example, after the VC service provider successfully records the relevant information required by the VC and the verification method of the VC, it can return indication information of successful setting to the third-party application.

[0210] S43c, the third-party application registers the callback interface of the VC verification result with the VC service provider.

[0211] For example, after the third-party application registers the relevant information required by the VC and the verification method of the VC with the VC service provider, the callback interface can be set so that the VC service provider returns the verification result through the agreed callback interface, thereby ensuring that the third-party application can reliably and correctly obtain the verification result.

[0212] S43d, the VC service provider returns the setting result to the third-party application.

[0213] For example, after the callback interface of the VC verification result is successfully recorded on the VC service provider, indication information of successful setting may be returned to the third-party application.

[0214] Figure 5 The following is a flow chart of VC application and verification provided by one embodiment of the present application. Figure 5 As shown in the figure, it includes the process of VC issuance and VC verification. Figure 4 The process shown is then executed Figure 5 The process in .

[0215] S51a, the third-party application sends an instruction message to the end-side wallet, where the instruction message is used to instruct the end-side wallet to present the VC, and the instruction message carries the address of the VC service provider.

[0216] If the VC service provider includes a business VC service provider, optionally, the third-party application indicates to the end-side wallet that the presented VC includes a business VC, and the address carried in the indication information includes the address of the business VC service provider.

[0217] If the VC service provider includes the basic VC service provider, optionally, the third-party application indicates to the end-side wallet that the presented VC includes a personal VC, and the address carried in the indication information includes the address of the basic VC service provider.

[0218] S51b, the client wallet obtains the address of the VC service provider.

[0219] For example, the client-side wallet obtains the address of the VC service provider from the instruction information of the third-party application.

[0220] If the client wallet has not applied for the VC, the VC application process is triggered. Accordingly, the client wallet applies for the VC from the corresponding VC service provider.

[0221] S51c, the client wallet sends the VC request information and the signature of the VC request information to the VC service provider.

[0222] Among them, the signature of the VC request information can be obtained through the private key signature corresponding to the user DID of the end-side wallet, and the VC request information contains the user DID.

[0223] If the VC service provider includes a business VC service provider, optionally, the end-side wallet sends VC request information and a signature of the VC request information to the business VC service provider based on the address indicated by the third-party application, and the VC request information is used to request the business VC.

[0224] If the VC service provider includes a basic VC service provider, optionally, the client-side wallet sends VC request information and a signature of the VC request information to the basic VC service provider based on the address indicated by the third-party application, and the VC request is used to request personal VC.

[0225] S51d, the VC service provider requests the DID resolution service provider to resolve the user DID.

[0226] After receiving the VC application request information sent by the client wallet, the VC service provider sends a DID resolution request information to the DID resolution service provider. The DID resolution request information carries the user's DID to obtain the address of the issuer of the user's DID.

[0227] S51e, the DID resolution service returns the address of the issuer of the user's DID to the VC service provider.

[0228] S51f, the VC service provider requests the public key of the user's DID from the DID service provider based on the address of the issuer.

[0229] For example, the issuer of the user DID is the DID service provider, and the VC service provider obtains the public key of the user DID from the DID service provider.

[0230] For example, the VC service provider determines the address of the DID service provider based on the address returned by the DID resolution service provider, and sends a public key request message to the DID service provider. The public key request message is used to obtain the public key of the user DID, and the request message carries the user DID.

[0231] S51g, the DID service provider returns the public key of the user DID to the VC service provider.

[0232] For example, after receiving the public key request information sent by the VC service provider, the DID service provider can obtain the DID document associated with the DID from the distributed system according to the user's DID, and obtain the public key corresponding to the DID from the DID document.

[0233] S51h, the VC service provider uses the public key of the user DID to verify the signature of the VC request information.

[0234] For example, the VC provider uses the public key of the user's DID to sign the VC request information, and compares the signature with the signature received from the end-side wallet. If they are consistent, it can be determined that the verification is successful, otherwise it can be determined that the verification has failed.

[0235] S51i, the VC service provider instructs the end-side wallet to fill in the information required to apply for VC.

[0236] After the signature verification of the VC request information is successful, the VC service provider will return the instructions on what information needs to be filled in when applying for VC to the client wallet.

[0237] S51j, the client wallet sends the information filled in for applying for VC and the signature of the information to the VC service provider, and the information also includes the user DID.

[0238] For example, the end-side wallet uses the private key of the user's DID to sign the filled-in information, and then sends the signature together with the information to the VC service provider.

[0239] S51k, the VC service provider requests the DID resolution service provider to resolve the user DID.

[0240] S511, the DID resolution service returns the address of the issuer of the user's DID to the VC service provider.

[0241] S51m, the VC service provider requests the public key of the user DID from the DID service provider based on the address of the issuer.

[0242] S51n, the DID service provider returns the public key of the user DID to the VC service provider.

[0243] Among them, S51k to S51n can refer to S51d to S51g, and will not be repeated here.

[0244] S51o, the VC service provider uses the public key of the user's DID to verify the signature of the information filled in the VC application and issues the VC.

[0245] The signature verification method in this step can refer to S51h, which will not be described here. When the signature verification is successful, the VC service provider issues a VC to the user based on the information filled in by the user.

[0246] As an example, before the VC service provider issues VC to the user based on the filled-in information, the VC service provider may first verify whether the filled-in information meets the requirements, for example, whether the filled-in information is complete, etc., and issue the VC if the requirements are met.

[0247] S51p, the VC service provider sends the issued VC to the end-side wallet.

[0248] The above process is the process of the VC service provider issuing VC for the end-side wallet. The following describes the process of the end-side wallet presenting VC and the VC service provider verifying VC.

[0249] S52a, the client wallet sends the VC and the VC's signature to the VC service provider.

[0250] For example, before a user wants to use some functions of a third-party application through the end-side wallet, he or she can present the VC to the VC service provider.

[0251] Among them, the signature of VC can be obtained by signing with the private key of the user DID. When the end-side wallet sends VC and VC's signature, it also sends the user DID.

[0252] S52b, the VC service provider requests the DID resolution service provider to resolve the user DID.

[0253] S52c, the DID resolution service returns the address of the issuer of the user's DID to the VC service provider.

[0254] S52d, the VC service provider requests the DID service provider to obtain the public key of the user's DID based on the address of the issuer.

[0255] S52e, the DID service provider returns the public key of the user DID to the VC service provider.

[0256] S52f, the VC service provider verifies the signature of the VC using the public key of the user DID.

[0257] Among them, S52b to S52f can refer to S51k to S51o, which will not be repeated here.

[0258] S52g, the VC service provider verifies the VC.

[0259] The VC service provider verifies the VC according to the VC registered by the third-party application and the verification method corresponding to the VC.

[0260] S52h, the VC service provider returns the VC verification result to the third-party application.

[0261] The VC service provider sends the VC verification result to the third-party application according to the callback interface of the VC verification result registered by the third-party application.

[0262] The VC service provider signs the verification result using its own DID private key.

[0263] S52i, the third-party application returns the VC verification result to the end-side wallet.

[0264] The third-party application returns the VC verification result to the client wallet. If the verification is successful, the user can use the functional services provided by the third-party application normally.

[0265] Combine the following Figure 6 A VC processing method for VC application and verification provided by yet another embodiment of the present application is introduced. Figure 6 In the process shown, the VC service provider does not return the verification result to the third-party application through the callback interface, but returns the verification result to the end-side wallet by signing the verification result.

[0266] For example, Figure 6 A schematic diagram of the process of applying for and verifying a VC provided in yet another embodiment of the present application. Figure 6 The implementation of S51a to S52g in can refer to Figure 5 S51a to S52g in the above are not described in detail here. Optionally, when executing Figure 6 The steps in Figure 4 Steps in .

[0267] S62h, the VC service provider returns the VC verification result to the end-side wallet.

[0268] For example, after the VC service provider verifies the VC presented by the end-side wallet, it signs the verification result with its own DID private key and returns the verification result and signature to the end-side wallet.

[0269] S62i, the end-side wallet presents the VC verification result and the signature of the verification result to the third-party application.

[0270] When a third-party application requires the user to present VC, the user can send the VC verification result and corresponding signature to the third-party application through the client-side wallet.

[0271] S62j, the third-party application requests the DID resolution service provider to resolve the DID of the VC service provider.

[0272] S62k, the DID resolution service returns the address of the issuer of the DID of the VC service provider to the third-party application.

[0273] S621, the third-party application requests the DID service provider to obtain the public key of the VC service provider DID based on the address of the issuer.

[0274] S62m, the DID service provider returns the public key of the DID of the VC service provider to the third-party application.

[0275] S62n, the third-party application verifies the signature of the verification result of the VC using the public key of the DID of the VC service provider.

[0276] S62k, the third-party application returns the verification result to the client wallet.

[0277] If the third-party application successfully verifies the signature of the VC verification result, the VC verification result can be sent to the end-side wallet, and the user can use the functional services provided by the third-party application normally.

[0278] Figure 6 In the method shown, after the VC service provider verifies the VC presented by the user, it can sign the verification result with its own DID private key and return it directly to the end-side wallet. When a third-party application requires the user to present the corresponding VC, the user can directly present the verification result with the signature of the VC service provider to the third-party application through the end-side wallet, and the third-party application verifies the verification result, thereby ensuring that the user can normally use the functional services provided by the third-party application.

[0279] Depend on Figure 6 From the content, it can be seen that in this method, the third-party application does not need to register the callback interface with the corresponding VC service provider, thus saving resources.

[0280] Figure 7 A flowchart of a method for processing VC provided by another embodiment of the present application is shown below. Figure 7 As shown, in S71, the business VC service provider communicates with the basic VC service provider, registers with the basic VC service provider what kind of related information the business VC depends on, sets the verification method of the personal VC and / or registers the callback interface of the verification result.

[0281] Among them, the relevant information that the business VC relies on can be understood as the personal information required to generate or issue the business VC; the verification method of the personal VC can be understood as the method of verifying whether the received personal VC meets the requirements; the verification result can include verification success or verification failure; the callback interface of the verification result can be understood as the interface for the basic VC service provider to indicate the verification result to the business VC service provider.

[0282] Accordingly, the business VC service provider indicates to the basic VC service provider the personal information required by the business VC, the verification method of the personal VC, and the callback interface of the verification result of the personal VC.

[0283] In S72, the end-side wallet sends the business information required by the business VC to the business VC service provider.

[0284] In S73, the business VC service provider instructs the end-side wallet to present the verification result of the personal VC.

[0285] In S74, the end-side wallet sends the personal VC to the basic VC service provider, requesting the basic VC service provider to verify the personal VC.

[0286] Among them, the end-side wallet sends personal VC to the basic VC service provider, and the basic VC service verifies the personal VC sent by the end-side wallet based on the verification method registered by the business VC service provider.

[0287] In S75, the basic VC service provider sends the verification result of the personal VC to the business VC service provider.

[0288] In S76, the business VC service provider issues a business VC to the end-side wallet.

[0289] The basic VC service provider indicates the verification result of the personal VC to the business VC service provider according to the callback interface of the verification result of the personal VC set by the business VC service provider.

[0290] Optionally, in some embodiments of the present application, part or all of the relevant information on which the business VC depends, the verification method of the personal VC and the callback interface of the verification result may be pre-set on the basic VC service provider, rather than indicated by the business VC service provider.

[0291] Optionally, in some embodiments of the present application, the business VC service provider may not need to set a callback interface for the verification result at the basic VC service provider. In this embodiment, the basic VC service provider may not send the verification result directly to the end-side wallet through the callback interface.

[0292] Optionally, before the business VC service provider communicates with the basic VC service provider, the business VC service provider and / or the basic VC service provider may first apply for a DID and establish a trust channel based on the DID. In this way, on the one hand, the communication security between the business VC service provider and the VC service provider can be improved, and on the other hand, login-free communication can be achieved.

[0293] Combine the following Figure 8 , Fig. 9 and Fig.10 , a schematic flowchart of a method for a business VC service provider and a basic VC service provider to perform VC processing when applying for a DID and establishing a mutual trust channel based on the DID is introduced.

[0294] Figure 8 A flowchart of a business service provider registration process provided by an embodiment of the present application. Figure 8 As shown, it includes the process of each role registering DID and the business VC service provider registering personal VC related content with the basic VC service provider.

[0295] S81a, the business DID service provider registers a DID for itself.

[0296] S81b, the business VC service provider applies to the business DID service provider for DID registration.

[0297] S81c, the business DID service provider returns the DID and private key issued by the business DID service provider to the business VC service provider.

[0298] S81d, the basic DID service provider registers a DID for itself.

[0299] S81e, the basic VC service provider applies to the basic DID service provider for DID registration.

[0300] S81f, the basic DID service provider returns the DID and private key issued by the basic DID service provider to the basic VC service provider.

[0301] S82a, the business VC service provider sends a channel establishment request message and a signature of the channel establishment request message to the basic VC service provider. The signature of the channel establishment request message is obtained by signing with the private key of the business VC service provider. The channel establishment request message includes the DID of the business VC service provider.

[0302] For example, the business VC service provider signs the channel establishment request information using the private key corresponding to its own DID, and sends the signature information, DID and channel establishment request information together to the basic VC service provider to request the establishment of a mutual trust channel with the basic VC service provider.

[0303] S82b, the basic VC service provider requests the DID resolution service provider to resolve the DID of the business VC service provider.

[0304] After receiving the channel establishment request information sent by the business VC service provider, the basic VC service provider sends a DID resolution request information to the DID resolution service provider. The DID resolution request information carries the DID of the business VC service provider to obtain the address of the issuer of the DID of the business VC service provider.

[0305] S82c, the DID resolution service returns the address of the issuer of the business VC service provider DID to the basic VC service provider.

[0306] S82d, the basic VC service provider requests the business DID service provider to obtain the public key of the business VC service provider based on the address of the issuer.

[0307] For example, the basic VC service provider can determine that the issuer is the aforementioned business DID service provider based on the address returned by the DID resolution service provider, and send a public key request message to the DID service provider, which carries the DID of the business VC service provider to obtain the public key corresponding to the DID of the business VC service provider.

[0308] S82e, the business DID service provider returns the public key of the business VC service provider to the basic VC service provider.

[0309] For example, after receiving the public key request information sent by the basic VC service provider, the business DID service provider can obtain the DID document associated with the DID from the distributed system according to the DID of the business VC service provider, and obtain the public key corresponding to the DID from the DID document.

[0310] S82f, the basic VC service provider uses the public key of the business VC service provider to verify the signature information of the channel establishment request information.

[0311] For example, the basic VC service provider uses the public key of the business VC service provider to sign the channel establishment request information, and compares the signature with the signature information received from the business VC service provider; if they are consistent, it can be determined that the signature information is successfully signed, otherwise it can be determined that the signature information verification fails.

[0312] S82g: The basic VC service provider indicates to the business VC service provider that a communication channel of mutual trust has been established between the business VC service provider and the basic VC service provider.

[0313] After this step is executed, it indicates that the communication channel between the business VC service provider and the basic VC service provider is mutually trustworthy.

[0314] S83a, the business VC service provider instructs the basic VC service provider of the personal information required for the business VC and sets a verification method for the personal VC.

[0315] Optionally, the personal VC may be a personal VC required when a business VC is issued by a business VC service provider.

[0316] For example, when a third-party application provides a comment function for users, users are required to present a comment VC. If the user does not have a comment VC, they need to apply for a comment VC from the business VC service provider. In this example, the business VC is the comment VC, personal information is the personal information that the user needs to provide when issuing the comment VC, and the verification method of the personal VC is the method of verifying whether the personal VC provided by the user is the comment VC issued by the business service provider.

[0317] S83b, the basic VC service provider returns the setting result to the business VC service provider.

[0318] For example, after successfully recording the personal information required by the service VC and the verification method of the personal VC on the basic VC service provider, it may return indication information of successful setting to the service VC service provider.

[0319] S83c, the business VC service provider registers the verification result callback interface of the personal VC to the basic VC service provider.

[0320] For example, after the business VC service provider registers the personal information required for the business VC and the verification method of the personal VC with the basic VC service provider, the business VC service provider can set a callback interface so that the basic VC service provider returns the verification result through the agreed callback interface, thereby ensuring that the business VC service provider can reliably and correctly obtain the verification result.

[0321] S83d, the basic VC service provider returns the setting result to the business VC service provider.

[0322] For example, after the callback interface of the basic VC service provider successfully records the verification result of the personal VC, it can return the indication information of the successful setting to the business VC service provider.

[0323] Fig. 9 A schematic diagram of a process for a business service provider to issue a business VC that relies on personal information, provided in one embodiment of the present application. Fig. 9 As shown in the figure, it includes the process of VC issuance and VC verification. Figure 8 The process shown is then executed Fig. 9 The process in .

[0324] Among them, in the implementation Fig. 9 Before the process in , the user has applied to the corresponding DID service provider for DID registration through the client wallet, and applied for personal VC from the basic VC service provider, which will not be repeated here.

[0325] In the case where the DID service provider includes a business DID service provider and a basic DID service provider, the user DID can optionally include an application DID and an identity DID. In this case, the business DID service provider can issue an application DID and a private key to the user, and the basic DID service provider can issue an identity DID and a private key to the user.

[0326] Among them, the user's application DID and identity DID can be saved in the end-side wallet.

[0327] S91a, the end-side wallet sends the business VC request information and the signature of the business VC request information to the business VC service provider.

[0328] Among them, the signature of the business VC request information can be obtained through the private key signature corresponding to the user's application DID in the end-side wallet, and the VC request information contains the user's application DID.

[0329] S91b, the business VC service provider sends an indication message to the end-side wallet, where the indication message is used to indicate the information that needs to be filled in when applying for the business VC and to instruct the end-side wallet to present the personal VC. The indication message carries the address of the basic VC service provider.

[0330] S91c, the end-side wallet performs multiple signatures on personal VC.

[0331] The client-side wallet uses the private key of the user's application DID and the private key of the identity DID to sign the personal VC, proving that the two DIDs are shared by the same user.

[0332] S91d, the client wallet sends the personal VC and the multi-signature of the personal VC to the basic VC service provider.

[0333] For example, when a user wants a business VC service provider to issue a business VC that relies on personal information, the user can present the personal VC to the basic VC service provider.

[0334] Among them, when the end-side wallet sends personal VC and multi-signatures of personal VC, it also sends the user's application DID and identity DID.

[0335] S91e, the basic VC service provider requests the DID resolution service provider to resolve the user's identity DID.

[0336] S91f, the DID resolution service returns the address of the issuer of the user's identity DID to the basic VC service provider.

[0337] Among them, the issuer of the user's identity DID is the basic DID service provider.

[0338] S91g, the basic VC service provider requests the basic DID service provider to obtain the public key of the user's identity DID based on the address of the issuer.

[0339] S91h, the basic DID service provider returns the public key of the user's identity DID to the basic VC service provider.

[0340] S91i, the basic VC service provider uses the public key of the user's identity DID to verify the signature of the personal VC.

[0341] For example, the basic VC provider uses the public key of the user's identity DID to sign the personal VC, and compares the signature with the signature received from the end-side wallet. If they are consistent, it can be determined that the verification is successful, otherwise it can be determined that the verification has failed.

[0342] S91j, the basic VC service provider requests the DID resolution service provider to resolve the user's application DID.

[0343] S91k, the DID resolution service returns the address of the issuer of the user's application DID to the basic VC service provider.

[0344] Among them, the issuer of the user's application DID is the business DID service provider.

[0345] S911, the basic VC service provider requests the business DID service provider to obtain the public key of the DID of the user application based on the address of the issuer.

[0346] S91m, the business DID service provider returns the public key of the user's application DID to the basic VC service provider.

[0347] S91n, the basic VC service provider verifies the signature of the personal VC using the public key of the user's application DID.

[0348] The signature verification method in this step can refer to S91i and will not be repeated here.

[0349] S91o, the basic VC service provider verifies the personal VC presented by the user.

[0350] After the basic service provider uses the public key of the user's DID to verify the multi-signature of the personal VC, the personal VC is verified according to the verification method of the personal VC registered by the business VC service provider.

[0351] S91p, the basic VC service provider records the correspondence between the user's identity DID and the user's application DID.

[0352] The basic VC service provider stores the correspondence between the user's identity DID and the user's application DID to facilitate subsequent regulatory operations.

[0353] S91q: The basic VC service provider returns the verification result of the personal VC to the business VC service provider.

[0354] The basic VC service provider sends the verification result of the personal VC to the business VC service provider according to the callback interface of the verification result of the personal VC registered by the business VC service provider.

[0355] S92a, the end-side wallet sends the information filled in for applying for the business VC and the signature of the information to the business VC service provider, and the information also includes the user's application DID.

[0356] For example, the end-side wallet uses the private key of the user's application DID to sign the filled-in information, and then sends the signature together with the information to the business VC service provider.

[0357] S92b, the business VC service provider requests the DID resolution service provider to resolve the user's application DID.

[0358] S92c, the DID resolution service returns the address of the issuer of the user's application DID to the business VC service provider.

[0359] S92d, the business VC service provider requests the business DID service provider to obtain the public key of the user's application DID based on the address of the issuer.

[0360] S92e, the business DID service provider returns the public key of the user's application DID to the business VC service provider.

[0361] S92f, the business VC service provider uses the public key of the user's application DID to verify the signature of the information filled in the business VC application.

[0362] S92g, the business VC service provider verifies the application information filled in by the user.

[0363] As an example, the business VC service provider may verify whether the filled-in information meets the requirements, for example, verify whether the filled-in information is complete.

[0364] S92h, the business VC service provider issues the business VC.

[0365] After the business VC service provider verifies the information filled in by the user and the basic VC service provider verifies the user's personal VC, a business VC is issued for the user's application DID.

[0366] S92i, the business VC service provider returns the issued business VC to the end-side wallet.

[0367] Combine the following Fig.10 Another embodiment of the present application provides a VC processing method for a business VC issued by a business service provider that relies on personal information. Fig.10 In the process shown, the basic VC service provider does not return the verification result to the business VC service provider through the callback interface, but returns the verification result to the end-side wallet by signing the verification result.

[0368] For example, Fig.10 A schematic diagram of a process for a business service provider to issue a business VC that relies on personal information is provided in yet another embodiment of the present application. Fig.10 The implementation of S91a to S91p in can refer to Fig. 9 S91a to S91p in the above are not described in detail here. Fig.10 The steps in Figure 8 Steps in .

[0369] S101q, the basic VC service provider returns the verification result and signature of the personal VC to the end-side wallet.

[0370] For example, after the basic VC service provider verifies the personal VC presented by the end-side wallet, it signs the verification result with its own DID private key and returns the verification result and signature to the end-side wallet.

[0371] S102a, the end-side wallet sends the information filled in by the business VC application and the signature of the information to the business VC service provider. The information also includes the user's application DID, the verification result of the personal VC and the signature of the verification result.

[0372] S102b, the business VC service provider requests the DID resolution service provider to resolve the user's application DID and the basic VC service provider's DID.

[0373] S102c, the DID resolution service returns the user's application DID and the address of the issuer of the basic VC service provider's DID to the business VC service provider.

[0374] S102d, the business VC service provider requests the business DID service provider to obtain the public key of the user's application DID based on the address of the issuer.

[0375] S102e, the business DID service provider returns the public key of the user's application DID to the business VC service provider.

[0376] S102f, the business VC service provider verifies the signature of the user's application DID.

[0377] S102g, the business VC service provider uses the public key of the user's application DID to verify the signature of the information filled in the business VC application.

[0378] S102h, the business VC service provider requests the basic DID service provider to obtain the public key of the DID of the basic VC service provider based on the address of the issuer.

[0379] S102i, the basic DID service provider returns the public key of the DID of the basic VC service provider to the business VC service provider.

[0380] S102j, the business VC service provider uses the public key of the DID of the basic VC service provider to verify the signature of the verification result of the personal VC.

[0381] S102k, the business VC service provider issues the business VC.

[0382] When the business VC service provider verifies the information filled in by the user and the verification result of the personal VC, it will issue a business VC for the user's application DID.

[0383] S1021, the business VC service provider returns the issued business VC to the end-side wallet.

[0384] Fig.10 In the method shown, after the basic VC service provider verifies the personal VC presented by the user, it can sign the verification result with its own DID private key and return it directly to the end-side wallet. When the business VC service provider issues a business VC that relies on personal information, the user can directly present the verification result with the signature of the basic VC service provider to the business VC service provider through the end-side wallet. The business VC service provider verifies the verification result and issues a business VC for the user's application DID.

[0385] Depend on Fig.10 It can be seen from the content that in this method, the business VC service provider does not need to register the callback interface with the corresponding basic VC service provider, which saves resources.

[0386] Fig.11 A schematic diagram of a process for obtaining user real-name information provided by an embodiment of the present application. Fig.11 As shown, in S111, the user sends a login request and signature to the third-party application through the end-side wallet. The signature is obtained by the end-side wallet using the private key of the user's application DID. The login request information also includes the user's application DID.

[0387] For example, the client wallet signs the login request with the private key of the user's application DID, and sends the signature information, the user's application DID and the login request to the third-party application to request login to the third-party application.

[0388] In S112, the third-party application returns the login result to the end-side wallet.

[0389] Among them, after the third-party application successfully verifies the signature of the login request, it can perform a second authentication on the end-side wallet and return the login result.

[0390] For example, the third-party application can generate a verification value, encrypt the verification value and send it to the end-side wallet. The end-side wallet decrypts the received encrypted verification value and returns it to the third-party application. The third-party application compares the verification value from the end-side wallet with the verification value generated by itself to see if they are consistent, thereby achieving secondary authentication of the end-side wallet.

[0391] Optionally, if the verification value received by the third-party application is consistent with the verification value generated by itself, a successful login message is returned to the end-side wallet. If they are inconsistent, a verification value error or login failure message is sent to the end-side wallet.

[0392] In S113, the third-party application sends a query request message to the authority.

[0393] When a user makes inappropriate remarks or uploads false content while using a third-party application, the third-party application will determine that the user has violated the rules.

[0394] If a third-party application detects that a user has violated the rules, it will save the violation and send a request to query the real-name information and the signature of the request to the authority. The signature can be obtained by signing the private key of the third-party application. The request information also includes the user's application DID, the third-party application's DID, and the user's violation evidence, in order to request the authority to review the user's violation evidence.

[0395] In S114, the authority sends a query request message and a signature to the basic VC service provider. The signature can be obtained by signing with the authority's private key. The query request message also includes the user's application DID and the authority's DID.

[0396] In S115 , the basic VC service provider returns the user's real-name information to the authority.

[0397] After receiving the request information sent by the authority, the basic VC service provider determines the user's identity DID based on the correspondence between the user's application DID and identity DID, calls out the information filled in by the user when applying for the identity DID, and returns the user's real-name information to the authority.

[0398] In S116 , the authority returns the user's real-name information to the third-party application.

[0399] If a third-party application receives the user's real-name information, it can restrict the user's behavior, thereby solving the problem of supervision of third-party applications.

[0400] It should be noted that after the user logs in to a third-party application with the application DID, when the user needs to use certain sensitive functions such as commenting, uploading content and other functional services, the third-party application requires the user to complete real-name authentication, including the user applying for, presenting and verifying the real-name information VC, before providing the above services to the user.

[0401] It should be understood that this function needs to be strictly restricted. Before a third-party application applies to obtain a user's real-name information, it needs to present evidence of the user's violation, and the corresponding service provider can return the user's real-name information to the third-party application.

[0402] Optionally, the third-party application can directly send a request to query the real-name information to the basic VC service provider without going through the authority. The basic VC service provider will review the user's violation evidence, and if it is determined that the user has indeed violated the rules, query the user's real-name information and return it directly to the third-party application.

[0403] Combine the following Fig.12 , introduces a method for obtaining a user's real-name information when the user violates regulations when using a third-party application.

[0404] Fig.12 A flowchart of obtaining user real-name information is provided for another embodiment of the present application. Fig.12 As shown, it includes the process of logging into a third-party application and obtaining the real-name information of the violating user.

[0405] S121a, the client-side wallet sends a login request to the third-party application, and the login request carries the user's application DID.

[0406] S121b, the third-party application requests the DID resolution service provider to resolve the user's application DID.

[0407] For example, after receiving a login request, a third-party application initiates a resolution request to the DID resolution service provider, and the resolution request carries the user's application DID to obtain the address of the issuer of the user's application DID.

[0408] S121c, the DID resolution service returns the address of the issuer of the user's application DID to the third-party application.

[0409] S121d, the third-party application requests the business DID service provider to obtain the public key of the user's application DID based on the address of the issuer.

[0410] S121e, the business DID service provider returns the public key of the user's application DID to the third-party application.

[0411] S121f, the third-party application generates a verification value and encrypts the verification value using the public key of the user's application DID to obtain the encrypted verification value.

[0412] For example, a third-party application generates a random value as a verification value used for login, and encrypts the verification value using the public key of the user's application DID to obtain an encrypted verification value.

[0413] S121g, the third-party application sends the encrypted verification value to the end-side wallet.

[0414] S121h, the client wallet uses the private key of the user's application DID to decrypt the encrypted verification value.

[0415] S121i, the client wallet returns the decrypted verification value and signature to the third-party application.

[0416] For example, the end-side wallet signs the decrypted verification value with the private key of the user's application DID, and sends the signature information, the user's application DID, and the decrypted verification value to the third-party application to request login.

[0417] S121j, the third-party application verifies the signature and verification value from the end-side wallet.

[0418] The signature verification method in this step can refer to Figure 5 S51d to S51h in the above are not described here. When the signature verification succeeds, the third-party application verifies the verification value from the end-side wallet. For example, the third-party application compares the verification value generated by itself with the verification value from the end-side wallet. If they are consistent, it can be determined that the verification is successful, otherwise it can be determined that the verification fails.

[0419] S121k, the third-party application returns the login result to the client wallet.

[0420] For example, if the verification value received from the end-side wallet is consistent with the unencrypted verification value generated by itself, a successful login is returned; otherwise, an incorrect verification value or a failed login may be returned.

[0421] Optionally, the end-side wallet can also sign the login request by using the private key of the user's application DID. After receiving the login request, the third-party application verifies the signature of the login request sent by the end-side wallet. If the verification is successful, the user login is successful, thereby realizing the user's password-free login.

[0422] S122a, the third-party application detects the user's illegal behavior.

[0423] When users use third-party applications, the third-party applications need to monitor the user's behavior and thus restrict the user's behavior. If the user makes inappropriate remarks or uploads false content when using a third-party application, it will be considered as a violation by the third-party application.

[0424] S122b, the third-party application sends a request query message and a signature of the request message to the authority. The signature of the request message is obtained by signing the private key of the third-party application. The request query message includes the user's violation evidence, the user's application DID and the DID of the third-party application.

[0425] For example, a third-party application signs the query request information with its own private key, and sends the user's violation evidence, signature information, the user's application DID, its own DID and the query request information to the authority to request the authority to query the real-name information of the violating user.

[0426] S122c, the authority requests the DID resolution service provider to resolve the DID of the third-party application.

[0427] Among them, the issuer of the third-party application DID is the business DID service provider.

[0428] S122d, the DID resolution service returns the address of the issuer of the DID of the third-party application to the authority.

[0429] S122e, the authority requests the business DID service provider to obtain the public key of the DID of the third-party application based on the address of the issuer.

[0430] S122f, the business DID service provider returns the public key of the DID of the third-party application to the authority.

[0431] S122g, the authority verifies the signature of the request query information using the public key of the third-party application.

[0432] S122h, the authority reviews the evidence of violation of the user in the request query information.

[0433] For example, the authority verifies whether the user's violation evidence is true, such as whether the user's behavior constitutes a violation.

[0434] S122i, the authority sends a request message and a signature of the request message to the basic VC service provider. The signature of the request message is obtained by signing with the private key of the authority. The request message includes the user's application DID and its own DID.

[0435] For example, after the authority confirms that the user has violated the rules, it signs the request information with its own private key and sends the user's application DID, its own DID and signature information to the basic VC service provider to request the basic VC service provider to query the user's real-name information.

[0436] S122j, the basic VC service provider requests the DID resolution service provider to resolve the DID of the authority.

[0437] S122k, the DID resolution service returns the address of the issuer of the DID of the authority to the basic VC service provider.

[0438] Among them, the issuer of the DID of the authoritative organization is the business DID service provider.

[0439] S1221, the basic VC service provider requests the business DID service provider to obtain the public key of the DID of the authority based on the address of the issuer.

[0440] S122m, the business DID service provider returns the public key of the DID of the authority to the basic VC service provider.

[0441] S122n, the basic VC service provider verifies the signature of the request information using the public key of the authority.

[0442] S122o, the basic VC service provider determines the user's identity DID according to the user's application DID and the correspondence between the user's application DID and the identity DID.

[0443] S122p, the basic VC service provider queries the real-name information filled in by the user when applying for the identity DID.

[0444] The real-name information is stored in the basic VC service provider, which can call the information based on the DID.

[0445] S122q: The basic VC service provider returns the user's real-name information to the authority.

[0446] S122r, the authority returns the user's real-name information to the third-party application.

[0447] After receiving the user's real-name information, the third-party application restricts the user's behavior, such as requiring the user to delete uploaded false information or prohibiting the use of the third-party application's comment function.

[0448] In the embodiment of the present application, the service providers are divided into business service providers and basic service providers according to the security level of user information. The basic service provider is endorsed by an authoritative organization and provides DID services and VC services for the user's personal information. The business service provider is provided by various application service providers and provides DID services and VC services for the user's user information. When the business service provider needs to use the user's personal information to issue a business VC, the personal VC that needs to be verified when issuing the business VC can be registered with the basic service provider and the judgment conditions for the VC can be set. When a user has more than one DID, the basic service provider can determine the correspondence between the user identity DID and the user application DID through the user's signature information, which is convenient for subsequent regulatory inquiries into user information. In the embodiment of the present application, third-party applications cannot access the user's personal information and business information, and the business service provider cannot access the user's personal information, thereby ensuring the security of user information.

[0449] Fig.13 A schematic diagram of a structure of a processing device for verifiable claims provided by an embodiment of the present application. Fig.13 As shown, the device 130 of this embodiment may include: an acquisition module 131 , a sending module 132 , and a receiving module 133 .

[0450] The acquisition module 131 is used to acquire relevant information of the first user; the sending module 132 is used to send relevant information to the service provider, and the relevant information is used to generate a target VC, which is a verification statement of the first user using the first business function through a third-party application.

[0451] Optionally, the sending module 132 is specifically used to send business information required by the first user to use the first business function to the business service provider, and the business information is used by the business service provider to generate a first VC; the sending module 132 is also used to send personal information required by the first user to use the first business function to the basic service provider, and the personal information is used by the basic service provider to generate a second VC.

[0452] Optionally, the receiving module 133 is used to receive a first VC from a business service provider; the receiving module 133 is also used to receive a second VC from a basic service provider; the sending module 132 is also used to send a first verification request to the business service provider, the first verification request is used to request the business service provider to verify the first VC; the sending module 132 is also used to send a second verification request to the basic service provider, the second verification request is used to request the basic service provider to verify the second VC.

[0453] Optionally, the above-mentioned receiving module 133 is also used to receive a first VC from the business service provider, where the first VC is generated by the business service provider when the basic service provider successfully verifies the second VC; the above-mentioned sending module 132 is also used to send a first verification request to the business service provider, where the first verification request is used to request the business service provider to verify the first VC.

[0454] Optionally, the receiving module 133 is further configured to receive a verification response from a third-party application, where the verification response is used to indicate whether the target VC is successfully verified.

[0455] Fig.14 A structural diagram of a device for processing verifiable claims provided by another embodiment of the present application. Fig.14 As shown, the device 140 of this embodiment may include: a receiving module 141 , a generating module 142 , a sending module 143 and a verifying module 144 .

[0456] Among them, the receiving module 141 is used to receive relevant information of the first user from the digital wallet, and the relevant information is used to generate a target VC, which is a verification statement of the first user using the first business function through a third-party application; the generating module 142 is used to generate the target VC based on the relevant information.

[0457] Optionally, the sending module 143 is used to send the first VC to the digital wallet; the above-mentioned receiving module 141 is also used to receive a first verification request from the digital wallet, and the first verification request is used to request the business service provider to verify the first VC.

[0458] Optionally, the verification module 144 is used to verify the first VC; the sending module 143 is also used to send a verification response to a third-party application or digital wallet, and the verification response is used to indicate whether the first VC is successfully verified.

[0459] Optionally, the above-mentioned receiving module 141 is also used to receive first configuration information from a third-party application, the first configuration information is used to indicate the business information required to generate the first VC and the verification method of the first VC; the above-mentioned sending module 143 is also used to send first prompt information to the digital wallet, the first prompt information is used to instruct the user to enter business information; the above-mentioned verification module 144 is specifically used to verify the first VC using the verification method.

[0460] Optionally, the above-mentioned verification module is also used to verify the first VC relying on the verification result of the second VC by the basic service provider, and the second VC is a VC generated by the basic service provider based on the personal information required for the first user to use the first business function; the above-mentioned receiving module 141 is also used to receive a verification response of the second VC from the basic service provider, and the verification response of the second VC is used to indicate whether the basic service provider has successfully verified the second VC; the above-mentioned verification module 144 is specifically used to verify the first VC based on the verification response of the second VC.

[0461] Optionally, the sending module 143 is also used to send a second VC to the digital wallet; the receiving module 141 is also used to receive a second verification request from the digital wallet, and the second verification request is used to request the basic service provider to verify the second VC; the sending module 143 is also used to send a verification response of the second VC to the digital wallet or the business service provider, and the verification response is used to indicate whether the second VC is successfully verified.

[0462] Optionally, the above-mentioned receiving module 141 is also used to receive second configuration information from a third-party application or business service provider, and the second configuration information is used to indicate the personal information required to generate the second VC and the verification method of the second VC; the above-mentioned sending module 143 is also used to send a second prompt information to the digital wallet, and the second prompt information is used to instruct the user to enter personal information; the above-mentioned verification module 144 is also used to verify the second VC using the verification method.

[0463] Optionally, the receiving module 141 is further used to receive an information request from a trusted application, where the information request is used to request personal information; and the sending module 143 is further used to send personal information to the trusted application.

[0464] It should be understood that the device 130 and the device 140 are embodied in the form of functional modules. The term "module" may refer to an application specific integrated circuit (ASIC), an electronic circuit, a processor (e.g., a shared processor, a dedicated processor, or a group processor, etc.) and a memory for executing one or more software or firmware programs, a merged logic circuit, and / or other suitable components that support the described functions. In an optional example, a person skilled in the art may understand that the device 130 may be specifically the end-side wallet in the above-mentioned method embodiment, or the function of the end-side wallet in the above-mentioned method embodiment may be integrated in the device 130, and the device 130 may be used to execute the various processes and / or steps corresponding to the end-side wallet in the above-mentioned method embodiment, and to avoid repetition, it will not be repeated here. The device 140 may be specifically the service provider in the above-mentioned method embodiment, including a basic service provider and a business service provider, or the function of the service provider in the above-mentioned method embodiment may be integrated in the device 140, and the device 140 may be used to execute the various processes and / or steps corresponding to the service provider in the above-mentioned method embodiment, and to avoid repetition, it will not be repeated here.

[0465] The above-mentioned device 130 has the function of implementing the corresponding steps executed by the end-side wallet in the above-mentioned method embodiment; the above-mentioned device 140 has the function of implementing the corresponding steps executed by the service provider in the above-mentioned method embodiment; the above-mentioned functions can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-mentioned functions.

[0466] Fig.15 A structural diagram of a device for processing verifiable claims provided in accordance with yet another embodiment of the present application. Fig.15 The illustrated apparatus 150 may be used to execute any of the aforementioned methods performed by any device in the service system 20 .

[0467] like Fig.15 As shown, the device 150 of this embodiment includes: a memory 151, a processor 152, a communication interface 153 and a bus 154. The memory 151, the processor 152 and the communication interface 153 are connected to each other through the bus 154.

[0468] The memory 151 may be a read only memory (ROM), a static storage device, a dynamic storage device or a random access memory (RAM). The memory 151 may store a program. When the program stored in the memory 151 is executed by the processor 152, the processor 152 is used to execute any of the aforementioned methods executed by any device in the service system 20.

[0469] The processor 152 may be a general-purpose central processing unit (CPU), a microprocessor, an application specific integrated circuit (ASIC), or one or more integrated circuits to execute related programs.

[0470] The processor 152 may also be an integrated circuit chip with signal processing capability. In the implementation process, each relevant step in the embodiment of the present application may be completed by an integrated logic circuit of hardware in the processor 152 or by instructions in the form of software.

[0471] The processor 152 may also be a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The methods, steps, and logic block diagrams disclosed in the embodiments of the present application may be implemented or executed. The general purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0472] The steps of the method disclosed in the embodiment of the present application can be directly embodied as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 151, and the processor 152 reads the information in the memory 151, and completes the functions required to be performed by the units included in the device of the present application in combination with its hardware.

[0473] The communication interface 153 may use, but is not limited to, a transceiver or other transceiver device to implement communication between the device 150 and other equipment or devices.

[0474] The bus 154 may include a path for transmitting information between various components of the device 150 (eg, the memory 151 , the processor 152 , and the communication interface 153 ).

[0475] In some embodiments of the present application, a computer program product is also provided. For example, when processing a verifiable statement, when the computer program product is executed on a processor, the method implemented by any element in the processing device for verifiable statements in any of the above embodiments can be implemented. In some embodiments of the present application, a computer-readable storage medium is also provided. The computer-readable storage medium contains computer instructions. When the computer instructions are executed on a processor, the method implemented by any element in the processing device for verifiable statements in any of the above embodiments can be implemented.

[0476] It should be noted that the modules or components shown in the above embodiments may be one or more integrated circuits configured to implement the above methods, such as one or more application specific integrated circuits (ASICs), or one or more microprocessors (DSPs), or one or more field programmable gate arrays (FPGAs). For another example, when a module above is implemented in the form of a processing element calling a program code, the processing element may be a general-purpose processor, such as a central processing unit (CPU) or other processors that can call program codes, such as a controller. For another example, these modules may be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0477] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, software module or any combination thereof. When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server, a data center, etc. that contains one or more available media integrated. The available medium can be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk Solid State Disk (SSD)), etc.

[0478] The term "plurality" in this article refers to two or more than two. The term "and / or" in this article is only a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the previous and next associated objects are in an "or" relationship; in the formula, the character " / " indicates that the previous and next associated objects are in a "division" relationship. In addition, it should be understood that in the description of this application, words such as "first" and "second" are only used for the purpose of distinguishing descriptions, and cannot be understood as indicating or implying relative importance, nor can they be understood as indicating or implying order.

[0479] It should be understood that the various numerical numbers involved in the embodiments of the present application are only used for the convenience of description and are not used to limit the scope of the embodiments of the present application.

[0480] It can be understood that in the embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

Claims

1. A method for processing verifiable claims, characterized in that: include: The digital wallet obtains relevant information of the first user; The digital wallet sends the relevant information to the service provider, where the relevant information is used to generate a target VC, where the target VC is a verification statement of the first user using the first business function through a third-party application; The service providers include a basic service provider and a business service provider, and the target VC includes a first VC and a second VC; The digital wallet sends the relevant information of the first user to the service provider, including: The digital wallet sends the business information required by the first user to use the first business function to the business service provider, and the business information is used by the business service provider to generate a first VC; The digital wallet sends the personal information required by the first user to use the first business function to the basic service provider, and the personal information is used by the basic service provider to generate a second VC.

2. The method according to claim 1, characterized in that: The method comprises: The digital wallet receives the first VC from the business service provider; The digital wallet receives the second VC from the basic service provider; The digital wallet sends a first verification request to the business service provider, where the first verification request is used to request the business service provider to verify the first VC; A second verification request is sent to the basic service provider, where the second verification request is used to request the basic service provider to verify the second VC.

3. The method according to claim 1, characterized in that The personal information is also used by the basic service provider to verify the second VC; Wherein, the method comprises: The digital wallet receives the first VC from the business service provider, where the first VC is generated by the business service provider when the basic service provider successfully verifies the second VC; The digital wallet sends a first verification request to the business service provider, where the first verification request is used to request the business service provider to verify the first VC.

4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: The digital wallet receives a verification response from the third-party application, where the verification response is used to indicate whether the target VC is successfully verified.

5. A method for processing a verifiable claim, characterized in that: include: The service provider receives relevant information of the first user from the digital wallet, where the relevant information is used to generate a target VC, where the target VC is a verification statement of the first user using the first business function through a third-party application; The service provider generates the target VC based on the relevant information; The service providers are business service providers and basic service providers; If the service provider is a business service provider, the relevant information includes business information required by the first user to use the first business function, and the target VC includes a first VC; If the service provider is a basic service provider, the relevant information includes personal information required by the first user to use the first service function, and the target VC includes a second VC.

6. The processing method according to claim 5, characterized in that: The business service provider sends the first VC to the digital wallet; The business service provider receives a first verification request from the digital wallet, where the first verification request is used to request the business service provider to verify the first VC.

7. The method according to claim 6, characterized in that The method further comprises: The business service provider verifies the first VC; The business service provider sends a verification response to the third-party application or the digital wallet, where the verification response is used to indicate whether the first VC is successfully verified.

8. The method according to claim 7, characterized in that Before the service provider receives the relevant information of the first user from the digital wallet, the method further includes: The business service provider receives first configuration information from the third-party application, where the first configuration information is used to indicate business information required to generate the first VC and a verification method for the first VC; The business service provider sends a first prompt message to the digital wallet, where the first prompt message is used to instruct the user to input the business information; The business service provider verifies the first VC, including: The business service provider verifies the first VC using the verification method.

9. The method according to claim 8, characterized in that The verification method further includes verifying the first VC based on a verification result of a second VC by a basic service provider, where the second VC is a VC generated by the basic service provider based on personal information required by the first user to use the first service function; The business service provider verifies the first VC including: The business service provider receives a verification response of the second VC from the basic service provider, where the verification response of the second VC is used to indicate whether the basic service provider has successfully verified the second VC; The business service provider verifies the first VC based on the verification response of the second VC.

10. The method according to claim 5, characterized in that The basic service provider receives a second verification request from the digital wallet, where the second verification request is used to request the basic service provider to verify the second VC; The basic service provider sends a verification response of the second VC to the digital wallet or the business service provider, where the verification response is used to indicate whether the second VC is successfully verified.

11. The method according to claim 10, characterized in that Before the service provider receives the relevant information of the first user from the digital wallet, the method further includes: The basic service provider receives second configuration information from the third-party application or business service provider, where the second configuration information is used to indicate personal information required to generate the second VC and a verification method for the second VC; The basic service provider sends a second prompt message to the digital wallet, where the second prompt message is used to instruct the user to enter the personal information; The basic service provider verifies the second VC, including: The basic service provider verifies the second VC using the verification method.

12. The method according to claim 10 or 11, characterized in that: Also includes: The basic service provider receives an information request from a trusted application, where the information request is used to request personal information; The basic service provider sends the personal information to the trusted application.

13. A processing device capable of verifying a claim, characterized in that: The method comprises various functional modules for implementing the method according to any one of claims 1 to 4 or any one of claims 5 to 12.

14. A processing device for verifying a claim, characterized in that: include: Memory and processor; The memory is used to store program instructions; The processor is configured to call the program instructions in the memory to execute the method according to any one of claims 1 to 4 or any one of claims 5 to 12.

15. A computer program product, characterized in that The method comprises a computer program code, which, when executed on a computer, causes the computer to implement the method as claimed in any one of claims 1 to 4 or any one of claims 5 to 12.

16. A computer readable medium, characterized in that The computer-readable medium stores a program code for computer execution, the program code including instructions for executing the method according to any one of claims 1 to 4 or any one of claims 5 to 12.

Images