CN117952605A

CN117952605A - Processing method and processing device for verifiable statement

Info

Publication number: CN117952605A
Application number: CN202211337842.7A
Authority: CN
Inventors: 祁毅; 莫兰
Original assignee: Petal Cloud Technology Co Ltd
Current assignee: Petal Cloud Technology Co Ltd
Priority date: 2022-10-28
Filing date: 2022-10-28
Publication date: 2024-04-30

Abstract

The application provides a processing method and a processing device for verifiable statement. In the technical scheme provided by the application, when a user uses the third party application, the user can apply or present the corresponding verifiable statement by sending the related information to the corresponding service provider through the end side wallet according to the indication information of the third party application, the service provider signs or verifies the verifiable statement according to the received information, and the verification result is sent to the third party application, so that the third party application is ensured not to contact the information of the user, and the safety of the user information is improved.

Description

Processing method and processing device for verifiable statement

Technical Field

The application relates to the technical field of intelligent terminals, in particular to a processing method and a processing device for verifiable statement.

Background

Currently, when a user uses a third party Application (APP), personal information, such as a name, an identification card number, a mobile phone number, etc., needs to be filled in to register or verify login, and these information can be left at a server side of the APP, so that the personal information of the user has a risk of disclosure. Therefore, how to ensure the security of information when the user uses the APP becomes a technical problem to be solved.

Disclosure of Invention

The application provides a processing method and a processing device for a verifiable statement, which can ensure the security of user information when a user uses a third party APP.

In a first aspect, the present application provides a method for processing a verifiable statement, including: the digital wallet obtains the related information of a first user; the digital wallet sends the related information to a service provider, wherein the related information is used for generating a target VC, and the target VC is an authentication statement that a first user uses a first service function through a third party application.

The digital wallet refers to a software program located in a terminal device (such as a mobile phone end or a computer end), can realize an online payment function, and can also be used for storing information (such as a private key) of a distributed identity (Decentralized Identifier, DID) of a user and verifiable statement (Verifiable Credential, VC) such as a driver license, a health card, a membership card and the like.

Service providers are classified into DID service providers and VC service providers. The DID service provider is used for providing DID service, and comprises registration and issue of DID, issue of public and private keys corresponding to DID, inquiry of relevant information such as verification method and the like. The VC service provider is configured to provide VC services, including issuance and validation of VCs.

When a user uses a third party application, a corresponding VC needs to be presented to enable use of the functional services provided by the third party application. If the user does not have a corresponding VC, the VC needs to be applied to the corresponding service provider.

Alternatively, the user may send, through a digital wallet, to the service provider, related information required for applying for VC, to request the service provider to issue VC.

In the technical scheme, the digital wallet directly transmits the related information of the user to the service provider without third party application, so that the safety of the user information is improved.

With reference to the first aspect, in one possible implementation manner, the service provider includes a base service provider and a traffic service provider, and the target VC includes a first VC and a second VC; wherein the digital wallet sending information related to the first user to a service provider comprises: the digital wallet sends service information required by the first user for using the first service function to the service provider, wherein the service information is used for the service provider to generate a first VC; the digital wallet transmits personal information required by the first user to use the first service function to the base service provider, the personal information being used by the base service provider to generate a second VC.

The business service provider can be provided by an application service provider, and comprises a business DID service provider and a business VC service provider, and the business service provider is used for providing business related services for users based on application information of the users. The base service provider is endorsed by an authority, including a base DID service provider and a base VC service provider, for providing personal related services to a user based on personal information of the user.

Optionally, the user sends related information required by applying for VC to the service provider through the digital wallet, and in the process of requesting the service provider to issue VC, if the service provider includes the service provider, the related information sent by the user to the service provider may include application information of the user. If the service provider includes a basic service provider, the related information sent by the user to the basic service provider may include personal information of the user.

Wherein the VC issued by the service provider for the user may be stored in a digital wallet.

In the implementation mode, the service provider is layered according to the importance of the user information, so that the operation pressure of the service provider is relieved, the service provider can not contact the personal information of the user, and the safety of the personal information of the user is improved.

With reference to the first aspect, in one possible implementation manner, the method includes: the digital wallet receiving the first VC from the traffic service provider; the digital wallet receiving the second VC from the base service provider; the digital wallet sends a first authentication request to the service provider, wherein the first authentication request is used for requesting the service provider to authenticate the first VC; and sending a second authentication request to the basic service provider, wherein the second authentication request is used for requesting the basic service provider to authenticate the second VC.

In this implementation, after the service provider issues the VC for the user, the issued VC may be returned to the digital wallet, which may present the VC to the service provider for verification through the issued VC.

Wherein if the service provider comprises a traffic service provider, optionally the digital wallet presents the traffic VC to the traffic service provider. If the service provider comprises a base service provider, optionally, the digital wallet presents the personal VC to the base service provider.

With reference to the first aspect, in a possible implementation manner, the personal information is further used for the base service provider to authenticate the second VC; wherein the method comprises the following steps: the digital wallet receives the first VC from the traffic service provider, the first VC being generated by the traffic service provider if the base service provider successfully authenticates the second VC; the digital wallet sends a first authentication request to the service provider, the first authentication request being for requesting the service provider to authenticate the first VC.

In this implementation manner, when the service provider performs authentication on personal information of the user in the process of issuing the service VC for the user, the service provider may instruct the user to present the personal VC to the base service provider, and after the base service provider successfully authenticates the personal VC presented by the user, the service provider issues the personal VC to the user under the condition that the personal VC authentication is successful.

With reference to the first aspect, in a possible implementation manner, the method further includes: the digital wallet receives an authentication response from the third party application indicating whether the target VC is authenticated successfully.

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

Optionally, if the verification is successful, information of the verification success may be returned to the digital wallet, otherwise, information of failure of the verification or unsatisfactory VC presented may be returned.

In a second aspect, the present application provides a method for processing a verifiable statement, including: the service provider receives related information of a first user from a digital wallet, wherein the related information is used for generating a target VC, and the target VC is an authentication statement that the first user uses a first service function through a third party application; the service provider generates the target VC based on the related information.

In the technical scheme, when a user needs to apply for VC to a service provider, the user sends information required by applying for VC to the service provider through a digital wallet, after receiving the related information required by applying for VC, a basic service provider verifies the applied information, and if verification is successful, the user is issued with VC.

As an example, before the service provider issues the VC for the user based on the filled information, the VC service provider may a priori verify whether the filled information meets the requirements, e.g., verify whether the filled information is complete, etc., and issue the VC if the requirements are met.

With reference to the second aspect, in a possible implementation manner, the service provider is a service provider, the related information includes service information required by the first user to use the first service function, and the target VC includes a first VC; the business service provider sends the first VC to the digital wallet; the traffic service provider receives a first authentication request from the digital wallet, the first authentication request for requesting the traffic service provider to authenticate the first VC.

In this implementation manner, if the service provider is a service provider, the related information sent by the user to the service provider may include application information of the user, and the service provider issues a service VC for the user based on the application information sent by the user, and returns the issued service VC to the digital wallet for storage. The service provider may also receive and respond to authentication requests sent by the user. Wherein the authentication request contains the service VC presented by the user.

With reference to the second aspect, in a possible implementation manner, the method further includes: the business service provider verifies the first VC; the service provider sends an authentication response to the third party application or the digital wallet, the authentication response indicating whether the first VC is successfully authenticated.

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

Alternatively, the service provider may directly return the verification result to the digital wallet after verifying the service VC in the verification request sent by the user.

With reference to the second aspect, in one possible implementation manner, before the service provider receives the related 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, wherein the first configuration information is used for indicating business information required by generating the first VC and an authentication mode of the first VC; the business service providing module sends first prompt information to the digital wallet, wherein the first prompt information is used for indicating a user to input the business information; wherein the verifying, by the service provider, the first VC includes: and the service provider uses the verification mode to verify the first VC.

In this implementation, before the third party application provides the functional service for the user, the third party application may communicate with the service provider, register, with the service provider, what relevant information the service VC depends on, set the verification manner of the service VC, and/or register a callback interface for the verification result.

Wherein, the related information on which the service VC depends can be understood as application information required for generating or issuing the service VC; the verification mode of the service VC can be understood as a mode of verifying whether the received service VC meets the requirement; the verification result may include verification success or verification failure; the callback interface of the verification result can be understood as an interface for indicating the verification result to the third party application by the service provider.

For example, when the third party application requests the user to present the service VC, the indication information may also be sent to the user, where the indication information includes an address of the service provider, and the user may apply for the service VC to the service provider through the address in the indication information, where the service provider indicates, to the user, information that the service VC needs to be filled according to the information of the service VC registered by the third party application, and issues the service VC.

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 verification manner of the service VC set by the third party application, and return a verification result.

With reference to the second aspect, in one possible implementation manner, the verification manner further includes verifying the first VC according to a verification result of a second VC by a base service provider, where the second VC is a VC generated by the base service provider based on personal information required by the first user to use the first service function; wherein the verifying the first VC by the service provider comprises: the business service provider receives an authentication response of the second VC from a basic service provider, wherein the authentication response of the second VC is used for indicating whether the basic service provider successfully authenticates the second VC or not; the traffic service provider authenticates the first VC based on an authentication response of the second VC.

In this implementation, before the service provider issues the service VC depending on the personal information of the user to the user, the service provider may communicate with the base service provider, register, with the base service provider, what relevant information the service VC depends on, set the authentication mode of the personal VC, and/or register a callback interface of the authentication result.

Wherein, the related information on which the service VC depends can be understood as personal information required for generating or issuing the service VC; the verification manner of the personal VC can be understood as a manner of verifying whether the received personal VC meets the requirement; the verification result may include verification success or verification failure; the callback interface of the verification result can be understood as an interface of the base service provider indicating the verification result to the service VC service provider.

