Data authorization method, device and system, storage medium and electronic equipment
By storing and generating verifiable expression VP locally on the client side of the authentication service provider, the problems of complex data authorization process and insufficient security in the existing technology are solved, the process is simplified and data privacy protection is achieved, and the access cost is reduced.
Patent Information
- Application Number
- CN202510549533.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-28
- Publication Date
- 2025-09-19
AI Technical Summary
The data authorization process in existing technologies is complex and lacks security and privacy. Third-party applications need to connect to the processes of multiple authentication service providers, resulting in high access costs and low efficiency.
A decentralized distributed authentication system is used to migrate the user's authorized data stored remotely to the local client of the authentication service provider. The client directly interacts with the third-party application point-to-point to generate a verifiable expression VP and provide the authorized data.
It simplifies the data authorization process, protects user data security and privacy, reduces access costs, and reduces the need for access to each authentication service provider.
Smart Images
Figure CN120671114A_ABST
Abstract
Description
Technical Field
[0001] This specification relates to the field of computer technology, and in particular to a method, device, system, storage medium, and electronic device for data authorization. Background Art
[0002] With the widespread adoption of intelligent user terminals, a wide variety of service-providing applications are flourishing. To facilitate user access to a wide variety of applications, data interoperability and sharing between different applications has become an urgent need, leading to the emergence of Open Authorization (OAuth).
[0003] The core purpose of OAuth is to allow third-party applications to securely access a user's data or permissions on a platform without having to know the user's account and password. A typical application of OAuth is authorized login, where a user can directly log in to application B using their data on application A (such as their profile picture and nickname).
[0004] Data authorization through OAuth primarily involves three roles: the authentication service provider (corresponding to application A in the above example), the third-party application (corresponding to application B in the above example), and the resource owner (i.e., the user). The third-party application must pre-register with the authentication service provider and obtain and configure information such as its ID and key. The authentication service provider uses this information to identify the third-party application and ensure data transmission security.
[0005] In the prior art, when a user authorizes data in a third-party application, the third-party application will first jump to the authentication service provider's page. After the authentication service provider verifies the user's identity, it generates an authorization code (Auth Code) and returns it to the third-party application. The third-party application obtains an access token (Access Token) from the authentication service provider through the authorization code. The third-party application requests the user's data from the authentication service provider through the access token (Access Token). After the authentication service provider verifies the validity of the token, it provides the data to the third-party application, and the entire authorization process is completed.
[0006] However, the entire data authorization process mentioned above must be conducted through the authentication service provider's server, which makes the entire data authorization process relatively complicated. The authentication service provider can also easily obtain all user authorization records, which poses a significant problem for user data security and privacy. In addition, in terms of development integration, third-party applications may need to integrate with multiple authentication service providers. Multiple authentication service providers mean that third-party applications need to integrate with multiple sets of processes, which increases integration costs and reduces efficiency. Summary of the Invention
[0007] The embodiments of this specification provide a method, device, system, storage medium, and electronic device for data authorization to partially solve the problems existing in the above-mentioned prior art.
[0008] The embodiments of this specification adopt the following technical solutions:
[0009] This specification provides a data authorization method, which is applied to a client of an authentication service provider; the method includes:
[0010] Receive data authorization requests from third-party applications;
[0011] According to the data authorization request, determining whether there is a verifiable credential VC for data to be authorized corresponding to the data authorization request in the user data stored locally on the client;
[0012] If so, upon receiving the first authorization from the user, a verifiable expression VP is generated based on the VC of the data to be authorized stored in the client itself, and the VP is returned to the third-party application, so that the third-party application can obtain the data to be authorized in the VP after verifying the VP.
[0013] This specification provides a data authorization method, which is applied to third-party applications; the method includes:
[0014] Sending a data authorization request to the client of the authentication service provider;
[0015] Receiving a verifiable expression VP returned by the client; wherein the VP is generated by the client according to the verifiable credential VC of the data to be authorized corresponding to the data authorization request when receiving the first authorization from the user;
[0016] The VP is verified, and after the verification is passed, the data to be authorized carried in the VP is obtained.
[0017] This specification provides a data authorization system, which includes a third-party application and a client of an authentication service provider; wherein:
[0018] The third-party application is used to send a data authorization request to the client;
[0019] The client is configured to, in response to the data authorization request, determine whether there is a verifiable credential (VC) for the data to be authorized corresponding to the data authorization request in the user's data stored locally on the client; if so, upon receiving the first authorization from the user, generate a verifiable representation (VP) based on the VC for the data to be authorized stored on the client itself, and return the VP to the third-party application;
[0020] The third-party application is further configured to verify the received VP and obtain the data to be authorized carried in the VP after the verification is successful.
[0021] This specification provides a data authorization device, which is applied to a client of an authentication service provider; the device includes:
[0022] A receiving module, used to receive data authorization requests sent by third-party applications;
[0023] A determination module, configured to determine, based on the data authorization request, whether there is a verifiable credential VC of the data to be authorized corresponding to the data authorization request in the user data stored locally on the device;
[0024] an authorization module configured to generate a verifiable expression VP based on the VC of the data to be authorized stored in the device itself when receiving the first authorization from the user if the judgment result of the judgment module is yes, and return the VP to the third-party application, so that the third-party application can obtain the data to be authorized in the VP after successfully verifying the VP.
[0025] This specification provides a data authorization device, which is applied to third-party applications; the device includes:
[0026] A sending module, configured to send a data authorization request to the client of the authentication service provider;
[0027] a receiving module, configured to receive a verifiable expression VP returned by the client; wherein the VP is generated by the client according to the verifiable credential VC of the data to be authorized corresponding to the data authorization request when the client receives the first authorization from the user;
[0028] The acquisition module is configured to verify the VP and obtain the data to be authorized carried in the VP after the verification is passed.
[0029] This specification provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the above-mentioned data authorization method is implemented.
[0030] This specification provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned data authorization method when executing the program.
[0031] At least one of the above technical solutions adopted in the embodiments of this specification can achieve the following beneficial effects:
[0032] The embodiments of this specification disclose a method for data authorization, in which the client directly provides the locally stored data to be authorized to a third-party application for use, thereby bypassing the server of the authentication service provider. This method can greatly simplify the data authorization process, and the authentication service provider cannot grasp the user's authorization behavior. In addition, since the client provides the data to be authorized to the third-party application in the form of generating a VP based on the VC of the data to be authorized and then returning the VP to the third-party application, as long as the third-party application can authenticate the VP, it can obtain and use the data to be authorized, thereby eliminating the need to access a set of authentication processes for each authentication service provider, which can effectively reduce the access cost. BRIEF DESCRIPTION OF THE DRAWINGS
[0033] The drawings described herein are used to provide a further understanding of this specification and constitute a part of this specification. The exemplary embodiments and descriptions of this specification are used to explain this specification and do not constitute an improper limitation of this specification. In the drawings:
[0034] Figure 1 A schematic diagram of a data authorization system structure provided in an embodiment of this specification;
[0035] Figure 2 A flow chart of a data authorization method provided in an embodiment of this specification;
[0036] Figure 3 A schematic diagram of a data authorization device provided in an embodiment of this specification;
[0037] Figure 4 A schematic diagram of another data authorization device provided in an embodiment of this specification;
[0038] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification. DETAILED DESCRIPTION
[0039] It can be seen from the data authorization process in the existing technology that the data authorization in the existing technology is a centralized authorization method with the authentication service provider's server as the center. That is, the data to be authorized stored by the user in the authentication service provider's server is directly provided by the authentication service provider's server to the third-party application for use. Because of this, the authentication service provider can easily know which third-party application the user has authorized which data, which brings hidden dangers to the user's data security and privacy. In addition, the authorization process is complicated, and the third-party application also needs to connect to different processes for different authentication service providers.
[0040] Therefore, the embodiments of this specification adopt a decentralized distributed authentication system to realize direct data authorization across applications, migrate the user's data to be authorized stored in the remote authentication service provider's server to the local client of the authentication service provider, and adopt a point-to-point approach in the distributed system to provide the data to be authorized directly to the third-party application in the client.
[0041] To make the objectives, technical solutions, and advantages of this specification more clear, the following will clearly and completely describe the technical solutions of this specification in conjunction with the specific embodiments of this specification and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of this specification.
[0042] The technical solutions provided by the embodiments of this specification are described in detail below with reference to the accompanying drawings.
[0043] Figure 1 This is a schematic diagram of a data authorization system structure provided in an embodiment of this specification, such as Figure 1 As shown, the system includes a third-party application, a client of an authentication service provider, and a server of an authentication service provider.
[0044] Among them, third-party applications and clients are front-end applications installed on the user's terminal, while the server is a remote server.
[0045] Third-party applications, clients, and servers are all nodes pre-registered on the distributed authentication system, and all have their own decentralized identifiers (DIDs). DID is the identity identifier of a node on the distributed authentication system, which is used to replace the traditional user name or account number, and is unique on the distributed authentication system. In the embodiments of this specification, when any node (any one of the third-party applications, clients, and servers) is registered in the distributed authentication system, the system will generate a unique DID for the node and associate the DID with a DID file. The DID file is stored in the distributed authentication system (specifically, it can be stored in each node of the distributed authentication system), which contains the public key, service endpoint, and other metadata corresponding to the DID for verifying the signature and resolving the identity. The private key corresponding to the DID is saved by the node itself.
[0046] Based on the above data authorization system, this specification embodiment provides a data authorization method, such as Figure 2 shown. Figure 2 A flowchart of a data authorization method provided in an embodiment of this specification includes the following steps:
[0047] S200: The client receives a data authorization request sent by a third-party application.
[0048] The client described in this specification refers to the client of the authentication service provider, which is installed on the user's terminal. The authentication service provider itself is also an application. In addition to providing data authorization and authentication services, it can also provide other services, such as instant messaging services. The third-party application is also installed on the user's terminal. It is another application that is different from the client of the authentication service provider (hereinafter referred to as the client). The third-party application can be another application installed on the user's terminal independently of the client, or it can be a small program that relies on the client and is parasitic on the client.
[0049] When a user launches a third-party application and needs to obtain services provided by the third-party application, if the services provided by the third-party application to the user require the use of the user's data on the authentication service provider, the user can send an authorization indication message to the third-party application. The authorization indication message is used to authorize the third-party application to obtain and use the corresponding data to be authorized from the authentication service provider. After receiving the authorization indication message, the third-party application can send a data authorization request to the client. The data authorization request is used to request the use of the data to be authorized.
[0050] For example, suppose Application A is an instant messaging application, and Application B is a gaming application. When a user launches and uses Application B to play a game, Application B requires the user's avatar and nickname in Application A to log in. In this case, Application A is the authentication service provider, Application B is a third-party application, and the data to be authorized is the user's avatar and nickname in Application A. Application B may first display a preset inquiry interface to ask the user whether to authorize Application B to use Application A's avatar and nickname for login. If Application B receives a confirmation message input by the user, it will use the confirmation message as an authorization indication message indicating that the user allows Application B to use Application A's avatar and nickname for login. Application B will then send a data authorization request to Application A's client, requesting Application A to provide the data to be authorized, namely, the user's avatar and nickname in Application A.
[0051] S202: Based on the data authorization request, determine whether there is a VC of the data to be authorized corresponding to the data authorization request in the user data stored locally on the client. If so, execute step S210; otherwise, execute step S204.
[0052] After receiving the data authorization request sent by the third-party application in step S200, the client may first determine the data to be authorized corresponding to the data authorization request, that is, the data of the user at the authentication service provider that the third-party application requests to obtain and use.
[0053] After determining the data to be authorized, the client can continue to query locally whether the verifiable credentials (VC) of the data to be authorized are saved.
[0054] In the embodiments of this specification, VC is a tamper-proof digital certificate in a distributed authentication system, signed by the issuer (Issuer), and used to prove certain attributes of the holder (Holder) of the VC. The VC of the above-mentioned data to be authorized carries the complete data to be authorized, which is used to prove that the client actually owns the data to be authorized. If the client locally stores the VC of the data to be authorized, steps S210 to S216 can be directly executed to provide the data to be authorized to a third-party application for use. If the client does not locally store the VC of the data to be authorized, steps S204 to S208 can be executed to apply to the Issuer in the distributed authentication system for the issuance of the VC of the data to be authorized.
[0055] S204: The client applies to the server for VC of the data to be authorized based on its own DID.
[0056] S206: The server generates a VC carrying the data to be authorized based on the server's own DID and the data to be authorized, and returns it to the client.
[0057] S208: The client receives and stores the VC returned by the server.
[0058] Figure 2 Steps S204 to S208 are the process of the client applying for VC from the server for the data to be authorized in this embodiment. That is, in this embodiment, the server of the authentication service provider (hereinafter referred to as the server) only serves as the Issuer node in the distributed authentication system.
[0059] If the client determines in step S202 that the VC for the data to be authorized is not locally stored, it may send a request to the server for the VC for the data to be authorized, based on its own DID. Specifically, the client may use the private key corresponding to its DID to sign the request for the VC for the data to be authorized and send it to the server. After the server verifies the signature, it confirms that the request is indeed issued by the client and issues the VC for the data to be authorized to the client.
[0060] When issuing a VC containing the data to be authorized to the client, the server may first retrieve the data to be authorized stored on its own. Based on the server's own DID and the data to be authorized, the server generates a VC containing the data to be authorized and returns it to the client. Specifically, the server may first construct a VC containing the data to be authorized, sign the constructed VC using the private key corresponding to the server's DID, and return the signed VC to the client as the generated VC containing the data to be authorized.
[0061] Furthermore, since the data to be authorized is stored on the server, the user is the owner of the data to be authorized. Therefore, before the client requests a VC of the data to be authorized from the server, and before the server issues the VC of the data to be authorized to the client, both the client and the server must obtain authorization from the user. This is referred to as "second authorization" in the embodiments of this specification. Specifically, before requesting a VC of the data to be authorized from the server, the client may send a first inquiry message to the user, asking whether the user allows the client to migrate the user's data to be authorized from the server to the client. If the client receives a confirmation message from the user in response to the first inquiry message, it is determined that the user's second authorization has been received, and a request may be sent to the server to request a VC of the data to be authorized.
[0062] Furthermore, the client may include the confirmation message (i.e., the second authorization) returned by the user in the request for the VC of the data to be authorized and send it to the server, so that the server can also determine that the request for issuing the VC of the data to be authorized is authorized by the user. That is, the server also obtains the user's second authorization through the request sent by the client. After obtaining the user's second authorization, the server issues the VC of the data to be authorized to the client. Of course, after receiving the request for the VC of the data to be authorized from the client, the server may also send a second inquiry message to the user to inquire whether the client is allowed to migrate the user's data to be authorized from the server to the local computer. After receiving the confirmation message returned by the user in response to the second inquiry message, the server determines that the user's second authorization has been received and then issues the VC of the data to be authorized to the client.
[0063] After the server returns the VC of the data to be authorized to the client, the client stores the received VC of the data to be authorized locally and may continue to execute step S210.
[0064] Continuing with the above example, if the client of application A determines that the VC of the user's avatar and nickname is not stored locally, it will send a first inquiry message to the user, asking the user whether to allow the avatar and nickname on application A to be downloaded locally for use by other third-party applications (including application B). If a confirmation message from the user is received, the confirmation message will be carried in the request for applying for the VC of the user's avatar and nickname on application A from the server of application A, and the request will be signed using the private key corresponding to the DID of the client of application A, and the signed request will be sent to the server of application A.
[0065] After receiving the request, the server of application A first verifies the signature of the request based on the public key corresponding to the DID of the client of application A. After the signature verification is passed, it confirms that the request carries the confirmation message of the user, then obtains the user's avatar and nickname, and constructs a VC carrying the user's avatar and nickname. Then, it signs the VC based on the private key corresponding to the DID of the server of application A, and returns the signed VC to the client of application A for storage.
[0066] At this point, the client of application A has already migrated the user's avatar and nickname from application A to its local computer in the form of a VC. If another third-party application (such as application B) subsequently seeks authorization to use the user's avatar and nickname, the client of application A can directly provide the user's avatar and nickname to the third-party application based on the locally stored VC. Because each node in a distributed authentication system interacts via point-to-point communication, the client of application A can provide the user's avatar and nickname to the third-party application directly based on the locally stored VC, without having to go through application A's server.
[0067] S210: upon receiving the first authorization from the user, generating a verifiable expression VP according to the verifiable credential VC of the data to be authorized stored by the client itself.
[0068] S212: Return the VP to the third-party application.
[0069] S214: The third-party application receives the VP returned by the client and verifies the VP.
[0070] S216: After the verification is passed, the data to be authorized carried in the VP is obtained.
[0071] Figure 2 Steps S210 to S216 are a process in which the client provides data to be authorized to a third-party application in an embodiment of this specification.
[0072] If the client has already stored a VC of the data to be authorized locally, then since the owner of the data to be authorized carried in the VC is the user, the client may first send a third inquiry message to the user. The third inquiry message is used to inquire whether the user allows the third-party application to use the data to be authorized. If a confirmation message is received from the user in response to the third inquiry message, it can be confirmed that the user's authorization has been received, which is referred to as the first authorization in the embodiment of this specification. Of course, since in step S200, when the third-party application needs to use the user's data on the authentication service provider, it has already sent a data authorization request to the client after obtaining the authorization indication message sent by the user, therefore, in step S200, the third-party application may also carry the above-mentioned authorization indication message sent by the user in the data authorization request and send it to the client. In step S210, the client may deem that it has received the first authorization from the user when it determines that the data authorization request received in step S200 carries the authorization indication message sent by the user.
[0073] After the client obtains the user's first authorization, it can generate a Verifiable Presentation (VP) based on the VC of the data to be authorized stored by the client itself. VP is a form of encapsulation of VC, which can disclose the entire content of VC, or selectively disclose part of the VC content, and can also encapsulate other proof information, such as the client's own signature.
[0074] Specifically, in step S206, the VC returned by the server to the client may not only contain the data to be authorized, but also contain other data that the client may need to authorize to other third-party applications in the future. At this time, the VC stored locally on the client not only carries the data to be authorized, but also carries other data. However, since the third-party application only requests authorization to use the data to be authorized, the client can selectively generate a VP based on the data to be authorized carried in the VC, while hiding other data in the VC except the data to be authorized, and then carry the server's signature in the VC (the server's signature is the signature made by the server using the private key corresponding to the server's own DID) in the VP, and the result is the VP of the data to be authorized.
[0075] In addition, the client may also carry its own signature in the VP. The client's own signature is a signature made by the client according to the private key corresponding to the client's own DID.
[0076] After the client sends the VP to a third-party application, the third-party application can verify the VP. Specifically, it can first query the public key corresponding to the server's DID based on the server's DID. Using this public key, it can verify the server's signature in the VP to verify that the VC corresponding to the VP was issued by the server. If the VP also contains the client's signature, it can query the public key corresponding to the client's DID based on the client's DID. Using this public key, it can verify the client's signature in the VP to verify that the sender of the VP is the client.
[0077] After all the above verifications are passed, the authorized data can be extracted from the VP for use. If at least one verification fails, the VP can be considered to be forged and discarded directly.
[0078] In addition, in order to further ensure the security of the data, Figure 2 In step S212, when the client returns the VP to the third-party application, it may also encrypt the VP using the third-party application's public key. Specifically, the client may first query the public key corresponding to the third-party application's DID based on the third-party application's DID, then encrypt the VP using the public key corresponding to the third-party application's DID, and then return the encrypted VP to the third-party application.
[0079] Correspondingly, in step S214, the third-party application needs to first use the private key corresponding to its own DID to decrypt the encrypted VP, then verify the decrypted VP, and obtain the data to be authorized carried in the decrypted VP after the verification is passed.
[0080] The above method registers the third-party application, the client of the authentication service provider, and the server of the authentication service provider as nodes in the distributed authentication system. The server is only used as the Issuer in the distributed authentication system. When providing the data to be authorized, the client directly provides the locally stored data to be authorized in the form of VP to the third-party application, thereby bypassing the server of the authentication service provider, which can greatly simplify the data authorization process.
[0081] Furthermore, because nodes in a distributed authentication system interact directly with each other through point-to-point communication, once the server issues the data to be authorized (VC) to the client, it cannot easily determine which third-party application the client has authorized to use the VC (VP), effectively protecting user data security and privacy. Furthermore, using this method, as long as a third-party application registers as a node in the distributed authentication system, it can authenticate the VP and obtain and use the data to be authorized. This eliminates the need to integrate a separate authentication process with each authentication service provider, effectively reducing access costs.
[0082] The above is a method for data authorization provided in an embodiment of this specification. Based on the same idea, this specification also provides corresponding devices, storage media and electronic devices.
[0083] Figure 3 A schematic diagram of a data authorization device provided in an embodiment of this specification is shown as follows: Figure 3 The device shown is applied to a client of an authentication service provider; the device includes:
[0084] Receiving module 301, used to receive a data authorization request sent by a third-party application;
[0085] A determination module 302 is configured to determine, based on the data authorization request, whether there is a verifiable credential VC for the data to be authorized corresponding to the data authorization request in the user data stored locally on the device;
[0086] The authorization module 303 is used to generate a verifiable expression VP based on the VC of the data to be authorized stored in the device itself when receiving the first authorization from the user if the judgment result of the judgment module is yes, and return the VP to the third-party application, so that the third-party application can obtain the data to be authorized in the VP after verifying the VP.
[0087] Optionally, the device, the third-party application, and the server of the authentication service provider are all pre-registered with their respective decentralized identifiers DID on the distributed authentication system;
[0088] The authorization module 303 is further configured to, if the VC of the data to be authorized corresponding to the data authorization request does not exist in the user data stored locally in the device, apply for the VC of the data to be authorized from the server according to the DID of the device itself, and store the VC.
[0089] Optionally, the authorization module 303 is further configured to determine whether a second authorization of the user is received before applying to the server for the VC of the data to be authorized.
[0090] Optionally, the authorization module 303 is specifically configured to encrypt the VP according to a public key corresponding to the DID of the third-party application; and return the encrypted VP to the third-party application.
[0091] Figure 4 A schematic diagram of another data authorization device provided in an embodiment of this specification is shown as follows: Figure 4 The device shown is applied to third-party applications; the device includes:
[0092] The sending module 401 is used to send a data authorization request to the client of the authentication service provider;
[0093] Receiving module 402, configured to receive a verifiable expression VP returned by the client; wherein the VP is generated by the client according to the verifiable credential VC of the data to be authorized corresponding to the data authorization request when receiving the first authorization from the user;
[0094] The acquisition module 403 is configured to verify the VP and obtain the data to be authorized carried in the VP after the verification is successful.
[0095] Optionally, the client, the device and the server of the authentication service provider are all pre-registered with their own decentralized identifiers DID on a distributed authentication system;
[0096] The VC is the VC of the data to be authorized that the client applies to the server according to the DID of the client itself;
[0097] The acquisition module 403 is specifically configured to verify, based on the DID of the server, whether the VC corresponding to the VP is issued by the server; and / or, based on the DID of the client, verify whether the sender of the VP is the client.
[0098] Optionally, the VP returned by the client is the VP encrypted by the client using the public key corresponding to the DID of the device;
[0099] The acquisition module 403 is specifically configured to decrypt the encrypted VP using the private key corresponding to the DID of the device; verify the decrypted VP, and obtain the data to be authorized carried in the decrypted VP after the verification is passed.
[0100] This specification also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it can be used to execute the data authorization method provided above.
[0101] based on Figure 2 The data authorization method shown in this specification also provides Figure 5 The structural diagram of the electronic device shown in FIG. Figure 5 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, memory, and non-volatile storage, and may also include other hardware required for its services. The processor reads the corresponding computer program from the non-volatile storage into the memory and then runs it to implement the aforementioned data authorization method.
[0102] The foregoing is merely an example of the present invention and is not intended to limit the present invention. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention are intended to be included within the scope of the claims of the present invention.
Claims
1. A data authorization method, the method being applied to a client of an authentication service provider; the method comprising: Receive data authorization requests from third-party applications; According to the data authorization request, determining whether there is a verifiable credential VC for the data to be authorized corresponding to the data authorization request in the user data stored locally on the client; If so, upon receiving the first authorization from the user, a verifiable expression VP is generated based on the VC of the data to be authorized stored in the client itself, and the VP is returned to the third-party application, so that the third-party application can obtain the data to be authorized in the VP after verifying the VP.
2. The method according to claim 1, wherein the client, the third-party application, and the authentication service provider's server are all pre-registered with their respective decentralized identifiers (DIDs) on a distributed authentication system; If the VC of the data to be authorized corresponding to the data authorization request does not exist in the user data stored locally on the client, the method further includes: According to the DID of the client itself, the client applies to the server for the VC of the data to be authorized, and stores the VC.
3. The method according to claim 2, before applying to the server for the VC of the data to be authorized, the method further comprises: It is determined that a second authorization of the user is received.
4. The method according to claim 2, wherein returning the VP to the third-party application comprises: Encrypting the VP according to the public key corresponding to the DID of the third-party application; The encrypted VP is returned to the third-party application.
5. A data authorization method, applied to a third-party application; the method comprising: Sending a data authorization request to the client of the authentication service provider; Receiving a verifiable expression VP returned by the client; wherein the VP is generated by the client according to the verifiable credential VC of the data to be authorized corresponding to the data authorization request when receiving the first authorization from the user; The VP is verified, and after the verification is passed, the data to be authorized carried in the VP is obtained.
6. The method according to claim 5, wherein the client, the third-party application, and the authentication service provider's server are all pre-registered with their respective decentralized identifiers (DIDs) on a distributed authentication system; The VC is the VC of the data to be authorized that the client applies to the server according to the DID of the client itself; Verifying the VP includes: Verify, based on the DID of the server, whether the VC corresponding to the VP is issued by the server; and / or, verifying, based on the DID of the client, whether the sender of the VP is the client.
7. The method according to claim 6, wherein the VP returned by the client is the VP encrypted by the client using the public key corresponding to the DID of the third-party application; Verifying the VP and obtaining the data to be authorized carried in the VP after the verification is successful, specifically including: Decrypt the encrypted VP using the private key corresponding to the DID of the third-party application; The decrypted VP is verified, and after the verification is passed, the data to be authorized carried in the decrypted VP is obtained.
8. A data authorization system, comprising a third-party application and a client of an authentication service provider; wherein: The third-party application is used to send a data authorization request to the client; The client is configured to, in response to the data authorization request, determine whether there is a verifiable credential (VC) for the data to be authorized corresponding to the data authorization request in the user's data stored locally on the client; if so, upon receiving the first authorization from the user, generate a verifiable representation (VP) based on the VC for the data to be authorized stored on the client itself, and return the VP to the third-party application; The third-party application is further configured to verify the received VP and obtain the data to be authorized carried in the VP after the verification is successful.
9. The system of claim 8, further comprising: The server of the authentication service provider; The client, the third-party application, and the server are all pre-registered with their respective decentralized identifiers (DIDs) on the distributed authentication system; The client is further configured to, if the VC of the data to be authorized corresponding to the data authorization request does not exist in the user data locally stored in the client, apply to the server for the VC of the data to be authorized according to the DID of the client itself, and store the VC; The server is configured to, in response to the client's request for the VC of the data to be authorized, generate a VC carrying the data to be authorized based on the server's own DID and the data to be authorized, and return the VC to the client.
10. A data authorization device, the device being applied to a client of an authentication service provider; the device comprising: A receiving module, used to receive data authorization requests sent by third-party applications; A determination module, configured to determine, based on the data authorization request, whether there is a verifiable credential VC of the data to be authorized corresponding to the data authorization request in the user data stored locally on the device; an authorization module configured to generate a verifiable expression VP based on the VC of the data to be authorized stored in the device itself when receiving the first authorization from the user if the judgment result of the judgment module is yes, and return the VP to the third-party application, so that the third-party application can obtain the data to be authorized in the VP after successfully verifying the VP.
11. A data authorization device, the device being applied to a third-party application; the device comprising: A sending module, configured to send a data authorization request to the client of the authentication service provider; a receiving module, configured to receive a verifiable expression VP returned by the client; wherein the VP is generated by the client according to the verifiable credential VC of the data to be authorized corresponding to the data authorization request when the client receives the first authorization from the user; The acquisition module is configured to verify the VP and obtain the data to be authorized carried in the VP after the verification is passed.
12. A computer-readable storage medium storing a computer program, wherein the computer program implements the method according to any one of claims 1 to 7 when executed by a processor.
13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 7 when executing the program.