TWM644096U - Data exchange system - Google Patents

Abstract

A data exchange system at least includes a user node, a first service node, and a second service node, wherein both the first service node and the second service node are informationally connected to the user node. The user node holds a public key and a private key. The first service node keeps a user data, and uses the public key provided by the user node to process the user data, so as to generate a verifiable certificate (VC) and a certificate data, wherein the certificate data is sent to the user node for storage. The second service node obtains the VC through the certificate data, and then requires the user node to verify a credibility of the VC with the private key thereof. If the user node successfully verifies the credibility of the VC, the second service node can obtain at least a part of the user data.

Description

data exchange system

This work is about a method of sharing data, especially a data exchange system based on the framework of Self-sovereign identity (SSI).

In the era of Web 2.0, the verification of digital identity is centered on the platform. For example, Facebook (Facebook) and Google (Google) both provide related services, which can verify the identity of users on behalf of third-party units. However, all the information of the digital identity under centralized management is managed by the platform, and its security is almost entirely dependent on the maintenance of the centralized platform. It has security risks in commercial entity applications, and even if the risk is low, personal data still has the opportunity to be verified centrally. The process is directly or indirectly identified.

In order to further reduce this risk, some technology development units propose to use fragmented personal data, supplemented by blockchain technology for decentralized verification. However, decentralized verification through the blockchain requires more computing power and additional blockchain service fees (gas fee). Therefore, although the risk is reduced, the cost is increased.

At present, there are also verification methods based on a single blockchain architecture with decentralized identity (Decentralized Identity, DID) and verifiable credentials (Verifiable Credential, VC), which can effectively improve security. The road load is too heavy, VC files may be fat, and VC may carry sensitive information, etc., in terms of practical application, it cannot achieve economic benefits and cannot meet the requirements of current financial regulations and personal data protection regulations, so it lacks industrial use value .

In addition, user data is often managed separately by different companies, and the content of the data is often repeated or inconsistent. If it is necessary to synchronize or exchange data between companies, it usually involves many manual procedures. Data circulation is not safe, and the operation is time-consuming, which does not meet the convenience and security requirements of the Internet generation.

In view of this, this creation intends to provide a data exchange system that can combine the advantages of centralized verification and decentralized verification to become a repeatable and economical and safe verification method, and can exchange data effectively.

According to an embodiment, the invention discloses a data exchange system, which at least includes a user node, a first service node, and a second service node. The user node holds a public key and a private key, wherein the public key and the private key are corresponding. The first service node is informationally connected with the user node, and keeps a user data; the first service node uses the public key provided by the user node and the user data to generate a verifiable certificate (Verifiable Credential, VC) and a certificate information, and send the credential information to the user node for storage. The second service node is informationally connected to the user node; the second service node uses the credential information provided by the user node to obtain the verifiable certificate, and then requires the user node to use the private key to verify the authenticity of the verifiable certificate . If the user node successfully verifies the authenticity of the verifiable certificate according to the request of the second service node, the second service node is allowed to obtain at least a part of the user information stored by the first service node.

In one embodiment, the verifiable certificate includes a verification message, and the second service node encrypts the verification of the verifiable certificate with the public key when requesting the user node to verify the authenticity of the verifiable certificate After the message is sent to the user node, the user node uses the private key to solve the verification message of the verifiable certificate, and then sends it back to the second service node for comparison. If the comparison is correct, a digit of the user node Identity is verified.

In one embodiment, the first service node further links the verifiable certificate to a consortium chain, and the certificate information is a block chain address of the verifiable certificate; the second service node uses the The blockchain address obtains the verifiable certificate in the consortium chain.

In one embodiment, the consortium chain adopts proof-of-authority (POA) as its consensus algorithm.

In one embodiment, the consortium chain is connected to a public chain through a side chain.

In one embodiment, the first service node stores the verifiable certificate in an InterPlanetary File System (IPFS), and the certificate information is a content identifier (CID) of the verifiable certificate ); the second service node obtains the verifiable certificate by using the content ID.

In one embodiment, at least a part of the user data kept by the first service node is included in the verifiable certificate; the second service node obtains the at least part of the user data from the verifiable certificate a part.

In one embodiment, at least a part of the user data stored by the first service node is transmitted to the second service node through an encrypted channel or an encrypted envelope.

In one embodiment, the first service node saves the user data in an InterPlanetary File System (IPFS), and the second service node obtains at least a part of the user data from the InterPlanetary File System .

In one embodiment, the public key held by the user node is a physical key.

The aforementioned data exchange system can meet the current relevant laws and regulations and the needs of personal information protection, and its security is high, and it can also effectively reduce the burden of operating on the blockchain; in addition, this system can exchange data safely and conveniently, eliminating the need for Unnecessary manual procedures. The aforementioned and other technical contents, features and functions of this creation will be clearly presented in the following detailed description of the embodiments with reference to the drawings.

In order to enable those skilled in the art to have a better understanding of the invention, the preferred embodiments of the invention are listed below, and the composition and the desired effect of the invention are described in detail with reference to the accompanying drawings.