For example, while the service VC service provider indicates that the user applies for information that the service VC needs to be filled, the service VC service provider may also send an address of the base service provider to the user, and the user may present the personal VC to the base service provider through the address information, where the base service provider verifies the personal VC presented by the user according to the verification manner of the personal VC set by the service provider, and returns a verification result.

With reference to the second aspect, in a possible implementation manner, the service provider is a base service provider, the related information includes personal information required by the first user to use the first service function, and the target VC includes a second VC; the base service provider sends the second VC to the digital wallet; the base service provider receiving a second authentication request from the digital wallet, the second authentication request for requesting the base service provider to authenticate the second VC; the base service provider sends an authentication response to the digital wallet or a service provider to the second VC, the authentication response indicating whether the second VC is authenticated successfully.

In this implementation manner, if the service provider is the base service provider, the related information sent by the user to the base service provider may include personal information of the user, and the base 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 base service provider may also receive and respond to authentication requests sent by the user. Wherein the authentication request contains the personal VC presented by the user.

Optionally, the base service provider may return the verification result to the service provider after verifying the individual VC in the verification request sent by the user through the digital wallet.

Alternatively, the base service provider may return the verification result directly to the digital wallet after verifying the individual VC in the verification request sent by the user through the digital wallet.

With reference to the second aspect, in one possible implementation manner, before the service provider receives the related 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 the business service provider, wherein the second configuration information is used for indicating personal information required for generating the second VC and a verification mode of the second VC; the basic service providing module sends second prompt information to the digital wallet, wherein the second prompt information is used for indicating a user to input the personal information; wherein the base service provider verifies the second VC, comprising: and the basic service provider uses the verification mode to verify the second VC.

In this implementation, before the third party application provides the functional service for the user, communication may be performed between the third party application and the basic service provider, and what relevant information the personal VC depends on is registered with the basic service provider, the authentication mode of the personal VC is set, and/or a callback interface for registering the authentication result is registered.

Wherein, the relevant information on which the personal VC depends can be understood as information required for generating or issuing the personal VC; the verification manner of the personal VC can be understood as a manner of verifying whether the received personal VC meets the requirement; the verification result may include verification success or verification failure; the callback interface of the verification result can be understood as an interface for indicating the verification result to the third party application by the service provider.

The specific implementation is similar to the communication between the third party application and the service provider and will not be described in detail here.

Accordingly, before the service provider issues the service VC depending on the personal information of the user to the user, the service provider may communicate with the base service provider, register what personal information the service VC depends on with the base service provider, set the authentication mode of the personal VC, and/or register a callback interface of the authentication result.

Therefore, when the user presents the personal VC to the base service provider, the base service provider can verify the personal VC presented by the user according to the verification manner of the personal VC set by the service provider, and returns a verification result.

With reference to the second aspect, in a possible implementation manner, the method further includes: the base service provider receiving an information request from a trusted application, the information request for requesting personal information; the base service provider sends the personal information to the trusted application.

In the implementation manner, when the user uses the third-party application, if there is an illegal act of publishing an incorrect language, the third-party application can send request information for inquiring real-name information of the user to the trusted application, and the request information contains the illegal evidence of the user. After receiving the request information of the third party application, the trusted application examines the illegal evidence of the user, if the user is determined to have illegal behaviors, the trusted application sends the request information to the basic service provider to acquire the real-name information of the user, the basic service provider returns the real-name information of the user to the third party application through the trusted application after calling the real-name information of the user, and the third party application can limit the behaviors of the user through the real-name information of the user, so that the supervision level of the third party application is improved.

In a third aspect, the present application is a processing device for verifiable claims, the device comprising means for implementing the method of the first aspect or any one of the implementations, each of the means being implemented in hardware and/or software.

For example, the apparatus may include: the device comprises an acquisition module and a sending module. The acquisition module is used for acquiring the related information of the first user; the sending module is used for sending the related information to the service provider, and the related information is used for generating a target VC, wherein the target VC is a verification statement that a first user uses a first service function through a third party application.

In a possible implementation manner, the sending module is specifically configured to send, to the service provider, service information required by the first user to use the first service function, where the service information is used by the service provider to generate a first VC; the sending module is further configured to send, to the basic service provider, personal information required by the first user to use the first service function, where the personal information is used by the basic service provider to generate a second VC.

In one possible implementation, the apparatus may further include: and a receiving module. A receiving module configured to receive the first VC from the traffic service provider; the receiving module is further configured to receive the second VC from the base service provider; the sending module is further configured to send a first authentication request to the service provider, where the first authentication request is used to request the service provider to authenticate the first VC; the sending module is further configured to send a second authentication request to the base service provider, where the second authentication request is used to request the base service provider to authenticate the second VC.

In one possible implementation, the receiving module is further configured to receive the first VC from the service provider, where the first VC is generated by the service provider if the base service provider successfully authenticates the second VC; the sending module is further configured to send a first authentication request to the service provider, where the first authentication request is used to request the service provider to authenticate the first VC.

In one possible implementation, the receiving module is further configured to receive an authentication response from the third party application, where the authentication response is used to indicate whether the target VC is authenticated successfully.

In a fourth aspect, the present application provides a processing device for verifiable claims, the device comprising means for implementing the method of the second aspect or any one of the implementations, each of the means being implemented in hardware and/or software.

For example, the apparatus may include: a receiving module and a generating module. The receiving module is used for receiving related information of the first user from the digital wallet, wherein the related information is used for generating a target VC, and the target VC is an authentication statement that the first user uses a first service function through a third party application; the generation module is used for generating the target VC based on the related information.

In one possible implementation, the apparatus may further include: and a transmitting module. The sending module is used for sending the first VC to the digital wallet; the receiving module is further configured to receive a first authentication request from the digital wallet, the first authentication request being for requesting the traffic service provider to authenticate the first VC.

In one possible implementation, the apparatus may further include: and a verification module. The verification module is used for verifying the first VC; the sending module is further configured to send an authentication response to the third party application or the digital wallet, where the authentication response is used to indicate whether the first VC is successfully authenticated.

In one possible implementation manner, the receiving module is further configured to receive first configuration information from the third party application, where the first configuration information is used to indicate service information required for generating the first VC and an authentication manner of the first VC; the sending module is also used for sending first prompt information to the digital wallet, wherein the first prompt information is used for indicating a user to input the service information; the verification module is specifically configured to verify the first VC using the verification manner.

In one possible implementation, the verification module is further configured to verify the first VC in dependence on a verification result of a second VC by a base service provider, where the second VC is a VC generated by the base service provider based on personal information required by the first user to use the first service function; the receiving module is further configured to receive an authentication response of the second VC from a base service provider, where the authentication response of the second VC is used to indicate whether the base service provider successfully authenticates the second VC; the authentication module is specifically configured to authenticate the first VC based on an authentication response of the second VC.

In one possible implementation, the sending module is further configured to send the second VC to the digital wallet; the receiving module is further configured to receive a second authentication request from the digital wallet, the second authentication request being for requesting the base service provider to authenticate the second VC; the sending module is further configured to send an authentication response to the digital wallet or a service provider for the second VC, where the authentication response is used to indicate whether the second VC is successfully authenticated.

In one possible implementation, the receiving module is further configured to receive second configuration information from the third party application or the service provider, where the second configuration information is used to indicate personal information required for generating the second VC and an authentication manner of the second VC; the sending module is also used for sending second prompt information to the digital wallet, wherein the second prompt information is used for indicating a user to input the personal information; the verification module is further configured to verify the second VC using the verification manner.

In one possible implementation, the receiving module is further configured to receive an information request from a trusted application, the information request being configured to request the personal information; the sending module is further configured to send the personal information to the trusted application.

In a fifth aspect, the present application provides a processing device for verifiable claims, comprising at least one processor and a communication interface, the communication interface and the at least one processor being interconnected by a line, the at least one processor being adapted to run a computer program or instructions to perform a method as described in the first aspect or any one of the possible implementations thereof.

In a sixth aspect, the present application provides an apparatus comprising at least one processor and a communication interface, the communication interface and the at least one processor being interconnected by a wire, the at least one processor being adapted to run a computer program or instructions to perform a method as described in the second aspect or any one of the possible implementations.

In a seventh aspect, the application provides a computer readable medium storing program code for execution by a device, the program code comprising instructions for performing the method of the first aspect, the second aspect or any one of the possible implementations thereof.

In an eighth aspect, the application provides a computer program product comprising instructions which, when run on a computer, cause the computer to perform the method according to the first aspect, the second aspect or any one of the possible implementations thereof.

Drawings

FIG. 1 is a flow chart of a method for a user to verify the identity of the user through a third party APP of digital money Bao Denglu;

fig. 2 is a schematic structural diagram of a service system according to an embodiment of the present application;

Fig. 3 is a flow chart illustrating a VC processing method according to an embodiment of the present application;

FIG. 4 is a flow chart of third party application registration provided by one embodiment of the present application;

Fig. 5 is a schematic flow chart of application and verification of VC according to an embodiment of the present application;

Fig. 6 is a schematic flow chart of application and verification of VC according to another embodiment of the present application;

Fig. 7 is a flowchart illustrating a VC processing method according to another embodiment of the present application;

FIG. 8 is a flow chart of a business service provider registration provided by an embodiment of the present application;

fig. 9 is a schematic flow chart of a business VC that relies on personal information issued by a business service provider according to an embodiment of the present application;

fig. 10 is a schematic flow chart of a service VC that depends on personal information and issued by a service provider according to another embodiment of the present application;

FIG. 11 is a flowchart of acquiring real name information of a user according to an embodiment of the present application;

fig. 12 is a flowchart of obtaining real name information of a user according to still another embodiment of the present application;

FIG. 13 is a schematic diagram of a processing device for verifiable claims according to an embodiment of the present application;

FIG. 14 is a schematic structural diagram of a processing device for verifiable declaration provided by another embodiment of the present application;

FIG. 15 is a schematic structural diagram of a processing device for verifiable declaration according to still another embodiment of the present application.

