Verification program, verification method, and information processing device.

Abstract

To detect fraud committed in signature replacement.SOLUTION: An information processing apparatus acquires a first VC 8 that proves the validity of attribute information of a user by a first signature 8a verifiable by verification procedures of a first DID infrastructure 1, and a second VC 9 that proves the validity of the attribute information of the user by a second signature 9a verifiable by verification procedures of a second DID infrastructure 2. Next, the information processing apparatus verifies the second signature 9a contained in the second VC 9 by the verification procedures of the second DID infrastructure 2. Further, the information processing apparatus transmits a verification request for verifying the first signature 8a contained in the first VC 8 to verification devices 7a, 7b, ... capable of verifying the first signature 8a contained in the first VC 8 by the verification procedures of the first DID infrastructure 1, and then acquires, from the verification devices 7a, 7b, ..., verification results of the first signature 8a contained in the first VC 8.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a verification program, a verification method, and an information processing apparatus.

Background Art

[0002] In recent years, in order to counter the current situation where large private companies manage a large amount of personal data, the concept of self-sovereign identity (SSI: Self-Sovereign Identifiers), which aims for individuals to control their own identities, has attracted attention. In order to realize SSI, the development of a decentralized identity (DID: Decentralized Identifiers) infrastructure using decentralized PKI (Public Key Infrastructure) has been progressing. The DID infrastructure is a mechanism for an individual to manage their own attribute information (age, gender, etc.) with the signature of the issuer who guarantees the authenticity of the attribute information. Currently, various companies and organizations are developing the DID infrastructure, and it is expected that the management entities of the DID infrastructure itself will be diverse in the future.

[0003] For example, in the DID infrastructure, a user (Holder) receives a certificate in which the user's attribute information is described from an issuer (Issuer). The certificate is plain text character data, and the issuer's digital signature (hereinafter simply referred to as a signature) is attached to the certificate. Hereinafter, a signed certificate is called a VC (Verifiable Credential). Note that the certificate referred to here does not mean a server certificate used in decentralized PKI, but refers to a document in which personal attribute information and the like are described.

[0004] A user can prove their own attributes by presenting a VC with the issuer's signature to a verifier (Verifier). For example, a licensing center (issuer) issues a driver's license (VC) to a driver (user). By using the DID infrastructure, the driver can prove to a liquor store (verifier) that they are 20 years old or older using the driver's license.

[0005] Technologies related to the DID infrastructure include, for example, a method for issuing digital certificates usable by multiple encryption systems. Furthermore, a privacy authentication system capable of proving compliance with multiple layered privacy policies during cross-border data access has also been proposed. [Prior art documents] [Patent Documents]

[0006] [Patent Document 1] Japanese Patent Publication No. 2020-10396 [Patent Document 2] Japanese Patent Publication No. 2018-11203 [Overview of the Initiative] [Problems that the invention aims to solve]

[0007] Currently, multiple DID (Declaration Identity) platforms exist, and each platform uses a different signature and verification method. Therefore, if, for example, the DID platform used by the issuer to issue the VC (Verification Certificate) differs from the DID platform available to the verifier, verification becomes impossible. Thus, using VCs across different DID platforms is difficult.

[0008] Therefore, one possible solution is to enable the use of VCs across multiple DID infrastructures by having an intermediary, a third party belonging to multiple DID infrastructures, resign the signatures. However, conventional technology cannot eliminate fraud by intermediary operators who resign signatures. For example, an intermediary operator can arbitrarily issue VCs that have not been signed by the issuer. This becomes a major problem when there is no firm trust in the intermediary operator.

[0009] In one respect, this project aims to enable the detection of fraudulent activity when signatures are substituted. [Means for solving the problem]

[0010] One proposal provides a verification program that instructs a computer to perform the following steps: The computer obtains a first VC that proves the user's attribute information is correct by a first signature verifiable in the verification procedure of the first DID infrastructure, and a second VC that proves the user's attribute information is correct by a second signature verifiable in the verification procedure of the second DID infrastructure. The computer verifies the second signature contained in the second VC in the verification procedure of the second DID infrastructure. The computer sends a verification request for the first signature contained in the first VC to a verification device that can verify the first signature contained in the first VC in the verification procedure of the first DID infrastructure. The computer then obtains the verification result for the first signature contained in the first VC from the verification device. [Effects of the Invention]

[0011] According to one embodiment, fraud during signature replacement can be detected. [Brief explanation of the drawing]

[0012] [Figure 1] This figure shows an example of a verification method according to the first embodiment. [Figure 2] This figure shows an example of a system configuration. [Figure 3] This figure shows an example of the hardware of an issuer device. [Figure 4] This figure shows an example of the procedure for verifying attribute information within the same DID infrastructure. [Figure 5] This figure shows an example of a proof method that spans across DIDs. [Figure 6] This figure shows an example of a signature replacement method in the second embodiment. [Figure 7] This figure shows an example of the first and second VCs being transmitted. [Figure 8] This is a block diagram showing an example of the functions of each device in the second embodiment. [Figure 9] This figure shows an example of a list of verifiers. [Figure 10] This is a flowchart illustrating an example of the procedure for reissuing a VC (Virtual Certificate). [Figure 11]It is a flowchart showing an example of the procedure for creating the second VC. [Figure 12] It is a flowchart showing an example of the procedure for the second VC verification process. [Figure 13] It is a flowchart showing an example of the procedure for the first VC confirmation process. [Figure 14] It is a diagram showing an example of the signature replacement method in the third embodiment. [Figure 15] It is a diagram showing an example of the second VC including the first VC. [Figure 16] It is a block diagram showing an example of the functions of each device in the third embodiment. [Figure 17] It is a flowchart showing an example of the procedure for creating the second VC in the third embodiment. [Figure 18] It is a diagram showing an example of the second VC including the first VC. [Figure 19] It is a flowchart showing an example of the procedure for reconstructing the first VC. [Figure 20] It is a diagram showing a first example of the method for reducing the data amount of the second VC. [Figure 21] It is a flowchart showing an example of the procedure for creating the second VC in the fourth embodiment. [Figure 22] It is a diagram showing an example of the procedure for reconstructing the first VC in the fourth embodiment. [Figure 23] It is a diagram showing a second example of the method for reducing the data amount of the second VC. [Figure 24] It is a flowchart showing an example of the procedure for creating the second VC in the fifth embodiment. [Figure 25] It is a diagram showing an example of the second VC with duplicate items excluded. [Figure 26] It is a diagram showing an example of the procedure for reconstructing the first VC in the fifth embodiment. [Figure 27] It is a diagram showing an example of the verifier list including the method for sending verification requests. [Figure 28]This diagram shows an example of the procedure for the first VC verification method when sending a verification request using the method specific to the requesting party. [Modes for carrying out the invention]

[0013] The following description of this embodiment will be made with reference to the drawings. Note that each embodiment can be implemented by combining multiple embodiments within a reasonable scope. [First Embodiment] The first embodiment is a signature verification method for deterring fraud when signatures are reassigned to different DID infrastructures.

[0014] Figure 1 is a diagram illustrating an example of a verification method according to the first embodiment. Figure 1 shows a system for implementing the verification method. The system includes an issuer device 3, a user terminal 4, a re-signing device 5, a verifier terminal 6, and a plurality of verifier devices 7a, 7b, ... The issuer device 3, user terminal 4, re-signing device 5, and the plurality of verifier devices 7a, 7b, ... belong to the first DID base 1. The user terminal 4, re-signing device 5, and verifier terminal 6 belong to the second DID base 2. That is, the user terminal 4 and re-signing device 5 belong to both the first DID base 1 and the second DID base 2. The plurality of verifier devices 7a, 7b, ... may belong not only to the first DID base 1 but also to the second DID base 2.

[0015] Issuer device 3 is an information processing device that manages the attribute information of a user who has a user terminal 4. User attribute information is personal information of the user, such as name and facial photograph. User terminal 4 is an information processing device owned by the user. Resigning device 5 is an information processing device that verifies the signature attached to a VC issued by the first DID base 1 and issues a new VC in accordance with the VC issuance procedure of the second DID base 2. Verifier terminal 6 is an information processing device used by a verifier who wishes to prove the legitimacy of the attribute information presented by the user. Verification devices 7a, 7b, ... are information processing devices that can verify the signature attached to a VC in the verification procedure of the first DID base 1.

[0016] The information processing device that functions as the verifier terminal 6 is, for example, a computer (including a personal information terminal) having a storage unit 6a and a processing unit 6b. The storage unit 6a is, for example, memory or a storage device. The processing unit 6b is, for example, a processor or an arithmetic circuit. Similarly, the information processing devices that function as the issuer device 3, user terminal 4, resigning device 5, or verification devices 7a, 7b, ... are, for example, computers (including personal information terminals) having a storage unit and a processing unit. The computer can function as the issuer device 3, user terminal 4, resigning device 5, verifier terminal 6, or verification devices 7a, 7b, ... by executing a predetermined program. For example, the verifier terminal 6 performs verification processing of the acquired VC by executing a verification program.

