Authorization management method and device based on DID credential data flow, electronic device and storage medium

Abstract

The present application discloses an authorization management method and device, electronic device and storage medium based on DID credential data flow. The method includes: receiving a user's credential data authorization query request, wherein the credential data authorization query request contains authorized party information and credential information; obtaining credential data authorization record data according to the authorized party information; and generating credential data authorization query results according to the credential data authorization record data and credential information. The embodiments of the present application not only ensure the security of user information during the query process, but also provide users with higher authorization management efficiency.

Description

Technical Field

[0001] The present application relates to the field of network technology, and in particular to an authorization management method and device, electronic device and storage medium based on DID credential data flow. Background Art

[0002] With the development of Internet technology, people can increasingly live and work through the Internet, and therefore, various websites built on the Internet have emerged to provide users with various services. Due to the identity anonymity of the Internet, websites often cannot know the true identity of users who visit or log in to their websites, and therefore cannot regulate and manage the users' use of services accordingly. For this reason, the prior art has proposed that users need to pre-register their identity information in the website they visit or log in to, so that the website can provide services to users based on the identity information submitted by the user when the user requests to use the website's services. In this process, users need to provide the original data of their identity information to the website and then save it in the website's server, but such identity information is usually the user's private data. Therefore, when users use the services provided by different websites, they also have to store their private data on each website, which greatly increases the risk of user privacy exposure. In this regard, a solution that can ensure the security of users' private data is needed. Summary of the invention

[0003] The embodiments of the present application provide an authorization management method and device, an electronic device, and a storage medium based on the flow of DID credential data to solve the defect in the prior art that the privacy data of users lacks security when using Internet services.

[0004] To achieve the above purpose, the embodiment of the present application provides an authorization management method based on DID credential data flow, including:

[0005] Receiving a credential data authorization query request from a user, wherein the credential data authorization query request includes authorized party information and credential information;

[0006] Acquire credential data authorization record data according to the authorized party information;

[0007] A credential data authorization query result is generated according to the credential data authorization record data and the credential information.

[0008] The embodiment of the present application also provides an authorization management device based on DID credential data flow, including:

[0009] A first receiving module is used to receive a credential data authorization query request from a user, wherein the credential data authorization query request includes authorized party information and credential data information;

[0010] A first acquisition module, used to acquire credential data authorization record data according to the authorized party information;

[0011] A generation module is used to generate a credential data authorization query result according to the credential data authorization record data and the credential data information.

[0012] The present application also provides an electronic device, including:

[0013] Memory, used to store programs;

[0014] A processor is used to run the program stored in the memory, and when the program is running, the authorization management method based on DID credential data flow provided in an embodiment of the present application is executed.

[0015] An embodiment of the present application also provides a computer-readable storage medium, on which a computer program executable by a processor is stored, wherein when the program is executed by the processor, an authorization management method based on DID credential data flow as provided in an embodiment of the present application is implemented.

[0016] The authorization management method and device, electronic device and storage medium based on DID credential data flow provided in the embodiments of the present application obtain credential data authorization record data according to the authorized party information in the received user credential data authorization query request and generate a credential data authorization query result according to the obtained authorization record data and the credential information included in the user credential data authorization query request. Therefore, the user does not need to include the user's own personal information in the authorization query request, but only needs to send the credential information and the authorized party information to obtain all the authorization records for the user's own credential data, and generate an authorization query result according to the authorization record and the credential information. Therefore, based on such authorization query results, it is convenient for the user to delete the authorization that has been performed. This not only ensures the security of user information during the query process, but also provides users with higher authorization management efficiency.

[0017] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present application. Also, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0019] Figure 1 It is a schematic diagram showing an application scenario of an authorization management solution based on DID credential data transfer according to an embodiment of the present application;

[0020] Figure 2 A flowchart of an embodiment of an authorization management method based on DID credential data transfer provided by this application;

[0021] Figure 3 A schematic diagram of the structure of the authorization management device based on DID credential data transfer provided by this application;

[0022] Figure 4 A schematic diagram of the structure of an electronic device embodiment provided in this application. DETAILED DESCRIPTION

[0023] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0024] Embodiment 1

[0025] The solution provided in the embodiments of the present application can be applied to any data system with data query and processing functions.

[0026] With the development of Internet technology, people can live and work more and more through the Internet, and therefore, various websites built on the Internet have emerged to provide users with various services. Due to the identity anonymity of the Internet, websites often cannot know the real identity of users who visit or log in to their websites, and therefore cannot regulate and manage the use of services by users accordingly. For this reason, it has been proposed in the prior art that users need to pre-register their identity information in the websites they visit or log in to, so that the websites can provide services to users based on the identity information submitted by users when users request to use the services of the websites. In this process, users need to provide the original data of their identity information to the website and then save it in the server of the website, but such identity information is usually the user's private data. Therefore, when users use the services provided by different websites, they also have to store their private data on various websites, which greatly increases the risk of user privacy exposure.