Specific embodiments of the present application have been shown by way of the above drawings and will be described in more detail below. The drawings and the written description are not intended to limit the scope of the inventive concepts in any way, but rather to illustrate the inventive concepts to those skilled in the art by reference to the specific embodiments.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the application. Rather, they are merely examples of apparatus and methods consistent with aspects of the application as detailed in the accompanying claims.

When using APP on a terminal device, login is often required, and even authentication is required. A method for logging in an APP is as follows: user information is recorded on the terminal equipment, and when the APP is logged in, the user information is directly called for logging in; further, the user information may be invoked for authentication. The function module for recording the user information can be called a digital wallet, and the logged-in APP can be called a third party APP.

FIG. 1 is a flow chart of a method for a user to verify the identity of the user through a third party APP of digital money Bao Denglu.

S101, the end-side wallet sends a DID request to a DID service provider, wherein the DID request carries first user information.

The end-side wallet is an example of a digital wallet, and may be a software program located in a terminal device (for example, a mobile phone end or a computer end), and may implement an online payment function, and may also be used to store DID information (such as a private key) of a user and verifiable claims (Verifiable Credential, VC) such as a driver license, a health card, a membership card, and the like.

The DID is a distributed identity (Decentralized Identifier, DID) that can be used to identify the identity of an entity. Wherein the entity may comprise a person, an organization, etc. One entity may have a plurality of DID, for example, the individual's DID may be the mother's DID, the photo fan's DID, and the engineer's DID, but one DID may correspond to only one entity. In addition, each DID corresponds to a DID document for storing information such as a public key and encryption scheme of the DID.

The DID service provider is used to provide DID services. The DID service comprises registration and issue of the DID, issue of public and private keys corresponding to the DID, inquiry of related information such as verification methods and the like.

For example, the end wallet sends a DID request to the DID service provider, and the DID request information carries some user information recorded in the end wallet, and the user information for applying for the DID may be referred to as first user information. After receiving the DID request, the DID service provider issues a DID for the user, and the DID is used for identifying the identity of the user.

It is understood that when the DID service provider issues the first DID, a pair of public and private keys corresponding to the first DID are also generated. This is used to verify the identity of the first DID holder with the public-private key.

S102, the DID service provides private key information corresponding to the first DID and the first DID issued for the user and returned to the end-side wallet.

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

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.

S103, the end side wallet sends a login request to the third party APP, wherein the login request carries a first DID.

The third party APP may be an APP located in a terminal device, an internet Web application, or the like. The third party APP supports the user to log in with the DID identity.

S104, the third party APP requests the DID analysis server to analyze the address of the issuer of the first DID. The DID analysis service side is used for analyzing the address of the issuing side of the DID according to the DID.

For example, after receiving the login request, the third party APP initiates an analysis request to the DID analysis server, where the analysis request carries the first DID of the user, so as 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.

S105, the DID analysis service returns the address of the issuer of the first DID to the third party APP.

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

And S106, the third party APP requests the public key corresponding to the first DID from the DID service provider.

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.

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

As an example, when the public key corresponding to the first DID is stored in the distributed system, the DID service provider may obtain the public key corresponding to the first DID from the distributed system.

S108, the third party APP generates a verification value and encrypts the verification value through a public key corresponding to the first DID to obtain an encrypted verification value.

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

S109, the third party APP sends the encrypted verification value to the end-side wallet.

S110, the end side wallet decrypts the encrypted verification value by using a private key corresponding to the first DID, and returns the decrypted verification value to the third party APP.

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

For example, the third party APP determines whether the authentication value received from the end-side wallet coincides with the authentication value itself generated in S108 that has not been encrypted yet.

S112, the third party APP returns a login result to the end-side wallet.

For example, if the authentication value received from the end-side wallet is consistent with the unencrypted authentication value generated by the end-side wallet, the login is successful, otherwise, the authentication value error or login failure can be returned.

S113, the end side wallet sends a VC request to the third party APP.

VC is a digital certificate through which the DID holder can prove to other entities some of its attributes, e.g., through which its own academic can be verified as trusted.

When a user uses some functions in the third-party APP, the user needs to present corresponding VC to the third-party APP. For example, when a user performs a recharging operation in a third party APP, a related proof of adult need to be presented to the third party APP. If there is no VC, then VC needs to be applied.

S114, the third party APP forwards the VC request to the VC service provider.

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

S115, the VC service provides information needed by the application VC for the third party APP.

S116, the third party APP forwards information required by the application VC to the end side wallet.

S117, the end side wallet receives information filled by the user.

Wherein the information filled in by the user may be referred to as second user information.

S118, the end side wallet sends second user information required for applying VC to the third party APP.

And S119, the third party APP forwards the second user information to the VC service provider.

And S120, the VC service provider verifies the second user information and issues the VC.

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

S121, the VC service provides a first VC to a third party APP.

S122, the third party APP forwards the first VC to the end-side wallet. After the end-side wallet receives the first VC, the first VC is stored.

S123, the end side wallet presents the first VC to the third party APP.

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

S124, the third party APP forwards the first VC to the VC service provider.

And S125, the VC service provider verifies the first VC.

S126, the VC service provider sends the verification result to the third party APP.

S127, the third party APP forwards the verification result to the end-side wallet.

And if the verification result is that the verification is successful, the third party APP provides corresponding functions for the user.

According to the content, the end-side wallet is realized through the third-party APP for user application VC and presentation VC, so that the risk of leakage of user information on the third-party APP can be increased, and the safety of the user information is reduced.

Aiming at the problems, the application provides a new technical scheme to reduce the risk of leakage of the user information on the third party APP and improve the safety of the user information.

Fig. 2 is a schematic structural diagram of a service system according to an embodiment of the present application. As shown in fig. 2, the service system 20 includes: the end side wallet 21, the third party application 22, the service provider 23, the DID resolution service 24, and the distributed system 25, the service provider 23 may include a base service provider 231 and a service provider 232, the base service provider 231 may include a base DID service provider 231-1 and a base VC service provider 231-2, and the service provider 231 may include a service DID service provider 232-1 and a service VC service provider 232-2.

The end-side wallet 21 may be a mobile phone-side APP or a computer-side software application. The end-side wallet 21 may be used to store user information, such as DID identity information (and corresponding private key information) of the user, VC credentials issued by each VC issuer, and so on.

By way of example, the user information may include information such as a graduation certificate, a driver license, or an identification number.

The third party application 22 may be an APP or web application on the cell phone side or on the computer side. The third party application 22 may support the user to log in through the DID and verify the user's DID when the user logs in through the DID to ensure the legitimacy of the identity.

When the third party application 22 provides a functional service for a user, all or part of the functions need to perform VC authentication on the user, and the user is allowed to use only if the authentication is successful.

The service provider 23 is used to provide DID services and VC services. It will be appreciated that the division of the service provider 23 into the base service provider 231 and the service provider 232 in this embodiment is only one example.

In other examples, the base service provider 231 and the business service provider 232 may not be distinguished in the service provider 23. For example, the service provider 23 includes a DID service provider and a VC service provider.

The base service provider 231 may be endorsed by an authority for providing the user with the DID service and the VC service based on personal information of the user. An example of an authority is an educational system.

As an example, the user information on which the base service provider 231 is based may contain important information of the user, which may also be understood as private information or information that is not desired to be revealed. For example, the important information may include identification card information, address, academic information, etc. of the user.

The service provider 232 may be provided by an application service provider for providing the DID service and the VC service to the user based on the user information. As an example, the user information on which the business service provider is based may contain relatively unimportant information. For example, the user information on which the service provider is based may include information of age, sex, etc. of the user.

The DID resolution service side 24 provides the DID resolution service. For example, the DID resolution service 24 may resolve the DID so as to learn the address of the DID service provider that issued the DID.

The distributed system 25 may be used to store DID documents, which may include public keys and verification methods, etc. that have a mapping relationship with the user's DID. Optionally, the DID document may also store a mapping relationship between the DID and the DID service provider.

Alternatively, distributed system 25 may use blockchain technology or a distributed file system for the preservation of DID documents.

Optionally, information interaction between the components in the verification system 20 may be performed through a unified SDK or API interface.

As an example, the address mentioned in the service system of the present embodiment may be a uniform resource locator (Uniform Resource Locator, URL). The uniform resource locator may also be referred to as a web address, or simply a web address.

Fig. 3 is a flowchart illustrating a VC processing method according to an embodiment of the present application. As shown in fig. 3, in S31, the third party application communicates with the VC service provider, registers with the service provider what relevant information the VC depends on, sets the authentication mode of the VC, and/or registers a callback interface for the authentication result.

Wherein, the related information on which the VC depends can be understood as information required for generating or issuing the VC; the verification manner of the VC can be understood as a manner of verifying whether the received VC meets the requirement; the verification result may include verification success or verification failure; the callback interface of the verification result may be understood as an interface where the service provider indicates the verification result to the third party application.

In some examples, the VC service provider may include a traffic VC service provider and an underlying VC service provider.

If the VC service provider comprises a traffic VC service provider, the relevant information may optionally comprise traffic information. Accordingly, the third party application indicates to the service VC service provider the service information required by the service VC, the verification manner of the service VC, and the callback interface of the verification result of the service VC.

If the VC service provider comprises a base VC service provider, the relevant information may optionally comprise personal information. Accordingly, the third party application indicates to the base VC service provider personal information required for the personal VC, a verification manner of the personal VC, and a callback interface of a verification result of the personal VC.

In S32, the end-side wallet transmits to the VC service provider the related information required for the VC.

If the VC service provider comprises a traffic VC service provider, optionally, the end-side wallet sends traffic information required for the traffic VC to the traffic VC service provider.

If the VC service provider comprises a base VC service provider, optionally, the end-side wallet sends personal information required for the personal VC to the base VC service provider.

In S33, the VC service provides for issuing VCs to end-side wallets.

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

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

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

In S35, the end-side wallet sends a VC to the VC service provider requesting the VC service provider to authenticate the VC.

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

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