[0017] In a system with this configuration, we assume a scenario where a user whose attribute information is managed by the first DID infrastructure 1 presents their attribute information to a verifier who has a verifier terminal 6 that is compatible only with the second DID infrastructure 2. In this case, the verifier requests that the attribute information presented by the user be verifiable using the verification procedure of the second DID infrastructure 2. In this case, the following processing is performed.

[0018] First, the issuer device 3 issues a first VC8 that proves the user's attribute information is correct by a first signature 8a that can be verified by the verification procedure of the first DID base 1. The user terminal 4 obtains the first VC8 from the issuer device 3. The user terminal 4 sends a request for reissuance of the VC based on the first VC8 to the resignature device 5. The reissuance request includes the first VC8.

[0019] In response to a reissue request, the resigning device 5 issues a second VC9 that proves the user's attribute information is correct using a second signature 9a that can be verified by the verification procedure of the second DID base 2. For example, the resigning device 5 verifies the first signature 8a of the first VC8 using the verification procedure of the first DID base 1, and issues the second VC9 if it confirms that the attribute information shown in the first VC8 is correct.

[0020] User terminal 4 obtains the second VC9 from the resigning device 5. Then, user terminal 4 sends the first VC8 and the second VC9 to the verifier terminal 6. The processing unit 6b of the verifier terminal 6 acquires the first VC8 and the second VC9. Then, the processing unit 6b verifies the second signature 9a included in the second VC9 using the verification procedure of the second DID base 2. The processing unit 6b outputs the verification result. For example, if the verification is successful, the processing unit 6b displays a processing result on the monitor indicating that the user's attribute information is correct.

[0021] The processing unit 6b then stores the acquired first VC8 in, for example, the storage unit 6a. Subsequently, the processing unit 6b sends a verification request for the first signature 8a contained in the first VC8 to at least one of the verification devices 7a, 7b, ... The verification device that receives the verification request verifies the first signature 8a contained in the first VC8 using the verification procedure of the first DID base 1. The processing unit 6b of the verifier terminal 6 obtains the verification result of the first signature 8a contained in the first VC8 from the verification device that performed the verification. If the processing unit 6b obtains the verification result of the first signature 8a, it then determines whether or not there is any fraud in the issuance procedure of the second VC9 based on the verification result.

[0022] With such a system, if a verifier has doubts about the legitimacy of the VC reissuance process (signature replacement), they can send a verification request to one of the verification devices 7a, 7b, ... via the verifier terminal 6 and obtain the verification result. Examples of fraudulent activity during signature replacement include the alteration of attribute information, or the resignature device 5 issuing the second VC9 without verifying that the attribute information of the first VC8 is correct using the first signature 8a.

[0023] Since it is assumed that the attribute information of the first VC8 and the second VC9 are common, it is assumed that any fraudulent attempt to rewrite attribute information will be carried out against both the first VC8 and the second VC9. If attribute information is rewritten during signature replacement, the verification results from any of the verification devices 7a, 7b, etc. will indicate that the attribute information is incorrect. This allows for the detection of fraud.

[0024] If the attribute information is rewritten only for the second VC9, the verification of the first signature 8a attached to the first VC8 will result in a verification result that the attribute information is correct. In this case, the processing unit 6b may determine the identity of the attribute information between the first VC8 and the second VC9. If the attribute information is not identical, the processing unit 6b can determine that fraud has occurred without performing any further processing such as signature verification.

[0025] Even if the attribute information of the first VC8 has been tampered with, and the re-signing device 5 issues the second VC9 without verifying the first signature 8a, the verification result by any of the verification devices 7a, 7b, ... will indicate that the attribute information is incorrect. This allows for the detection of fraud.

[0026] In this way, the verifier terminal 6 belonging to the second DID base 2 can detect fraud during signature replacement using the first VC8, even if it cannot verify the first signature 8a attached to the first VC8 created by the first DID base 1. By providing a means to check for fraud, it becomes more difficult to conceal fraud, and this is expected to have a deterrent effect on fraudulent activity.

[0027] Furthermore, it is conceivable that a second VC9 may be issued by the re-signing device 5 for attribute information for which the issuing device 3 has not issued a VC. In such a case, the first VC8 cannot be sent from the user terminal 4 to the verifier terminal 6. For example, if the processing unit 6b cannot obtain the first VC8 from the user terminal 4, it will not determine that the attribute information of the second VC9 is correct. Therefore, by specifying that the first VC8 should also be sent to the verifier terminal 6, it is possible to prevent the re-signing device 5 from issuing the second VC9 without relying on the first VC8.

[0028] When the processing unit 6b of the verifier terminal 6 sends a verification request, it selects a predetermined number of verifiers from a list of verifiers that shows multiple verifiers, for example, and sends the verification request to the selected verifiers. The processing unit 6b then determines that there is no fraud in the issuance procedure of the second VC9 if it obtains verification results from a number of verifiers that indicate that the attribute information has been verified to be correct by the first signature 8a, which is greater than or equal to a threshold (e.g., a majority). The processing unit 6b also determines that there is fraud in the issuance procedure of the second VC9 if the number of verifiers that obtain verification results indicating that the attribute information has been verified to be correct by the first signature 8a is less than the threshold.

[0029] By determining whether or not fraud has occurred based on whether verification results indicating the correctness of attribute information have been received from a certain number of verification devices, the accuracy of the judgment can be improved. In other words, it can be difficult to determine which of the verification devices 7a, 7b, ... corresponding to the first DID base 1 can provide reliable verification results. By judging whether or not fraud has occurred based on the verification results of a large number of verification devices, even if some verification devices are managed by those who are complicit in fraudulent activities, a correct judgment result can ultimately be obtained.

[0030] Furthermore, the first signature that was assigned to the first VC8 was also applied to the re-signing device 5. 8a Verification is possible. However, since the verification request to any verification device is a process carried out because fraud is suspected at the re-signing device 5, it is inappropriate to send a verification request to the re-signing device 5. Therefore, when selecting a verification device to which to send the verification request, the processing unit 6b excludes the re-signing device 5, which is the issuer of the second VC9, from the selection. This improves the reliability of the verification results obtained from the verification devices.

[0031] Furthermore, fraudulent signature replacement can occur either at the user terminal 4 or at the re-signing device 5. In addition to simply knowing that fraud has occurred, it may be necessary to clearly determine whether the fraud occurred at the user terminal 4 or the re-signing device 5. Therefore, the re-signing device 5 may create a second VC9 that encompasses the first VC8. In this case, the second VC9 will contain information indicating the first VC8, and the second signature 9a contained in the second VC9 will be information that proves the first VC8 and its attribute information are correct. The processing unit 6b of the verifier terminal 6 will then use the second signature 9a to verify the attribute information and the first VC8. 8 We will verify that this is correct.

[0032] If the second VC9 incorporates the first VC8, and fraud (e.g., rewriting attribute information) occurs in the resigning device 5, the verification of the second signature 9a of the second VC9 will result in a verification result indicating that the attribute information is correct. On the other hand, the verification of the first signature 8a of the first VC8 will result in a verification result indicating that the attribute information is incorrect. If fraud (e.g., rewriting attribute information) occurs in the user terminal 4, both the verification of the first signature 8a of the first VC8 and the verification of the second signature 9a of the second VC9 will result in a verification result indicating that the attribute information is incorrect. The processing unit 6b of the verifier terminal 6 can identify where the fraud occurred based on these differences in verification results.

[0033] Furthermore, if the second VC9 incorporates the first VC8, it becomes unnecessary to install a separate processing component on the user terminal 4 for sending the first VC8, in addition to the processing component for sending the second VC9.

[0034] If the second VC9 simply contains the first VC8, the attribute information in the second VC9 will be duplicated. Therefore, the resigning device 5 may remove the duplication of attribute information between the first VC8 and the second VC9 when creating the second VC9 which includes information indicating the first VC8. In this case, the processing unit 6b of the verifier terminal 6 will process the second VC 9 From the 1st VC 8 When acquiring it, the first VC8 is reconstructed based on the second VC9.

[0035] By removing duplicate attribute information in this way, the amount of data transmitted from user terminal 4 to verifier terminal 6 can be reduced. [Second Embodiment] Next, a second embodiment will be described. The second embodiment is a system that enables verification of VCs across multiple DID infrastructures.

[0036] Figure 2 shows an example of a system configuration. In the example in Figure 2, there are two DID infrastructures (first DID infrastructure 30 and second DID infrastructure 40) with different signature and verification methods. The first DID infrastructure 30 and the second DID infrastructure 40 are system infrastructures that enable individuals to manage their own attribute information.

[0037] Network 20 is connected to devices belonging to the first DID infrastructure 30 and the second DID infrastructure 40, respectively. The first DID infrastructure 30 includes an issuer device 100, a user terminal 200, a verifier terminal 300, a distributed PKI system 400, and multiple gateways 900, 900a, 900b, etc. The second DID infrastructure 40 includes a user terminal 200, an issuer device 500, a verifier terminal 700, a distributed PKI system 800, and gateways 900, 900a, 900b, etc.