[0027] In this regard, the DID (decentralized identity) system has been proposed in the prior art. This system is mainly proposed for the above-mentioned existing centralized identity system in which each website manages the identity information of users. Since the identity registration modules of most different websites or platforms are not interoperable, most websites or platforms of different operators currently do not have the authority to access or even manage the identity data of each other's websites, and cannot verify the identity of users who use the identity identifiers issued by each other's websites.

[0028] In the DID system, users can request identity authentication from the issuer that is capable of authenticating the user's real identity, and the issuer can verify the identity information requested by the user based on the user's authentication request and issue credential data to the user after the verification is passed. The credential data can be used as proof data issued by an authority to the user to prove the user's specific identity information. For example, Figure 1 is a schematic diagram showing an application scenario of DID credential data according to an embodiment of the present application. Figure 1 In the scenario shown in , a user can use a user node in the DID system to send a credential issuance request to the issuing node according to the user's credential acquisition request or according to his own credential needs. The issuing node can be, for example, a department or unit that is legally or recognized to authenticate one or more identity information of the user, and thus the issuing party can respond to the received authentication request sent by the user through the user node, that is, request to issue an authentication credential, to authenticate the specified identity information contained in the user's request. For example, the website that the user needs to log in needs to know the user's age to confirm whether the user's age has reached the age value for using the services provided by the website.

[0029] Therefore, in traditional Internet systems, users need to register their own information such as date of birth in the personal information interface of the website first, and in order to ensure the accuracy of the date of birth information registered by the user, the website often requires the user to upload legal documents such as identity documents for the website to verify. In order for the website to know their age information, the user needs to send their birthday information and complete certificate information including birthday information to the website. However, usually, such legal certificate information usually contains many kinds of identity information, such as the user's address, photo, etc., and the user uploads such complete certificate information to the website only to prove his age, which is one kind of identity information.

[0030] In this regard, in the DID system, the user can request the issuer with legal or recognized certification authority for his or her age to issue credential data about his or her current age. The issuer can retrieve the user's identity information stored in its database or only retrieve the user's date of birth information based on the user identifier contained in the user's authentication request, and determine the user's age on that date in combination with the date of receipt of the user's request or the date specified by the user in the request, and thus issue credential data about the user's age on the specified date to the user. After receiving the credential data, the user can present the credential data to the website 1 when accessing the website 1 that is the user of the credential data, so that the website 1 can confirm the user's age on the current date based on the credential data, and when the user's age meets the regulations for using the relevant service, the service can be provided to the user. For example, after the issuer sends the credential data to the service node, and the service node encrypts and stores the credential data using the credential key generated for it, the user can request the service node to authorize the user to access the credential data based on the user information, so that the service node can create an authorization for the credential data for the user in the service node based on the authorization request of the owner of the credential data.

[0031] In the DID system, when a user requests various services that require identity authentication from the user, although the website needs to determine whether to provide services to the user based on whether the user's identity information complies with regulations, the user only needs to request the issuer to issue corresponding credential data for the type of identity information required by the website to be visited or the website service to be used, and request the service node to authorize the corresponding website to access the credential data as identity proof. The website can then access the credential data encrypted and stored in the service node based on the authorization information sent to it by the user or the service node to determine whether the corresponding service can be provided to the user.

[0032] In this process, the user does not need to provide any specific identity information to the website, but instead authorizes the website to access the identity certificate required by the website, that is, the credential data. The issuing party can write the user's corresponding identity information verification result or the conclusion data calculated or judged based on the user's corresponding identity information in the credential data. For example, in the above example where the website needs to verify the user's age, the website does not actually need the current age, but needs to confirm whether the user visiting the website is over 18 years old. Therefore, in the credential data for the website issued by the user requesting the issuing party, the issuing party does not need to write the user's age on the specified date in the credential data, but can only write the user's age value on the specified date and the information of the issuing party in the credential data.

[0033] However, as the number of Internet services used by users increases, users as owners of credential data will not only store more and more credential data in service nodes, but also create more and more authorizations. For example, the same credential data may be authorized to multiple users, or multiple credential data may be authorized to one user. Therefore, the increase in the number of authorizations for user credential data means that more and more third parties can access the user's credential data, which undoubtedly increases the risk of user privacy data leakage.

