Conversion device and smart contract

Abstract

To convert an electronic document such that a verifier can believe that contents after conversion are the same as contents before the conversion by allowing confirmation of the validity of the conversion.SOLUTION: A conversion device 1 comprises: an acquisition unit 111 capable of acquiring target data to be converted and provider information pertaining to a provider of the target data; a conversion request unit 112 capable of commanding a smart contract to convert the target data, where the smart contract can cause an electronic computer 2 to perform a conversion step capable of converting the target data into converted data, and a provision step capable of providing verifiable converted data obtained by adding the provider data and an address of the smart contract to the converted data; and a smart contract display unit 113 capable of commanding the display of the processing contents of the smart contract pertaining to the address.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a conversion device and a smart contract. [Background technology]

[0002] When converting electronic documents (data), there is a demand for verifying the validity of the conversion. Regarding verifying the validity of the conversion, for example, in a method that detects tampering by verifying an electronic signature, the method detects tampering by detecting changes in the data itself using the electronic signature. Therefore, if the format of a document is converted or part of a document is extracted, the document is erroneously detected as having been tampered with. Therefore, there is a concern that such a method cannot verify the validity of the conversion, including the format conversion, etc. Thus, there is a demand for a means that can verify the validity of the conversion, including the format conversion, etc.

[0003] With regard to verifying the validity of electronic document conversion, Patent Document 1 discloses an information processing device that verifies the data integrity of a signed converted document file in which signature information is added to a converted document file generated by performing a data conversion process on a document file, the information processing device comprising: an extraction means that extracts first lossy compressed data calculated from the document file before the signature information is added, which is included in the signed converted document file, and second lossy compressed data calculated from the converted document file generated by performing the data conversion process on the document file; a first calculation means that calculates third lossy compressed data from the converted document file of the signed converted document file; and a first verification means that verifies the data integrity of the signed converted document file by comparing the second lossy compressed data with the third lossy compressed data.

[0004] The technique of Patent Document 1 can verify the data integrity of a converted document file in the state of the converted document file after the data conversion process of the document file. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2008-312064 A Summary of the Invention [Problem to be solved by the invention]

[0006] In the technology of Patent Document 1, data integrity of the converted document file is confirmed by checking the assigned electronic name and comparing the lossy compressed data to confirm that it has not been tampered with. However, there are concerns that the information processing device of Patent Document 1 will be complex to implement. Furthermore, the verification of the information processing device of Patent Document 1 cannot eliminate the possibility of name matching due to collusion between multiple recipients (loss of pairwise pseudonymity). In addition, there are concerns that the verification is not suitable for many use cases because it imposes many restrictions on conversion, such as being unable to handle conversion that extracts part of the data.

[0007] Even if it were possible to verify the validity of conversion, including format conversion and partial data extraction, by using some kind of cryptographic technology, there would be concerns that the implementation would be complicated and that many restrictions would be placed on the conversion, as with the technology in Patent Document 1.

[0008] In order to accommodate many use cases, a method of requesting conversion from a trusted entity can be used. However, this method raises concerns that the entity requesting the conversion cannot verify the legitimacy of the conversion.

[0009] One possible method is to request the issuer of the data to be converted to create the converted data and affix a digital signature to it. However, with this method, there is a concern that the converted data cannot be created if the issuer does not store the data to be converted, or if the issuer is offline and not connected to the Internet.

[0010] The object of the present invention is to enable a verifier to trust that the content after conversion is the same as the content before conversion by making it possible to verify the validity of the conversion when converting an electronic document. [Means for solving the problem]

[0011] As a result of intensive research into solving the above problem, the inventors have found that the above object can be achieved by performing a conversion in a smart contract to generate converted data to which the address of the converted smart contract is assigned, and by making it possible to display the smart contract related to the address. The inventors have then completed the present invention. Specifically, the present invention provides the following.

[0012] The present invention provides a conversion device comprising: an acquisition unit capable of acquiring target data to be converted and provider information related to a provider of the target data; a conversion request unit capable of requesting conversion of the target data from a smart contract on a blockchain, the smart contract being capable of causing the blockchain to execute a conversion step capable of converting the target data into converted data, and a provision step capable of providing verifiable converted data in which the provider data and the address of the smart contract are assigned to the converted data; and a smart contract display unit capable of displaying processing contents of the smart contract related to the address, wherein the conversion step is capable of conversion that changes the format of the target data and conversion that extracts a part of the target data.