Please refer to Fig. 1, which is a schematic diagram of a data exchange system 100 according to an embodiment of this invention, including a user node 10, a first service node 20, and a second service node 30, wherein the user node 10 is in this embodiment The mobile APP is used as an example, but it is not limited to this. In practice, it can also be a computer software, a web browser, a cloud tool, or a general-purpose or customized smart device operated by the user; as long as it can execute All functions of the user node 10 as described below should be considered as falling within the scope of this creation. In this embodiment, the first service node 20 and the second service node 30 are all terminal servers, but this is not the limitation of this invention; in other embodiments, the first service node 20 and the second service node 30 It may also be other types of computing equipment, or even consist of multiple computing equipment, such as multiple modules, components, or devices scattered in different locations on wired or wireless networks, etc., should all fall within the equivalent scope of this creation Inside.

Among them, the first service node 20 and the second service node 30 are nodes that constitute a consortium blockchain (consortium blockchain) C. What needs to be explained is that in practice, a consortium blockchain usually does not contain only two nodes. The example shown here It is just for the convenience of explanation, and does not imply that the alliance chain C has any restrictions on the number of nodes. The data exchange system 100 provided by this creation operates based on the verifiable credential (VC) protocol proposed by W3C, and the naming system of the first service node 20 and the second service node 30 mentioned in this embodiment Distinguished by their roles in the protocol, more specifically, the first service node 20 acts as a verifiable certificate issuer (VC issuer), while the second service node 30 acts as a verifiable certificate verifier (VC issuer) VC verifier). In other words, in the context of any verifiable certificate protocol operation, the worker responsible for the issuer of the verifiable certificate is called the first service node 20 in this creation; and the worker responsible for the verifier of the verifiable certificate is It is the second service node 30 referred to in this creation. It should be clearly understood that since the same terminal server may have the functions of a verifiable certificate issuer and a verifiable certificate verifier in practice, when it is used as a verifiable certificate issuer in a usage scenario, That is, it is regarded as the first service node 20 of this invention; but when it is changed to be a verifiable certificate verifier in another usage scenario, the same terminal server is then regarded as the second service node 30 of this invention. These descriptions are purely for explaining the logic behind the naming of the components of this creation. Therefore, when interpreting the scope of this creation, one should not be limited to the relevant descriptions of the first service node 20 and the second service node 30, and then mistakenly assume that all As the first service node 20, it is impossible to become the second service node 30 in another situation, or the second service node 30 has no possibility of turning into the first service node 20 in another situation, let’s explain first .

The user node 10 holds a pair of a public key 12 and a private key 14. Preferably, in order to provide higher security, the public key 12 can be a physical key, such as a specially designed hardware chip or USB device, but its actual implementation is not limited to the example here. In addition, the user node 10 also holds a digital identity 16, wherein the digital identity 16 can correspond to the ID card number or real name of the user of the user node 10, and can also be the machine code or serial number of the user node 10 itself. The description here is limited; in this embodiment, the digital identity 16 is a decentralized identity (Decentralized Identity, DID). It should be noted that the digital identity 16 corresponds to the user of the user node 10; in other words, the corresponding identity used by a real user in the data exchange system 100 provided by this creation represents the user. The decentralized identity and its corresponding decentralized identity document (DID document, not shown) can be stored together or separately on various storage media, such as a distributed key management system (Distributed Key Management System, DKMS, not shown in the figure), an InterPlanetary File System (InterPlanetary File System, IPFS) on a local or remote server, or a general database, etc., preferably, can be stored and mapped to a blockchain , wherein the decentralized identity file is meta-data describing the object identified by the decentralized identity (ie, the user of the user node 10), and also includes a description of the authentication method, which is used by an unspecified third party to authenticate the For decentralized identity purposes.

The first service node 20 is informationally connected with the user node 10 (that is, there can be information communication and circulation between the two elements), and keeps a user data 22 . The user data 22 mentioned here refers to unspecific data related to the user of the user node 10. In practice, it can be the user's medical data, insurance policy data, financial data, or basic personal data. Limit the examples shown here. In practice, the decentralized identity held by the aforementioned user node 10 and the corresponding decentralized identity file may be generated by the first service node 20, or may be generated by a certain competent authority or authoritative unit, But these technical correlations are not the focus of this creation. As mentioned above, the first service node 20 plays the role of verifiable certificate issuer. More specifically, the first service node 20 uses the public key 12 and the user information 22 provided by the user node 10 to A verifiable certificate 24 is generated, and a certificate information 26 is correspondingly generated, and sent to the user node 10 for storage. Preferably, the action of the first service node 20 to generate the verifiable certificate 24 and the certificate information 26 is initiated by the user node 10. For example, the user node 10 may make a request for the verifiable certificate 24 and transmit the digital identity 16 (the decentralized identity) and the public key 12 to the first service node 20; the first service node 20 refers to the authentication method contained in the corresponding decentralized identity file to authenticate the decentralized identity, and After the authentication is successful and the decentralized identity is determined to represent the user of the user node 10, the verifiable credential 24 and credential information 26 are generated; the verifiable credential 24 can contain all or part of the user data 22, and can Inclusion or exclusion of this decentralized identity depends on the needs. In this embodiment, the first service node 20 links the verifiable certificate 24 to the consortium chain C to achieve the purpose of depositing the verifiable certificate 24, and the certificate information 26 is a block chain bit of the verifiable certificate 24 site. After the user node 10 receives the credential information 26 (block chain address in this example) from the first service node 20, it saves it for future verification of the verifiable credential 24's credibility. It should be noted that the user node 10 can save the credential information 26 in an internal storage space (such as the aforementioned DKMS), or in an external virtual space as the case may be, and the actual storage method is not a limitation of this invention where.