In S36, the VC service provider transmits the authentication result of the VC to the third party application.

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

If the VC service provider includes a base VC service provider, optionally, the base VC service provider indicates the authentication result of the personal VC to the third party application according to a callback interface of the authentication result of the personal VC set by the third party application.

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

As an example, the authentication result of the VC may include an authentication result of the service VC and an authentication result of the personal VC.

Optionally, in some embodiments of the present application, part or all of the VC dependent related information, the VC verification manner, and the callback interface of the verification result may be preset on the VC service provider, and not indicated by the third party application.

Alternatively, in some embodiments of the present application, the third party application may not need to set a callback interface for the validation result at the VC service provider. In this embodiment, the VC service provider may send the verification result directly to the third party application, rather than through the callback interface.

Alternatively, in some embodiments of the present application, the traffic VC service provider and the base VC provider may be the same provider.

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 mutually trusted channel based on the DID. Thus, on 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 realized.

A schematic flow chart of a method for VC processing by a third party application and a VC service provider in applying a DID and establishing a mutually trusted channel based on the DID is described below in connection with fig. 4,5 and 6.

Fig. 4 is a schematic flow chart of third party application registration according to an embodiment of the present application. As shown in fig. 4, the process of performing DID registration by each character and performing VC-related content registration by a third party application at a VC service provider is included.

S41a, the DID service provider registers the DID for itself.

Before issuing the DID for other entities, the DID service provider can register the DID for itself, so that when the DID analysis service provider analyzes the DID of the other entities, the DID analysis service provider can determine the issuing address of the DID of the other entities based on the DID of the DID service provider, namely the address of the DID service provider for issuing the DID to the other entities.

The DID service provider may be a basic DID service provider or a business DID service provider.

S41b, the VC service provider applies for registering DID to the DID service provider.

And S41c, the DID service provider returns the DID and the private key issued by the DID service provider for the VC service provider to the VC service provider.

In the case where the VC service provider comprises a traffic VC service provider and a base VC service provider, the DID service provider may optionally comprise a traffic DID service provider and a base DID service provider. In this case, the base DID service provider may issue the DID and the private key for the base VC service provider, and the service DID service provider issues the DID and the private key for the service VC service provider.

And S41d, the third party application applies for registering the DID to the DID service provider.

S41e, the DID service providing direction returns the DID and the private key issued by the DID service providing direction for the third party application to the third party application.

In the case where the VC service provider comprises a traffic VC service provider and a base VC service provider, the DID and private key may optionally be issued by the traffic DID service provider for a third party application.

S42a, the third party application sends channel establishment request information and signature information of the channel establishment request information to the VC service provider, the signature information of the channel establishment request information is obtained through private key signature of the third party application, and the channel establishment request information contains DID of the third party application.

For example, the third party application signs the channel establishment request information through a private key corresponding to its DID, and sends the signature information, the DID, and the channel establishment request information together to the VC service provider to request establishment of a mutually trusted channel with the VC service provider.

The VC service provider may include, among other things, a base VC service provider and a traffic VC service provider.

And S42b, the VC service provider requests the DID analysis service provider to analyze the DID of the third party application.

After receiving the channel establishment request information sent by the third party application, the VC service provider sends DID analysis request information to the DID analysis server, wherein the DID analysis request information carries the DID of the third party application so as to acquire the address of the issuer of the DID of the third party application.

And S42c, the DID analysis service returns the address of the issuer of the DID of the third party application to the VC service provider.

And S42d, the VC service provider requests the DID service provider for the public key of the third party application based on the address of the issuer.

For example, the VC service provider may determine that the issuer is the foregoing DID service provider according to the address returned by the DID resolution service provider, and send public key request information to the DID service provider, where the public key request information carries the DID of the third party application to obtain a public key corresponding to the DID of the third party application.

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

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

And S42f, the VC service provider verifies the signature information of the channel establishment request information by using the public key of the third party application.

For example, the VC service provider signs the channel setup request information using the public key of the third party application and compares the signature to signature information received from the third party application; if the signature information is consistent, the signature information is confirmed to be successful, otherwise, the signature information is confirmed to be failed to verify.

S42g, the VC service provider indicates to the third party application that a mutually trusted communication channel has been established between the VC service provider and the third party application.

After this step is performed, it is indicated that the communication channel between the third party application and the VC service provider is mutually trusted.

S43a, the third party application indicates the relevant information required by the VC to the VC service provider and sets the verification mode of the VC.

Alternatively, the VC may be a VC required to use the corresponding service function by a third party application.

For example, a third party application may require a user to present a member credential when the user is provided with a function that the member is able to use. In this example, the VC is a member VC, the related information is related information that needs to be provided by the user to register the member VC, and the verification manner of the VC is a method for verifying whether the VC provided by the user is a member VC applied by a third party.

And S43b, the VC service provides a setting result for the third party application.

For example, after successfully recording the relevant information required by the VC and the verification manner of the VC on the VC service provider, an indication of successful setting may be returned to the third party application.

And S43c, the third party application registers a callback interface of the verification result of the VC to the VC service provider.

For example, after the third party application registers the relevant information required by the VC and the verification manner of the VC, the VC service provider may set a callback interface, so that the VC service provider returns a verification result through the agreed callback interface, thereby ensuring that the third party application can reliably and correctly reach the verification result.

And S43d, the VC service provides a setting result for the third party application.

For example, after a callback interface on the VC service provider successfully records the verification result of the VC, an indication of successful setting may be returned to the third party application.

Fig. 5 is a schematic flow chart of application and verification of VC according to an embodiment of the present application. As shown in fig. 5, which includes the flow of VC issue and VC verification. Alternatively, the flow in fig. 5 may be performed after the flow shown in fig. 4 is performed.

And S51a, the third party application sends indication information to the end-side wallet, wherein the indication information is used for indicating the end-side wallet to show the VC, and the indication information carries the address of the VC service provider.

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

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

And S51b, the end-side wallet acquires the address of the VC service provider.

For example, the end-side wallet obtains the address of the VC service provider from the indication of the third party application.

If the end wallet does not apply for the VC, triggering a VC application process. Accordingly, the end-side wallet applies for VC to the corresponding VC service provider.

And S51c, the end-side wallet sends the VC request information and the signature of the VC request information to the VC service provider.

The signature of the VC request information may be obtained by a private key signature corresponding to the user DID of the end-side wallet, where the VC request information includes the user DID.

If the VC service provider comprises a traffic VC service provider, optionally, the end-side wallet sends VC request information and a signature of the VC request information to the traffic VC service provider based on an address indicated by the third party application, where the VC request information is used to request a traffic VC.

If the VC service provider comprises a base VC service provider, optionally, the end-side wallet sends VC request information and a signature of the VC request information to the base VC service provider based on an address indicated by the third party application, the VC request being for requesting a personal VC.

S51d, the VC service provider requests the DID analysis service provider to analyze the user DID.

After receiving the VC application request information sent by the end wallet, the VC service provider sends DID analysis request information to the DID analysis server, wherein the DID analysis request information carries the DID of the user so as to obtain the address of the issuer of the DID of the user.

S51e, the DID analysis service returns the address of the issuer of the user DID to the VC service provider.

S51f, the VC service provider requests the public key of the user DID from the DID service provider based on the address of the issuer.

For example, the issuer of the user DID is a DID service provider, from which the VC service provider obtains the public key of the user DID.

For example, the VC service provider determines the address of the DID service provider according to the address returned by the DID resolution service provider, and sends public key request information to the DID service provider, where the public key request information is used to obtain the public key of the user DID, and the request information carries the user DID.

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

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

And S51h, the VC service provider verifies the signature of the VC request information by using the public key of the user DID.

For example, the VC provider signs the VC request information using the public key of the user DID and compares the signature to the signature received from the end-side wallet, if it is consistent, then the verification may be determined to be successful, otherwise the verification may be determined to be failed.

S51i, the VC service provides information indicating to the end-side wallet that the application VC needs to fill in.

After the signature verification of the VC request information is successful, the VC service provider returns an indication of which information the VC is required to fill to the end wallet.

S51j, the end wallet sends information filled in for applying for VC and a signature of the information to the VC service provider, wherein the information also comprises user DID.

For example, after signing the filled information with the private key of the user DID, the end-side wallet sends the signature to the VC service provider along with the information.

S51k, the VC service provider requests the DID analysis service provider to analyze the user DID.

S51l, the DID analysis service returns the address of the issuer of the user DID to the VC service provider.

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.

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

Wherein, S51k to S51n may refer to S51d to S51g, and will not be described herein.

And S51, the VC service provider verifies the signature of the information filled in by the application VC by using the public key of the user DID and issues the VC.

The signature verification method in this step may refer to S51h, and will not be described here again. When signature verification is successful, the VC service provider issues VCs for the user based on the information filled by the user.

As an example, before the VC service provider issues the VC for the user based on the filled information, the VC service provider may verify a priori whether the filled information meets the requirements, e.g., verify whether the filled information is complete, etc., and issue the VC if the requirements are met.

S51p, the VC service provides the VC for sending the issued to the end-side wallet.

The above procedure is a procedure in which the VC service provider issues a VC for the end-side wallet, and a procedure in which the end-side wallet presents a VC and the VC service provider verifies the VC is described below.

And S52a, the end-side wallet sends the VC and the signature of the VC to a VC service provider.

For example, a VC service provider may be presented with a VC before a user wishes to use some of the functionality of a third party application through an end-side wallet.

The signature of the VC may be obtained by using a private key signature of the user DID, and when the end-side wallet sends the VC and the signature of the VC, the user DID is also sent.

S52b, the VC service provider requests the DID analysis service provider to analyze the user DID.

S52c, the DID resolution service returns the address of the issuer of the user DID to the VC service provider.

And S52d, the VC service provider requests the DID service provider to acquire the public key of the user DID based on the address of the issuer.

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

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

Wherein, S52b to S52f may refer to S51k to S51o, and will not be described herein.