[0013] The present invention can instruct a smart contract to perform processing to convert target data, such as changing the format of the target data or extracting a part of the target data. This allows the conversion of electronic documents to be performed by the smart contract on the blockchain. Here, the smart contract on the blockchain can verify the processing content of the smart contract and any fraud or tampering related to it in a distributed manner.

[0014] The present invention makes it possible to easily confirm whether the conversion process related to the converted data, i.e., the conversion process in the smart contract, is a process that performs legitimate data conversion, by displaying the smart contract related to the address assigned to the converted data. This allows the verifier to believe through the confirmation that the content after conversion is the same as the content before conversion. In other words, the present invention can realize the formation of distributed trust related to data conversion.

[0015] In addition, the conversion device of the present invention can be configured such that the above-mentioned conversion step is capable of writing verification information into a specified blockchain, capable of verifying whether the converted data is data converted by the smart contract, and the providing step is capable of assigning a verification information address of the verification information to the verifiable converted data.

[0016] When the verifier receives the verifiable converted data from the present invention configured in this way, the verifier can retrieve the verification information from the verification information address assigned thereto and use the verification information to verify that the data is converted by the smart contract of the present invention. This allows the verifier to be more confident that the converted content is the same as the pre-conversion content. Effect of the Invention

[0017] The present invention provides a means for verifying the validity of conversion of an electronic document, thereby enabling a verifier to trust that the content after conversion is the same as the content before conversion. [Brief description of the drawings]

[0018] [Figure 1] FIG. 1 is a block diagram showing an example of the hardware configuration and software configuration of a system S of the present embodiment. [Diagram 2] FIG. 2 is a main flowchart showing an example of a preferable flow of the data conversion process in conversion device 1. [Diagram 3] FIG. 3 is a continuation of FIG. [Figure 4] FIG. 4 is a flowchart showing an example of a preferred flow of the conversion process executed by smart contract C. [Diagram 5] FIG. 5 is a continuation of FIG. [Figure 6] FIG. 6 is a flowchart showing an example of the process flow in the system S when the holder and the verifier are the same person. [Figure 7] FIG. 7 is a flowchart showing an example of a process flow in the system S when the holder and the verifier are different. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] Hereinafter, an example of an embodiment of the present invention will be described in detail with reference to the drawings.

[0020] <System S> 1 is a block diagram showing an example of the hardware configuration and software configuration of the system S of this embodiment. The following describes an example of a preferred embodiment of the hardware configuration and software configuration of the system S of this embodiment with reference to FIG.

[0021] The system S includes a conversion device 1 and a blockchain 2 that can communicate with each other via a network N.

[0022] [Conversion device 1] The conversion device 1 includes a control unit 11, a storage unit 12, and a communication unit 13. The type of the conversion device 1 is not particularly limited. The type of the conversion device 1 may be, for example, a server device, a cloud server, a terminal, etc. The terminal may be, for example, a personal computer, a laptop computer, a smartphone, a tablet terminal, etc.

[0023] [Control unit 11] The control unit 11 includes a central processing unit (CPU), a random access memory (RAM), and a read only memory (ROM).

[0024] The control unit 11 cooperates with the storage unit 12 and / or the communication unit 13 as necessary. The control unit 11 then realizes an acquisition unit 111, a conversion request unit 112, a smart contract display unit 113, and the like, which are software components of the program of this embodiment executed by the conversion device 1. The functions provided by each of the software components of the program of this embodiment will be described later in the description of a preferred flow of the data conversion process.

[0025] [Storage unit 12] The storage unit 12 is a device in which data and / or files are stored, and includes a data storage unit such as a hard disk, a semiconductor memory, a recording medium, and a memory card.

[0026] The storage unit 12 may have a mechanism that enables connection via the network N to a storage device or storage system such as a NAS, a SAN, cloud storage, a file server, and / or a distributed file system.

[0027] Programs executed by a microcomputer and the like are stored in the storage unit 12. The storage unit 12 can store target data, provider information, a verification key, converted data, and the like.

[0028] [Communications Section 13] The communication unit 13 is not particularly limited as long as it connects the conversion device 1 to the network N and enables communication with the blockchain 2, etc. Examples of the communication unit 13 include a wireless device compatible with a mobile phone network, a device connectable to a wireless LAN, and a network card compatible with the Ethernet standard.