In another embodiment, the first service node 20 does not link the verifiable certificate 24 to the consortium chain C, but saves it in an InterPlanetary File System (IPFS). In such an embodiment, the certificate information 26 is naturally not a blockchain address, but a content identifier (CID) that verifies the certificate 24 instead. Similarly, when the user node 10 receives the certificate information 26 (in this example, the content identification code) returned by the first service node 20, the user node 10 saves the certificate information 26 for future use. It is also worth mentioning that the first service node 20 can further use a decentralized identity resolver (DID resolver) to perform a hash operation on the verifiable credential 24 to generate a hash value, and upload the hash value to the alliance chain C. In this way, in addition to storing evidence for the verifiable certificate 24, the decentralized identity file can also be found by analyzing the decentralized identity contained in the verifiable certificate 24.

When the authenticity of the verifiable credential 24 needs to be verified, it is when the aforementioned second service node 30 acting as a verifier of the verifiable credential operates. The second service node 30 is also informationally connected with the user node 10, and information communication and flow can also be carried out between the two components. Therefore, the second service node 30 can obtain verifiable information through the certificate information 26 retained by the user node 10. credential24. More specifically, in the embodiment where the certificate information 26 is the blockchain address, the second service node 30 uses the blockchain address to obtain the verifiable certificate 24 on the consortium chain C; and in the certificate information In the embodiment where 26 is the content identification code, the second service node 30 uses the content identification code to obtain the verifiable certificate 24 in the interstellar file system used by the first service node 20 . Of course, the first service node 20 may also use other methods to save the verifiable certificate 24, but no matter what the method is, it should be able to correspond to the output certificate information 26, so that the second service node 30 can obtain the verifiable certificate according to it twenty four.

Wherein, the verifiable certificate 24 includes a verification message 24A, when the second service node 30 wants to verify the authenticity of the verifiable certificate 24, the second service node 30 uses the public key 12 provided by the user node 10 to verify the verification message 24A Encrypt, and send the encrypted verification message 24A to the user node 10, requesting the user node 10 to decrypt. Since the user node 10 holds the corresponding private key 14, the user node 10 can use the private key 14 to decrypt the encrypted verification message 24A, and then obtain the content of the verification message 24A. After the user node 10 solves the verification message 24A, it can return the verification message 24A to the second service node 30 for comparison. If the comparison is correct, it proves that the user node 10 is the correct user holding the private key 14, and also That is, the credibility of the verifiable certificate 24 is verified.

If the second service node 30 successfully verifies the authenticity of the verifiable credential 24, then it is allowed to obtain at least a part of the user data 22 kept by the first service node 20, whereby at least a part of the user data 22 can be It is exchanged to the second service node 30 for the second service node 30 to update or synchronize data and other purposes. Wherein, in the case that at least a part of the user information 22 has been included in the verifiable certificate 24, the second service node 30 can directly obtain it from the verifiable certificate 24 whose credibility has been verified; or, the second service The node 30 can also obtain the required data from the first service node 20 in other ways. It can be understood that if the user of the user node 10 does not want the second service node 30 to know some parts of the user information 22, the user can request the first service node 20 to only Part of the user information 22 is made into a verifiable certificate 24, so that the necessary information can be transmitted to the second service node 30 without disclosing unnecessary information, thereby achieving the purpose of autonomously controlling the disclosure degree of the user information 22, practical It is more likely that the requirements of Zero Knowledge Proof can be met; conversely, the actual operation mode of the system 100 is of course also possible that the second service node 30 actively requests some user information 22, and then Referred to by the user node 10 to the first service node 20, so that the first service node 20 can generate a verifiable credential 24 accordingly, and only include the user information 22 of these parts required by the second service node 30, so It also avoids overdisclosure of information. In this embodiment, at least a part of the user data 22 stored by the first service node 20 is transmitted to the second service node 30 through an encrypted channel T, wherein the encrypted channel T may have (but not limited to) three layers of protection , the first layer of protection is to use AES 256 encrypted channel, the second layer of protection is to encrypt user data 22 with AES 256 file encryption, and the third layer of protection is to use a non-open channel protocol. In another embodiment, the first service node 20 may also save the user information 22 in the interstellar file system, and the second service node 30 obtains at least a part of the user information 22 through the interstellar file system. It should be understood that, of course, there may also be other implementation methods for exchanging data, as long as at least a part of the user data 22 can be safely transmitted to the second service node 30 , it is not limited to the example shown here.