[0034] In this regard, Figure 1 As shown in , in the DID system scenario according to the embodiment of the present application, the user can log in to the DID system from the user node by using a terminal installed with the client of the DID system according to the embodiment of the present application, and can send an authorization query request for the credential data to the service node to query the authorization information that has been created for the credential data currently owned by the user at the service node. In the embodiment of the present application, the authorization information can be that the user requests the issuer to issue the corresponding credential data according to the identity certification request of the user, and the service node encrypts and stores the credential data issued by the issuer. For example, the service node can first generate a credential key dedicated to the credential data for the credential data and use the credential key to encrypt the credential data, thereby ensuring the security of the credential data, and then use the owner of the credential data, that is, the user's user public key to encrypt the credential key, so that the credential key can only be decrypted by the user using his user private key, ensuring the security of the credential key. On this basis, the user can create authorization for the user for the credential data that has been encrypted and stored in the service node. For example, the user can use the user's secret key to re-encrypt the credential key, so that the user can use his own user public key to decrypt the authorized credential key and then decrypt the credential data to obtain the credential data.

[0035] Therefore, the authorization query request sent by the user to the service node may include the authorized party, such as the authorized party information of the user, and the credential information of the credential data to be queried. For example, in an embodiment of the present application, the authorized party information may include the user public key of the authorized user, such as the user public key of the user who requested the user to provide identity proof, that is, the credential data, and the credential information may include the storage address of the credential data to be queried by the user in the service node. Therefore, the credential data and the corresponding encrypted credential key can be uniquely identified according to the storage address, and the encrypted credential key encrypted by the user public key in the encrypted credential key in the service node can be retrieved according to the user public key, so that all authorization records authorized to the user for the credential data specified in the query request can be obtained. In other words, in an embodiment of the present application, a user can query the authorization record by including, for example, the user's public key as the authorization party information and, for example, the storage address of the credential data in the service node as the credential information in the credential data authorization query request sent to the service node. Therefore, no privacy data is included in the query request, and since the credential data is encrypted in the service node using a credential key that uniquely corresponds to it, and the credential key is encrypted by the user's public key to authorize the user, even if the authorization request is hijacked by a third party and this information is learned, the malicious third party cannot obtain the user's privacy information stored in the service node based on the information contained in the query request.

[0036] In addition, the user may further include his own user public key in the authorization query request sent to the service node. After receiving the user public key included in the authorization query request sent by the user, the service node may first retrieve the corresponding encrypted credential key in the service node according to the user information of the user specified in the authorization request, such as the user. That is, as described above, in the service node, the user may encrypt the credential key of the credential data to be presented to the user by using the user public key to implement the authorization for the user. Therefore, in the service node, the credential key corresponding to the credential data authorized to be accessed by the user is encrypted by the user public key corresponding to the user information. Therefore, the service node may retrieve which credential keys are encrypted by the user public key corresponding to the user information according to the user information in the authorization query request, and then determine the credential key associated with the owner of the credential data specified in the authorization query request from the retrieved credential keys according to the credential key information and the user public key of the owner of the credential data as the authorization record. In other words, in an embodiment of the present application, the service node can first retrieve all the credential keys encrypted by the user key corresponding to the user information specified in the authorization query request, and then further retrieve the credential key related to the owner of the credential data specified in the authorization request from all the credential keys retrieved in this way.

[0037] After determining the credential key related to the user, the service node can further query the usage of the credential key, such as whether it has been used by the user and the usage time, so that the service node can use the credential usage information further obtained in this way and the above-mentioned authorization record to generate an authorization query result, and can send it to the user for verification.

[0038] For example, in Figure 1In the scenario shown in , user 1 stores credential data 1 and credential data 1 in the service node. The credential data 1 and 2 may be sent to the service node through the issuing node by user 1 in response to the identity certification requirement of user 1. In the service node, credential key 1 and credential key 2 may be generated for the credential data 1 and credential data 2, respectively, and credential key 1 may be used to encrypt credential data 1 to generate encrypted credential data 1, and credential key 2 may be used to encrypt credential data 2 to generate encrypted credential data 2. At the same time, the service node may encrypt credential keys 1 and 2 using the user public key of the user who is the owner of credential data 1 and 2, thereby generating encrypted credential key 1 and encrypted credential key 2. After the credential data is stored, since user 1 requires the user to provide credential data 1 and credential data 2, the user can use his own user private key to decrypt the encrypted credential key 1 and encrypted credential key 2 sent to him by the service node and re-encrypt them using the user public key of user 1 to obtain encrypted credential key 11 and encrypted credential key 21, and send them to the service node for storage, so that the encrypted credential key 11 and encrypted credential key 21 encrypted with the user public key of user 1 can be stored in the service node for the credential data 1 and 2 of user 1 to authorize user 1 to access credential data 1 and 2. Similarly, when user 2 requires the user to provide identity proof, and the identity information involved in the identity proof is actually the content of credential data 1 that user 1 has requested from the user, the user can generate encrypted credential key 12 in a similar manner based on the credential information of credential data 1, and store it in the service node to complete the authorization of user 2.