[0029] [Blockchain 2] There are no particular limitations on the blockchain 2, so long as it is possible to execute a smart contract C that uses data recorded in the blockchain. The blockchain 2 has a data structure that can easily prove the sequence of events or the time when data existed, and detect tampering, by using a chain of electronic signatures and hash values, and achieves high availability and data integrity by storing the data in a large number of nodes distributed over the network. This makes it possible for the blockchain 2 to verify fraud and tampering in the executed smart contract C and the various written data in a distributed manner.

[0030] The blockchain 2 is preferably configured to allow verification information to be written therein. Here, the verification information is information that allows verification as to whether the converted data is data converted by the smart contract C. This allows the verifier to confirm that the converted data is data converted by the smart contract C by using the verification information that is difficult to tamper with written on the blockchain 2. This allows the verifier to have even greater confidence that the content after conversion is the same as the content before conversion.

[0031] [Smart Contract C] Smart contract C is not particularly limited as long as it is possible to cause blockchain 2 to execute the following steps: an acquisition step capable of acquiring target data to be converted and provider information related to the provider of the target data; a conversion step capable of converting the target data to be converted into converted data; and a provision step capable of providing verifiable converted data in which the provider data and the address of smart contract C are added to the converted data.

[0032] It is preferable that smart contract C is further capable of executing a verification step in which a verification key is used to verify whether the target data is legitimate data, and that the conversion step is capable of executing the conversion if the target data is verified to be legitimate data in the verification step.

[0033] The conversion step can change the format of the target data and extract a part of the target data. Examples of such conversion include a conversion from an X.509 format digital certificate to a JSON format, a conversion from an X.509 format digital certificate to a JWT format with an HMAC added, etc. The conversion in the conversion step is not limited to the exemplified conversion, and may be various conversions including a change in the format of the target data and / or extraction of a part of the target data.

[0034] [Network N] The type of the network N is not particularly limited as long as it enables the conversion device 1 and the blockchain 2 to communicate with each other. The type of the network N is, for example, the Internet, a mobile phone network, a wireless LAN, etc.

[0035] [Main Flowchart of Data Conversion Processing in Conversion Device 1] Fig. 2 is a main flowchart showing an example of a preferable flow of the data conversion process in the conversion device 1. Fig. 3 is a diagram following Fig. 2. Below, an example of a preferable flow of the data conversion process in the conversion device 1 will be described using Figs. 2 and 3.

[0036] First, the conversion device 1 executes an acquisition step of acquiring target data to be converted and provider information related to the provider of the target data (steps S1 to S4).

[0037] [Step S1: Determine whether the target data and provider information can be acquired] The control unit 11 executes the acquisition unit 111 in cooperation with the storage unit 12 and the communication unit 13. Then, the control unit 11 executes a process of determining whether the target data to be converted and the provider information related to the provider of the target data can be acquired (step S1, target data, etc. acquisition possibility determination step). If it is determined that it can be acquired, the control unit 11 shifts the process to step S2. If it is not determined that it can be acquired, the control unit 11 shifts the process to step S7.

[0038] [Step S2: Obtain target data and provider information] The control unit 11 executes a process of acquiring the target data and the provider information related to the determination in step S1 (step S2, target data acquisition execution step). The control unit 11 moves the process to step S3.

[0039] The format of the target data acquired in the target data acquisition execution step is not particularly limited. The format preferably includes, for example, a digital certificate in X.509 format. This allows the conversion device 1 and smart contract C to extract some information, exemplified by the subject who is the owner of the certificate, the subject's public key information, and the like, from various information included in the digital certificate in X.509 format, which is the standard format for public key certificates, and convert it into another format.

[0040] In addition, the format preferably includes various formats of decentralized identifiers (DIDs) defined by, for example, ERC725, ERC734, ERC735, etc. This allows the conversion device 1 and smart contract C to extract some information necessary for the destination format from various information included in the DID and convert it into another format.

[0041] The provider information acquired in the target data acquisition execution step is not particularly limited as long as it can identify the provider (issuer, etc.) of the target data. As a result, the conversion device 1 and the smart contract C can include information that can identify the provider of the target data in the converted data after conversion. The provider information may be, for example, issuer information included in the target data.

[0042] [Step S3: Determine whether a verification key can be obtained] The control unit 11 executes a process to determine whether a verification key related to the target data etc. acquired in step S2 can be acquired (step S3, verification key acquisition possibility determination step). If it is determined that the verification key can be acquired, the control unit 11 moves the process to step S4. If it is not determined that the verification key can be acquired, the control unit 11 moves the process to step S5. The verification key related to the target data etc. is, for example, a verification key of a user of the conversion device 1, a verification key of a holder of the target data, etc.