In addition, in order to ensure that all nodes on the alliance chain C participate in the calculation and recording, preferably, the alliance chain C adopts proof-of-authority (POA) as its consensus algorithm. If it is necessary to further improve the openness of the alliance chain C, the alliance chain C can also be connected to a public chain P through a side chain S, where the public chain P can be a blockchain operated by Bitcoin or Ethereum, but it does not This is the limit.

It should also be noted that although only the user node 10 has the decentralized identity in the foregoing description, this is not the limitation of this creation; in practice, all nodes on the alliance chain C can also have more than one decentralized identity. It is convenient for each participant in the system 100 to confirm each other's identity. However, the application and acquisition of decentralized identities is not the focus of this creation, so let’s skip it here.

Hereinafter, this creation will use two scenarios to illustrate the actual operation of the data exchange system 100 . Please refer to Figure 2 first, which is a flow chart of the steps of the first usage scenario, which is the scenario of transmitting policyholder personal data between different insurance companies, wherein the user node 10 is a mobile phone APP used by a policyholder, and the first One service node 20 is the terminal server of an insurance company (hereinafter referred to as insurance company A), and the second service node 30 is the terminal server of another insurance company (hereinafter referred to as insurance company B), and policyholders wish to use this system 100 transmits the user information 22 stored on the first service node 20 to the second service node 30, where the user information 22 may include the policyholder's ID number, basic personal information, and decentralized identity (DID ), etc., but not limited to this.

The initial step S11 is when the system 100 operates for the first time, and there is no verifiable certificate 24 at this point, so the first service node 20 acting as the verifiable certificate issuer is still responsible for generating the verifiable certificate 24 . In order to achieve this purpose, the policyholder operates the user node 10 to generate a pair of keys, namely the aforementioned public key 12 and private key 14, and transmits the public key 12 to the first service node 20 owned by the insurance company A ; In step S12, the first service node 20 uses the public key 12 sent by the user node 10 to make a verifiable certificate 24 from the stored user information 22. Next, in step S13, the first service node 20 uses the decentralized identity resolver to calculate the hash value of the verifiable certificate 24, and uploads the hash value to the alliance chain C, so as to verify the verifiable certificate 24 Deposit evidence.

Please refer to the next step S14, the first service node 20 in this usage scenario saves the verifiable certificate 24 in the interstellar file system, so the certificate information 26 is the content that the verifiable certificate 24 is located in the interstellar file system identification code, and the first service node 20 will transmit the content identification code to the user node 10 for storage, and it will be used when verifying the digital identity represented by the user node 10 in the future. In step S15, the policyholder operates the user node 10 to request identity verification, so the user node 10 transmits the public key 12 and the content identification code to the second service node 30 owned by the insurance company B; , the second service node 30 obtains the verifiable certificate 24 from the interstellar file system used by the first service node 20 . Next, in step S16, the second service node 30 takes out the verification message 24A contained in the verifiable certificate 24, encrypts it with the public key 12, and then transmits the encrypted result to the user node 10, requesting the user node 10 to assist in verification The authenticity of the credential 24 may be verified.

Since the user node 10 is the correct identity holder, it naturally has the corresponding private key 14 . In step S17 , the user node 10 uses the private key 14 to decrypt the verification message 24A, and then sends it back to the second service node 30 . In the next step S18, the second service node 30 compares the verification message 24A held by itself with the verification message 24A sent back by the user node 10. If the two are identical, it proves that the user node 10 indeed holds the private key 14. As a qualified person, the authenticity of the verifiable credential 24 is therefore verified. Finally, in step 19, the second service node 30 obtains at least a part or all of the user data 22 from the first service node 20 through the encrypted channel T, and thus the data exchange is successfully completed.

Based on such operation logic, the system 100 can also perform more complicated actions. For example, the policyholder can modify the user information stored in the terminal server of insurance company B, and check on the user node 10 (i.e., the mobile phone APP) to synchronize the changed information to another insurance company (below Call the terminal server of the insurance company C). It should be clearly understood that when performing this action, the terminal server of insurance company B is responsible for generating a verifiable certificate for the changed user information, while the terminal server of insurance company C is responsible for identity verification, so the insurance company At this time, the terminal server of B should be regarded as the first service node 20 mentioned above, and the terminal server of insurance company C becomes the second service node 30 mentioned above. The various steps performed by the first service node 20 and the second service node 30 in this round of action are generally as described above, please do not repeat them here. ) after completing the identity verification, the updated user information can be obtained from the terminal server of insurance company B (that is, the first service node 20 of this round) through an encrypted channel, so as to perform synchronous modification of the data. From this example and the previous example shown in FIG. 2, it can be found that the terminal server of insurance company B plays the role of the second service node 30 and the first service node 20 successively in different situations; Nodes are not a special case. In practice, all nodes on the consortium chain C can have the functions of verifiable certificate issuer and verifiable certificate verifier at the same time, which is more convenient for actual use scenarios.