[0039] exist Figure 1In the scenario shown in , when a user wants to query the authorization that he has created for user 1, the user can send an authorization query request to the service node, and the request can include credential information, such as the storage address of credential data 1, and user information of user 1, such as the user public key of user 1. When the service node receives the authorization query request sent by the user, the encrypted credential keys 11 and 21 encrypted by using the user public key of user 1 in all the encrypted credential keys stored in the service node according to the user public key of user 1 included in the authorization query request. For example, when the service node creates authorization for user 1 for the user, the encrypted credential keys 11 and 21 can be associated with the user public key of user 1 in advance, and the associated information can be stored, so that when the user includes the user public key in the authorization query request, the service node can retrieve the user public key matching the user public key included in the authorization query request of the user from the stored associated information, and use the encrypted credential keys corresponding to the retrieved matching user public keys as authorization records. The service node can then continue to determine the corresponding credential data based on the retrieved encrypted credential key, and can then, for example, obtain records related to the credential data, such as information such as whether it has been accessed by user 1 and the access time, so that the service node can use the usage information and authorization records of the credential obtained in this way as the authorization query result of the user's credential data.

[0040] In addition, after the service node sends the authorization query result of the credential data queried by the user to the user, the user can check according to the authorization query result and delete unnecessary authorization. For example, after user 1 authorizes user 1 to access credential data 1 according to the identity verification requirement of user 1, after a period of time, user 1 does not want his or her identity information involved in credential data 1 to be accessed by others, then an authorization deletion request can be sent to the service node according to the authorization query result sent by the service node as described above. For example, the user can include the credential information of the credential data whose authorization information the user wants to delete in the authorization deletion request, such as the encrypted credential key 1 of credential data 1, so that the service node can determine that the target credential data is credential data 1 according to the encrypted credential key 1. In addition, in, for example Figure 1In the scenario shown in , credential data 1 is authorized to be accessible to both user 1 and user 2. Therefore, the user can specify the deletion of the authorized user by further including the user public key of the authorized party in the authorization deletion request. For example, the user can include the user public key of user 1 in the authorization deletion request, so that after receiving the user's authorization deletion request, the service node can also determine, based on the user public key of user 1 contained therein, from the authorization record of credential data 1 previously determined according to the credential information contained in the authorization deletion request that what needs to be deleted is the encrypted credential key 11 encrypted with the user public key of user 1.

[0041] In addition, when receiving the user's authorization deletion request, the service node can also first determine whether the user has the right to delete the credential data based on the user's user identification contained therein, such as the user's public key. Afterwards, the service node can further obtain the access status of, for example, credential data 1 based on the user's public key, and when credential data 1 has not been accessed after user 1 is authorized, the authorization information can be deleted according to the user's deletion request, for example, by deleting the encrypted credential key 11 encrypted by the user key of user 1 of credential data 1. Therefore, the user can, in the above manner, after requesting the service node to query the authorization of the specified credential data for the specified user, further delete the authorization of the authorized party in the record according to the authorization query result fed back by the service node, thereby ensuring the user's secure management of his or her privacy data.

[0042] The authorization management scheme based on DID credential data flow provided by the embodiment of the present application obtains credential data authorization record data according to the authorized party information in the received user credential data authorization query request and generates a credential data authorization query result according to the obtained authorization record data and the credential information included in the user credential data authorization query request. Therefore, the user does not need to include the user's own personal information in the authorization query request, but only needs to send the credential information and the authorized party information to obtain all the authorization records for the user's own credential data, and generate an authorization query result according to the authorization record and the credential information. Therefore, based on such authorization query results, it is convenient for the user to delete the authorization that has been performed. This not only ensures the security of user information during the query process, but also provides users with higher authorization management efficiency.

[0043] The above embodiments are illustrations of the technical principles and exemplary application frameworks of the embodiments of the present application. The specific technical solutions of the embodiments of the present application are further described in detail below through multiple embodiments.

[0044] Embodiment 2

[0045] Figure 2 This is a flowchart of an embodiment of the authorization management method based on DID credential data transfer provided by this application. The execution subject of this method can be various terminals or server devices with data processing capabilities, or it can be a device or chip integrated on these devices. Figure 2 As shown, the authorization management method includes the following steps:

[0046] S201, receiving a user's credential data authorization query request.

[0047] In step S201, for example, a service node in a DID system may receive a credential data authorization query request sent by a user through, for example, a user node. In an embodiment of the present application, a user may request an issuer with legal or recognized authentication validity for his or her age in the DID system to issue credential data related to the identity proof required by the user. The issuer may retrieve the user's identity information stored in its database according to the user identifier contained in the user's authentication request, thereby issuing credential data about the identity information proof required by the user to the user. For example, the issuer may send the credential data generated in this way to the service node, and after the service node encrypts and stores the credential data using the credential key generated for it, the user may request the service node to authorize the user to access the credential data based on the user information of the user, so that the service node may create an authorization for the credential data for the user in the service node based on the authorization request of the owner of the credential data.