[0043] [Step S4: Obtain verification key] The control unit 11 executes a process of acquiring the verification key determined to be obtainable in step S3 (step S4, verification key acquisition execution step), and the control unit 11 moves the process to step S5.

[0044] The verification key for the verification key acquisition determination step and the verification key acquisition execution step is not particularly limited as long as it can verify the target data. If the target data is in the format of an X.509 digital certificate, the verification key may be, for example, a public key of a higher-level certificate of the target data.

[0045] [Step S5: Request conversion of target data] The control unit 11 executes the conversion request unit 112 in cooperation with the storage unit 12 and the communication unit 13. The control unit 11 executes a process of requesting the smart contract C on the blockchain 2 to convert the target data acquired in step S2 (step S5, conversion request step). The control unit 11 shifts the process to step S6.

[0046] The conversion request step preferably includes a procedure of providing provider information to smart contract C. This enables smart contract C to include the provided provider information in the converted data after conversion.

[0047] If the verification key has been acquired in the verification key acquisition execution step, the conversion request step may include a procedure of providing the verification key to smart contract C and instructing verification using the verification key. This enables smart contract C to verify the target data using the provided verification key.

[0048] The conversion request step may include a procedure of instructing the smart contract C to write the verification information. This allows the smart contract C to write the verification information capable of verifying whether the converted data is data converted by the smart contract C in response to the instruction.

[0049] [Step S6: Obtain converted data] The control unit 11 executes a process of acquiring the converted data from the smart contract C in response to the request in step S5 (step S6, converted data acquisition step). The control unit 11 moves the process to step S7. The converted data acquired in the converted data acquisition step is assigned the address of the smart contract C that converted the converted data.

[0050] [Step S7: Determine whether a command to display the processing contents has been issued] The control unit 11 executes the smart contract display unit 113 in cooperation with the storage unit 12 and the communication unit 13. The control unit 11 executes a process of determining whether a command has been issued to display the processing contents of the smart contract C related to the specified address (step S7, display command determination step). If it is determined that a command has been issued, the control unit 11 transfers the process to step S8. If it is not determined that a command has been issued, the control unit 11 transfers the process to step S1.

[0051] The "designated address" in the display command determination step is the address of the smart contract C assigned to the converted data acquired in step S6. This allows the conversion device 1 to display the processing content of the smart contract C related to the converted data in the following step S8.

[0052] [Step S8: Display processing details] The control unit 11 executes a process of displaying the processing content of the smart contract C related to the address specified in step S7 (step S8, smart contract display step). The control unit 11 shifts the process to step S1.

[0053] The conversion device 1 displays the smart contract C related to the address assigned to the converted data, thereby making it possible to easily confirm whether the conversion process related to the converted data, i.e., the conversion process in the smart contract C, is a process that performs legitimate data conversion. This allows the verifier to believe through the confirmation that the content after conversion is the same as the content before conversion. In other words, the conversion device 1 can realize the formation of distributed trust related to data conversion.

[0054] [Flowchart of conversion process related to smart contract C] Fig. 4 is a flowchart showing an example of a preferred flow of the conversion process that smart contract C causes blockchain 2 to execute. Fig. 5 is a diagram following Fig. 4. The following describes an example of a preferred flow of the conversion process related to smart contract C using Figs. 4 and 5.

[0055] In the description of this embodiment, the execution of some [processing] related to smart contract C by some or all of the computers participating in the realization of processing in the blockchain 2 is also described as "smart contract C causes blockchain 2 to execute [processing]" or "smart contract C executes [processing]." In addition, the transition of processing related to smart contract C from a currently executing step to [another step] is also described as "smart contract C transfers processing to [another step]."

[0056] [Step S11: Obtain the sent data] The smart contract C executes a process of acquiring the data sent from the conversion device 1 (step S11, data acquisition step). The smart contract C moves the process to step S12. The data includes, for example, the target data, the provider information, a verification key, an instruction to verify the target data by the verification key, and / or an instruction to write the verification information.

[0057] [Step S12: Determine whether target data and provider information have been acquired] The smart contract C executes a process of determining whether the target data and provider information have been acquired in step S11 (step S12, data determination step). If it is determined that the target data and provider information have been acquired, the smart contract C moves the process to step S13. If it is not determined that the target data and provider information have been acquired, the smart contract C ends the conversion process.