[0038] Issuer devices 100 and 500 are one or more computers managed by the issuer that issues VCs. User terminal 20 0 is The first computer is managed by user 31, who uses VC to prove their own attributes. The second computer terminals 300 and 700 are computers managed by verifiers 32 and 42, respectively, who verify user 31's attributes based on VC. The third computer distributed PKI system 400 and 800 are one or more computers that manage public keys. The fourth computer distributed PKI system 400 and 800 may manage public keys using a distributed ledger such as a blockchain.

[0039] GW900, 900a, 900b, ... are computers managed by intermediaries that provide re-signature services to VCs. As shown in Figure 2, GW900, 900a, 900b, ... belong to both the first DID infrastructure 30 and the second DID infrastructure 40, and can utilize both distributed PKI systems 400, 800.

[0040] Figure 3 shows an example of the hardware of an issuer device. The issuer device 100 is controlled as a whole by a processor 101. The processor 101 is connected to memory 102 and several peripheral devices via a bus 109. The processor 101 may be a multiprocessor. The processor 101 may be, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), or a DSP (Digital Signal Processor). At least some of the functions that the processor 101 implements by executing a program may be implemented by electronic circuits such as an ASIC (Application Specific Integrated Circuit) or a PLD (Programmable Logic Device).

[0041] Memory 102 is used as the main memory of the issuer device 100. Memory 102 temporarily stores at least a portion of the OS (Operating System) program and application programs to be executed by the processor 101. Memory 102 also stores various data used for processing by the processor 101. For memory 102, a volatile semiconductor memory device such as RAM (Random Access Memory) is used.

[0042] Peripheral devices connected to bus 109 include a storage device 103, a GPU (Graphics Processing Unit) 104, an input interface 105, an optical drive device 106, a device connection interface 107, and a network interface 108.

[0043] The storage device 103 electrically or magnetically writes and reads data from its built-in recording medium. The storage device 103 is used as an auxiliary storage device for a computer. The storage device 103 stores the OS program, application programs, and various data. For example, the storage device 103 can be an HDD (Hard Disk Drive) or an SSD (Solid State Drive).

[0044] The GPU104 is a processing unit that performs image processing and is also called a graphics controller. A monitor 21 is connected to the GPU104. The GPU104 displays images on the screen of the monitor 21 according to instructions from the processor 101. The monitor 21 can be a display device using organic EL (Electro Luminescence) or a liquid crystal display device.

[0045] The input interface 105 is connected to a keyboard 22 and a mouse 23. The input interface 105 transmits signals from the keyboard 22 and mouse 23 to the processor 101. Note that the mouse 23 is just one example of a pointing device; other pointing devices can also be used. Other pointing devices include touch panels, tablets, touchpads, and trackballs.

[0046] The optical drive device 106 uses laser light or the like to read data recorded on the optical disc 24 or write data to the optical disc 24. The optical disc 24 is a portable recording medium on which data is recorded in a way that makes it readable by the reflection of light. Examples of optical discs 24 include DVD (Digital Versatile Disc), DVD-RAM, CD-ROM (Compact Disc Read Only Memory), and CD-R (Recordable) / RW (ReWritable).

[0047] The device connection interface 107 is a communication interface for connecting peripheral devices to the issuer device 100. For example, a memory device 25 and a memory reader / writer 26 can be connected to the device connection interface 107. The memory device 25 is a recording medium equipped with a communication function with the device connection interface 107. The memory reader / writer 26 is a device that writes data to or reads data from the memory card 27. The memory card 27 is a card-type recording medium.

[0048] The network interface 108 is connected to the network 20. The network interface 108 transmits and receives data to and from other computers or communication devices via the network 20. The network interface 108 is a wired communication interface, for example, connected by cable to a wired communication device such as a switch or router. Alternatively, the network interface 108 may be a wireless communication interface, connected by radio waves to a wireless communication device such as a base station or access point.

[0049] The issuer device 100 can be implemented with the hardware described above. The issuer device 500, user terminal 200, verifier terminals 300, 700, distributed PKI systems 400, 800, and GWs 900, 900a, 900b, ... can also be implemented with the same hardware as the issuer device 100. The issuer device 3, user terminal 4, resigning device 5, verifier terminal 6, and verifier devices 7a, 7b, ... shown in the first embodiment can also be implemented with the same hardware as the issuer device 100 shown in Figure 3.

[0050] The publisher device 100 realizes the processing function of the second embodiment by executing a program recorded on, for example, a computer-readable recording medium. The program describing the processing content to be executed by the publisher device 100 can be recorded on various recording media. For example, the program to be executed by the publisher device 100 can be stored in the storage device 103. The processor 101 loads at least a portion of the program in the storage device 103 into the memory 102 and executes the program. Alternatively, the program to be executed by the publisher device 100 can be recorded on a portable recording medium such as an optical disc 24, a memory device 25, or a memory card 27. The program stored on the portable recording medium becomes executable after being installed in the storage device 103, for example, under control from the processor 101. The processor 101 can also directly read and execute the program from the portable recording medium.

[0051] The issuer device 500, user terminals 200, verifier terminals 300, 700, distributed PKI systems 400, 800, and GW900, 900a, 900b, ... can also be implemented by executing a program recorded on a computer-readable recording medium.

[0052] When two DID infrastructures exist as shown in Figure 2, if the user and the verifier belong to the same DID infrastructure, it is easy for the user to prove their attribute information to the verifier.

[0053] Figure 4 shows the same DID. basis This figure shows an example of the procedure for verifying attribute information within the system. In the example in Figure 4, a user 31 (see Figure 2) belonging to the first DID infrastructure 30 verifies the validity of attribute information indicating their own attributes to a verifier 32 (see Figure 2) also belonging to the same first DID infrastructure 30.

[0054] The issuer device 100 generates a pair of the issuer's private key 111 and public key 112. The issuer device 100 registers the public key 112 with the distributed PKI system 400, thereby enabling other devices belonging to the first DID infrastructure 30 to use the public key 112.

[0055] The issuer device 100 issues a first VC211 with a signature 212 in response to a request from, for example, a user 31. The first VC211 contains attribute information of the user 31. For example, if the first VC211 is a driver's license, it contains the user 31's name, date of birth, gender, address, license number, etc. The signature 212 is a digital signature generated using the issuer's private key 111 in accordance with the specifications of the first DID base 30.

[0056] User 31 receives the first VC211 issued by the issuer device 100 at the user terminal 200. The user terminal 200 manages the first VC211 with the first Wallet 210. The first Wallet 210 is implemented, for example, by running application software provided by the organization operating the first DID infrastructure 30.

[0057] When user 31 provides personal attribute information to verifier 32, the first VC211 is sent from user terminal 200 to verifier terminal 300. The verifier terminal 300 queries the distributed PKI system 400 for the issuer's public key 112. The distributed PKI system 400 sends the corresponding public key 112 to the verifier terminal 300. The verifier terminal 300 verifies the signature 212 using the public key 112 and confirms that the contents of the first VC211 have been certified by the issuer device 100. As a result, user 31 can verify their attributes with the verifier. 32 This can be proven. For example, if the attribute information included in the first VC211 is driver's license information, it can be proven to the verifier 32 who operates the liquor store that user 31 is 20 years of age or older.

[0058] On the other hand, user 31 cannot prove the validity of attribute information indicating its own attributes to a verifier 42 belonging to another second DID base 40 using the first VC211. That is, even if user terminal 200 transmits the first VC211 to a verifier terminal 700 belonging to the second DID base 40, the verifier terminal 700 does not have a means of verification using signature 212. Therefore, verifier 42, who has the verifier terminal 700, cannot confirm that the attribute information described in the first VC211 is correct.

[0059] Thus, while attribute information described in the first VC211 can be easily verified within the first DID base 30, verifying attribute information across two DID bases is difficult. One possible method for verifying attribute information across two DID bases is for a third party, a GW belonging to both the first DID base 30 and the second DID base 40, to re-sign an already issued VC.

[0060] Figure 5 shows an example of a method of proof that spans multiple DIDs. Figure 5 shows an example of signature replacement by a GW900 managed by a third-party intermediary. The GW900 generates a pair of private key 901 and public key 902, and registers the public key 902 with the distributed PKI system 800 of the second DID infrastructure 40. Subsequently, for example, the user terminal 200 sends the first VC211 with signature 212 to the GW900 and requests the GW900 to reissue the signature.

[0061] GW900 responds to a signature reissue request from the user terminal 200 by querying the distributed PKI system 400 of the first DID infrastructure 30 for the issuer's public key 112. GW900 obtains the public key 112 from the distributed PKI system 400 and uses that public key 112 to verify the signature 212 of the first DID infrastructure 30. Then, using its own private key 901, GW900 becomes the new issuer of the second DID infrastructure 40. 2nd VC221 The GW900 generates a signature 222 for the attribute information shown. The GW900 sends the second VC221, with the signature 222 attached to the attribute information, to the user terminal 200.

[0062] The user terminal 200 has a second wallet 220 that corresponds to the second DID infrastructure 40, in addition to the first wallet 210 that corresponds to the first DID infrastructure 30. The first wallet 210 has functions belonging to the first DID infrastructure 30, while the second wallet 220 has functions belonging to the second DID infrastructure 40. The second wallet 220 is a VC management function for the second DID infrastructure 40. The second wallet 220 is implemented, for example, by running application software provided by the organization operating the second DID infrastructure 40.