[0048] For example, the service node can first generate a credential key dedicated to the credential data and use the credential key to encrypt the credential data, thus ensuring the security of the credential data. Then, the owner of the credential data, that is, the user's public key, is used to encrypt the credential key, so that only the user can decrypt the credential key using his or her private key, thus ensuring the security of the credential key. On this basis, the user can create an authorization for the user for the credential data that has been encrypted and stored in the service node. For example, the user can re-encrypt the credential key using the user's secret key and send the re-encrypted credential key to the service node for storage as an authorization for the user.

[0049] Therefore, the authorization query request of the user received by the service node in step S201 may include the authorized party, such as the authorized party information of the user, and the credential information of the credential data to be queried. In particular, the authorized party information may include the user public key of the authorized user, such as the user public key of the user who requested the user to provide identity proof, that is, the credential data user, and the credential information may include the storage address of the credential data to be queried by the user in the service node.

[0050] S202, obtaining credential data authorization record data according to the authorized party information.

[0051] S203, generating a credential data authorization query result according to the credential data authorization record data and the credential information.

[0052] In step S202, the service node may obtain the credential data authorization record data according to the authorized party information in the authorization query request received in step S201. In an embodiment of the present application, the credential data authorization record data may be a related record of a user authorizing one or more credential data owned by the user to one or more users. For example, the service node may query the corresponding credential data according to the storage address of the credential data contained in the authorization query request received in step S201 in step S202, and may further determine the corresponding encrypted credential key according to the queried credential data. The authorized party information received in step S201 includes the user public key, so the service node may obtain the encrypted credential key encrypted by the user public key in the encrypted credential key retrieved as above in step S202, thereby obtaining all the authorization records of the credential data specified in the query request that are authorized to the user.

[0053] In other words, in an embodiment of the present application, the credential data authorization query request received by the service node in step S201 may include, for example, the user's public key as the authorization party information and, for example, the storage address of the credential data in the service node as the credential information, so that the service node can query the authorization record based on such information in step S202. Therefore, no privacy data is included in the query request, and since the credential data is encrypted in the service node using a credential key that uniquely corresponds to it, and the credential key is encrypted by the user's public key to authorize the user, even if the authorization request is hijacked by a third party and this information is obtained, the malicious third party cannot obtain the user's privacy information stored in the service node based on the information contained in the query request.

[0054] In addition, the authorization query request received by the service node in step S201 may further include the user's own user public key, so that the service node can first retrieve the corresponding encrypted credential key in the service node according to the user information of the user specified in the authorization request received in step S201 in step S202. That is, as described above, the user can encrypt the credential key of the credential data to be presented to the user by using the user public key and store the encrypted credential key in the service node to achieve authorization for the user. Therefore, in the service node, the credential key corresponding to the credential data authorized to be accessed by the user is encrypted using the user public key corresponding to the user information, so that the service node can retrieve which credential keys are encrypted by the user public key corresponding to the user information according to the user information in the authorization query request, and then determine the credential key associated with the owner of the credential data specified in the authorization query request from the retrieved credential keys according to the credential key information and the user public key of the owner of the credential data.

[0055] In other words, in the embodiment of the present application, the service node can first retrieve all the credential keys encrypted by the user key corresponding to the user information specified in the authorization query request, and then further retrieve the credential key related to the owner of the credential data specified in the authorization request, that is, the user, from all the credential keys retrieved in this way. After determining the credential key related to the user, the service node can further query the usage of the credential key, such as whether it has been used by the user and the usage time, so that the service node can generate the authorization query result together with the credential usage information further obtained in step S203 and send it to the user for verification.

[0056] After the service node sends the authorization query result of the credential data generated in step S203 to the user, the user can check according to the authorization query result and delete unnecessary authorization. For example, after the user authorizes the user to access one or more credential data owned by the user according to the identity verification requirements of the user, the user may no longer want his or her identity information involved in one of the credential data to be accessed by others, so an authorization deletion request can be sent to the service node according to the authorization query result generated by the service node in step S203. For example, the authorization deletion request can include the credential information of the credential data whose authorization information the user wants to delete, such as the encrypted credential key of the specified credential data that the user wants to delete authorization, so that the service node can determine the target credential data according to the encrypted credential key.

[0057] In addition, the authorization deletion request may further include the user public key of the authorized party to specify the deletion of the authorized user. For example, the authorization deletion request may further include the user public key of a certain user, so that after receiving the authorization deletion request from the user, the service node may determine, based on the user public key of the specified user included therein, that the encrypted credential key encrypted using the user public key of the specified user needs to be deleted from the authorization record of the credential data previously determined based on the credential information included in the authorization deletion request.