Please refer to Figure 3 again, which is a flow chart of the steps of the second usage scenario, which is that an insured person applies for a claim to an insurance company after completing treatment in a hospital, wherein the mobile phone APP used by the insured person is the aforementioned user node 10. The terminal server of the hospital is the first service node 20 , and the terminal server of the insurance company is the second service node 30 . Likewise, there is no verifiable certificate 24 at the time of the initial step S21, and the first service node 20 is responsible for issuing it. To achieve this purpose, the policyholder operates the user node 10 to generate a pair of public key 12 and private key 14 , and the user node 10 transmits the public key 12 to the first service node 20 . Next, in step S22, the first service node 20 generates a verifiable credential 24 using the public key 12 and the stored user information 22, wherein the user information 22 may include the policyholder's ID number, Basic personal data, medical records, diagnosis certificates, and decentralized identity (DID), etc., but not limited to.

The difference from the previous usage scenario is that in step S23, the first service node 20 saves the user information 22 in the interstellar file system, and then in step S24 uploads the verifiable certificate 24 to the alliance chain C, and at this time returns The certificate information 26 transmitted to the user node 10 is the blockchain address of the verifiable certificate 24 . When the insurance company receives the policyholder's claim settlement application, the insurance company needs to verify the digital identity represented by the user node 10. Therefore, in step S25, the user node 10 transmits the public key 12 and the certificate information 26 (in this example middle is the blockchain URL) to the second service node 30, and the second service node 30 obtains the verifiable certificate 24 on the consortium chain C through the certificate information 26. After obtaining the verifiable certificate 24 , the second service node 30 retrieves the verification message 24A from it, encrypts the verification message 24A with the public key 12 in step S26 , and sends the result to the user node 10 .

The user node 10 holds the corresponding private key 14 , so it can decrypt the content of the verification message 24A in step S27 and send it back to the second service node 30 . In the next step S28, the second service node 30 compares the verification message 24A returned by the user node 10 with the verification message 24A held by itself. If the two are identical, it can prove that the private key 14 held by the user node is authentic Paired with its public key 12, in other words, the user node 10 has a qualified identity, the authenticity of the verifiable credential 24 is verified. In the final step S29, the second service node 30 is allowed to obtain at least a part or all of the user information 22 from the interstellar file system of the first service node 20, as a basis for determining subsequent claims. Of course, the terminal server of the insurance company (ie, the second service node 30) can also obtain user information from the terminal server of the hospital (ie, the first service node 20) through the encrypted channel T as in the previous usage scenario; in other words, the actual There may be more changes in the data exchange method in other usage scenarios.

Based on the usage scenarios described here, it should be clear that if the insured person is insured by two or more insurance companies at the same time, other insurance companies can also obtain user information from the hospital through the same or similar steps22. In addition, in order to authorize the claim application action to be authorized by the policyholder himself, in practice, natural person certificates, chip financial cards, or MID mobile identity identification plus biometric identification of two-factor authentication, etc. can be integrated into this creation A data exchange system 100 is provided. It is worth mentioning that, according to the usual claim application procedure, the policyholder needs to apply to the hospital for multiple paper diagnosis certificates depending on the number of insurance companies insured, and then complete the claim settlement through manual procedures such as mailing or delivery by business personnel. software, in contrast, the system 100 can provide a safer, more private, and more convenient solution.

Next, please refer to Figure 4, which is a flow chart of the steps of the third usage scenario in this case, which is also the scenario where an insured household applies for a claim to an insurance company after completing treatment in a hospital. In order to facilitate various operations in the future, the policyholder can join a service platform to become a member, and then use the platform membership to log in to multiple insurance companies and become members of each insurance company. The mobile phone APP used by the policyholder is the aforementioned user node 10, a platform host of the service platform is the aforementioned first service node 20, and the terminal servers of each insurance company can be regarded as the aforementioned second node respectively. Service node 30. In step S31, the platform host (i.e. the first service node 20) uses the public key 12 provided by the insurer's mobile APP (i.e. the user node 10) to generate a verifiable certificate 24 and corresponding certificate information from the user data 22 stored in it 26. The content of the verifiable credential 24 includes the decentralized avatar held by the user node 10, a decentralized identity of the platform host, and at least a part of the user information 22, including but not limited to whether the policyholder is Platform members, whether they have reached the age of 18, whether they have insurance records of member companies, and other related information. In this example, the content of the certificate information 26 is a decentralized identity address specified by the user node 10, and the verifiable certificate 24 is sent to the decentralized identity address according to the instructions. As described in step S32, the certificate information 26 is handed over to The user node 10 saves. When any insurance company wants to check the policyholder's membership status, in step S33, its terminal server (ie, the second service node 30 ) requests the user node 10 for credential information, and obtains the verifiable credential 24 accordingly. Then in step S34, the second service node 30 requires the user node 10 to assist in verifying the authenticity of the verifiable certificate by using its private key 14. If the verification is passed, in step S35, the second service node 30 can use the verifiable certificate 24, confirm whether the insured user who uses the user node 10 is a company member.