And S52g, the VC service provider verifies the VC.

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.

And S52h, the VC service provides a verification result of returning the VC to the third party application.

The VC service provider sends the VC verification result to the third party application according to a callback interface of the VC verification result registered by the third party application.

Wherein the VC service provider signs the verification result with its own DID private key.

And S52i, the third party application returns a verification result of the VC to the end-side wallet.

And the third party application returns the verification result of the VC to the end-side wallet. If the verification is successful, the user can normally use the functional service provided by the third party application.

A VC processing method regarding VC application and verification provided by a further embodiment of the present application is described below with reference to fig. 6. In the flow shown in fig. 6, 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.

Fig. 6 is a schematic flow chart of application and verification of VC according to still another embodiment of the present application. The embodiments of S51a to S52g in fig. 6 may refer to S51a to S52g in fig. 5, and are not described here again. Alternatively, the steps of fig. 4 may be performed before the steps of fig. 6 are performed.

And S62h, the VC service provides a verification result of returning the VC to the end-side wallet.

For example, after the VC presented by the VC service provider to the end-side wallet passes the verification, the verification result is signed by the private key of its DID and the verification result and signature are returned to the end-side wallet.

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

When the third party application requires the user to present the VC, the user may send the verification result of the VC and the corresponding signature to the third party application via the end-side wallet.

And S62j, the third party application requests the DID analysis server to analyze the DID of the VC service provider.

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

S62l, 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.

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

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.

And S62k, the third party application returns a verification result to the end-side wallet.

If the signature verification of the VC verification result by the third party application is successful, the VC verification result can be sent to the end-side wallet, and the user can normally use the function service provided by the third party application.

In the method shown in fig. 6, after the VC service provider verifies the VC presented by the user, the user may sign the verification result with his own DID private key and then directly return to the end-side wallet. When the third party application needs the user to show the corresponding VC, the user can directly show the verification result carrying 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, so that the user can be ensured to normally use the function service provided by the third party application.

As can be seen from the content in fig. 6, in this method, the third party application does not need to register the callback interface in the corresponding VC service provider, thereby saving resources.

Fig. 7 is a flowchart of a VC processing method according to another embodiment of the present application. As shown in fig. 7, in S71, the traffic VC service provider communicates with the base VC service provider, registers to the base VC service provider what related information the traffic VC depends on, sets the authentication mode of the personal VC, and/or registers a callback interface for the authentication result.

Wherein, the related information on which the service VC depends can be understood as personal information required for generating or issuing the service VC; the verification manner of the personal VC can be understood as a manner of verifying whether the received personal VC meets the requirement; the verification result may include verification success or verification failure; the callback interface of the verification result may be understood as an interface where the base VC service provider indicates the verification result to the service VC service provider.

Accordingly, the service VC service provider instructs the basic VC service provider about personal information required for the service VC, a verification manner of the personal VC, and a callback interface of a verification result of the personal VC.

In S72, the end-side wallet transmits service information required for the service VC to the service VC service provider.

In S73, the traffic VC service provider instructs the end-side wallet to present the authentication result of the personal VC.

In S74, the end-side wallet sends a personal VC to the base VC service provider requesting the base VC service provider to authenticate the personal VC.

The base VC service verifies the personal VC sent by the end wallet based on a verification mode registered by the service VC service provider.

In S75, the base VC service provider transmits the authentication result of the personal VC to the traffic VC service provider.

In S76, the service VC service provides for issuing the service VC to the end-side wallet.

The basic VC service provider indicates the verification result of the personal VC to the service VC service provider according to a callback interface of the verification result of the personal VC set by the service VC service provider.

Optionally, in some embodiments of the present application, part or all of the relevant information on which the service VC depends, the authentication manner of the personal VC, and the callback interface of the authentication result may be preset on the base VC service provider, instead of being indicated by the service VC service provider.

Alternatively, in some embodiments of the present application, the traffic VC service provider may not need to set a callback interface for the validation result at the base VC service provider. In this embodiment, the base VC service provider may send the verification result directly to the end-side wallet instead of through the callback interface.

Optionally, before the service VC service provider communicates with the base VC service provider, the service VC service provider and/or the base VC service provider may first apply for a DID and establish a mutually trusted channel based on the DID. Thus, on one hand, the communication safety between the business VC service provider and the VC service provider can be improved, and on the other hand, login-free communication can be realized.

A schematic flow chart of a method for a traffic VC service provider and a base VC service provider to perform VC processing in case of applying a DID and establishing a mutually trusted channel based on the DID is described below in connection with fig. 8, 9 and 10.

Fig. 8 is a schematic flow chart of business service provider registration according to an embodiment of the present application. As shown in fig. 8, the process of performing DID registration by each role and performing personal VC-related content registration by the service VC service provider at the base VC service provider is included.

S81a, the business DID service provider registers the DID for itself.

S81b, the service VC service provider applies for registering DID to the service DID service provider.

And S81c, the service DID service provider returns the DID and the private key issued by the service DID service provider for the service VC service provider to the service VC service provider.

And S81d, the base DID service provider registers the DID for the base DID service provider.

S81e, the base VC service provider applies for registering DID to the base DID service provider.

And S81f, the base DID service provider returns the DID and the private key issued by the base DID service provider for the base VC service provider to the base VC service provider.

S82a, the business VC service provider sends channel establishment request information and a signature of the channel establishment request information to the basic VC service provider, the signature of the channel establishment request information is obtained through a private key signature of the business VC service provider, and the channel establishment request information comprises DID of the business VC service provider.

For example, the service VC service provider signs the channel establishment request information through a private key corresponding to its DID, and sends the signature information, the DID, and the channel establishment request information to the base VC service provider together to request establishment of a mutually trusted channel with the base VC service provider.

S82b, the base VC service provider requests the DID resolution service to resolve the DID of the traffic VC service provider.

After receiving the channel establishment request information sent by the service VC service provider, the base VC service provider sends DID analysis request information to the DID analysis service provider, wherein the DID analysis request information carries the DID of the second service VC service provider so as to obtain the address of the issuer of the DID of the service VC service provider.

And S82c, the DID analyzes the address of the issuer of the service direction basic VC service provider DID returned by the service direction basic VC service provider.

And S82d, the base VC service provider requests the service DID service provider to acquire the public key of the service VC service provider based on the address of the issuer.

For example, the base VC service provider may determine that the issuer is the foregoing service DID service provider according to the address returned by the DID resolution service provider, and send public key request information to the DID service provider, where the public key request information carries the DID of the service VC service provider to obtain a public key corresponding to the DID of the service VC service provider.

S82e, the service DID service provider returns the public key of the service VC service provider to the base VC service provider.

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

And S82f, the basic VC service provider verifies the signature information of the channel establishment request information by using the public key of the business VC service provider.

For example, the base VC service provider signs the channel setup request information using the public key of the traffic VC service provider and compares the signature with the signature information received from the traffic VC service provider; if the signature information is consistent, the signature information is confirmed to be successful, otherwise, the signature information is confirmed to be failed to verify.

S82g, the base VC service provider indicates to the traffic VC service provider that a mutually trusted communication channel has been established between the traffic VC service provider and the base VC service provider.

After this step is performed, it is indicated that the communication channel between the traffic VC service provider and the base VC service provider is mutually trusted.

S83a, the business VC service provider indicates personal information required by the business VC to the basic VC service provider, and sets the verification mode of the personal VC.

Alternatively, the personal VC may be a personal VC required when a service VC is issued by a service VC service provider.

For example, when a third party application provides a comment function for a user, the user is required to present a comment VC. If the user does not comment on the VC, the user needs to apply for the comment on the VC to the service VC service provider. In this example, the service VC is a comment VC, the personal information is personal information that needs to be provided by the user when the comment VC is issued, and the verification manner of the personal VC is a method for verifying whether the personal VC provided by the user issues the comment VC for the service provider.

And S83b, the basic VC service provider returns a setting result to the business VC service provider.

For example, after the personal information and the authentication mode of the personal VC required by the service VC are successfully recorded on the base VC service provider, an indication information of successful setting may be returned to the service VC service provider.

And S83c, the business VC service provides a callback interface for registering the verification result of the personal VC for the basic VC service provider.

For example, after the basic VC service provider registers personal information and a verification manner of the personal VC required by the service VC, the service VC service provider may set a callback interface, so that the basic VC service provider returns a verification result through the agreed callback interface, thereby ensuring that the service VC service provider can reliably and correctly reach the verification result.

And S83d, the basic VC service provider returns a setting result to the business VC service provider.

For example, after the callback interface on the base VC service provider successfully records the verification result of the personal VC, an indication of successful setting may be returned to the service VC service provider.

Fig. 9 is a schematic flow chart of a service VC issued by a service provider depending on personal information according to an embodiment of the present application. As shown in fig. 9, which includes the flow of VC issue and VC verification. Alternatively, the flow in fig. 9 may be performed after the flow shown in fig. 8 is performed.

Before executing the flow in fig. 9, the user has applied for registering the DID with the corresponding DID service provider through the end-side wallet, and applied for personal VC with the base VC service provider, which will not be described herein.

In case the DID service provider comprises a business DID service provider and a base DID service provider, optionally the user DID may comprise an application DID and an identity DID. In this case, the service DID service provider may issue the application DID and the private key to the user, and the base DID service provider issues the identity DID and the private key to the user.

The application DID and the identity DID of the user may be stored in an end-side wallet.

S91a, the end wallet sends the business VC request information and the signature of the business VC request information to the business VC service provider.

The signature of the service VC request information may be obtained by a private key signature corresponding to the application DID of the user in the end-side wallet, where the VC request information includes the application DID of the user.

And S91b, the service VC service provider sends indication information to the end side wallet, wherein the indication information is used for indicating information which needs to be filled in by the service VC and indicating the end side wallet to show the personal VC, and the indication information carries the address of the basic VC service provider.

S91c, the end-side wallet signs the personal VC multiple times.