[0063] The user terminal 200 sends the second VC221, including signature 222, to the verifier terminal 700 of the second DID infrastructure 40, and verifies its own attribute information using the second VC221. The verifier terminal 700 queries the distributed PKI system 800 of the second DID infrastructure 40 for the intermediary's public key 902. The verifier terminal 700 obtains the public key 902 from the distributed PKI system 800. Then, the verifier terminal 700 uses the obtained public key 902 to verify signature 222 and confirm that the contents of the second VC221 are authentic.

[0064] In the method shown in Figure 5, if it is expected that the GW900 will correctly perform signature verification on each DID infrastructure, it becomes possible to prove attribute information across DID infrastructures based on the first VC211. This allows the GW900 to later re-sign the signature on DID infrastructures that were not anticipated when the first VC211 was issued, thereby enabling the proof of attribute information on different DID infrastructures.

[0065] However, the method shown in Figure 5 allows the GW900 to affix a signature to attribute information that has not been signed by the issuer device 100. Therefore, it is not possible to deter fraud by intermediary operators operating the GW900.

[0066] Therefore, when the user terminal 200 proves attribute information to the verifier terminal 700, it sends the first VC211 in addition to the second VC221. The verifier 42 using the verifier terminal 700 can check for fraud based on the first VC211 if fraud by GW900 in reassigning signatures is suspected. For example, the first VC211 signature from the user terminal 200 to a GW other than GW900. 212 We request verification of the following. The requested GW is the first VC211 signature. 212 Verification failed (signature) 212 If the system determines the result to be "Invalid," it can be concluded that fraud has occurred. By enabling retrospective verification of whether or not fraud has occurred in this way, fraudulent activity using GW900 can be deterred.

[0067] Figure 6 shows an example of a signature reassignment method in the second embodiment. In Figure 6, the process from issuing the second VC221 in GW900 to saving the second VC221 in the second Wallet220 of the user terminal 200 is the same as in the example shown in Figure 5. Subsequently, when user 31 using user terminal 200 proves their attribute information to verifier 42, the first VC211 and the second VC221 are transmitted from user terminal 200 to verifier terminal 700.

[0068] Figure 7 shows an example of a first VC and a second VC being transmitted. The first VC211 includes non-attribute information 213, attribute information 214, and a signature 212 for the non-attribute information 213 and attribute information 214. The non-attribute information 213 includes information such as DID. The DID in the first VC211 is information that identifies the first VC211 within the first DID base 30. The attribute information 214 includes information such as name and facial image. The second VC221 includes non-attribute information 223, attribute information 224, and a signature 222 for the non-attribute information 223 and attribute information 224. The non-attribute information 223 includes information such as DID. The DID in the second VC221 is information that identifies the second VC221 within the second DID base 40. The attribute information 224 includes information such as name and facial image.

[0069] Now, let's return to the explanation of Figure 6. The verifier terminal 700 verifies the attribute information 224 shown in the second VC221 using the signature 222 of the second VC221. In other words, the verifier terminal 700 operates the GW900 from the distributed PKI system 800 of the second DID infrastructure 40. middle The operator's public key 902 is obtained. Then, the verifier terminal 700 verifies the authenticity of the signature 222 attached to the second VC221 using the procedure specified in the second DID infrastructure 40 with the obtained public key 902.

[0070] Furthermore, in response to the verification instruction for the signature 212 assigned to the first VC211 by the verifier 42, the verifier terminal 700 sends verification requests to a predetermined number of GWs other than GW900, such as GW900a, 900b, ... For example, the verifier terminal 700 sends verification requests to a predetermined number of GWs via email or other means. The verification requests include the first VC211.

[0071] For example, when GW900a receives a verification request, GW900a obtains the issuer's public key 112 of the first VC211 from the distributed PKI system 400 of the first DID infrastructure 30. Using the obtained public key 112, GW900a verifies the validity of the signature 212 attached to the first VC211 according to the procedure specified in the first DID infrastructure 30. For example, when GW900a receives a verification request, it imports the received digital data into the verification component of the first DID infrastructure 30 and verifies it. This verification method conforms to the procedure specified in the first DID infrastructure 30. GW900a then sends the verification result (Valid or Invalid) to the verifier terminal 700. Other GWs that receive a verification request (e.g., GW900b) perform the same verification process as GW900a.

[0072] The verifier terminal 700 verifies the legitimacy of the first VC211 based on the verification results received from the gateways (GWs) that sent the verification request. For example, the verifier terminal 700 verifies the legitimacy of the signature 212 attached to the first VC211 by unanimous agreement or majority vote of the verification results. If unanimous agreement is adopted, the verifier terminal 700 determines that the signature 212 attached to the first VC211 is legitimacy if it receives a "Valid" response from all gateways that sent the verification request. If majority vote is adopted, the verifier terminal 700 determines that the signature 212 attached to the first VC211 is legitimacy if more than half of the gateways that sent the verification request responded with "Valid".

[0073] In this way, by having the user terminal 200 also send the first VC211 to the verifier terminal 700, even if GW900 issues a signature fraudulently, the verifier terminal 700 can confirm whether or not the signature 212 is fraudulent by requesting verification of the signature 212 from other GWs. This established method for confirming whether or not the signature is fraudulent deters fraudulent activity by GW900 when it replaces signatures. In other words, the verifier terminal 700 of the second DID infrastructure 40 cannot verify the signature 212 attached to the first VC211, but if it becomes suspicious of the operation of GW900, it can confirm the correctness of GW900's operation by requesting verification of the signature 212 from a GW other than GW900.

[0074] Furthermore, when the verifier terminal 700 selects a verification request recipient from among GW900a, 900b, etc., it is desirable to select them independently to avoid collusion among the selected GWs. However, the verification process for signature 212 described above is solely for the purpose of securing verification means to deter fraud by GW900, and is not something that the verifier terminal 700 of the second DID infrastructure 40 always performs.

[0075] Next, we will explain the functions of each device in order to realize the process shown in Figure 6. Figure 8 is a block diagram showing an example of the functions of each device in the second embodiment. The issuer device 100 has a first VC creation unit 110 and an attribute item name list storage unit 120. The first VC creation unit 110 creates a first VC 211 containing the attribute information 214 of user 31 in response to a VC creation request from, for example, a user terminal 200. The first VC creation unit 110 then transmits the created first VC 211 to the user terminal 200. The attribute item name list storage unit 120 stores an attribute item name list. The attribute item name list is a list of item names of items that indicate the attribute information of user 31 among the information contained in the first VC 211. For example, the information contained in the first VC 211 is represented by a list of pairs of item names (Key) and item values ​​(Value). The information contained in the first VC 211 includes non-attribute information 213 used on the DID system and personal attribute information 214. The attribute item name list lists the Keys that indicate the item names of the attribute information 214.

[0076] For example, the attribute item name list storage unit 120 stores information such as "attribute item name list = {firstName, lastName, age}". The attribute item name list shown in this example indicates that, among the information contained in the first VC211, the first name, last name, and age of user 31 correspond to attribute information 214. The attribute item name list stored in the attribute item name list storage unit 120 is publicly available information. Therefore, for example, GW900 can obtain the attribute item name list from the issuer device 100.

[0077] As shown in Figure 6, the user terminal 200 has a first wallet 210 and a second wallet 220. When user 31 proves their attribute information to verifier 42, for example, the first VC211 obtained from the first wallet 210 and the second VC221 obtained from the second wallet 220 are transmitted from the user terminal 200 to the verifier terminal 700.

[0078] The GW900 has a first VC storage unit 910, a first VC verification unit 920, a second VC creation unit 930, a second VC storage unit 940, and an attribute item name list storage unit 950. The first VC storage unit 910 receives from the user terminal 200 Request for reissue The first VC211 sent along with it is stored. The first VC verification unit 920 verifies the signature 212 attached to the first VC211 in accordance with the verification procedure of the first DID base 30.

[0079] The second VC creation unit 930, upon successful verification of the signature 212 assigned to the first VC211, creates the second VC221 by transferring the attribute information of the first VC211 in accordance with the VC issuance procedure of the second DID base 40. At that time, the second VC creation unit 930 obtains the attribute item name list from the issuer device 100 and determines the attribute information among the information in the first VC211 based on the obtained attribute item name list. The second VC storage unit 940 stores the second VC221 created by the second VC creation unit 930. The second VC221 stored in the second VC storage unit 940 is Request for reissue This is sent to the user terminal 200 as a response.

[0080] The attribute item name list storage unit 950 stores the attribute item name list obtained by the second VC creation unit 930 from the issuer device 100. The attribute item name list stored in the attribute item name list storage unit 950 is publicly available information. Therefore, for example, the verifier terminal 700 can obtain the attribute item name list from the GW900.

[0081] The verifier terminal 700 includes a second VC storage unit 710, a second VC verification unit 720, a verification result storage unit 730, a first VC storage unit 740, a first VC confirmation unit 750, and a confirmation result storage unit 760. The second VC storage unit 710 stores the second VC 221 sent from the user terminal 200. The second VC verification unit 720 verifies the signature 222 attached to the second VC 221 in accordance with the verification procedure of the second DID base 40. The verification result storage unit 730 stores the verification result by the second VC verification unit 720.