Figure 5 is a flow chart of the steps of the fourth usage scenario of this creation. The background of this usage scenario is the continuation of the previous usage scenario, but this time is when the policyholder intends to apply for a claim after completing the treatment. In such a situation, a medical host in the hospital becomes the aforementioned first service node 20, the mobile APP used by the policyholder is also the user node 10, and the terminal server of the insurance company also serves as the second service node. Node 30. In step S41, the medical host (that is, the first service node 20) makes an electronic diagnosis, and issues a verifiable credential 24 this time, wherein the verifiable credential 24 includes the decentralized identity of the user node 10, a Decentralized identity, and at least a part of user information 22, including but not limited to the month of the accident, whether the insured has recovered, whether to use health insurance to see a doctor, whether to have out-of-pocket medicine and other information. In this example, the credential information 26 corresponding to the verifiable credential 24 is also a decentralized identity address specified by the user node 10, and the credential information 26 is handed over to the user node 10 for safekeeping in step S42. Then in step S43, the terminal server of the insurance company (i.e. the second service node 30) obtains the verifiable certificate 24 according to the certificate information 26, and in the next step S44 requests the user node 10 to assist in verifying the verifiable certificate with its private key 14 24 credibility. Once the credibility is verified, the insurance company's terminal server can perform the following actions, including but not limited to entering the medical host data set to query the issuance record of the verifiable certificate 24, querying the policyholder's decentralized identity, verifying The medical host key is signed, etc., and then it is released and the insurance company's internal claim settlement process is carried out. As for the personal medical privacy data (that is, a part of the user data 22) required for the claim settlement service, in step S45, through an encrypted envelope, it starts from the medical host (the first service node 20) and passes through the aforementioned platform host , sent to the insurance company's terminal server (the second service node 30).

Also according to the process shown in Figure 5, in practice, the first two usage scenarios can be continued for follow-up actions, for example, the policyholder requests the insurance company that has accepted the claim to transfer the claim data to another insurance company. In such a situation, the terminal server of the insurance company that has accepted the claim becomes the aforementioned first service node 20, and the mobile phone APP used by the policyholder is still serving as the user node 10. The company's terminal server naturally becomes the aforementioned second service node 30 . Also as shown in step S41, the terminal server (first service node 20) of the insurance company that has accepted the claim uses the public key 12 of the user node 10 to generate a verifiable certificate 24, wherein the verifiable certificate 24 contains the user node 10 The decentralized identity held by the first service node 20, a decentralized identity held by the first service node 20, and at least a part of the user information 22, including but not limited to whether it is a duplicate claim, whether the claim amount does not exceed the new One million Taiwan dollars and so on. The certificate data 26 in this example is still a decentralized identity address specified by the user node 10. The certificate information 26 is also kept by the user node 10 in step S42, and the verifiable certificate 24 is stored in the certificate data 26 according to the instructions. The decentralized identity address. In this way, when the policyholder requests to transmit the claim information to the other insurance company, the terminal server of the other insurance company (that is, the second service node 30 ) can obtain the verifiable certificate 24 according to the certificate data 26 , as described in step S43. Next, the second service node 30 requests the user node 10 to use its private key 14 to assist in confirming the authenticity of the verifiable credential 24 in step S44. Once verified, the second service node 30 can perform the following actions, including but not limited to The data set query entering the first service node 20 can verify the issuance record of the certificate 24, query the decentralized identity of the user node 10, and verify the key of the medical host mentioned in the previous usage scenario, etc. The other insurance company described here then releases and proceeds with the system claims process. Similarly, the personal medical privacy data required for the claims process, as shown in step S45, is sent by the first service node 20 (the terminal server of the insurance company that accepts claims) in an encrypted envelope, via the aforementioned platform host, Then it is delivered to the second service node 30 (the terminal server of the other insurance company that is ready to accept data transfer).

Please refer to Figure 6 again, which is a schematic flow diagram of the fifth usage scenario, which is applied to the needs of insurance salesmen to sign insurance policies remotely. According to current laws and regulations, insurance salespersons need to sign in person or via video when processing insurance policies. However, since the data exchange system 100 provided by this creation is designed based on the identity autonomy (SSI) framework, it can be used to verify online The policyholder is the person himself, thus achieving the legal effect of his signature. Assume that an insurance company (hereinafter referred to as insurance company A) in the alliance chain C has completed the detailed KYC process of a policyholder and stored the relevant data in a server within the company in a structured manner. If the same policyholder wants to purchase insurance products from another insurance company (hereinafter referred to as insurance company B), the clerk of insurance company B needs to verify whether the policyholder is himself or not. The clerk can use a handheld device (such as a tablet computer) ) to send the required verification items to the policyholder’s mobile phone, at this time the mobile phone can perform the following three actions sequentially, simultaneously or alternatively:

1. Check whether there is an on-chain record with the same verification on the consortium chain C. If there is, provide the public key to the handheld device of the salesman of insurance company B for verification calculation. If the verification is successful, you can authenticate yourself.