[0058] [Step S13: Determine whether to perform verification using the verification key] The smart contract C executes a process to determine whether to perform verification using the verification key on the target data related to step S12 (step S13, verification execution determination step). If it is determined that verification should be performed, the smart contract C transfers the process to step S14. If it is not determined that verification should be performed, the smart contract C transfers the process to step S15.

[0059] The verification execution determination step includes, for example, a procedure of determining that verification using the verification key is to be performed when an instruction to verify the target data using the verification key is acquired in step S11.

[0060] [Step S14: Determine whether the target data is valid] The smart contract C executes a process of determining whether the target data is valid using the verification key related to step S13 (step S14, verification step). If it is determined that the data is valid, the smart contract C moves the process to step S15. If it is not determined that the data is valid, the smart contract C ends the conversion process.

[0061] The smart contract C executes a conversion step of converting the target data related to step S12 (steps S15 to S17). The conversion step preferably includes a verification information writing step (steps S16 to S17) capable of writing verification information capable of verifying whether the converted data is data converted by the smart contract C to the blockchain 2.

[0062] [Step S15: Convert the target data] The smart contract C executes a process of converting the target data related to step S12 and obtaining converted data (step S15, conversion execution step). The smart contract C shifts the process to step S16.

[0063] The conversion execution step is not particularly limited. The conversion execution step is a step capable of performing conversion to change the format of the target data and to extract a part of the target data.

[0064] The conversion execution step includes, for example, a procedure for converting a digital certificate in X.509 format into a JSON format, a procedure for converting a digital certificate in X.509 format into a JWT format with an HMAC added, and the like.

[0065] The procedure for converting a digital certificate in X.509 format to JSON format is a conversion for converting the format of the target data from X.509 format to JSON format. This procedure can also be a conversion for extracting a part of various information contained in the target data. For example, a conversion for extracting a part may be a conversion for extracting only the issuer identifier and the date of birth from the information contained in the digital certificate in X.509 format and including them in the converted data in JSON format.

[0066] The procedure for converting an X.509 format digital certificate into a JWT format with an HMAC is a conversion for converting the format of the target data from the X.509 format to the JWT format. This procedure can also be a conversion for extracting a part of various information contained in the target data. An example of a conversion for extracting a part is a conversion for extracting only the issuer identifier and the date of birth from the information contained in the X.509 format digital certificate, using the identifier of smart contract C as the sub value which is the target user ID of the ID token, using the document number as the JTI value which is the JWT identifier of the converted data, and adding an HMAC value.

[0067] The conversion execution step may also include a procedure for converting various formats of decentralized identifiers (DIDs) defined by, for example, ERC725, ERC734, ERC735, etc. into DIDs of another format. In this case, if smart contract C is configured as a universal resolver capable of converting various DIDs, the smart contract C can function as a DID universal resolver that does not require a central service.

[0068] [Step S16: Determine whether to write verification information] The smart contract C executes a process of determining whether to write the verification information of the converted data related to step S15 to the blockchain 2 (step S16, verification information writing determination step). If it is determined to write, the smart contract C transfers the process to step S17. If it is not determined to write, the smart contract C transfers the process to step S18.

[0069] The verification information write determination step includes, for example, a procedure of determining that the verification information is to be written if an instruction to write the verification information is acquired in step S11.

[0070] [Step S17: Write verification information] The smart contract C executes a process of writing the verification information of the converted data related to step S15 to the blockchain 2 (step S17, verification information writing execution step). The smart contract C shifts the process to step S18.

[0071] The verification information is not particularly limited. The verification information is information that enables verification as to whether the converted data is data converted by smart contract C. The verification information includes, for example, an identifier of the converted data and a hash value of the converted data. This allows a verifier to verify that the converted data is data converted by smart contract C using the identifier and the hash value. When the format of the converted data is a JWT format with HMAC added, the verification information is, for example, information including a JTI value and an HMAC value of the converted data.

[0072] [Step S18: Provide converted data] The smart contract C executes a process of providing the verifiable converted data to the conversion device 1 according to step S11 (step S18, providing step). Here, the verifiable converted data is data obtained by adding the provider data according to step S12 and the address of the smart contract C to the converted data according to step S15. The smart contract C ends the conversion process.