[0082] The first VC storage unit 740 stores the first VC211 sent from the user terminal 200. The first VC verification unit 750 obtains a list of verifiers from one of the GW900a, 900b, ... and sends a verification request for the first VC211 to the verifiers indicated in the obtained list of verifiers. Based on the response to the verification request, the first VC verification unit 750 checks whether there is any fraud in the issuance procedure for the second VC221. The verification result storage unit 760 stores the verification result by the first VC verification unit 750.

[0083] The GW900a includes a first VC storage unit 910a, a first VC verification unit 920a, a verification result storage unit 960a, and a verifier information storage unit 970a. The first VC storage unit 910a stores the first VC211 included in the verification request from the verifier terminal 700. The first VC verification unit 920a verifies the signature 212 attached to the first VC211 in accordance with the verification procedure of the first DID base 30. The verification result storage unit 960a stores the verification result by the first VC verification unit 920a.

[0084] The verifier information storage unit 970a stores verifier information for intermediary operators that have a GW900a capable of verifying the VC of the first DID infrastructure 30. The verifier information includes information such as the email address for verification that the intermediary operator operating the GW900a has made publicly available. Other GW900b, etc., and verifier terminals 300 within the first DID infrastructure 30 also make their own verifier information public. For example, verifier terminal 700 can obtain verifier information from GW900a, 900b, etc., and verifier terminal 300, and generate a list of verifiers or intermediary operators that have devices capable of verifying the VC of the first DID infrastructure 30.

[0085] Note that the functions of the GW900 are also present in the other GW900a, 900b, etc. Similarly, the functions of the GW900a are also present in the other GW900, 900b, etc. The lines connecting the elements shown in Figure 8 represent only a portion of the communication path; other communication paths can also be configured. Furthermore, the functions of each element shown in Figure 8 can be realized, for example, by having a computer execute the corresponding program module for that element.

[0086] Figure 9 shows an example of a verifier list. In the verifier list 971, the service names of the verifiers who perform verification of the VC of the first DID infrastructure 30 are associated with the second DID infrastructure 40 DID, email recipients, etc. are registered. Second DID infrastructure 40 The DID in this context refers to the identification information within the second DID infrastructure 40 of a device (such as a gateway or verifier terminal) that also belongs to the second DID infrastructure 40. The email recipient is the email address to which the verification request from the first VC using the relevant service will be sent. Note: Verifier list 971 This also includes information on services that do not belong to the second DID infrastructure 40.

[0087] In a system configured as described above, when a user 31 in the first DID infrastructure 30 proves to a verifier 42 in the second DID infrastructure 40 that their attribute information is correct, a request for reissuance of the VC is sent from the user terminal 200 to the GW900 at the user's instruction. The GW900 then performs the VC reissuance process. The VC reissuance process will be explained in detail below with reference to Figures 10 and 11.

[0088] Figure 10 is a flowchart illustrating an example of the procedure for reissuing a VC (Virtual Certificate). The process shown in Figure 10 will be explained below according to the step numbers. [Step S101] GW900 obtains a VC reissue request from the user terminal 200. The VC reissue request includes the first VC211. GW900 stores the first VC211 included in the VC reissue request in the first VC storage unit 910.

[0089] [Step S102] The first VC verification unit 920 obtains the issuer's public key 112. For example, the first VC verification unit 920 queries the distributed PKI system 400 of the first DID infrastructure 30 for the issuer's key. The distributed PKI system 400 responds with the issuer's public key 112 in response to the query.

[0090] [Step S103] The first VC verification unit 920 verifies the signature 212 of the first VC 211 using the acquired public key 112. [Step S104] The first VC verification unit 920 determines whether the verification was successful or not. If the verification is successful, the first VC verification unit 920 instructs the second VC creation unit 930 to create the second VC221 and proceeds to step S105. If the verification is unsuccessful, the first VC verification unit 920 terminates the VC reissuance process with an error.

[0091] [Step S105] The second VC creation unit 930 performs the second VC creation process. Details of the second VC creation process will be described later (see Figure 11). The second VC 221 created by the second VC creation unit 930 is stored in the second VC storage unit 940.

[0092] [Step S106] GW900 transmits the second VC221 stored in the second VC storage unit 940 to the user terminal 200. Next, we will explain in detail the procedure for creating the second VC.

[0093] Figure 11 is a flowchart showing an example of the procedure for creating the second VC. The process shown in Figure 11 will be explained below according to the step numbers. [Step S111] The second VC creation unit 930 obtains the first VC 211, the private key 901 of the GW 900, and the attribute item name list. The first VC 211 can be obtained from the first VC verification unit 920. The private key 901 of the GW 900 can be obtained, for example, from a storage device within the GW 900. The attribute item name list can be obtained from the issuer device 100.

[0094] [Step S112] The second VC creation unit 930 copies the item value of the corresponding item name in the first VC 211 to the second VC 221 as the item value of the corresponding item name in the attribute item name list. As a result, the attribute information 214 in the first VC 211 is recorded as attribute information 224 in the second VC 221.

[0095] [Step S113] The second VC creation unit 930 sets the item values ​​of item names not included in the attribute item name list in the second VC 221 in accordance with the VC issuance procedure of the second DID base 40. As a result, non-attribute information 223 is recorded in the second VC 221.

[0096] [Step S114] The second VC creation unit 930 creates a signature 222 of the attribute information 224 using the private key 901 of GW900, in accordance with the signature creation procedure of the second DID base 40. The second VC creation unit 930 writes the created signature 222 to the second VC221.

[0097] [Step S115] The second VC creation unit 930 outputs the created second VC221. For example, the second VC creation unit 930 stores the second VC221 in the second VC storage unit 940. Through this reissuance process, the second VC221 is issued based on the first VC211. The second VC221 is managed in the second Wallet 220 of the user terminal 200. The user terminal 200 then transmits the first VC211 and the second VC221 to the verifier terminal 700 based on instructions from user 31. For example, the verifier terminal 700 indicates the destination using a 2D code or the like. User 31 inputs the destination information into the user terminal 200 and instructs it to transmit the first VC211 and the second VC221. For example, if the destination is indicated by a 2D code, user 31 can input the destination information into the user terminal 200 by having the camera on the user terminal 200 read the 2D code. The user terminal 200 transmits the first VC211 and the second VC221 to the entered destination. The verifier terminal 700, having received the first VC211 and the second VC221, performs verification processing on the second VC221.

[0098] Figure 12 is a flowchart showing an example of the procedure for the second VC verification process. The process shown in Figure 12 will be explained below according to the step numbers. [Step S121] The verifier terminal 700 receives the first VC211 and the second VC221 from the user terminal 200.

[0099] [Step S122] The verifier terminal 700 stores the first VC211 in the first VC storage unit 740 and the second VC221 in the second VC storage unit 710. [Step S123] The second VC verification unit 720 of the verifier terminal 700 obtains the public key 902 of GW900. For example, the second VC verification unit 720 queries the distributed PKI system 800 of the second DID infrastructure 40 for the key of GW900. The distributed PKI system 800 responds with the public key 902 of GW900 in response to the query.

[0100] [Step S124] The second VC verification unit 720 verifies the signature 222 of the second VC 221 using the acquired public key 902. [Step S125] The second VC verification unit 720 outputs the verification result. For example, the second VC verification unit 720 stores the verification result in the verification result storage unit 730.

[0101] The verifier 42 recognizes the verification result by displaying the verification result stored in the verification result storage unit 730 on the verifier terminal 700. If the verification result is "Valid", the verifier 42 determines that the content of the attribute information 224 shown in the second VC221 correctly represents the attributes of the user 31.

[0102] Even if the verification process of the second VC221 is successful, there is a possibility that GW900 may have committed fraud, causing the content of attribute information 224 to differ from the original attributes of user 31. If the verifier 42 suspects fraud of GW900, for example, they can use the first VC211 to check for fraud. In that case, the verifier 42 inputs a verification instruction for the first VC211 to the verifier terminal 700. The verifier terminal 700 then executes the first VC verification process.

[0103] Figure 13 is a flowchart showing an example of the procedure for the first VC verification process. The process shown in Figure 13 will be explained below according to the step numbers. [Step S131] The first VC verification unit 750 obtains the first VC211, parameters n and k, the verifier list 971 of the first DID base 30, and the DID of the issuer (GW900) of the second VC221. The first VC211 can be obtained from the first VC storage unit 740. Parameters n and k are integers set in advance on the verifier terminal 700. Parameter n indicates the number of recipients of the verification request. Parameter k is a threshold indicating how many of the n recipients must respond with "Valid" for the verification result to be considered "Valid". The verifier list 971 can be obtained, for example, from GW900a. The DID of the issuer of the second VC221 is shown, for example, in the non-attribute information 223 of the second VC221.