2. Check whether there is a verifiable certificate in the storage space of the mobile phone itself. If there is, it will be sent to the handheld device of the salesman of insurance company B. At this time, the handheld device will ask the mobile phone to decrypt it with its private key. After decryption If the text of the document is confirmed as the same, it is confirmed as the person.

3. Use the data exchange system 100 provided by this creation, that is, the mobile phone is the aforementioned user node 10, the server of insurance company A is the aforementioned first service node 20, and the handheld device of the salesman of insurance company B Then it becomes the aforementioned second service node 30 . In step S51, the user node 10 requests the first service node 20 to generate a suitable verifiable credential 24, and this verifiable credential 24 includes the decentralized identity held by the user node 10 and a part of the user profile 22 , including but not limited to the aforementioned KYC process-related information, whether there are past diseases, whether to purchase insurance products from other insurance companies, whether the total claim amount exceeds NT$3 million, etc. In step S52, the first service node 20 uses the public key 12 of the user node to produce a verifiable certificate 24; in step S53, the verifiable certificate 24 is stored in a decentralized identity address specified by the user node 10 (this is the credential information 26). In the next step S54, the second service node 30 obtains the verifiable certificate 24 according to the certificate information 26; in step S55, the second service node 30 requests the user node 10 to assist in verifying the authenticity of the verifiable certificate 24 with its private key 12 , if the verification is successful, it can also be confirmed as the person.

Finally, please refer to Figure 7 to create a flow diagram of the sixth usage scenario. The scenario is about the qualification verification mechanism for salespersons in the insurance recruitment market. The purpose is to overcome the information unequal problem between salespersons and policyholders. And help policyholders choose good salesmen. The level of salespersons can be ensured through the relevant qualifications and common examinations required by financial regulations. The regulations also require that businesses need to undergo education and training every year, and they can only attract business after obtaining a certificate. Although the traditional verification method can help policyholders to determine the qualifications of the salesperson, it will over-expose the personal privacy information of the salesperson, which is a kind of rights infringement for the salesperson, and this problem can be solved by using the data exchange system provided by this creation 100 were resolved.

Assuming that a salesman passes the examination in an examination and training institution and completes relevant education and training, the mobile phone APP used by the salesman is the aforementioned user node 10, and the terminal server of the examination and training institution can Act as the aforementioned first service node 20, and use the public key 12 of the user node 10 to make a verifiable credential 24 based on the salesman's examination and training results (step S61), wherein the content of the verifiable credential 24 includes the salesman's A decentralized identity and at least part of its user information, including but not limited to the results of a certain annual salesperson qualification examination, the results of a certain annual financial market and moral examination, the results of a certain annual investment insurance policy salesman qualification examination, the results of a certain annual legal Obey the results of six hours of education and training, etc. In step S62, the verifiable certificate 24 is sent to the mobile phone APP (user node 10) used by the salesperson and stored there.

If a policyholder wants to verify the qualification of the salesperson, the mobile phone APP used by the policyholder is the aforementioned second service node 30 . This requirement can be accomplished simply by scanning the QR code generated by the first service node 20, or, in step S63, the second service node 30 requires the user node 10 to provide a verifiable certificate 24, and then in step S64, the second service node 30 The user node 10 is required to verify the authenticity of the verifiable credential 24 with its private key 14 . If the authenticity of the verifiable credential 24 is verified, then the second service node 30 can obtain at least a part of the user profile 22 therefrom (step S65 ), thereby confirming whether the salesperson is qualified. In addition, in order to strengthen the trust of the policyholder, the alliance chain C can be further used to verify the digital certificate of the salesman, and to confirm the qualification of the certificate issuer (the examination and training institution) for the second time.

In practice, because the user's desired actions may have different levels of security requirements, the user node 10 may also have a multi-layered security architecture, applying the data exchange system 100 provided by the present invention at different levels. For example, actions such as checking an insurance policy or checking a passbook generally have low security requirements. The user node 10 can use the FIDO (Fast IDentity Online) architecture with the aforementioned identity verification method or other self-sovereign identity (SSI) ) method for verification; actions such as claim settlement or micropayment require relatively higher security levels, and user nodes 10 can be verified by corresponding blockchain keys; finally, actions such as policy purchases, large-amount transfers, and payments require the highest level of security level, in addition to the blockchain key verification, the user node can also be verified by a time-based one-time password algorithm (Time-based One-Time Password, TOTP). Here is a brief explanation based on the actual usage situation: If a policyholder wants to insure with an insurance company, the usual practice needs to be assisted by a salesperson or telemarketing customer service to fill in personal information, and then transfer it to the underwriting department for paper review; In the new online insurance application process, the insurance products are relatively limited, and it still takes time to fill in personal information, and the verification method mostly uses MID mobile identification, which takes a long time and costs high.

In contrast, the policyholder can first go through the detailed KYC process, and then use the data exchange system 100 provided by this creation, the user node 10 used by the policyholder can send the insurance company’s terminal server (ie, the first service node 20 ) The information such as the public key 12 and the ID number in the high-level transaction key are transmitted, and then the first service node 20 generates a verifiable certificate 24 . If another insurance company wants to obtain the user information 22 of the policyholder, it can perform identity verification through its terminal server (ie, the second service node 30), and then obtain it from the first service node 20, so as to facilitate its subsequent Internal underwriting operations.