The end-side wallet signs the individual VC using the private key of the user's application DID and the private key of the identity DID, proving that both DID are shared by the same user.

S91d, the end-side wallet sends the personal VC and multiple signatures of the personal VC to the base VC service provider.

For example, when a user wishes a traffic VC service provider to issue a traffic VC that depends on personal information, the personal VC may be presented to the base VC service provider.

When the end-side wallet sends the personal VC and the multiple signatures of the personal VC, the application DID and the identity DID of the user are also sent.

S91e, the base VC service provider requests the DID analysis service provider to analyze the identity DID of the user.

S91f, the DID analyzes the address of the issuer of the identity DID of the user returned by the service direction basic VC service provider.

Wherein the issuer of the identity DID of the user is the base DID service provider.

And S91g, the base VC service provider requests the base DID service provider to acquire the public key of the identity DID of the user based on the address of the issuer.

And S91h, returning the public key of the identity DID of the user to the basic VC service provider by the basic DID service provider.

S91i, the base VC service provider verifies the signature of the personal VC using the public key of the identity DID of the user.

For example, the base VC provider signs the personal VC using the public key of the user's identity DID and compares the signature to the signature received from the end-side wallet, if consistent, then the verification may be determined to be successful, otherwise the verification may be determined to be failed.

S91j, the base VC service provider requests the DID analysis service provider to analyze the application DID of the user.

S91k, the DID analyzes the address of the issuing party of the application DID of the service direction basic VC service provider, and returns the address of the issuing party of the application DID of the user.

The issuer of the application DID of the user is a service DID service provider.

S91l, the base VC service provider requests the service DID service provider to obtain the public key of the DID of the user application based on the address of the issuer.

S91m, the business DID service provider returns the public key of the user' S application DID to the base VC service provider.

S91n, the base VC service provider verifies the signature of the personal VC using the public key of the user' S application DID.

The signature verification method in this step may refer to S91i, and will not be described here.

S91o, the base VC service provider verifies the personal VC presented by the user.

After the multiple signatures of the personal VCs are verified by the basic service provider by using the public key of the DID of the user, the personal VCs are verified according to the verification method of the personal VCs registered by the service VC service provider.

S91p, the basic VC service provider records the corresponding relation between the identity DID of the user and the application DID of the user.

The basic VC service provider stores the corresponding relation between the identity DID of the user and the application DID of the user, so that the follow-up supervision operation is facilitated.

S91q, the base VC service provider returns the authentication result of the personal VC to the service VC service provider.

And the basic VC service provider sends the verification result of the personal VC to the service VC service provider according to a callback interface of the verification result of the personal VC registered by the service VC service provider.

S92a, the end wallet sends information filled in by the application service VC and a signature of the information to the service VC service provider, wherein the information also comprises the application DID of the user.

For example, after signing the filled information by using the private key of the application DID of the user, the end-side wallet sends the signature together with the information to the service VC service provider.

S92b, the service VC service provider requests the DID resolution service to resolve the application DID of the user.

S92c, the DID resolution service returns the address of the issuer of the user' S application DID to the service VC service provider.

And S92d, the business VC service provider requests the business DID service provider to acquire the public key of the application DID of the user based on the address of the issuer.

S92e, the service DID service provider returns the public key of the user' S application DID to the service VC service provider.

And S92f, the service VC service provider uses the public key of the user application DID to verify the signature of the information filled in the application service VC.

And S92g, the business VC service provider verifies the application information filled by the user.

As an example, the traffic VC service provider may verify whether the filled information meets the requirements, e.g., verify whether the filled information is complete, etc.

And S92h, the service VC service provider issues the service VC.

And after the information filled by the service VC service provider for the user and the personal VC of the user are verified by the basic VC service provider, issuing the service VC for the application DID of the user.

S92i, the service VC service provides the service VC that returns the issuance to the end-side wallet.

A VC processing method for a service provider to issue a service VC depending on personal information according to still another embodiment of the present application is described below with reference to fig. 10. In the flow shown in fig. 10, the base VC service provider does not return the verification result to the service VC service provider through the callback interface, but returns the verification result to the end-side wallet by signing the verification result.

Fig. 10 is a schematic flow chart of a service VC according to personal information issued by a service provider according to still another embodiment of the present application. The embodiments of S91a to S91p in fig. 10 may refer to S91a to S91p in fig. 9, and are not described here. Alternatively, the steps of fig. 8 may be performed before the steps of fig. 10 are performed.

S101q, the base VC service provides a verification result and signature of the personal VC back to the end-side wallet.

For example, after the personal VC presented by the base VC service provider to the end-side wallet passes the verification, the verification result is signed by the private key of its DID and the verification result and the signature are returned to the end-side wallet.

S102a, the end wallet sends information filled in by the application service VC and a signature of the information to the service VC service provider, wherein the information also comprises the application DID of the user, the verification result of the personal VC and the signature of the verification result.

And S102b, the business VC service provider requests the DID analysis service provider to analyze the application DID of the user and the DID of the basic VC service provider.

And S102c, the DID analyzes the addresses of the application DID of the user and the issuer of the DID of the basic VC service provider returned by the service direction business VC service provider.

And S102d, the business VC service provider requests the business DID service provider to acquire the public key of the application DID of the user based on the address of the issuer.

S102e, the service DID service provider returns the public key of the user' S application DID to the service VC service provider.

And S102f, the business VC service provider verifies the signature of the application DID of the user.

And S102g, the service VC service provider uses the public key of the user application DID to verify the signature of the information filled in the application service VC.

And S102h, the business VC service provider requests to acquire the public key of the DID of the basic VC service provider from the basic DID service provider based on the address of the issuer.

S102i, the base DID service provider returns the public key of the DID of the base VC service provider to the traffic VC service provider.

S102j, the service VC service provider verifies the signature of the verification result of the personal VC using the public key of the DID of the base VC service provider.

S102k, the service VC service provider issues the service VC.

And when the information filled by the user and the verification result of the personal VC are verified by the service VC service provider, the service VC is issued for the application DID of the user.

S102l, the service VC service provides service VC which returns to the end wallet.

In the method shown in fig. 10, after the basic VC service provider verifies the personal VC presented by the user, the user may sign the verification result with his own DID private key and then directly return to the end-side wallet. When the service VC service provider issues a service VC depending on personal information, a user may directly present, through an end-side wallet, a verification result carrying a signature of the base VC service provider to the service VC service provider, and the service VC service provider verifies the verification result, thereby issuing the service VC for the application DID of the user.

As can be seen from the content in fig. 10, in this method, the service VC service provider does not need to register a callback interface in the corresponding base VC service provider, thereby saving resources.

Fig. 11 is a flowchart of acquiring real name information of a user according to an embodiment of the present application. As shown in fig. 11, in S111, the user sends a login request and a signature to the third party application through the end-side wallet, the signature being obtained by the end-side wallet using the private key signature of the user 'S application DID, and the login request information further includes the user' S application DID.

For example, the end-side wallet signs the login request with a 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 to login to the third-party application.

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

After the signature verification of the login request by the third party application is successful, the second authentication can be performed on the end side wallet, and a login result is returned.

For example, the third party application may generate a verification value, encrypt the verification value, send the verification value to the end-side wallet, decrypt the received encrypted verification value by the end-side wallet, and return to the third party application. The third party application realizes the secondary authentication of the end side wallet by comparing whether the authentication value from the end side wallet is consistent with the authentication value generated by the third party application.

Optionally, if the third party application receives that the verification value is consistent with the verification value generated by the third party application, information of successful login is returned to the end-side wallet, and if the verification value is inconsistent with the verification value, information of incorrect verification value or login failure is sent to the end-side wallet.

In S113, the third party application sends a request query to the authority.

When a user uses a third party application, and a behavior of publishing incorrect language or uploading unreal content occurs, the third party application can identify that the user has illegal behaviors.

If the third party application monitors that the user has the illegal behaviors, the illegal behaviors are stored, and a request for inquiring real-name information and a signature of the request are sent to an authority. The signature can be obtained through private key signature of the third party application, and the request information also comprises the application DID of the user, the DID of the third party application and evidence of user violation, so as to request an authority to inspect the evidence of user violation.

In S114, the authority sends a request query message and a signature to the basic VC service provider, where the signature may be obtained by signing with a private key of the authority, and the request query message further includes an application DID of the user and a DID of the authority.

In S115, the base VC service provider returns real name information of the user to the authority.

After receiving the request information sent by the authority, the basic VC service provider determines the identity DID of the user according to the corresponding relation between the application DID and the identity DID of the user, and returns the real-name information of the user to the authority after calling the information filled in when the user applies for the identity DID.

In S116, the authority returns the real name information of the user to the third party application.

If the third party application receives the real name information of the user, the behavior of the user can be limited, and then the supervision problem of the third party application can be solved.

It should be noted that, after the user logs in the third party application with the DID, when the user needs to use some sensitive functions such as comment, uploading content, etc. function services, the third party application needs the user to complete real-name authentication, including the user applying, presenting and verifying the name information VC, and then providing the services to the user.

It should be understood that the function needs to be strictly limited, and before the third party application applies for obtaining the real-name information of the user, the corresponding service provider can return the real-name information of the user to the third party application after the evidence of the user's illegal behavior is presented.

Alternatively, the third party application may send the request to query real name information directly to the base VC service provider without going through an authority. And the basic VC service provider examines the illegal evidences of the users, and if the user is determined to have illegal behaviors, the real-name information of the users is queried and returned to the third party application directly.

Next, a method for acquiring real-name information of a user in the case where an offence occurs when the user uses a third party application will be described with reference to fig. 12.

Fig. 12 is a flowchart of acquiring real name information of a user according to still another embodiment of the present application. As shown in fig. 12, a process of logging in a third party application and obtaining real-name information of an offending user is included.

S121a, the end side wallet sends a login request to the third party application, wherein the login request carries the application DID of the user.