[0104] [Step S132] The first VC verification unit 750 selects n verifiers (including intermediate operators operating the GW) to request verification from the verifier list 971 belonging to the first DID base 30. The selection of n verifiers to request verification is performed by the user terminal. 200 You may also follow the instructions provided. When selecting the n verifiers to submit the verification request, the first VC verification unit 750 excludes the issuer of the second VC221 from the list of verifiers submitting the verification request. For example, the second VC221 has the DID of the GW900 that issued the second VC221 set as the item value for the item name "issuer". The first VC verification unit 750 excludes from the list of verifiers that submit the verification request any verifiers whose DID set in "DID in the second DID base" is the same as the DID of the GW900.

[0105] [Step S133] The first VC verification unit 750 sends verification requests via email to n verifiers belonging to the first DID base 30. The first VC211 is attached to the verification request email. The first VC211 attached to the email is input as the target of verification to a verification device such as GW900a, 900b, etc., by a verifier who has checked the email. In other words, the verification request sent via email is ultimately passed to the verification device. The first VC verification unit 750 receives the verification results from the verification device (verifier terminal or GW) of the verifier who sent the verification request.

[0106] [Step S134] The first VC verification unit 750 determines whether k or more verifiers have responded with "Valid". If k or more verifiers have responded with "Valid", the first VC verification unit 750 proceeds to step S135. If the number of verifiers who responded with "Valid" is less than k, the first VC verification unit 750 proceeds to step S136.

[0107] [Step S135] The first VC verification unit 750 outputs a verification result of "Valid". For example, the first VC verification unit 750 stores the verification result "Valid" in the verification result storage unit 760. After that, the first VC verification unit 750 terminates the first VC verification process.

[0108] [Step S136] The first VC verification unit 750 outputs a verification result of "Invalid". For example, the first VC verification unit 750 stores the verification result "Invalid" in the verification result storage unit 760.

[0109] Verifier 42 refers to the verification results stored in the verification result storage unit 760 and determines whether or not fraud has occurred. For example, if the verification result is "Valid", verifier 42 determines that no fraud has occurred. Conversely, if the verification result is "Invalid", verifier 42 determines that fraud has occurred.

[0110] In this way, when user 31 proves their attribute information to verifier 42 of the second DID infrastructure 40, user terminal 200 sends not only the second VC221 with the resigned signature but also the first VC211 to verifier terminal 700. As a result, if the GW900 that resigned the signature fraudulently issues a signature, verifier 42 can verify the fraud by verifying the signature 212 of the first VC211. In other words, it becomes easier to detect fraud by the GW900. Consequently, it can be expected to have a deterrent effect on fraud by the GW900.

[0111] For example, if verifier 42 has doubts about the operation of GW900, verifier 42 of GW900 belongs to the first DID base 30. other than The correct operation of GW900 can be confirmed by requesting verification of signature 212 from the devices (e.g., 900a, 900b, ...). In this case, for example, verifier 42 can correctly determine whether or not there is fraud by requesting verification of signature 212 from multiple verifiers and confirming the presence or absence of fraud by unanimous agreement or majority vote.

[0112] Furthermore, when selecting verifiers for the first DID infrastructure 30 to check for fraud, it is desirable to select them from independent organizations to prevent collusion among the verifiers of the first DID infrastructure 30. For example, by obtaining the verifier list 971 from a device other than the GW900 that performed the signature change (e.g., GW900a), interference from the intermediary operator operating the GW900 can be suppressed regarding the verifiers listed in the verifier list 971.

[0113] Furthermore, the above-mentioned process for verifying the presence or absence of fraud (first VC verification process) is solely for the purpose of ensuring a means of verification to deter fraud on GW900. In other words, it is at the discretion of the verifier 42 whether or not to have the verifier terminal 700 execute the process for verifying the presence or absence of fraud.

[0114] [Third Embodiment] The third embodiment allows for the determination of whether or not user 31 has committed fraud. In other words, the second embodiment does not take into account fraud by user 31, and even if the verification process of the first VC211 results in "Invalid," it is not possible to distinguish whether the fraud is due to GW900 or user 31. For example, even if user 31 tampers with the signature 212 of the first VC211 and the verification result of the first VC211 by the verifier terminal 700 is "Invalid," the verifier 42 cannot distinguish this from fraud by GW900.

[0115] Furthermore, in the second embodiment, it is required that a communication channel and processing components are provided for transmitting the first VC211 and the second VC221 to the verifier terminal 700.

[0116] Therefore, the third embodiment makes it possible to distinguish between fraud by GW900 and fraud by user 31, and eliminates the need for a special mechanism for transmitting information from user terminal 200 to verifier terminal 700. The differences between the third embodiment and the second embodiment will be explained in detail below.

[0117] Figure 14 shows an example of a signature replacement method in the third embodiment. The process is the same as in the second embodiment up to the point where the user terminal 200 sends a request for VC reissuance to the GW900. In the third embodiment, the GW900, upon receiving the VC reissuance request, verifies the signature 212 of the first VC211, then adds the GW900's signature 222a to the information including the first VC211, and generates the second VC221a. For example, the second VC221a includes the user 31's attribute information, the first VC211, and the signature 222a. The GW900 sends the generated second VC221a to the user terminal 200. In this way, the VC is reissued.

[0118] The user terminal 200 manages the second VC221a in the second Wallet 220. When user 31 proves their attribute information to the verifier 42, the user terminal 200 sends the second VC221a, which is managed in the second Wallet 220, to the verifier terminal 700.

[0119] When the verifier terminal 700 obtains the second VC221a, it obtains the public key 902 of the GW900 from the distributed PKI system 800 of the second DID infrastructure 40. The verifier terminal 700 then uses the obtained public key 902 to verify the signature 222a of the second VC221a. If the verifier 42 finds the signature 222a to be valid, it determines that the attribute information of user 31 shown in the second VC221a is correct. If the verifier 42 finds anything suspicious about the operation of the GW900, it instructs the verifier terminal 700 to perform a verification process on the first VC211. The verifier terminal 700 then sends a verification request to a device (or a verifier possessing such a device) capable of verifying VCs in the first DID infrastructure 30, such as GW900a, 900b, etc. Based on the verification results for the verification request, the verifier terminal 700 determines whether the first VC211 is valid or not.

[0120] Figure 15 shows an example of a second VC containing a first VC. The second VC221a contains non-attribute information 223, attribute information 224, the first VC211, and signature 222a. The first VC211 contains non-attribute information 213, attribute information 214, and signature 212. Signature 222a of the second VC221a is a signature to certify the contents of the non-attribute information 223, attribute information 224, and the first VC211.

[0121] This makes it possible to reliably verify fraudulent activity by GW900. For example, if signature 222a of 2VC221a is "Valid" and signature 212 of 1VC211 is "Invalid", it can be determined that GW900 committed fraud. Also, if both signature 222a of 2VC221a and signature 212 of 1VC211 are "Invalid", it can be determined that user 31 tampered with signature 212 of 1VC211.

[0122] Furthermore, GW900 reissues a second VC221a (non-attribute information 213 + attribute information 224 + first VC211 + signature 222a) with the original first VC211 (non-attribute information 213 + attribute information 214 + signature 212) embedded within it. This enables the second Wallet 220 to manage the first VC211. It also becomes possible to send the first VC211 using the existing communication mechanism defined in the second DID infrastructure 40 between the second Wallet 220 and the verifier terminal 700. As a result, it becomes unnecessary to add processing components for sending the first VC211 from the user terminal 200 to the verifier terminal 700.

[0123] Next, we will explain the functions of each device in order to realize the process shown in Figure 14. Figure 16 is a block diagram showing an example of the functions of each device in the third embodiment. In the third embodiment, the verifier terminal 700 has a first VC reconstruction unit 770 in addition to the elements shown in the second embodiment (see Figure 8). Furthermore, a communication path for transmitting the first VC211 from the first Wallet 210 of the user terminal 200 to the verifier terminal 700 is not required. The first VC reconstruction unit 770 extracts the first VC211 from the second VC221a stored in the second VC storage unit 710. The first VC reconstruction unit 770 then stores the extracted first VC211 in the first VC storage unit 740.

[0124] Each element shown in Figure 16 has the same function as the element of the same name in the second embodiment shown in Figure 8. However, unlike the second embodiment, the second VC creation unit 930 in the third embodiment creates a second VC221a that contains the first VC211.

[0125] Figure 17 is a flowchart showing an example of the procedure for creating the second VC in the third embodiment. The process shown in Figure 17 will be described below according to the step numbers. [Step S201] The second VC creation unit 930 obtains the first VC211, the private key 901 of GW900, and the attribute item name list.

[0126] [Step S202] The second VC creation unit 930 copies the item value of the corresponding item name described in the first VC211 to the second VC221a as the item value of the corresponding item name in the attribute item name list.

[0127] [Step S203] The second VC creation unit 930 sets the item values ​​of the non-attribute information to the second VC221a in accordance with the VC issuance procedure of the second DID base 40. [Step S204] The second VC creation unit 930 adds "originalCredential" to the item name of the second VC221a and writes the first VC211 as is as the item value of that item name.

[0128] [Step S205] The second VC creation unit 930 creates a signature 222a between the attribute information 224 and the first VC 211 using the private key 901 of the GW 900, in accordance with the signature creation procedure of the second DID base 40. The second VC creation unit 930 then writes the created signature 222a to the second VC 221a.