[0073] If the verification information is written in step S17, the verifiable converted data provided in the providing step is preferably provided with a verification information address of the verification information. This allows the verifier to obtain the verification information using the verification information address provided in the verifiable converted data. The verifier can then verify the verifiable converted data using the verification information obtained in this manner.

[0074] [Conversion process effect] Through the conversion process from step S11 to step S18, the holder of the target data can instruct smart contract C to convert the target data, such as changing the format of the target data or extracting a part of the target data. As a result, the conversion of the electronic document is performed by smart contract C on the blockchain 2. Here, smart contract C on the blockchain 2 can verify fraud, tampering, etc. related to smart contract C in a distributed manner.

[0075] The conversion step in the conversion process from step S11 to step S18 can be configured to write verification information into the blockchain 2 (steps S16 to S17) that can verify whether the converted data is data converted by smart contract C, and the providing step can be configured to assign a verification information address of the verification information to the verifiable converted data.

[0076] The verifier receives the verifiable converted data from the smart contract C configured in this way, and can extract the verification information from the verification information address assigned thereto. The verifier can then use the verification information to confirm that the data is converted by the smart contract C according to the present invention. This allows the verifier to be more confident that the converted content is the same as the pre-conversion content.

[0077] Therefore, the smart contract C of the present invention can provide a means for a verifier to trust that the content after conversion is the same as the content before conversion by enabling the verifier to verify the validity of the conversion when an electronic document is converted.

[0078] <Example> Next, various examples of this embodiment will be described.

[0079] [Example 1] Extracting issuer ID and date of birth from an X.509 format ID card and converting it into JSON format data In the first embodiment, a smart contract C is configured to extract an issuer ID and a date of birth from an identification card in X.509 format and convert the data into JSON format. The conversion device 1 and smart contract C in the first embodiment provide conversion from an identification card in X.509 format to data in JSON format when the holder and the verifier are the same person.

[0080] As a result, the conversion device 1 and smart contract C of this embodiment can provide a means for a verifier, who is also the holder, to believe that the converted content is the same as the pre-conversion content in the conversion of an identification document, where legitimacy is particularly important.

[0081] 6 is a flowchart showing an example of a process flow in the system S when the holder and the verifier are the same person. The following describes the flow of conversion according to the first embodiment with reference to FIG.

[0082] [Step SA1: Issue target data] First, the issuer issues an X.509 formatted identification card D to the verifier. The verifier, who is also the holder of the issued identification card D, obtains the identification card D via the conversion device 1 or the like.

[0083] [Step SA2: Conversion request] The verifier requests the smart contract C, via the conversion device 1, to convert the identity document D issued in step SA1 into JSON format data.

[0084] [Step SA3: Conversion] Smart contract C extracts the issuer ID and date of birth from identification document D using the above-mentioned conversion process and converts them into converted data B in JSON format with the address of smart contract C attached.

[0085] [Step SA4: Converted data] The conversion device 1 obtains the converted data B from the smart contract C.

[0086] [Additional Steps] The verifier issues a command to display the processing content of smart contract C corresponding to the address assigned to converted data B via conversion device 1. The verifier is convinced from the displayed processing content that converted data B has been subjected to the desired conversion by smart contract C.

[0087] [Example 2] Extracting the issuer ID and date of birth from an X.509 format ID card and converting it into JWT format data so that a third party can verify it In the second embodiment, a smart contract C is configured to extract an issuer ID and a date of birth from an identification card in X.509 format, and convert the data into JWT format so that a third party can verify the data. The conversion device 1 and smart contract C in the second embodiment provide conversion from an identification card in X.509 format to data in JWT format when the holder and the verifier are different.

[0088] As a result, the conversion device 1 and smart contract C of this embodiment can provide a means for a verifier other than the holder to believe that the converted content is the same as the pre-conversion content in the conversion of an identification document, where legitimacy is particularly important.

[0089] 7 is a flowchart showing an example of a process flow in the system S when the holder and the verifier are different. The following describes the flow of conversion according to the second embodiment with reference to FIG.

[0090] [Step SB1: Issue target data] First, the issuer issues an X.509 formatted identity card D to the verifier. The holder obtains the identity card D via a conversion device 1 or the like.

[0091] [Step SB2: Conversion request] The holder requests the smart contract C to convert the identification D issued in step SB1 into JWT format data via the conversion device 1. At this time, it is preferable that the holder further transmits data for authenticating the holder of the identification D and confirming that the subject of the identification D and the holder are the same. It is also preferable that the holder further transmits verification data that the holder uses to authenticate the verifier when presenting the converted data in step SB6 described later.