In addition, even though all the data exchange behaviors in the above usage scenarios occur on a single consortium chain C, the need for cross-chain verification cannot be ruled out in practice. In detail, under the current commercial application, in order to take into account privacy and legal requirements, sometimes a complete service needs to rely on more than one alliance chain, for example, medical data may be stored on a medical alliance chain, education Credentials are stored on an education chain, KYC certification is stored on a financial chain, etc. Various materials may require cross-chain verification. There will be different data structures on different consortium chains, and it is possible to properly utilize the data exchange system 100 provided by this creation to carry out the endorsement certification of the entire blockchain network and the issuing party without distributing personal data .

To sum up, the data exchange system 100 provided by this creation can carry out identity verification in a safe and convenient way under the premise of meeting the current regulations and personal data protection, and can exchange data effectively, and because it operates on the alliance chain C , can also reduce the burden of using the public key P, and save the service fee of the blockchain. It is a good solution with automation, high security, wide application scenarios, and low cost.

The above description is only a preferable feasible embodiment of this creation, and any equivalent structure or method changes made by applying this creation instruction manual and the scope of the patent application should be included in the scope of the patent of this creation.

100: Data Exchange System 10: User node 12: public key 14: Private key 20: The first service node 22: User Profile 24: Verifiable Credentials 24A: Verification message 26: Voucher Information 30: Second service node C: alliance chain S: side chain P: public chain T: encrypted channel S11-S19: Steps S21-S29: Steps S31-S35: Steps S41-S45: Steps S51-S55: Steps S61-S65: Steps

Fig. 1 is a schematic diagram of a data exchange system of an embodiment of the invention; Figure 2 is a flow chart of the steps for the first usage scenario of this creation; Figure 3 is a flow chart of the steps for the second use scenario of this creation; Figure 4 is a flow chart of the steps of the third usage scenario of this creation; Figure 5 is a flow chart of the steps of the fourth usage scenario of this creation; Figure 6 is a flow chart of the steps of the fifth usage scenario of this creation; and Figure 7 is a flow chart of the steps for creating the sixth usage scenario.

100: Data Exchange System

10: User node

12: public key

14: Private key

16: Digital Identity

20: The first service node

22: User Profile

24: Verifiable Credentials

24A: Verification message

26: Voucher Information

30: Second service node

C: alliance chain

S: side chain

P: public chain

T: encrypted channel

Claims (10)

A data exchange system at least includes: a user node, holding a public key and a private key, wherein the public key and the private key are corresponding; a first service node, connected with the user node information, and keeping a User information; the first service node uses the public key provided by the user node and the user information to generate a verifiable certificate (Verifiable Credential, VC) and a certificate information, and transmits the certificate information to the user node for storage; and A second service node is informationally connected to the user node; the second service node obtains the verifiable certificate by using the certificate information provided by the user node, and then requires the user node to use the private key to verify the authenticity of the verifiable certificate Wherein, if the user node successfully verifies the authenticity of the verifiable credential in accordance with the requirements of the second service node, the second service node is allowed to obtain at least a part of the user data kept by the first service node share. The data exchange system as described in claim 1, wherein the verifiable certificate includes a verification message, and when the second service node requests the user node to verify the authenticity of the verifiable certificate, it encrypts the certificate with the public key The verification message of the verifiable certificate is sent to the user node, and the user node uses the private key to decrypt the verification message of the verifiable certificate, and then sends it back to the second service node for comparison. If the comparison is correct, then A digital identity of the user node is verified. The data exchange system as described in Claim 1, wherein the first service node further links the verifiable certificate to a consortium blockchain, and the certificate information is a block chain bit of the verifiable certificate address; the second service node uses the block chain address to obtain the verifiable certificate in the consortium chain. The data exchange system as described in Claim 3, wherein the consortium chain adopts proof-of-authority (POA) as its consensus algorithm. The data exchange system as described in Claim 3, wherein the consortium chain is connected to a public chain through a side chain. The data exchange system as described in Claim 1, wherein the first service node stores the verifiable certificate in an InterPlanetary File System (IPFS), and the certificate information is a content identification of the verifiable certificate code (content identifier, CID); the second service node obtains the verifiable certificate by using the content identifier. The data exchange system as described in Claim 1, wherein at least a part of the user data kept by the first service node is included in the verifiable certificate; the second service node is obtained from the verifiable certificate the at least a portion of the user profile. The data exchange system as described in Claim 1, wherein at least a part of the user data stored by the first service node is transmitted to the second service node through an encrypted channel or an encrypted envelope. The data exchange system as described in Claim 1, wherein the first service node saves the user data in an InterPlanetary File System (IPFS), and the second service node obtains the user from the InterPlanetary File System at least part of the data. The data exchange system as described in Claim 1, wherein the public key held by the user node is an entity key.

Images