[0058] In addition, when receiving the user's authorization deletion request, the service node can also first determine whether the user has the right to delete the credential data based on the user's user identification contained therein, such as the user's public key. Afterwards, the service node can further obtain the access status of the target credential data that the user wants to delete authorization based on the user's public key, and when the designated credential data has not been accessed by the user after the user is authorized, the authorization information can be deleted according to the user's authorization deletion request. For example, the authorization for the corresponding user can be deleted by deleting the encrypted credential key of the designated credential data. Therefore, after the service node queries the authorization result of the designated credential data for the designated user according to the user's authorization query request, it can further delete the authorization of the authorized party designated by the user according to the authorization deletion request sent by the user, thereby ensuring the user's secure management of his or her privacy data.

[0059] The authorization management method based on DID credential data flow provided in the embodiment of the present application obtains credential data authorization record data according to the authorized party information in the received user credential data authorization query request and generates a credential data authorization query result according to the obtained authorization record data and the credential information included in the user credential data authorization query request. Therefore, the user does not need to include the user's own personal information in the authorization query request, but only needs to send the credential information and the authorized party information to obtain all the authorization records for the user's own credential data, and generate an authorization query result according to the authorization record and the credential information. Therefore, based on such authorization query results, it is convenient for the user to delete the authorization that has been performed. This not only ensures the security of user information during the query process, but also provides users with higher authorization management efficiency.

[0060] Embodiment 3

[0061] Figure 3 This is a schematic diagram of the structure of the authorization management device based on DID credential data transfer provided by the present application. The authorization management device based on DID credential data transfer can be used to implement, for example, reference Figure 2The authorization management method based on DID credential data transfer provided by the embodiment of the present application described herein may include: a first receiving module 31 , a first obtaining module 32 and a generating module 33 .

[0062] The first receiving module 31 may be configured to receive a credential data authorization query request from a user.

[0063] The first receiving module 31 may be located, for example, in a service node in a DID system, and may receive a credential data authorization query request sent by a user, for example, through a user node. In an embodiment of the present application, a user may request an issuer with legal or recognized authentication validity for his or her age in the DID system to issue credential data related to the identity certificate required by the user. The issuer may retrieve the user's identity information stored in its database according to the user identifier contained in the user's authentication request, thereby issuing credential data about the identity information certificate required by the user to the user. For example, the issuer may send the credential data generated in this way to the service node, and after the service node encrypts and stores the credential data using the credential key generated for it, the user may request the service node to authorize the user to access the credential data based on the user information of the user, so that the service node may create an authorization for the credential data for the user in the service node based on the authorization request of the owner of the credential data.

[0064] For example, the service node can first generate a credential key dedicated to the credential data and use the credential key to encrypt the credential data, thus ensuring the security of the credential data. Then, the owner of the credential data, that is, the user's public key, is used to encrypt the credential key, so that only the user can decrypt the credential key using his or her private key, thus ensuring the security of the credential key. On this basis, the user can create an authorization for the user for the credential data that has been encrypted and stored in the service node. For example, the user can re-encrypt the credential key using the user's secret key and send the re-encrypted credential key to the service node for storage as an authorization for the user.

[0065] Therefore, the authorization query request of the user received by the first receiving module 31 may include the authorized party, such as the authorized party information of the user, and the credential information of the credential data to be queried. In particular, the authorized party information may include the user public key of the authorized user, such as the user public key of the user who requested the user to provide identity proof, that is, the credential data user, and the credential information may include the storage address of the credential data to be queried by the user in the service node.

[0066] The first acquisition module 32 may be configured to acquire credential data authorization record data according to the authorized party information.

[0067] The generating module 33 may be used to generate a credential data authorization query result according to the credential data authorization record data and the credential information.

[0068] The first acquisition module 32 can obtain the credential data authorization record data according to the authorized party information in the authorization query request received by the first receiving module 31. In an embodiment of the present application, the credential data authorization record data can be a related record of a user authorizing one or more credential data owned by the user to one or more users. For example, the first acquisition module 32 can query the corresponding credential data according to the storage address of the credential data contained in the authorization query request received by the first receiving module 31, and can further determine the corresponding encrypted credential key based on the queried credential data. The authorized party information received by the first receiving module 31 contains the user public key, so the first acquisition module 32 can use the user public key to encrypt the encrypted credential key in the encrypted credential key retrieved as above, thereby obtaining all the authorization records of the credential data specified in the query request that are authorized to the user.

[0069] In other words, in an embodiment of the present application, the credential data authorization query request received by the first receiving module 31 may include, for example, the user's public key as the authorization party information and, for example, the storage address of the credential data in the service node as the credential information, so that the first acquisition module 32 can query the authorization record based on such information. Therefore, no privacy data is included in the query request, and because the credential data is encrypted in the service node using a credential key that uniquely corresponds to it, and the credential key is encrypted by the user's public key to authorize the user, therefore, even if the authorization request is hijacked by a third party and this information is learned, the malicious third party cannot obtain the user's privacy information stored in the service node based on the information contained in the query request.