S121b, the third party application requests the DID resolution server to resolve the user' S application DID.

For example, after receiving the login request, the third party application initiates an analysis request to the DID analysis server, where the analysis request carries the user's application DID to obtain the address of the issuer of the user's application DID.

S121c, the DID resolution service returns the address of the issuer of the application DID of the user to the third party application.

S121d, the third party application requests the service DID service provider for obtaining the public key of the user' S application DID based on the address of the issuer.

S121e, the business DID service providing returns the public key of the user' S application DID to the third party application.

And S121f, the third party application generates a verification value and encrypts the verification value by using the public key of the user application DID to obtain the encrypted verification value.

For example, the third party application generates a random value as the authentication value used for login, and encrypts the authentication value by the public key of the user's application DID to obtain an encrypted authentication value.

S121g, the third party application sends the encrypted authentication value to the end-side wallet.

S121h, the end-side wallet decrypts the encrypted verification value by using the private key of the user application DID.

S121i, the end-side wallet returns the decrypted verification value and signature to the third-party application.

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

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

The signature verification method in this step may refer to S51d to S51h in fig. 5, and will not be described here. And when the signature verification is successful, the third party application verifies the verification value from the end-side wallet. For example, the third party application compares the authentication value generated by itself with the authentication value from the end-side wallet, if so, may determine that the authentication was successful, otherwise may determine that the authentication failed.

S121k, the third party application returns the login result to the end-side wallet.

Optionally, the end-side wallet may sign the login request by using a private key of the application DID of the user, and after receiving the login request, the third party application verifies the signature of the login request sent by the end-side wallet, and if the verification is passed, the user logs in successfully, so that the user's password-free login may be implemented.

And S122a, the third party application monitors the illegal behaviors of the user.

When a user uses a third party application, the third party application needs to monitor the behavior of the user, thereby constraining the behavior of the user. If the user uses the third party application, the third party application can identify the behavior as illegal behavior when the user issues incorrect language, uploads the illegal content and the like.

And S122b, the third party application sends request query information and the signature of the request information to the authority, wherein the signature of the request information is obtained through private key signature of the third party application, and the request query information comprises violation evidence of the user, application DID of the user and DID of the third party application.

For example, the third party application signs the request query information through its private key, and sends the evidence of the violation of the user, the sign information, the application DID of the user, the self DID, and the request query information together to the authority to request the authority to query the real-name information of the violating user.

And S122c, the authority requests the DID analysis server to analyze the DID of the third party application.

Wherein, the issuer of the third party application DID is a service DID service provider.

And S122d, the DID analysis service direction authority returns the address of the issuer of the DID of the third party application.

And S122e, the authority requests the service DID service provider to acquire the public key of the DID of the third-party application based on the address of the issuer.

And S122f, returning the public key of the DID of the third party application to the authority by the service DID service provider.

And S122g, the authority uses the public key of the third party application to verify the signature of the request query information.

And S122h, the authority reviews the illegal evidence of the user in the request query information.

For example, the authority verifies whether the user's evidence of the violation is authentic, e.g., whether the user's behavior belongs to the violation.

S122i, the authority sends request information and signature of the request information to the basic VC service provider, wherein the signature of the request information is obtained through private key signature of the authority, and the request information comprises application DID and self DID of a user.

For example, after the authority confirms that the user has the illegal action, the authority signs the request information through the private key of the authority, and sends the application DID of the user, the self DID and the signature information to the base VC service provider together, so as to request the base VC service provider to query the real name information of the user.

S122j, the base VC service provider requests the DID analysis service provider to analyze the DID of the authority.

S122k, the DID analyzes the address of the issuer of the DID of the service direction base VC service provider returns the authority.

Wherein, the issuer of the DID of the authority is a business DID service provider.

S122l, the base VC service provider requests the service DID service provider for the public key of the DID of the authority based on the address of the issuer.

S122m, the business DID service provider returns the public key of the DID of the authority to the base VC service provider.

And S122n, the base VC service provider verifies the signature of the request information by using the public key of the authority.

And S122o, the basic VC service provider determines the identity DID of the user according to the application DID of the user and the corresponding relation between the application DID and the identity DID of the user.

S122p, the basic VC service provider inquires real name information filled in when the user applies for the identity DID.

Wherein the real name information is stored in the base VC service provider. The basic VC service provider may invoke the information according to the DID.

S122q, the basic VC service provides real name information of the user returned by the direction authority.

And S122r, the authority returns real-name information of the user to the third party application.

After receiving the real-name information of the user, the third-party application limits the behavior of the user, for example, the user is required to delete the uploaded unreal information or the comment function of the third-party application is forbidden.

In the embodiment of the application, the service provider is divided into a business service provider and a basic service provider according to the security level of the user information. The basic service provider is endorsed by an authority to provide DID service and VC service for personal information of the user. The service provider is provided by each application service provider and provides DID service and VC service for user information of the user. When a service provider needs to issue a service VC using personal information of a user, a personal VC that needs to be verified when the base service provider registers the issue service VC may be registered and a judgment condition of the VC may be set. When the user has more than one DID, the basic service provider can determine the corresponding relation between the user identity DID and the user application DID through the signature information of the user, so that the user information can be conveniently inquired in a follow-up supervision mode. In the embodiment of the application, the third party application cannot contact the personal information and the service information of the user, and the service provider cannot contact the personal information of the user, so that the safety of the user information is ensured.

FIG. 13 is a schematic diagram of a processing device for verifiable claims according to an embodiment of the present application. As shown in fig. 13, the apparatus 130 of the present embodiment may include: an acquisition module 131, a transmission module 132, and a reception module 133.

The acquiring module 131 is configured to acquire related information of a first user; the sending module 132 is configured to send related information to the service provider, where the related information is used to generate a target VC, and the target VC is a verification statement that the first user uses the first service function through the third party application.

Optionally, the sending module 132 is specifically configured to send, to the service provider, service information required by the first user to use the first service function, where the service information is used by the service provider to generate the first VC; the above-mentioned transmitting module 132 is further configured to transmit, to the base service provider, personal information required for the first user to use the first service function, the personal information being used by the base service provider to generate the second VC.

Optionally, the receiving module 133 is configured to receive the first VC from the traffic service provider; the receiving module 133 is further configured to receive a second VC from the base service provider; the sending module 132 is further configured to send a first authentication request to the service provider, where the first authentication request is used to request the service provider to authenticate the first VC; the foregoing transmitting module 132 is further configured to send a second authentication request to the base service provider, where the second authentication request is used to request the base service provider to authenticate the second VC.

Optionally, the receiving module 133 is further configured to receive a first VC from the service provider, where the first VC is generated by the service provider if the first VC is successfully authenticated by the service provider to the second VC; the foregoing sending module 132 is further configured to send a first authentication request to the service provider, where the first authentication request is used to request the service provider to authenticate the first VC.

Optionally, the receiving module 133 is further configured to receive an authentication response from the third party application, where the authentication response is used to indicate whether the target VC is successfully authenticated.

Fig. 14 is a schematic structural diagram of a processing device for verifiable statement according to still another embodiment of the present application. As shown in fig. 14, the apparatus 140 of the present embodiment may include: a receiving module 141, a generating module 142, a transmitting module 143 and a verifying module 144.

The receiving module 141 is configured to generate, from related information of the first user of the digital money Bao Jieshou, a target VC, where the target VC is a verification statement that the first user uses the first service function through the third party application; the generating module 142 is configured to generate the target VC based on the related information.

Optionally, the sending module 143 is configured to send the first VC to the digital wallet; the receiving module 141 is further configured to receive a first authentication request from the digital wallet, where the first authentication request is for requesting the service provider to authenticate the first VC.

Optionally, the verification module 144 is configured to verify the first VC; the sending module 143 is further configured to send an authentication response to the third party application or the digital wallet, where the authentication response is used to indicate whether the first VC is successfully authenticated.

Optionally, the receiving module 141 is further configured to receive first configuration information from a third party application, where the first configuration information is used to indicate service information required for generating the first VC and an authentication manner of the first VC; the sending module 143 is further configured to send first prompt information to the digital wallet, where the first prompt information is used to instruct the user to input service information; the verification module 144 is specifically configured to verify the first VC using a verification manner.

Optionally, the above-mentioned verification module is further configured to verify the first VC in dependence on a verification result of the base service provider on the second VC, where the second VC is a VC generated by the base service provider based on personal information required by the first user to use the first service function; the receiving module 141 is further configured to receive an authentication response of the second VC from the base service provider, where the authentication response of the second VC is used to indicate whether the base service provider successfully authenticates the second VC; the verification module 144 is specifically configured to verify the first VC based on the verification response of the second VC.

Optionally, the sending module 143 is further configured to send the second VC to the digital wallet; the receiving module 141 is further configured to receive a second authentication request from the digital wallet, where the second authentication request is used to request the base service provider to authenticate the second VC; the sending module 143 is further configured to send an authentication response of the second VC to the digital wallet or the service provider, where the authentication response is used to indicate whether the second VC is successfully authenticated.

Optionally, the receiving module 141 is further configured to receive second configuration information from a third party application or a service provider, where the second configuration information is used to indicate personal information required for generating the second VC and a verification manner of the second VC; the sending module 143 is further configured to send second prompt information to the digital wallet, where the second prompt information is used to instruct the user to input personal information; the verification module 144 is further configured to verify the second VC using a verification method.

Optionally, the receiving module 141 is further configured to receive an information request from a trusted application, where the information request is used to request personal information; the above-mentioned transmitting module 143 is also used for transmitting personal information to the trusted application.