[0092] [Step SB3: Conversion] The smart contract C extracts the issuer ID and date of birth from the identification D through the above-mentioned conversion process, and converts them into converted data E in JWT format with the address and HMAC of the smart contract C. At this time, it is preferable that the smart contract C authenticates the holder of the identification D prior to the conversion, and confirms that the subject of the identification D and the said holder are the same person. In this way, the smart contract C can prevent a person other than the subject of the identification D from performing the conversion.

[0093] [Step SB4: Write verification information] The smart contract C writes the verification information F related to the converted data E of step SB3 to the blockchain 2. This verification information F includes the JTI value and HMAC of the converted data E.

[0094] [Step SB5: Converted data] The holder obtains the converted data E, which has the address of the verification information F attached, from the smart contract C via the conversion device 1.

[0095] [Step SB6: Present converted data] The holder presents to the verifier the converted data E acquired in step SB5. At this time, it is preferable that the holder further sends verification data that the verifier uses for authentication.

[0096] [Step SB7: Obtain verification information] The verifier obtains the verification information F using the address of the verification information F attached to the converted data E presented in step SB6.

[0097] [Step SB8: Verification] The verifier uses the verification information F acquired in step SB7 to verify the converted data E. The verifier can be confident that the converted data E is data converted by the smart contract C based on the verification information F, and therefore can be confident that the converted data E is the identification document D converted by the smart contract C.

[0098] [Additional Steps] The verifier issues a command to display the processing details of smart contract C corresponding to the address assigned to converted data E via the conversion device 1. The verifier is convinced from the displayed processing details that the converted data B has undergone the desired conversion by smart contract C. At this time, the conversion device 1 used by the verifier is not limited to the conversion device 1 used by the holder, and may be another conversion device 1 with a similar configuration.

[0099] An example of a preferred embodiment of the present invention has been described above. However, within the scope of the concept of the present invention, a person skilled in the art may come up with various modifications and alterations. Therefore, it is understood that such modifications and alterations are within the scope of the present invention, as is the case with the above-mentioned example. For example, if a person skilled in the art appropriately adds, deletes, or modifies the design of the above-mentioned embodiment, or adds, omits, or modifies the conditions of a process, these modifications and alterations are included in the scope of the present invention, as is the case with the above-mentioned example, as long as they include the gist of the present invention. [Explanation of symbols]

[0100] S System 1. Conversion device 11 Control section 111 Acquisition Department 112 Conversion request section 113 Smart Contract Display 12 Storage section 13. Communications Department 2. Blockchain C. Smart Contract N Network T-Terminal A. Target Data B, E Transformed data D. Identification card F. Verification Information

Claims

1. an acquisition unit capable of acquiring target data to be converted; A smart contract on a blockchain that, when executed by a node of the blockchain, a conversion step capable of converting the target data into converted data; and a providing step capable of providing the converted data and the address of the smart contract; A conversion request unit capable of requesting the conversion of the target data to a smart contract that realizes the above. Equipped with Conversion device.

2. A conversion device as described in claim 1, further comprising a smart contract display unit capable of displaying the processing contents of the smart contract related to the address.

3. A conversion device as described in claim 1, wherein the conversion step is capable of at least one of a conversion that changes the format of the target data and a conversion that extracts a portion of the target data.

4. The acquisition unit is also capable of acquiring provider information relating to a provider of the target data, In the providing step, the provider information can be further provided. The conversion device according to claim 1 .

5. The conversion step can write verification information into the blockchain that can verify whether the converted data is data converted by the smart contract, The conversion device according to claim 1 , wherein the providing step further provides a verification information address of the verification information.

6. the acquisition unit is further capable of acquiring a verification key related to a user of the conversion device, The conversion request unit is capable of providing the verification key to the smart contract; The smart contract is executed by a node of the blockchain, thereby realizing a verification step of verifying whether the target data is legitimate data using the verification key, The conversion step can perform the conversion when the target data is verified as valid data in the verification step. The conversion device according to claim 1 .

7. A smart contract on a blockchain, The blockchain node an acquisition step capable of acquiring target data to be converted; a conversion step capable of converting target data to be converted into converted data; a providing step for providing the converted data and the address of the smart contract; It is possible to execute Smart contracts.

Images