[0070] In addition, the authorization query request received by the first receiving module 31 may further include the user's own user public key, so that the first acquisition module 32 can first retrieve the corresponding encrypted credential key in the service node according to the user information of the user specified in the authorization request received by the first receiving module 31. That is, as described above, the user can encrypt the credential key of the credential data to be presented to the user by using the user public key and store the encrypted credential key in the service node to achieve authorization for the user. Therefore, in the service node, the credential key corresponding to the credential data authorized to be accessed by the user is encrypted using the user public key corresponding to the user information, so that the first acquisition module 32 can retrieve which credential keys are encrypted by the user public key corresponding to the user information according to the user information in the authorization query request, and then determine the credential key associated with the owner of the credential data specified in the authorization query request from the retrieved credential keys according to the credential key information and the user public key of the owner of the credential data.

[0071] In other words, in the embodiment of the present application, the first acquisition module 32 can first retrieve all the credential keys encrypted by the user key corresponding to the user information specified in the authorization query request, and then further retrieve the credential key related to the owner of the credential data specified in the authorization request, that is, the user, from all the credential keys retrieved in this way. After determining the credential key related to the user, the first acquisition module 32 can further query the usage of the credential key, such as whether it has been used by the user and the usage time, so that the generation module 33 can generate the authorization query result together with the credential usage information further obtained in this way and the above-mentioned authorization record, and can send it to the user for verification.

[0072] After the service node sends the authorization query result of the credential data generated by the generation module 33 to the user, the user can check according to the authorization query result and delete the unnecessary authorization. For example, after the user authorizes the user to access one or more credential data owned by the user according to the identity verification requirements of the user, the user may not want his or her identity information involved in one of the credential data to be accessed by others, so the user can send an authorization deletion request to the second module 34 of the service node according to the authorization query result generated by the generation module 33. For example, the authorization deletion request can include the credential information of the credential data whose authorization information the user wants to delete, for example, it can include the encrypted credential key of the specified credential data that the user wants to delete authorization, so that the service node can determine the target credential data according to the encrypted credential key.

[0073] In addition, the authorization deletion request may further include the user public key of the authorized party to specify the deletion of the authorized user. For example, the authorization deletion request may further include the user public key of a certain user, so that after receiving the authorization deletion request from the user, the service node may determine, based on the user public key of the specified user included therein, that the encrypted credential key encrypted using the user public key of the specified user needs to be deleted from the authorization record of the credential data previously determined based on the credential information included in the authorization deletion request.

[0074] In addition, after the second receiving module 34 receives the user's authorization deletion request, the second obtaining module 35 can first determine whether the user has the deletion authority for the credential data according to the user's user identification contained in the authorization deletion request, such as the user's public key. Afterwards, the third obtaining module 36 can obtain the access status of the target credential data that the user wants to delete authorization according to the user's public key, and the deletion module 37 can delete the authorization information according to the user's authorization deletion request when it is determined that the credential data specified by the user has not been accessed by the user after the user is authorized. For example, the authorization for the corresponding user can be deleted by deleting the encrypted credential key of the specified credential data. Therefore, after the generation module 33 queries the authorization result of the specified credential data for the specified user according to the user's authorization query request, the deletion module 37 can further delete the authorization of the authorized party specified by the user according to the authorization deletion request sent by the user, thereby ensuring the user's safe management of his privacy data.

[0075] The authorization management device based on DID credential data flow provided in the embodiment of the present application obtains credential data authorization record data according to the authorized party information in the received user credential data authorization query request and generates a credential data authorization query result according to the obtained authorization record data and the credential information included in the user credential data authorization query request. Therefore, the user does not need to include the user's own personal information in the authorization query request, but only needs to send the credential information and the authorized party information to obtain all the authorization records for the user's own credential data, and generate an authorization query result according to the authorization record and the credential information. Therefore, based on such authorization query results, it is convenient for the user to delete the authorization that has been performed. This not only ensures the security of user information during the query process, but also provides users with higher authorization management efficiency.

[0076] Embodiment 4

[0077] The above describes the internal functions and structure of the authorization management device based on the DID credential data flow, which can be implemented as an electronic device. Figure 4 This is a schematic diagram of the structure of an electronic device embodiment provided by this application. Figure 4 As shown, the electronic device includes a memory 41 and a processor 42 .

[0078] The memory 41 is used to store programs. In addition to the above programs, the memory 41 can also be configured to store various other data to support operations on the electronic device. Examples of such data include instructions for any application or method operating on the electronic device, contact data, phone book data, messages, pictures, videos, etc.

[0079] The memory 41 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0080] The processor 42 is not limited to a processor (CPU), but may also be a processing chip such as a graphics processing unit (GPU), a field programmable gate array (FPGA), an embedded neural network processor (NPU) or an artificial intelligence (AI) chip. The processor 42 is coupled to the memory 41 and executes the program stored in the memory 41 to execute the authorization management method based on the DID credential data flow of the above-mentioned embodiment 2.