[0129] [Step S206] The second VC creation unit 930 outputs the created second VC221a. For example, the second VC creation unit 930 stores the second VC221a in the second VC storage unit 940.

[0130] In this way, the second VC221a, which contains the first VC211, is created. Figure 18 shows an example of a second VC containing a first VC. Figure 18 shows an example of creating the first VC211 and the second VC221a using VCDM (Verifiable Credentials Data Model) 1.0. As shown in Figure 18, in the second VC221a, the item name "originalCredential" is contained within the item name "credentialSubject". "credentialSubject" is the item that sets the information to be signed. The item value of the item name "originalCredential" contains the entire first VC211. Because the item representing the first VC211 is contained within "credentialSubject", signature 222a is applied to the information containing the first VC211.

[0131] Such a second VC221a conforms to the specifications of the second DID board 40 and can be managed by the second Wallet 220. The second Wallet 220 can also transmit the second VC221a, which contains the first VC211, to the verifier terminal 700 within the second DID board 40 using the communication method defined in the second DID board 40. At the verifier terminal 700, the first VC reconstruction unit 770 extracts the first VC211 from the received second VC221a.

[0132] Figure 19 shows the first VC Rebuild This is a flowchart illustrating an example of the processing procedure. The process shown in Figure 19 will be explained below according to the step numbers. [Step S211] The first VC reconstruction unit 770 acquires the second VC221a from the second VC storage unit 710.

[0133] [Step S212] The first VC reconstruction unit 770 retrieves the item value of the item name "originalCredential" of the second VC221a. The retrieved item value represents the first VC211.

[0134] [Step S213] The first VC reconstruction unit 770 outputs the first VC211. For example, the first VC reconstruction unit 770 stores the first VC211 in the first VC storage unit 740. In this way, the first VC211 can be handed over to the verifier terminal 700 using the communication method of the second DID board 40. Then, using the first VC211, it becomes possible to correctly verify whether or not the GW900 is tampered with.

[0135] [Fourth Embodiment] The fourth embodiment reduces the amount of data in the second VC compared to the third embodiment. In the second or third embodiment, the amount of data transmitted from the user terminal 200 to the verifier terminal 700 increases by the amount of data in the first VC 211. The first VC 211 may contain large data such as facial images. If the amount of data transmitted from the user terminal 200 to the verifier terminal 700 is too large, it can cause processing delays when the user 31 proves their own attribute information. Therefore, in the fourth embodiment, items included in the attribute information 214 of the first VC 211 that overlap with the attribute information 224 of the second VC 221a are deleted from the first VC 211.

[0136] Figure 20 shows a first example of a method for reducing the data volume of the second VC. In the example in Figure 20, the items "Name" and "Face Image" included in the attribute information 214 of the first VC211 are also included in the attribute information 224 of the second VC221a. Duplicate items are those in which the item name and item value match in both the first VC211 and the second VC221a.

[0137] In the fourth embodiment, the second VC creation unit 930 creates a second VC221b based on the second VC221a shown in the third embodiment, with duplicate items removed. For example, duplicate attribute information 225 is set as a new item in the second VC221b. Duplicate attribute information 225The item name is, for example, "Same Attr.". The item value of duplicate attribute information 225 is set to the item name of the item that is included in both the attribute information 214 of the first VC211 and the attribute information 224 of the second VC221a. The second VC221b also contains the first VC211a with the duplicate items removed. In the example in Figure 20, the first VC211a is obtained by removing the "Name" and "Face Image" items from the first VC211.

[0138] The second VC221b, with duplicate items removed in this manner, is sent from the user terminal 200 to the verifier terminal 700. The verifier terminal 700 can then reconstruct the original first VC211 by referring to the duplicate attribute information 225. For example, the verifier terminal 700 can retrieve the items shown in the duplicate attribute information 225 from the attribute information 224 of the second VC221b and add them to the first VC211a included in the second VC221b to create the original first VC211.

[0139] In this fourth embodiment, attribute information 224 such as name and facial image is copied to the second VC221a without being modified by GW900, and items that overlap with the second VC221a are removed from the first VC211a in the created second VC221b. As a result, the amount of data in the second VC221b managed by the second Wallet220 and the amount of communication data between the second Wallet220 and the verifier terminal 700 are reduced. Furthermore, by setting the overlapping attribute information 225 in the second VC221b, the original first VC211 can be easily reconstructed.

[0140] Next, referring to Figure 21, we will explain in detail the process of creating the second VC221b after removing duplicate items. Figure 21 is a flowchart showing an example of the procedure for creating the second VC in the fourth embodiment. Of the processes shown in Figure 21, steps S301 to S304, S307, and S308 are the same as steps S201 to S206 in the third embodiment shown in Figure 17. Below, we will describe the processes S305 to S306 shown in Figure 21 that differ from those in the third embodiment.

[0141] [Step S305] The second VC creation unit 930 adds "Same Attr." to the item name of the second VC221b, and enters the item name listed in the attribute item name list as the item value corresponding to the added item name.

[0142] [Step S306] The second VC creation unit 930 deletes the item from the first VC that corresponds to the item name shown in the attribute item name list, which is set as the item value for the item name "originalCredential".

[0143] By inserting the processes in steps S305 to S306 into the second VC creation process, it is possible to create a second VC221b with duplicate items removed. Next, with reference to Figure 22, the reconstruction process of the first VC211 from the second VC221b will be explained in detail.

[0144] Figure 22 shows an example of the procedure for the first VC reconstruction process in the fourth embodiment. The process shown in Figure 22 will be described below in accordance with the step numbers. [Step S311] The first VC reconstruction unit 770 obtains the second VC221b and the attribute item name list. For example, the first VC reconstruction unit 770 obtains the second VC221b from the second VC storage unit 710. The first VC reconstruction unit 770 also obtains the attribute item name list from the attribute item name list storage unit 950 of the GW900.

[0145] [Step S312] The first VC reconstruction unit 770 obtains the item value of the item name "originalCredential" in the second VC221b. The first VC reconstruction unit 770 sets the obtained item value as the first VC'.