It should be understood that the apparatus 130 and the apparatus 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, dedicated, or group processor, etc.) and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that support the described functionality. In an alternative example, it will be understood by those skilled in the art that the apparatus 130 may be specifically an end-side wallet in the foregoing method embodiment, or the functions of the end-side wallet in the foregoing method embodiment may be integrated in the apparatus 130, and the apparatus 130 may be configured to perform each flow and/or step corresponding to the end-side wallet in the foregoing method embodiment, which is not repeated herein for avoiding repetition. The apparatus 140 may be specifically a service provider in the foregoing method embodiment, including a base service provider and a service provider, or the functions of the service provider in the foregoing method embodiment may be integrated in the apparatus 140, and the apparatus 140 may be configured to execute each flow and/or step corresponding to the service provider in the foregoing method embodiment, which is not repeated herein for avoiding repetition.

The above-mentioned device 130 has the function of implementing the corresponding steps performed by the end-side wallet in the above-mentioned method embodiment; the above-mentioned apparatus 140 has a function of implementing the corresponding steps performed by the service provider in the above-mentioned method embodiment; the above functions may be implemented by hardware, or may be implemented by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the functions described above.

FIG. 15 is a schematic structural diagram of a processing device for verifiable declaration according to still another embodiment of the present application. The apparatus 150 shown in fig. 15 may be used to perform any of the methods described above as being performed by any device in the service system 20.

As shown in fig. 15, the apparatus 150 of the present embodiment includes: memory 151, processor 152, communication interface 153, and bus 154. The memory 151, the processor 152, and the communication interface 153 are communicatively connected to each other via a bus 154.

The memory 151 may be a Read Only Memory (ROM), a static storage device, a dynamic storage device, or a random access memory (random access memory, RAM). The memory 151 may store a program, and when the program stored in the memory 151 is executed by the processor 152, the processor 152 is configured to perform any of the methods described above that are performed by any of the devices in the service system 20.

The processor 152 may employ a general-purpose central processing unit (central processing unit, CPU), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits for executing the associated program.

The processor 152 may also be an integrated circuit chip with signal processing capabilities. In implementation, various relevant steps of embodiments of the present application may be accomplished through integrated logic circuitry in hardware or instructions in software in processor 152.

The processor 152 may also be a general purpose processor, a digital signal processor (DIGITAL SIGNAL processing unit, DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (field programmable GATE ARRAY, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The steps of the method disclosed in connection with the embodiments of the present application may be embodied directly in the execution of a hardware decoding processor, or in the execution of a combination of hardware and software modules in a decoding processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in the memory 151 and the processor 152 reads the information in the memory 151 and in combination with its hardware performs the functions required by the units comprised in the device according to the application.

Communication interface 153 may enable communication between apparatus 150 and other devices or apparatuses using, but is not limited to, a transceiver or the like.

Bus 154 may include a path to transfer information between various components of device 150 (e.g., memory 151, processor 152, communication interface 153).

Some embodiments of the application also provide a computer program product which, when run on a processor, for example, processes a verifiable claim, can implement a method implemented by any element of a verifiable claim processing device in any of the embodiments described above. Some embodiments of the application also provide a computer readable storage medium having computer instructions embodied therein which, when executed on a processor, implement a method as in any of the embodiments described above as implemented by any element in a processing device of a verifiable claim.

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, for example: one or more Application SPECIFIC INTEGRATED Circuits (ASICs), or one or more microprocessors (DIGITAL SIGNAL processors, DSPs), or one or more field programmable gate arrays (field programmable GATE ARRAY, FPGAs), etc. For another example, when a module above is implemented in the form of a processing element calling program code, the processing element may be a general-purpose processor, such as a central processing unit (central processing unit, CPU) or other processor that may call program code, such as a controller. For another example, the modules may be integrated together and implemented in the form of a system-on-a-chip (SOC).

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, software modules or any combination thereof. When implemented in software, may 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 a computer, the processes or functions in accordance with embodiments of the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another, for example, by wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)), or wireless (e.g., infrared, wireless, microwave, etc.) means from one website, computer, server, or data center. Computer readable storage media can be any available media that can be accessed by a computer or data storage devices, such as servers, data centers, etc., that contain an integration of one or more available media. Usable media may be magnetic media (e.g., floppy disks, hard disks, magnetic tape), optical media (e.g., DVD), or semiconductor media (e.g., solid state disk Solid STATE DISK (SSD)), among others.

The term "plurality" herein refers to two or more. The term "and/or" is herein merely an association relationship describing an associated object, meaning that there may be three relationships, e.g., a and/or B, may represent: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship; in the formula, the character "/" indicates that the front and rear associated objects are a "division" relationship. In addition, it should be understood that in the description of the present application, the words "first," "second," and the like are used merely for distinguishing between the descriptions and not for indicating or implying any relative importance or order.

It will be appreciated that the various numerical numbers referred to in the embodiments of the present application are merely for ease of description and are not intended to limit the scope of the embodiments of the present application.

It should be understood that, in the embodiment of the present application, the sequence number of each process does not mean that the execution sequence of each process should be determined by the function and the internal logic, and should not limit the implementation process of the embodiment of the present application.

Claims

1. A method of processing a verifiable claim, comprising:

the digital wallet obtains the related information of a first user;

The digital wallet sends the related information to a service provider, wherein the related information is used for generating a target VC, and the target VC is an authentication statement that a first user uses a first service function through a third party application.

2. The method of claim 1, wherein the service provider comprises a base service provider and a traffic service provider, and the target VC comprises a first VC and a second VC;

Wherein the digital wallet sending information related to the first user to a service provider comprises:

the digital wallet sends service information required by the first user for using the first service function to the service provider, wherein the service information is used for the service provider to generate a first VC;

The digital wallet transmits personal information required by the first user to use the first service function to the base service provider, the personal information being used by the base service provider to generate a second VC.

3. The method according to claim 2, characterized in that the method comprises:

The digital wallet receiving the first VC from the traffic service provider;

The digital wallet receiving the second VC from the base service provider;

the digital wallet sends a first authentication request to the service provider, wherein the first authentication request is used for requesting the service provider to authenticate the first VC;

And sending a second authentication request to the basic service provider, wherein the second authentication request is used for requesting the basic service provider to authenticate the second VC.

4. The method of claim 2, wherein the personal information is further used by the base service provider to authenticate the second VC;

Wherein the method comprises the following steps:

the digital wallet receives the first VC from the traffic service provider, the first VC being generated by the traffic service provider if the base service provider successfully authenticates the second VC;

the digital wallet sends a first authentication request to the service provider, the first authentication request being for requesting the service provider to authenticate the first VC.

5. The method according to any one of claims 1 to 4, further comprising:

The digital wallet receives an authentication response from the third party application indicating whether the target VC is authenticated successfully.

6. A method of processing a verifiable claim, comprising:

The service provider receives related information of a first user from a digital wallet, wherein the related information is used for generating a target VC, and the target VC is an authentication statement that the first user uses a first service function through a third party application;

The service provider generates the target VC based on the related information.

7. The processing method according to claim 6, wherein the service provider is a service provider, the related information comprises service information required by the first user to use the first service function, and the target VC comprises a first VC;

the business service provider sends the first VC to the digital wallet;

the traffic service provider receives a first authentication request from the digital wallet, the first authentication request for requesting the traffic service provider to authenticate the first VC.

8. The method of claim 7, wherein the method further comprises:

the business service provider verifies the first VC;

The service provider sends an authentication response to the third party application or the digital wallet, the authentication response indicating whether the first VC is successfully authenticated.

9. The method of claim 8, wherein prior to the service provider receiving the first user related information from the digital wallet, the method further comprises:

The business service provider receives first configuration information from the third party application, wherein the first configuration information is used for indicating business information required by generating the first VC and an authentication mode of the first VC;

the business service providing module sends first prompt information to the digital wallet, wherein the first prompt information is used for indicating a user to input the business information;

Wherein the verifying, by the service provider, the first VC includes:

and the service provider uses the verification mode to verify the first VC.

10. A method according to claim 9, wherein the authentication means further comprises authenticating the first VC in dependence on authentication results of a base service provider for a second VC, the second VC being a VC generated by the base service provider based on personal information required by the first user to use the first traffic function;

Wherein the verifying the first VC by the service provider comprises:

The business service provider receives an authentication response of the second VC from a basic service provider, wherein the authentication response of the second VC is used for indicating whether the basic service provider successfully authenticates the second VC or not;

the traffic service provider authenticates the first VC based on an authentication response of the second VC.

11. The method of claim 6, wherein the service provider is a base service provider, the related information comprises personal information required by the first user to use the first traffic function, and the target VC comprises a second VC;

The base service provider sends the second VC to the digital wallet;

The base service provider receiving a second authentication request from the digital wallet, the second authentication request for requesting the base service provider to authenticate the second VC;

The base service provider sends an authentication response to the digital wallet or a service provider to the second VC, the authentication response indicating whether the second VC is authenticated successfully.

12. The method of claim 11, wherein prior to the service provider receiving the first user related information from the digital wallet, the method further comprises:

the basic service provider receives second configuration information from the third party application or the business service provider, wherein the second configuration information is used for indicating personal information required for generating the second VC and a verification mode of the second VC;

The basic service providing module sends second prompt information to the digital wallet, wherein the second prompt information is used for indicating a user to input the personal information;

Wherein the base service provider verifies the second VC, comprising:

And the basic service provider uses the verification mode to verify the second VC.

13. The method according to claim 11 or 12, further comprising:

The base service provider receiving an information request from a trusted application, the information request for requesting personal information;

the base service provider sends the personal information to the trusted application.

14. A processing device for verifiable claims, characterized by comprising respective functional modules for implementing the method of any one of claims 1 to 5 or of any one of claims 6 to 13.

15. A processing apparatus for verifiable claims, comprising: a memory and a processor;

The memory is used for storing program instructions;

The processor is configured to invoke program instructions in the memory to perform the method of any of claims 1 to 5 or any of claims 6 to 13.

16. A computer program product comprising computer program code which, when run on a computer, causes the computer to implement the method of any one of claims 1 to 5 or any one of claims 6 to 13.

17. A computer readable medium storing program code for computer execution, the program code comprising instructions for performing the method of any one of claims 1 to 5 or any one of claims 6 to 13.