[0081] Further, if Figure 4 As shown, the electronic device may also include: a communication component 43, a power component 44, an audio component 45, a display 46 and other components. Figure 4 Only some components are shown schematically, which does not mean that the electronic device only includes Figure 4 Components shown.

[0082] The communication component 43 is configured to facilitate wired or wireless communication between the electronic device and other devices. The electronic device can access a wireless network based on a communication standard, such as WiFi, 3G, 4G or 5G, or a combination thereof. In an exemplary embodiment, the communication component 43 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 43 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0083] The power supply assembly 44 provides power to various components of the electronic device. The power supply assembly 44 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device.

[0084] The audio component 45 is configured to output and / or input audio signals. For example, the audio component 45 includes a microphone (MIC), and when the electronic device is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 41 or sent via the communication component 43. In some embodiments, the audio component 45 also includes a speaker for outputting audio signals.

[0085] The display 46 includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation.

[0086] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0087] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. An authorization management method based on DID credential data transfer, comprising: Receiving a credential data authorization query request from a user, wherein the credential data authorization query request includes authorized party information and credential information; Acquire credential data authorization record data and credential usage information according to the authorized party information; Generate a credential data authorization query result based on the credential data authorization record data and credential usage information, The authorized party information includes a user public key of the authorized user, and the credential information includes a storage address of the credential data in the service node, and the credential data and the corresponding encrypted credential key are uniquely identified according to the storage address, The credential information also includes a user public key of the owner of the credential data, and the authorized party information includes user information of the authorized user, and The step of obtaining credential data authorization record data and credential usage information according to the authorized party information includes: Retrieving, according to the user public key of the authorized user, from the encrypted credential keys stored in the service node, an encrypted credential key that matches the user public key of the authorized user; Acquire all authorization records of the credential data that are authorized to the authorized party according to the matched encrypted credential key, and use the authorization records as the credential data authorization record data, Acquire, according to the user information of the authorized user, a credential key encrypted in the service node using a user public key of the authorized party corresponding to the user information; determining, from the credential keys, a credential key associated with an owner of the credential data based on the credential key and a user public key of an owner of the credential data; The credential usage information is obtained based on a credential key associated with an owner of the credential data.

2. The authorization management method according to claim 1, wherein: The authorization management method further comprises: Receiving a credential data authorization deletion request sent by the user, wherein the credential data deletion request is generated by the user according to the credential data authorization query result and includes credential information of the credential data as the authorization deletion target and a user public key of the authorized user; Obtaining the user's authority over the credential data according to the credential information; Acquiring the access status of the credential data according to the user public key of the authorized user; A deletion process is performed on the credential data according to the authority and the access status.

3. An authorization management device based on DID credential data transfer, comprising: A first receiving module is used to receive a credential data authorization query request from a user, wherein the credential data authorization query request includes authorized party information and credential information; A first acquisition module, used to acquire credential data authorization record data and credential usage information according to the authorized party information; A generation module is used to generate a credential data authorization query result according to the credential data authorization record data and the credential usage information, The authorized party information includes a user public key of the authorized user, and the credential information includes a storage address of the credential data in the service node, and the credential data and the corresponding encrypted credential key are uniquely identified according to the storage address, The credential information includes a user public key of the owner of the credential data, and the authorized party information includes user information of the authorized user, and The first acquisition module is further used for: Retrieving, according to the user public key of the authorized user, from the encrypted credential keys stored in the service node, an encrypted credential key that matches the user public key of the authorized user; Obtain all authorization records of the credential data that are authorized to the authorized party according to the matched encrypted credential key, and use the authorization records as the credential data authorization record data, Acquire, according to the user information of the authorized user, a credential key encrypted in the service node using a user public key of the authorized party corresponding to the user information; determining, from the credential keys, a credential key associated with an owner of the credential data based on the credential key and a user public key of an owner of the credential data; The credential usage information is obtained based on a credential key associated with an owner of the credential data.

4. The authorization management device according to claim 3, wherein: The authorization management device further comprises: A second receiving module, configured to receive a credential data authorization deletion request sent by the user, wherein the credential data deletion request is generated by the user according to the credential data authorization query result and includes credential information of the credential data as the authorization deletion target and a user public key of the authorized user; A second acquisition module, configured to acquire the user's authority over the credential data according to the credential information; A third acquisition module, configured to acquire the access status of the credential data according to the user public key of the authorized user; A deletion module is used to perform deletion processing on the credential data according to the authority and the access status.

5. An electronic device comprising: Memory, used to store programs; A processor, configured to run the program stored in the memory to execute the authorization management method based on DID credential data flow as described in any one of claims 1-2.

6. A computer-readable storage medium having stored thereon a computer program executable by a processor, wherein: When the program is executed by the processor, the authorization management method based on DID credential data flow as described in any one of claims 1-2 is implemented.

Images