[0146] [Step S313] The first VC reconstruction unit 770 adds the item name described in the item value of the item name "Same Attr." in the second VC221b to the acquired item value (first VC').

[0147] [Step S314] The first VC reconstruction unit 770 transfers the item value of the same item name in the second VC221b as the item value of the item name added to the first VC'. The first VC' after the item value transfer is the reconstructed first VC211.

[0148] [Step S315] The first VC reconstruction unit 770 outputs the reconstructed first VC211. In this way, the first VC211 can be reconstructed even from the second VC221b, from which duplicate items have been removed.

[0149] [Fifth Embodiment] The fifth embodiment removes duplicate items in a different way than the fourth embodiment. In the fifth embodiment, the non-attribute information 213 in the first VC211 is set as an item in the second VC, with information indicating that it is an item in the original VC.

[0150] Figure 23 shows a second example of a method for reducing the data volume of the second VC. In the example in Figure 23, the non-attribute information 213 items of the first VC211 are copied to the second VC221c as non-duplicate information 226, with "original" added to the beginning of the item name. Similarly, the signature 212 of the first VC211 is also set in the second VC221c as the original signature 212a of the first VC211, with "original" added to the beginning of the item name.

[0151] When reconstructing the first VC211 from the second VC221c, the non-duplicate information 226 within the second VC221c is copied to the first VC211 being reconstructed. At this time, the "original" notation is removed from the item names of the items included in the non-duplicate information 226. In addition, the attribute information 224 within the second VC221c is copied to the first VC211 being reconstructed. Furthermore, the signature 212a of the first VC211 contained in the second VC221c is copied to the first VC211 being reconstructed. At this time, the "original" notation is removed from the item names of the items included in the signature 212a of the first VC211.

[0152] In this fifth embodiment, attribute information 224 such as name and facial image is copied to the second VC221c only once without being modified by the GW900, thereby eliminating duplicate items between the second VC221a and the first VC211. This reduces the amount of data in the second VC221c managed by the second Wallet220, as well as the amount of communication data between the second Wallet220 and the verifier terminal 700. Furthermore, by adding "original" to the beginning of the item names in the non-duplicate information 226 and the signature 212a of the first VC211, duplication of item names within the second VC221c is suppressed, and the original first VC211 can be easily reconstructed.

[0153] Next, referring to Figure 24, we will explain in detail the process of creating the second VC221c after removing duplicate items. Figure 24 is a flowchart showing an example of the procedure for creating the second VC in the fifth embodiment. The process shown in Figure 24 will be described below according to the step numbers.

[0154] [Step S401] The second VC creation unit 930 obtains the first VC211, the private key 901 of GW900, and the attribute item name list. [Step S402] The second VC creation unit 930 copies the item value of the corresponding item name described in the first VC211 to the second VC221c as the item value of the corresponding item name in the attribute item name list.

[0155] [Step S403] The second VC creation unit 930 sets the item values ​​of items not included in the attribute item name list to the second VC221c in accordance with the VC issuance procedure of the second DID base 40. [Step S404] The second VC creation unit 930 copies the item values ​​of items in the first VC211 that are not included in the attribute item name list to the second VC221c, with "original" added to the beginning of the corresponding item name. As a result, the non-duplicate information 226 and the signature 212a are added to the second VC221c.

[0156] [Step S405] The second VC creation unit 930 creates a signature 222c using the private key 901 of GW900 in accordance with the signature creation procedure of the second DID base 40, combining the attribute information 224, the non-duplicate information 226, and the signature 212a. The second VC creation unit 930 then writes the created signature 222c to the second VC221c.

[0157] [Step S406] The second VC creation unit 930 outputs the created second VC221c. For example, the second VC creation unit 930 stores the second VC221c in the second VC storage unit 940.

[0158] In this way, a second VC221c can be created with duplicate items removed. Figure 25 shows an example of a second VC with duplicate items removed. The second VC221c contains copies of items from the first VC211 whose item names are not listed in the attribute item name list. The word "original" has been added to the beginning of the item names of these items.

[0159] Next, with reference to Figure 26, the reconstruction process of the first VC211 from the second VC221c will be described in detail. Figure 26 shows an example of the procedure for the first VC reconstruction process in the fifth embodiment. The process shown in Figure 26 will be described below in accordance with the step numbers.

[0160] [Step S411] The first VC reconstruction unit 770 obtains the second VC221c and the attribute item name list. [Step S412] The first VC reconstruction unit 770 overwrites the item values ​​of the item names excluding "original" with the item values ​​of the item names that start with "original" in the second VC221c. For example, the item value of the item name "DID" is overwritten with the item value of the item name "original DID".

[0161] [Step S413] The first VC reconstruction unit 770 deletes item names that start with "original" and the item values ​​corresponding to those item names from the second VC221c. [Step S414] The first VC reconstruction unit 770 sets the second VC221c after the deletion process in step S413 as the first VC211 after reconstruction.

[0162] [Step S415] The first VC reconstruction unit 770 outputs the reconstructed first VC211. In this way, the first VC211 can be reconstructed even from the second VC221c, from which duplicate items have been removed.

[0163] [Sixth Embodiment] The sixth embodiment allows the verification request for the first VC211 to be sent from the verifier terminal 700 to the verifiers of the first DID base 30 in an appropriate manner for each verifier. In this case, for example, the method for sending verification requests is specified for each verifier in the verifier list.

[0164] Figure 27 shows an example of a verifier list, including the method of sending verification requests. The verifier list 971a shown in Figure 27 registers the DID, sending method, and recipient in the second DID infrastructure 40, corresponding to the service name of the verifier performing the verification of the VC in the first DID infrastructure 30. The sending method is the method of sending the verification request. For example, if the method of sending the verification request is email, the sending method is set to "Mail". Also, if the method of sending the verification request is data upload via the web, the sending method is set to "Web". The recipient is the recipient of the verification request. If the sending method is "Mail", the recipient is set to an email address. method If the destination is "Web," the destination will be set to a URL (Uniform Resource Locator).

[0165] The verifier terminal 700 can send verification requests to each verifier using the appropriate method by referring to the verifier list 971a. Figure 28 shows an example of the procedure for the first VC confirmation method when sending a verification request using a method specific to each recipient. Steps S501 to S502 and S504 to S506 in Figure 28 are the same as steps S131 to S132 and S134 to S136 in the second embodiment shown in Figure 13. The process of step S503, which differs from the second embodiment, is as follows.

[0166] [Step S503] The first VC verification unit 750 sends a verification request to each of the n verifiers using the method specified in the verifier list 971a. In this way, verification requests can be sent to each verifier using a pre-specified delivery method.

[0167] [Other embodiments] In the second to sixth embodiments, attribute information within the VC is recognized based on the attribute item name list, but if attribute information can be recognized by other means, the attribute item name list does not need to be used. For example, if the naming convention for attribute information items is predetermined in the description format of the VC, items with names that follow a predetermined rule can be determined to be attribute information.

[0168] Although embodiments have been illustrated above, the configurations of each part shown in the embodiments can be replaced with others having similar functions. Furthermore, other arbitrary components or processes may be added. Moreover, any two or more configurations (features) from the embodiments described above may be combined. [Explanation of Symbols]

[0169] 1. First DID Infrastructure 2. Second DID infrastructure 3. Issuer device 4. User terminals 5 Re-signature device 6. Verifier terminal 6a Storage section 6b Processing Unit 7a, 7b, ... Verification device 8 1st VC 8a First Author 9th VC 9a Second Signature

Claims

1. Obtaining a first VC issued by an issuer device managing user attribute information, which proves that the user's attribute information is correct by a first signature verifiable by the verification procedure of a first DID infrastructure, and a second VC issued by a resigning device verifiable by the verification procedure of the first DID infrastructure in response to a reissue request based on the first VC, which proves that the user's attribute information is correct by a second signature verifiable by the verification procedure of a second DID infrastructure, The verification procedure of the second DID infrastructure verifies the second signature included in the second VC, In the verification procedure of the first DID infrastructure, a verification request for the first signature contained in the first VC is sent to a verification device capable of verifying the first signature contained in the first VC. The verification result of the first signature included in the first VC is obtained from the verification device. A verification program that causes a computer to execute a process.

2. Based on the verification result of the first signature, the computer is further instructed to perform a process to determine whether or not there is any fraud in the issuance procedure of the second VC. The verification program according to claim 1.

3. In sending the verification request, a predetermined number of verification devices are selected from a list of verifiers showing multiple verification devices, and the verification request is sent to the selected verification devices. If verification results indicating that the attribute information is correct can be verified by the first signature are obtained from a threshold number of verification devices, it is determined that there is no fraud in the issuance procedure of the second VC. If the number of verification devices that were able to obtain verification results indicating that the attribute information was correct by the first signature is less than the threshold, it is determined that there is fraud in the issuance procedure of the second VC. The computer is then made to perform further processing. The verification program according to claim 2.

4. In selecting the verification device, the device of the issuer of the second VC is excluded from the selection. The verification program described in claim 3.

5. The second VC contains information indicating the first VC, and the second signature contained in the second VC is information that proves the first VC and the attribute information are correct. In the verification of the second signature, the second signature is used to verify that the attribute information and the first VC are correct. A verification program according to any one of claims 1 to 4.

6. In the second VC which includes information indicating the first VC, the duplication of attribute information between the first VC and the second VC is removed. In the process of obtaining the first VC from the second VC, the first VC is reconstructed based on the second VC. A verification program according to any one of claims 1 to 5.

7. Obtaining a first VC issued by an issuer device managing user attribute information, which proves that the user's attribute information is correct by a first signature verifiable by the verification procedure of the first DID infrastructure, and a second VC issued by a resigning device capable of verifying the first signature contained in the first VC in the verification procedure of the first DID infrastructure in response to a reissue request based on the first VC, which proves that the user's attribute information is correct by a second signature verifiable by the verification procedure of the second DID infrastructure, The verification procedure of the second DID infrastructure verifies the second signature included in the second VC, In the verification procedure of the first DID infrastructure, a verification request for the first signature contained in the first VC is sent to a verification device capable of verifying the first signature contained in the first VC. The verification result of the first signature included in the first VC is obtained from the verification device. A verification method for a computer to execute a process.

8. A processing unit that obtains a first VC issued by an issuer device managing user attribute information, which proves that the user's attribute information is correct by a first signature verifiable by the verification procedure of a first DID infrastructure, and a second VC issued by a resigning device capable of verifying the first signature contained in the first VC in the verification procedure of the first DID infrastructure in response to a reissue request based on the first VC, which proves that the user's attribute information is correct by a second signature verifiable by the verification procedure of a second DID infrastructure, verifies the second signature contained in the second VC in the verification procedure of the second DID infrastructure, transmits a verification request for the first signature contained in the first VC to a verification device capable of verifying the first signature contained in the first VC in the verification procedure of the first DID infrastructure, and obtains the verification result of the first signature contained in the first VC from the verification device. An information processing device having

9. The issuer device managing the user's attribute information issues a first VC that proves the user's attribute information is correct by a first signature verifiable in the verification procedure of the first DID infrastructure, The user terminal owned by the user acquires the first VC and transmits a request for reissuance of the VC based on the first VC to the resignature device. The resigning device, in response to the reissue request, issues a second VC that proves the user's attribute information is correct by a second signature verifiable by the verification procedure of the second DID infrastructure. The user terminal acquires the second VC and transmits the first VC and the second VC to the verifier terminal. The verifier terminal verifies the second signature included in the second VC in the verification procedure of the second DID infrastructure, The verifier terminal transmits a request to the verification device for verification of the first signature included in the first VC. The verification device verifies the first signature included in the first VC in the verification procedure of the first DID base, The verifier terminal obtains the verification result of the first signature included in the first VC from the verification device. Verification method.

10. In issuing the second VC, the resigning device generates the second VC which includes information indicating the first VC and the second signature which proves that the first VC and the attribute information are correct. In the verification of the second signature, the verifier terminal verifies that the attribute information and the first VC are correct based on the second signature. The verification method according to claim 9.

Images