Patent Description:
In recent years, the concept of self-sovereign identifiers (SSI) has been drawing attention, which aims to give individuals control over their own identities to compete with a world where giant private companies manage large amounts of personal data. In order to realize SSI systems, decentralized identifiers (DID) infrastructures using decentralized public key infrastructures (PKIs) are under development. DID infrastructures are mechanisms for individually managing personal attribute information (age, gender, etc.) with the signature of an issuer who guarantees the authenticity of the attribute information. Various companies and organizations are currently involved in development of DID infrastructures, and a wide range of management entities for DID infrastructures is expected to emerge in the future.

For example, in a DID infrastructure, a holder receives a certificate containing attribute information of the holder from an issuer. The certificate is plaintext character data, and a digital signature (hereinafter referred to simply as "signature") of the issuer is attached to the certificate. Such a certificate with a signature is referred to hereinafter as a verifiable credential (VC). Note that the certificate here refers not to a server certificate used in a decentralized PKI, but to a document with personal attribute information and the like.

The holder is able to prove their attributes by presenting a VC with the issuer's signature to a verifier. For example, a license center (issuer) issues a driver's license (VC) to a driver (holder). Through the use of a DID infrastructure, the driver is able to use their driver's license to prove to a liquor store (verifier) that they are <NUM> years old or older.

As a technique related to DID infrastructures, for example, there is a proposed method of issuing a digital certificate usable in multiple encryption systems. In addition, there is a proposed privacy authentication system capable of validating compliance with multiple hierarchical privacy policies in cross-border data access.

Chinese Patent Application Publication No. <CIT> relates to a cross-block chain identity verification method and a system in an inter-cloud computing environment. The method involves an entity registration distributed identity identification DID, where a publisher in each block chain issues a verifiable certificate VC for the entity and submits the verifiable certificate VC to a holder, the holder issues the received verifiable certificate VC to the block chain in which the holder is located, and the distributed identity identifications DID of each entity are issued to the same DID block chain; the signer and verifier DID blockchains perform cross-blockchain signature, verification and chaining for the relay.

Chinese Patent Application Publication No. <CIT> relates to a verification method and a verification device for verifiable statements and electronic equipment, wherein the verification method comprises the following steps: acquiring a first DID method corresponding to a target DID in a statement to be verified; determining a first driver corresponding to the first DID method from the corresponding relation between the DID method and the driver; reading DID document data of a target DID from a first block chain network containing a first DID method through a first driver, and obtaining a DID document of the target DID based on the DID document data; verifying the declaration to be verified based on the DID document.

Currently, there are multiple DID infrastructures, and each DID infrastructure has a different signature and verification scheme. Therefore, for example, if a DID infrastructure used by an issuer to issue a VC is different from a DID infrastructure available to a verifier, verification of the VC fails. Thus, it is difficult to use VCs across different DID infrastructures.

In view of the above, it may be considered reasonable to allow third-party intermediary operators belonging to multiple DID infrastructures to replace signatures, thereby enabling the use of VCs across DID infrastructures. However, conventional technologies are not able to eliminate fraud committed by intermediary operators in charge of signature replacement. For example, such intermediary operators could arbitrarily issue VCs not signed by issuers. This creates a serious problem in case of not fully trusted intermediary operators being involved.

One aspect of the embodiments is to enable detection of fraud in signature replacement.

The invention is defined in the independent claims, to which reference should now be made. Specific embodiments are defined in the dependent claims. According to an aspect, there is provided a computer program that causes a computer to execute a process.

Embodiments are set out, by way of example only, with reference to the following drawings, in which:.

Several embodiments will be described below with reference to the accompanying drawings. These embodiments may be combined with each other unless they have contradictory features.

A first embodiment is directed to a signature verification method of deterring fraud in signature replacement for a different DID infrastructure.

<FIG> illustrates an example of a verification method according to the first embodiment. <FIG> depicts a system for implementing the verification method. The system includes an issuer device <NUM>, a holder terminal <NUM>, a re-signing device <NUM>, a verifier terminal <NUM>, and multiple verification devices 7a, 7b, and so on. The issuer device <NUM>, the holder terminal <NUM>, the re-signing device <NUM>, and the multiple verification devices 7a, 7b, and so on belong to a first decentralized identifiers (DID) infrastructure <NUM>. The holder terminal <NUM>, the re-signing device <NUM>, and the verifier terminal <NUM> belong to a second DID infrastructure <NUM>. That is, the holder terminal <NUM> and the re-signing device <NUM> belong to both the first DID infrastructure <NUM> and the second DID infrastructure <NUM>. The multiple verification devices 7a, 7b, and so on may belong not only to the first DID infrastructure <NUM>, but also to the second DID infrastructure <NUM>.

The issuer device <NUM> is an information processor for managing attribute information of a holder who has the holder terminal <NUM>. The attribute information of the holder is, for example, the holder's personal information, such as the name and a face photo. The holder terminal <NUM> is an information processor owned by the holder. The re-signing device <NUM> is an information processor for verifying a signature attached to a verifiable credential (VC) issued in the first DID infrastructure <NUM> and issuing a new VC according to VC issuance procedures of the second DID infrastructure <NUM>. The verifier terminal <NUM> is an information processor used by a verifier who wants to validate the authenticity of the attribute information presented by the holder. The verification devices 7a, 7b, and so on are information processors capable of verifying a signature attached to a VC according to verification procedures of the first DID infrastructure <NUM>.

The information processor that functions as the verifier terminal <NUM> is, for example, a computer (including a handheld terminal) with a storing unit 6a and a processing unit 6b. The storing unit 6a is, for example, a memory or storage device. The processing unit 6b is, for example, a processor or arithmetic circuit. Similarly, the information processors individually functioning as the issuer device <NUM>, the holder terminal <NUM>, the re-signing device <NUM>, and the verification devices 7a, 7b, and so on are, for example, computers (including handheld terminals) with a storing unit and a processing unit. Such a computer is able to function as the issuer device <NUM>, the holder terminal <NUM>, the re-signing device <NUM>, or each of the verification devices 7a, 7b, and so on by executing a predetermined program. For example, the verifier terminal <NUM> runs a verification program to perform a verifying process of an acquired VC.

Assume here a case where, in a system with the above-described configuration, a holder whose attribute information is managed in the first DID infrastructure <NUM> presents the attribute information to a verifier having the verifier terminal <NUM> compatible only with the second DID infrastructure <NUM>. Assume further that, at this time, the verifier requests that the attribute information presented by the holder be verified through verification procedures of the second DID infrastructure <NUM>. In this case, the following process is performed.

First, the issuer device <NUM> issues a first VC <NUM> proving that the attribute information of the holder is valid by means of a first signature 8a which is verifiable through the verification procedures of the first DID infrastructure <NUM>. The holder terminal <NUM> acquires the first VD <NUM> from the issuer device <NUM>. The holder terminal <NUM> sends, to the re-signing device <NUM>, a request for reissuance of a VC based on the first VC <NUM>. The reissuance request includes the first VC <NUM>.

In response to the reissuance request, the re-signing device <NUM> issues a second VC <NUM> proving that the attribute information of the holder is valid by means of a second signature 9a which is verifiable through the verification procedures of the second DID infrastructure <NUM>. For example, the re-signing device <NUM> verifies the first signature 8a of the first VC <NUM> through the verification procedures of the first DID infrastructure <NUM>, and issues the second VC <NUM> when the attribute information contained in the first VC <NUM> is confirmed to be valid.

The holder terminal <NUM> acquires the second VC <NUM> from the re-signing device <NUM>. Then, the holder terminal <NUM> transmits the first VC <NUM> and the second VC <NUM> to the verifier terminal <NUM>.

The processing unit 6b of the verifier terminal <NUM> acquires the first VC <NUM> and the second VC <NUM>. Then, the processing unit 6b verifies the second signature 9a contained in the second VC <NUM> through the verification procedures of the second DID infrastructure <NUM>. The processing unit 6b outputs the verification results. For example, when the verification is successful, the processing unit 6b displays, on a monitor, the verification results indicating that the attribute information of the holder is valid.

In addition, the processing unit 6b stores the acquired first VC <NUM>, for example, in the storing unit 6a. Subsequently, the processing unit 6b sends a request to verify the first signature 8a contained in the first VC <NUM> to at least one of the verification devices 7a, 7b, and so on. The verification device having received the verification request verifies the first signature 8a contained in the first VC <NUM> through the verification procedures of the first DID infrastructure <NUM>. The processing unit 6b of the verifier terminal <NUM> acquires the verification results for the first signature 8a contained in the first VC <NUM> from the verification device having performed the verification. Then, upon acquisition of the verification results for the first signature 8a, the processing unit 6b determines based on the verification results whether the issuance procedures of the second VC <NUM> are fraudulent.

According to the system described above, if having doubts about the legitimacy of the VC reissuing process (signature replacement), the verifier sends a verification request from the verifier terminal <NUM> to one of the verification devices 7a, 7b, and so on to acquire the verification results. Conceivable fraudulent acts involved in signature replacement include, for example, rewriting of the attribute information and issuance of the second VC <NUM> by the re-signing device <NUM> without verifying the validity of the attribute information of the first VC <NUM> using the first signature 8a.

Because the first VC <NUM> and the second VC <NUM> are supposed to share the same attribute information, fraudulent rewriting of the attribute information is expected to be made to both the first VC <NUM> and the second VC <NUM>. If the attribute information has been rewritten in signature replacement, the verification results produced by any one of the verification devices 7a, 7b, and so on indicate that the attribute information is invalid. Herewith, it is possible to detect the fraud.

Note that if rewriting of the attribute information is made only to the second VC <NUM>, verification of the first signature 8a attached to the first VC <NUM> yields results indicating that the attribute information is valid. For this reason, the processing unit 6b may check the identity of the attribute information between the first VC <NUM> and the second VC <NUM>. If the attribute information is not the same, the processing unit 6b is able to determine the existence of fraud without performing signature verification or the like.

Even if the re-signing device <NUM> has issued the second VC <NUM> without verifying the first signature 8a even though the attribute information of the first VC <NUM> had been tampered, the verification results obtained by any one of the verification devices 7a, 7b, and so on indicate that the attribute information is invalid. Herewith, it is possible to detect the fraud.

In this manner, the verifier terminal <NUM> belonging to the second DID infrastructure <NUM> is able to detect fraud in signature replacement by the use of the first VC <NUM> when not being able to verify the first signature 8a of the first VC <NUM> created in the first DID infrastructure <NUM>. Thus, provision of the means for confirming the existence or nonexistence of fraud makes it difficult to conceal fraudulent acts, and is therefore expected to help deter such activity.

Another conceivable case is that the re-signing device <NUM> issues the second VC <NUM> for attribute information for which the issuer device <NUM> has not issued a VC. In this case, transmission of the first VC <NUM> from the holder terminal <NUM> to the verifier terminal <NUM> fails. For example, without the first VC <NUM> from the holder terminal <NUM>, the processing unit 6b does not determine the validity of the attribute information of the second VC <NUM>. Therefore, by stipulating that the first VC <NUM> also needs to be transmitted to the verifier terminal <NUM>, it is possible to prevent the re-signing device <NUM> from issuing the second VC <NUM> not based on the first VC <NUM>.

When sending a verification request, the processing unit 6b of the verifier terminal <NUM> selects a predetermined number of verification devices from, for example, a verifier list enumerating multiple verification devices, and transmits the verification request to the selected verification devices. Then, the processing unit 6b determines that no fraud has been committed in the issuance procedures of the second VC <NUM> when verification results indicating that the attribute information has been verified to be valid based on the first signature 8a are obtained from the number of verification devices equal to or greater than a threshold (e.g., more than half of the total number of requested verification devices). On the other hand, the processing unit 6b determines that some fraud has been involved in the issuance procedures of the second VC <NUM> if the number of verification devices with verification results indicating that the attribute information has been verified to be valid based on the first signature 8a is less than the threshold.

Thus, the existence or nonexistence of fraud is determined based on whether the verification results indicating the validity of the attribute information have been received from a certain number or more of verification devices. This improves the determination accuracy. That is, it is sometimes difficult to determine which of the verification devices 7a, 7b, and so on of the first DID infrastructure <NUM> have produced reliable verification results. Determination of the existence or nonexistence of fraud based on the verification results of a large number of verification devices leads to correct determination results in the end even if there are some verification devices managed by a person taking part in fraudulent activity.

Note that the re-signing device <NUM> is also able to verify the first signature 8a attached to the first VC <NUM>. However, it is inappropriate to send the verification request to the re-signing device <NUM> because making such a verification request to any of the verification devices is a process carried out when fraudulent activity on the re-signing device <NUM> is suspected. In view of this, when selecting verification devices to which a verification request is sent, the processing unit 6b excludes the re-signing device <NUM>, which is the issuer of the second VC <NUM>, from the selection targets. Herewith, it is possible to improve the reliability of the verification results obtained from verification devices.

Note that a fraudulent act in signature replacement may possibly be committed on the holder terminal <NUM> or on the re-signing device <NUM>. It is sometimes desired to clearly determine not only the existence of fraud, but also where the fraud has occurred, i.e., at the holder terminal <NUM> or the re-signing device <NUM>. In view of this, the re-signing device <NUM> is configured to create the second VC <NUM> containing the first VC <NUM>. In this case, the second VC <NUM> includes information representing the first VC <NUM>, and the second signature 9a attached to the second VC <NUM> serves as information for proving the validity of the first VC <NUM> and the attribute information. The processing unit 6b of the verifier terminal <NUM> verifies the validity of the attribute information and the first VC <NUM> based on the second signature 9a.

In the case where the first VC <NUM> is included in the second VC <NUM>, if a fraudulent act (e.g., rewriting of the attribute information) is committed on the re-signing device <NUM>, verification results obtained for the second signature 9a attached to the second VC <NUM> indicate that the attribute information is valid. On the other hand, the verification of the first signature 8a attached to the first VC <NUM> yields results indicating that the attribute information is invalid. If a fraudulent act (e.g., rewriting of the attribute information) is committed on the holder terminal <NUM>, not only verification results obtained for the first signature 8a of the first VC <NUM> but also those obtained for the second signature 9a of the second VC <NUM> indicate that the attribute information is invalid. Such a difference in the verification results allows the processing unit 6b of the verifier terminal <NUM> to identify where the fraud has been exercised.

In the case of including the first VC <NUM> in the second VC <NUM>, there is no need to introduce a processing component for transmitting the first VC <NUM> into the holder terminal <NUM>, other than a processing component for transmitting the second VC <NUM>.

Simple inclusion of the first VC <NUM> in the second VC <NUM> results in duplicate attribute information in the second VC <NUM>. Therefore, the re-signing device <NUM> may eliminate duplication of the attribute information between the first VC <NUM> and the second VC <NUM> when creating the second VC <NUM> including information representing the first VC <NUM>. In this case, in retrieving the first VC <NUM> from the second VC <NUM>, the processing unit 6b of the verifier terminal <NUM> reconstructs the first VC <NUM> based on the second VC <NUM>.

Elimination of the duplicate attribute information in this manner results in a reduction in the data volume transmitted from the holder terminal <NUM> to the verifier terminal <NUM>.

Next described is a second embodiment. The second embodiment is directed to a system capable of verifying a VC across multiple DID infrastructures.

<FIG> illustrates an example of a system structure. The example of <FIG> depicts two DID infrastructures (a first DID infrastructure <NUM> and a second DID infrastructure <NUM>) having different signature and verification schemes. Each of the first DID infrastructure <NUM> and the second DID infrastructure <NUM> is a system infrastructure allowing individuals to manage their personal attribute information on their own.

Devices belonging to the first DID infrastructure <NUM> and the second DID infrastructure <NUM> are connected to a network <NUM>. Devices belonging to the first DID infrastructure <NUM> include an issuer device <NUM>, a holder terminal <NUM>, a verifier terminal <NUM>, a decentralized PKI system <NUM>, and multiple gateways (GWs) <NUM>, 900a, 900b, and so on. Devices belonging to the second DID infrastructure <NUM> include the holder terminal <NUM>, an issuer device <NUM>, a verifier terminal <NUM>, a decentralized PKI system <NUM>, and the GWs <NUM>, 900a, 900b, and so on.

Each of the issuer devices <NUM> and <NUM> is one or more computers managed by an issuer who issues VCs. The holder terminal <NUM> is a computer managed by a holder <NUM> who uses a VC to prove their own attributes. The verifier terminals <NUM> and <NUM> are computers individually managed by verifiers <NUM> and <NUM> who verify the attributes of the holder <NUM> based on the VC. Each of the decentralized PKI systems <NUM> and <NUM> is one or more computers that manage public keys. The decentralized PKI systems <NUM> and <NUM> may individually manage the public keys on a decentralized ledger, such as a blockchain.

The GWs <NUM>, 900a, 900b, and so on are computers managed by intermediary operators providing VC re-signing services. The GWs <NUM>, 900a, 900b, and so on belong to both the first DID infrastructure <NUM> and the second DID infrastructure <NUM>, as depicted in <FIG>, and are able to use both the decentralized PKI systems <NUM> and <NUM>.

<FIG> illustrates an example of a hardware platform of an issuer device. The issuer device <NUM> has a processor <NUM> to control its entire operation. The processor <NUM> is connected to a memory <NUM> and other various devices and interfaces via a bus <NUM>. The processor <NUM> may be a single processing device or a multiprocessor system including two or more processing devices, such as a central processing unit (CPU), micro processing unit (MPU), and digital signal processor (DSP). It is also possible to implement processing functions of the processor <NUM> and its programs wholly or partly into an application-specific integrated circuit (ASIC), programmable logic device (PLD), or other electronic circuits, or any combination of them.

The memory <NUM> serves as the primary storage device in the issuer device <NUM>. Specifically, the memory <NUM> is used to temporarily store at least some of the operating system (OS) programs and application programs that the processor <NUM> executes, as well as various types of data to be used by the processor <NUM> for its processing. For example, the memory <NUM> may be implemented using a random access memory (RAM) or other volatile semiconductor memory devices.

Other devices on the bus <NUM> include a storage device <NUM>, a graphics processing unit (GPU) <NUM>, an input device interface <NUM>, an optical disc drive <NUM>, a peripheral device interface <NUM>, and a network interface <NUM>.

The storage device <NUM> writes and reads data electrically or magnetically in or on its internal storage medium. The storage device <NUM> serves as a secondary storage device in the computer to store program and data files of the operating system and applications. For example, the storage device <NUM> may be implemented using hard disk drives (HDD) or solid state drives (SSD).

The GPU <NUM> is an arithmetic unit that performs image processing, and is also called a graphic controller. The GPU <NUM>, coupled to a monitor <NUM>, produces video images in accordance with drawing commands from the processor <NUM> and displays them on a screen of the monitor <NUM>. The monitor <NUM> may be, for example, an organic electro-luminescence (OEL) display or a liquid crystal display.

The input device interface <NUM> is connected to input devices, such as a keyboard <NUM> and a mouse <NUM>, and supplies signals from those devices to the processor <NUM>. The mouse <NUM> is a pointing device, which may be replaced with other kinds of pointing devices, such as a touchscreen, tablet, touchpad, and trackball.

The optical disc drive <NUM> reads out data encoded on an optical disc <NUM> or writes data to the optical disc <NUM> by using laser light. The optical disc <NUM> is a portable storage medium on which data is recorded in such a manner as to be read by reflection of light. The optical disc <NUM> may be a digital versatile disc (DVD), DVD-RAM, compact disc read-only memory (CD-ROM), CD-Recordable (CD-R), or CD-Rewritable (CD-RW), for example.

The peripheral device interface <NUM> is a communication interface used to connect peripheral devices to the issuer device <NUM>. For example, the peripheral device interface <NUM> may be used to connect a memory device <NUM> and a memory card reader/writer <NUM>. The memory device <NUM> is a data storage medium having a capability to communicate with the peripheral device interface <NUM>. The memory card reader/writer <NUM> is an adapter used to write data to or read data from a memory card <NUM>, which is a data storage medium in the form of a small card.

The network interface <NUM> is connected to the network <NUM> so as to exchange data with other computers or communication devices (not illustrated). The network interface <NUM> is a wired communication interface connected to a wired communication device, such as a switch or router, with a cable. Alternatively, the network interface <NUM> may be a wireless communication interface communicatively connected to a wireless communication device, such as a base station and an access point, using radio waves.

The issuer device <NUM> may be realized with the above-described hardware configuration. Each of the issuer device <NUM>, the holder terminal <NUM>, the verifier terminals <NUM> and <NUM>, the decentralized PKI systems <NUM> and <NUM>, and the GWs <NUM>, 900a, 900b, and so on may be delivered with the same hardware configuration as the issuer device <NUM>. In addition, each of the issuer device <NUM>, the holder terminal <NUM>, the re-signing device <NUM>, the verifier terminal <NUM>, and the verification devices 7a, 7b, and so on of the first embodiment may be delivered with the same hardware configuration as the issuer device <NUM> depicted in <FIG>.

The issuer device <NUM> provides various processing functions of the second embodiment by, for example, executing computer programs stored in a computer-readable storage medium. A variety of storage media are available for recording programs to be executed by the issuer device <NUM>. For example, the issuer device <NUM> may store program files in its own storage device <NUM>. The processor <NUM> reads out at least part of those programs from the storage device <NUM>, loads them into the memory <NUM>, and executes the loaded programs. Other possible storage locations for the programs include the optical disc <NUM>, the memory device <NUM>, the memory card <NUM>, and other portable storage media. The programs stored in such a portable storage medium are installed in the storage device <NUM> under the control of the processor <NUM>, so that they are ready to be executed upon request. It may also be possible for the processor <NUM> to execute program codes read out of a portable storage medium, without installing them in its local storage devices.

The issuer device <NUM>, the holder terminal <NUM>, the verifier terminals <NUM> and <NUM>, the decentralized PKI systems <NUM> and <NUM>, and the GWs <NUM>, 900a, 900b, and so on may also be implemented by executing programs stored in computer-readable recording media.

When there are two DID infrastructures, as illustrated in <FIG>, if the holder and the verifier belong to the same DID infrastructure, it is easy for the holder to prove their attribute information to the verifier.

<FIG> illustrates an example of procedures for proving attribute information within the same DID infrastructure. The example of <FIG> assumes that the holder <NUM> (see <FIG>) belonging to the first DID infrastructure <NUM> proves the validity of attribute information representing their attributes to the verifier <NUM> (see <FIG>) belonging to the same first DID infrastructure <NUM>.

The issuer device <NUM> generates a pair of a private key <NUM> and a public key <NUM> of the issuer. The issuer device <NUM> registers the public key <NUM> in the decentralized PKI system <NUM> to thereby enable other devices belonging to the first DID infrastructure <NUM> to use the public key <NUM>.

The issuer device <NUM> issues a first VC <NUM> with a signature <NUM>, for example, in response to a request from the holder <NUM>. The first VC <NUM> contains attribute information of the holder <NUM>. For example, if the first VC <NUM> is a driver's license, the first VC <NUM> includes, for example, the name, date of birth, sex, address, and license number of the holder <NUM>. The signature <NUM> is a digital signature generated using the private key <NUM> of the issuer according to specifications of the first DID infrastructure <NUM>.

The holder <NUM> receives the first VC <NUM> issued by the issuer device <NUM> at the holder terminal <NUM>. The holder terminal <NUM> manages the first VC <NUM> in a first wallet <NUM>. The first wallet <NUM> is implemented, for example, by running application software provided by an organization operating the first DID infrastructure <NUM>.

In order for the holder <NUM> to prove their attribute information to the verifier <NUM>, the holder <NUM> transmits the first VC <NUM> from the holder terminal <NUM> to the verifier terminal <NUM>.

The verifier terminal <NUM> queries the decentralized PKI system <NUM> for the public key <NUM> of the issuer. The decentralized PKI system <NUM> transmits the appropriate public key <NUM> to the verifier terminal <NUM>. The verifier terminal <NUM> verifies the signature <NUM> using the public key <NUM>, and confirms that the contents of the first VC <NUM> have been certified by the issuer device <NUM>. Herewith, the holder <NUM> is able to prove their attributes to the verifier <NUM>. In the case where the attribute information contained in the first VC <NUM> is information of the driver's license of the holder <NUM>, the holder <NUM> is able to prove to the verifier <NUM> operating a liquor store that they are <NUM> years old or older.

On the other hand, the holder <NUM> is not able to use the first VC <NUM> to prove the validity of the attribute information representing their attributes to a verifier <NUM> belonging to the second DID infrastructure <NUM> different from the first DID infrastructure <NUM>. That is, even if the holder terminal <NUM> transmits the first VC <NUM> to the verifier terminal <NUM> belonging to the second DID infrastructure <NUM>, the verifier terminal <NUM> has no verification means to use the signature <NUM>. Therefore, the verifier <NUM> having the verifier terminal <NUM> is not able to confirm the validity of the attribute information on the first VC <NUM>.

As described above, the attribute information on the first VC <NUM> may be easily proved within the first DID infrastructure <NUM>; however, it is difficult to prove the attribute information across the two DID infrastructures. It may be considered reasonable, as a method of proving the attribute information across the two DID infrastructures, for example, to allow a GW, which is a third party belonging to both the first DID infrastructure <NUM> and the second DID infrastructure <NUM>, to replace the signature of the already issued VC.

<FIG> illustrates an example of a method of proving attribute information across DIDs. The example of <FIG> depicts signature replacement performed by the GW <NUM> which is managed by a third party intermediary operator. The GW <NUM> generates a pair of a private key <NUM> and a public key <NUM> and registers the public key <NUM> in the decentralized PKI system <NUM> of the second DID infrastructure <NUM>. After that, for example, the holder terminal <NUM> transmits the first VC <NUM> with the signature <NUM> to the GW <NUM> and requests the GW <NUM> to reissue a signature.

In response to the signature reissuance request from the holder terminal <NUM>, the GW <NUM> queries the decentralized PKI system <NUM> of the first DID infrastructure <NUM> for the public key <NUM> of the issuer. The GW <NUM> acquires the public key <NUM> from the decentralized PKI system <NUM> and verifies the signature <NUM> of the first DID infrastructure <NUM> using the public key <NUM>. Then, as an issuer of the second DID infrastructure <NUM>, the GW <NUM> uses its own private key <NUM> to generate a signature <NUM> for attribute information newly written on a second VC <NUM>. The GW <NUM> transmits the second VC <NUM> with the signature <NUM> attached to the attribute information to the holder terminal <NUM>.

The holder terminal <NUM> has a second wallet <NUM> corresponding to the second DID infrastructure <NUM>, separately from the first wallet <NUM> corresponding to the first DID infrastructure <NUM>. That is, the first wallet <NUM> is a function belonging to the first DID infrastructure <NUM> while the second wallet <NUM> is a function belonging to the second DID infrastructure <NUM>. The function of the second wallet <NUM> is to manage a VC for the second DID infrastructure <NUM>. The second wallet <NUM> is implemented, for example, by running application software provided by an organization operating the second DID infrastructure <NUM>.

The holder terminal <NUM> transmits the second VC <NUM> including the signature <NUM> to the verifier terminal <NUM> of the second DID infrastructure <NUM> to prove the attribute information using the second VC <NUM>. The verifier terminal <NUM> queries the decentralized PKI system <NUM> of the second DID infrastructure <NUM> for the public key <NUM> of the intermediary operator. The verifier terminal <NUM> acquires the public key <NUM> from the decentralized PKI system <NUM>. Then, the verifier terminal <NUM> uses the acquired public key <NUM> to verify the signature <NUM>, and confirms the validity of the contents of the second VC <NUM>.

With the method illustrated in <FIG>, if the GW <NUM> may be expected to correctly verify a signature in each DID infrastructure, it is possible to prove attribute information across the DID infrastructures based on the first VC <NUM>. As a result, replacing a signature afterward by the GW <NUM> allows for proving attribute information in a different DID infrastructure, even one which is unintended at the time of issuance of the first VC <NUM>.

However, the method depicted in <FIG> allows the GW <NUM> to give a signature also to attribute information to which a signature has not been given by the issuer device <NUM>. Therefore, the method of <FIG> is flawed in terms of deterring fraud exercised by the intermediatory operator running the GW <NUM>.

In view of the above problem, the holder terminal <NUM> transmits the first VC <NUM> in addition to the second VC <NUM> when proving the attribute information to the verifier terminal <NUM>. The verifier <NUM> using the verifier terminal <NUM> is able to check for fraud based on the first VC <NUM> when fraudulent signature replacement on the GW <NUM> is suspected. For example, the holder terminal <NUM> requests a GW other than the GW <NUM> to verify the signature <NUM> of the first VC <NUM>. If the verification of the signature <NUM> of the first VC <NUM> by the requested GW fails (the signature <NUM> is determined to be "Invalid"), a fraudulent act is determined to have occurred. Thus, allowing for checking the existence or nonexistence of fraud afterward will help deter fraudulent acts on the GW <NUM>.

<FIG> illustrates an example of a signature replacement method according to the second embodiment. In <FIG>, the processes from issuing the second VC <NUM> by the GW <NUM> up to storing the second VC <NUM> in the second wallet <NUM> of the holder terminal <NUM> are the same as those depicted in the example of <FIG>. Subsequently, when the holder <NUM> using the holder terminal <NUM> wants to prove their own attribute information to the verifier <NUM>, both the first VC <NUM> and the second VC <NUM> are transmitted from the holder terminal <NUM> to the verifier terminal <NUM>.

<FIG> illustrates an example of transmitted first VC and second VC. The first VC <NUM> includes non-attribute information <NUM>, attribute information <NUM>, and the signature <NUM> corresponding to the non-attribute information <NUM> and the attribute information <NUM>. The non-attribute information <NUM> contains, for example, DID information. The DID included in the first VC <NUM> is information used to identify the first VC <NUM> within the first DID infrastructure <NUM>. The attribute information <NUM> contains information including name, face image, and so on. The second VC <NUM> includes non-attribute information <NUM>, attribute information <NUM>, and the signature <NUM> corresponding to the non-attribute information <NUM> and the attribute information <NUM>. The non-attribute information <NUM> contains, for example, DID information. The DID included in the second VC <NUM> is information used to identify the second VC <NUM> within the second DID infrastructure <NUM>. The attribute information <NUM> contains information including name, face image, and so on.

The verifier terminal <NUM> uses the signature <NUM> of the second VC <NUM> to verify the attribute information <NUM> on the second VC <NUM>. That is, the verifier terminal <NUM> acquires the public key <NUM> of the intermediatory operator running the GW <NUM> from the decentralized PKI system <NUM> in the second DID infrastructure <NUM>. Then, using the acquired public key <NUM>, the verifier terminal <NUM> verifies the validity of the signature <NUM> attached to the second VC <NUM> according to procedures defined for the second DID infrastructure <NUM>.

In addition, in response to an instruction from the verifier <NUM> to verify the signature <NUM> attached to the first VC <NUM>, the verifier terminal <NUM> transmits a verification request to a predetermined number of GWs 900a, 900b, and so on, other than the GW <NUM>. For example, the verifier terminal <NUM> transmits the verification request by e-mail or the like to the predetermined number of GWs. The verification request includes the first VC <NUM>.

For example, if the GW 900a has received the verification request, the GW 900a acquires the public key <NUM> of the issuer of the first VC <NUM> from the decentralized PKI system <NUM> of the first DID infrastructure <NUM>. Using the acquired public key <NUM>, the GW 900a verifies the validity of the signature <NUM> attached to the first VC <NUM> according to procedures defined for the first DID infrastructure <NUM>. For example, upon reception of the verification request, the GW 900a performs verification by importing the received digital data into a verification component of the first DID infrastructure <NUM>. This verification method complies with the procedures defined for the first DID infrastructure <NUM>. Then, the GW 900a transmits the verification results (valid or invalid) to the verifier terminal <NUM>. Other GWs (e.g., the GW 900b) having received the verification request also perform a verifying process similar to that of the GW 900a described above.

The verifier terminal <NUM> checks the validity of the first VC <NUM> based on the verification results returned from the GWs to which the verification request has been sent. For example, the verifier terminal <NUM> confirms the validity of the signature <NUM> attached to the first VC <NUM> based on unanimous or majority verification results. If the unanimity rule is adopted, the verifier terminal <NUM> determines that the signature <NUM> attached to the first VC <NUM> is valid upon reception of responses with "Valid" from all the GWs to which the verification request has been sent. If the majority rule is adopted, the verifier terminal <NUM> determines that the signature <NUM> attached to the first VC <NUM> is valid when the number of GWs having returned responses with "Valid" exceeds half of all the GWs to which the verification request has been sent.

Thus, the holder terminal <NUM> transmits the first VC <NUM> to the verifier terminal <NUM> in addition to the second VC <NUM> so that, even if the GW <NUM> wrongly issues a signature, the verifier terminal <NUM> is able to check for the existence of fraud by requesting other GWs to verify the signature <NUM>. By establishing a method of confirming the existence or nonexistence of fraud as described above, it is possible to prevent fraudulent acts in signature replacement exercised on the GW <NUM>. That is, the verifier terminal <NUM> in the second DID infrastructure <NUM> is not able to verify the validity of the signature <NUM> attached to the first VC <NUM>; however, when there is some distrust for the operation of the GW <NUM>, the verifier terminal <NUM> requests GWs other than the GW <NUM> to verify the validity of the signature <NUM> to thereby check for the legitimacy of the operation of the GW <NUM>.

In selecting destinations for the verification request amongst the GWs 900a, 900b, and so on, it is desirable that the verifier terminal <NUM> select GWs discretely such that there would be no collusion between them. Note however that the above-described verifying process for the signature <NUM> is provided only for securing verification means for deterring fraudulent acts on the GW <NUM>, and the verifier terminal <NUM> in the second DID infrastructure <NUM> does not always implement this process.

Next described are functions of the individual devices for realizing the processes depicted in <FIG>.

<FIG> is a block diagram illustrating an example of functions of each device according to the second embodiment. The issuer device <NUM> includes a first VC creating unit <NUM> and an attribute item name list storing unit <NUM>. The first VC creating unit <NUM> creates the first VC <NUM> including the attribute information <NUM> of the holder <NUM>, for example, in response to a VC creation request from the holder terminal <NUM>. Then, the first VC creating unit <NUM> transmits the created first VC <NUM> to the holder terminal <NUM>. The attribute item name list storing unit <NUM> stores an attribute item name list. The attribute item name list enumerates item names of items representing attribute information of the holder <NUM> amongst information included in the first VC <NUM>. For example, the information included in the first VC <NUM> is represented by a list of pairs of an item name (key) and an item value (value). The information included in the first VC <NUM> contains the non-attribute information <NUM> used on a DID system and the attribute information <NUM> about personal attributes. The attribute item name list enumerates keys representing item names of the attribute information <NUM>.

For example, the attribute item name list storing unit <NUM> stores therein information read as "attribute item name list = {firstName, lastName, age}". The attribute item name list in this example indicates that the first name (firstName), last name (lastName), and age (age) of the holder <NUM> amongst the information included in the first VC <NUM> correspond to the attribute information <NUM>. The attribute item name list stored in the attribute item name list storing unit <NUM> is information open to the public. Therefore, for example, the GW <NUM> is able to acquire the attribute item name list from the issuer device <NUM>.

The holder terminal <NUM> includes the first wallet <NUM> and the second wallet <NUM>, as depicted in <FIG>. When the holder <NUM> wants to prove their own attribute information to the verifier <NUM>, the first VC <NUM> acquired from the first wallet <NUM> and the second VC <NUM> acquired from the second wallet <NUM> are transmitted from the holder terminal <NUM> to the verifier terminal <NUM>, for example.

The GW <NUM> includes a first VC storing unit <NUM>, a first VC verifying unit <NUM>, a second VC creating unit <NUM>, a second VC storing unit <NUM>, and an attribute item name list storing unit <NUM>. The first VC storing unit <NUM> stores therein the first VC <NUM> sent from the holder terminal <NUM> together with a reissuance request. The first VC verifying unit <NUM> verifies the signature <NUM> attached to the first VC <NUM> according to verification procedures defined for the first DID infrastructure <NUM>.

When the verification of the signature <NUM> attached to the first VC <NUM> is successful, the second VC creating unit <NUM> creates the second VC <NUM> by transcribing the attribute information of the first VC <NUM> according to VC issuance procedures defined for the second DID infrastructure <NUM>. At that time, the second VC creating unit <NUM> acquires the attribute item name list from the issuer device <NUM>, and determines attribute information amongst the information included in the first VC <NUM> based on the acquired attribute item name list. The second VC storing unit <NUM> stores therein the second VC <NUM> created by the second VC creating unit <NUM>. The second VC <NUM> stored in the second VC storing unit <NUM> is transmitted to the holder terminal <NUM> as a response to the reissuance request.

The attribute item name list storing unit <NUM> stores therein the attribute item name list acquired from the issuer device <NUM> by the second VC creating unit <NUM>. The attribute item name list stored in the attribute item name list storing unit <NUM> is information open to the public. Therefore, for example, the verifier terminal <NUM> is able to acquire the attribute item name list from the GW <NUM>.

The verifier terminal <NUM> includes a second VC storing unit <NUM>, a second VC verifying unit <NUM>, a verification result storing unit <NUM>, a first VC storing unit <NUM>, a first VC checking unit <NUM>, and a check result storing unit <NUM>. The second VC storing unit <NUM> stores the second VC <NUM> sent from the holder terminal <NUM>. The second VC verifying unit <NUM> verifies the signature <NUM> attached to the second VC <NUM> according to verification procedures defined for the second DID infrastructure <NUM>. The verification result storing unit <NUM> stores therein the verification results obtained by the second VC verifying unit <NUM>.

The first VC storing unit <NUM> stores therein the first VC <NUM> sent from the holder terminal <NUM>. The first VC checking unit <NUM> acquires a verifier list from one of the GWs 900a, 900b, and so on, and transmits a request for verifying the first VC <NUM> to verifiers on the acquired verifier list. The first VC checking unit <NUM> confirms, based on responses to the verification request, whether fraud has occurred in the issuance procedures of the second VC <NUM>. The check result storing unit <NUM> stores therein the check results obtained by the first VC checking unit <NUM>.

The GW 900a includes a first VC storing unit 910a, a first VC verifying unit 920a, a verification result storing unit 960a, and a verifier information storing unit 970a. The first VC storing unit 910a stores therein the first VC <NUM> included in the verification request from the verifier terminal <NUM>. The first VC verifying unit 920a verifies the signature <NUM> attached to the first VC <NUM> according to the verification procedures defined for the first DID infrastructure <NUM>. The verification result storing unit 960a stores therein verification results obtained by the first VC verifying unit 920a.

The verifier information storing unit 970a stores therein verifier information on an intermediary operator having the GW 900a capable of verifying VCs in the first DID infrastructure <NUM>. The verifier information is, for example, a verification e-mail destination disclosed externally by the intermediary operator running the GW 900a. Other GWs 900b and so on and the verifier terminal <NUM> in the first DID infrastructure <NUM> also disclose their own verifier information. For example, the verifier terminal <NUM> is able to acquire the verifier information from each of the GWs 900a, 900b, and so on and the verifier terminal <NUM> and generate a verifier list of verifiers or intermediary operators having devices capable of verifying VCs in the first DID infrastructure <NUM>.

Note that other GWs 900a, 900b, and so on are also provided with the same functions as those of the GW <NUM>. Similarly, other GWs <NUM>, 900b, and so on are also provided with the same functions as those of the GW 900a.

It is noted that the solid lines interconnecting functional blocks in <FIG> represent only some of their communication paths. A person skilled in the art would appreciate that there may be other communication paths in actual implementations. Each functional block seen in <FIG> may be implemented as a program module so that a computer executes the program module to provide its encoded functions.

<FIG> illustrates an example of a verifier list. In a verifier list <NUM>, the service name of each verifier who verifies VCs in the first DID infrastructure <NUM> is registered in association with, for example, a second DID infrastructure-dedicated DID and an email destination. Each second DID infrastructure-dedicated DID is the identification information of a device (e.g., a GW or verifier terminal), used within the second DID infrastructure <NUM>, in the case where the device also belongs to the second DID infrastructure <NUM>. Each email destination is an email address to which a request for verifying the first VC using the associated service is transmitted. Note that the verifier list <NUM> also includes information on services which do not belong to the second DID infrastructure <NUM>.

In the system configured as described above, when the holder <NUM> in the first DID infrastructure <NUM> wants to prove the validity of their attribute information to the verifier <NUM> in the second DID infrastructure <NUM>, a VC reissuance request is sent to the GW <NUM> from the holder terminal <NUM> under the instruction of the holder <NUM>. Subsequently, the GW <NUM> performs a VC reissuing process. The VC reissuing process is described in detail below with reference to <FIG> and <FIG>.

<FIG> is a flowchart illustrating an example of procedures of a VC reissuing process. The process in <FIG> is described below in the order of step numbers.

[Step S101] The GW <NUM> receives a VC reissuance request from the holder terminal <NUM>. The VC reissuance request includes the first VC <NUM>. The GW <NUM> stores, in the first VC storing unit <NUM>, the first VC <NUM> included in the VC reissuance request.

[Step S102] The first VC verifying unit <NUM> acquires the public key <NUM> of the issuer. For example, the first VC verifying unit <NUM> queries the decentralized PKI system <NUM> in the first DID infrastructure <NUM> for the key of the issuer. In response to the query, the public key <NUM> of the issuer is returned from the decentralized PKI system <NUM>.

[Step S103] The first VC verifying unit <NUM> verifies the signature <NUM> of the first VC <NUM> using the acquired public key <NUM>.

[Step S104] The first VC verifying unit <NUM> determines whether the verification is successful. If the verification is successful, the first VC verifying unit <NUM> instructs the second VC creating unit <NUM> to create the second VC <NUM>, and the process moves to step S105. If the verification is unsuccessful, the first VC verifying unit <NUM> terminates the VC reissuing process with an error.

[Step S105] The second VC creating unit <NUM> performs a second VC creating process. This process is described in detail later (see <FIG>). The second VC <NUM> created by the second VC creating unit <NUM> is stored in the second VC storing unit <NUM>.

[Step S106] The GW <NUM> transmits the second VC <NUM> stored in the second VC storing unit <NUM> to the holder terminal <NUM>.

Next, the procedures of the second VC creating process are described in detail.

<FIG> is a flowchart illustrating an example of procedures of a second VC creating process. The process in <FIG> is described below in the order of step numbers.

[Step S111] The second VC creating unit <NUM> acquires the first VC <NUM>, the private key <NUM> of the GW <NUM>, and the attribute item name list. The first VC <NUM> is obtained from the first VC verifying unit <NUM>. The private key <NUM> of the GW <NUM> is obtained, for example, from a storage device within the GW <NUM>. The attribute item name list is obtained from the issuer device <NUM>.

[Step S112] For each item name on the attribute item name list, the second VC creating unit <NUM> copies the item value of the item name from the first VC <NUM> into the second VC <NUM>. Herewith, the attribute information <NUM> of the first VC <NUM> is written as the attribute information <NUM> of the second VC <NUM>.

[Step S113] The second VC creating unit <NUM> sets, in the second VC <NUM>, the item values of item names not included in the attribute item name list according to the VC issuance procedures defined for the second DID infrastructure <NUM>. Herewith, the non-attribute information <NUM> is written in the second VC <NUM>.

[Step S114] The second VC creating unit <NUM> creates the signature <NUM> of the attribute information <NUM> using the private key <NUM> of the GW <NUM> according to signature creation procedures defined for the second DID infrastructure <NUM>. The second VC creating unit <NUM> writes the created signature <NUM> in the second VC <NUM>.

[Step S115] The second VC creating unit <NUM> outputs the created second VC <NUM>. For example, the second VC creating unit <NUM> stores the second VC <NUM> in the second VC storing unit <NUM>.

By the above-described reissuing process, the second VC <NUM> is issued based on the first VC <NUM>. The second VC <NUM> is managed in the second wallet <NUM> of the holder terminal <NUM>. Then, the holder terminal <NUM> transmits the first VC <NUM> and the second VC <NUM> to the verifier terminal <NUM> under the instruction of the holder <NUM>. For example, the verifier terminal <NUM> presents a destination as a two-dimensional code or the like. The holder <NUM> inputs information of the destination into the holder terminal <NUM> and enters an instruction to transmit the first VC <NUM> and the second VC <NUM>. For example, if the destination is presented as a two-dimensional code, the holder <NUM> causes a camera of the holder terminal <NUM> to read the two-dimensional code to input the information of the destination into the holder terminal <NUM>. The holder terminal <NUM> transmits the first VC <NUM> and the second VC <NUM> to the entered destination. Upon receiving the first VC <NUM> and the second VC <NUM>, the verifier terminal <NUM> performs a verifying process for the second VC <NUM>.

<FIG> is a flowchart illustrating an example of procedures of a second VC verifying process. The process in <FIG> is described below in the order of step numbers.

[Step S121] The verifier terminal <NUM> receives the first VC <NUM> and the second VC <NUM> from the holder terminal <NUM>.

[Step S122] The verifier terminal <NUM> stores the first VC <NUM> in the first VC storing unit <NUM> and the second VC <NUM> in the second VC storing unit <NUM>.

[Step S123] The second VC verifying unit <NUM> of the verifier terminal <NUM> acquires the public key <NUM> of the GW <NUM>. For example, the second VC verifying unit <NUM> queries the decentralized PKI system <NUM> in the second DID infrastructure <NUM> for the key of the GW <NUM>. In response to the query, the public key <NUM> of the GW <NUM> is returned from the decentralized PKI system <NUM>.

[Step S124] The second VC verifying unit <NUM> verifies the signature <NUM> of the second VC <NUM> using the acquired public key <NUM>.

[Step S125] The second VC verifying unit <NUM> outputs the verification results. For example, the second VC verifying unit <NUM> stores the verification results in the verification result storing unit <NUM>.

The verifier <NUM> causes the verifier terminal <NUM> to display the verification results stored in the verification result storing unit <NUM> to thereby recognize the verification results. If the verification results indicate "Valid", the verifier <NUM> determines that the contents of the attribute information <NUM> in the second VC <NUM> correctly represent attributes of the holder <NUM>.

Even if "Valid" is obtained as the verification results in the verifying process of the second VC <NUM>, there is a possibility that a fraudulent act has been committed on the GW <NUM> and, therefore, the contents of the attribute information <NUM> differ from the original attributes of the holder <NUM>. For example, when a fraudulent act on the GW <NUM> is suspected, the verifier <NUM> is able to check for the existence or nonexistence of fraud using the first VC <NUM>. In that case, the verifier <NUM> enters an instruction to check the first VC <NUM> on the verifier terminal <NUM>. In response, the verifier terminal <NUM> performs a first VC checking process.

<FIG> is a flowchart illustrating an example of procedures of a first VC checking process. The process in <FIG> is described below in the order of step numbers.

[Step S131] The first VC checking unit <NUM> acquires the first VC <NUM>, parameters n and k, the verifier list <NUM> of the first DID infrastructure <NUM>, and the DID of the issuer (the GW <NUM>) of the second VC <NUM>. The first VC <NUM> is obtained from the first VC storing unit <NUM>. The parameters n and k are integers set in the verifier terminal <NUM> in advance. The parameter n indicates the number of destinations for a verification request. The parameter k is a threshold indicating how many responses of "Valid" need to be received from the n number of request destinations to set the check results as "Valid". The verifier list <NUM> is obtained from, for example, the GW 900a. The DID of the issuer of the second VC <NUM> is indicated, for example, in the non-attribute information <NUM> of the second VC <NUM>.

[Step S132] The first VC checking unit <NUM> selects, from the verifier list <NUM> with verifiers belonging to the first DID infrastructure <NUM>, n number of verifiers to whom a verification request is to be made (including intermediary operators running GWs). The n number of verifiers may be selected under the instruction of the holder terminal <NUM>. In selecting the n number of verifiers to be requested for verification, the first VC checking unit <NUM> excludes the issuer of the second VC <NUM> from the selection. For example, in the second VC <NUM>, the DID of the GW <NUM> having issued the second VC <NUM> is set as the item value of the item name "issuer". Amongst the verifiers registered in the verifier list <NUM>, the first VC checking unit <NUM> excludes, from the selection, a verifier whose DID set under "second DID infrastructure-dedicated DID" is the same as the DID of the GW <NUM>.

[Step S133] The first VC checking unit <NUM> transmits a verification request by e-mail to the selected n number of verifiers, who belong to the first DID infrastructure <NUM>. The verification request e-mail is accompanied by the first VC <NUM>. Upon checking the e-mail, for example, the verifiers input, as a verification subject, the first VC <NUM> attached to the e-mail into their verification devices, e.g., the GWs 900a, 900b, and so on. That is, the verification request sent by e-mail is passed to the verification devices at the end. Thereafter, the first VC checking unit <NUM> receives the verification results from the verification device (verification terminal or GW) of each verifier to whom the verification request has been sent.

[Step S134] The first VC checking unit <NUM> determines whether k or more number of verifiers have returned "Valid". If k or more number of verifiers have returned "Valid", the first VC checking unit <NUM> moves to step S135. If the number of verifiers having returned "Valid" is less than k, the first VC checking unit <NUM> moves to step S136.

[Step S135] The first VC checking unit <NUM> outputs "Valid" as the check results. For example, the first VC checking unit <NUM> stores the check results "Valid" in the check result storing unit <NUM>. Subsequently, the first VC checking unit <NUM> ends the first VC checking process.

[Step S136] The first VC checking unit <NUM> outputs "Invalid" as the check results. For example, the first VC checking unit <NUM> stores the check results "Invalid" in the check result storing unit <NUM>.

With reference to the check results stored in the check result storing unit <NUM>, the verifier <NUM> determines the existence or nonexistence of fraud. If the check results are "Valid", the verifier <NUM> determines that no fraud has been committed. If the check results are "Invalid", the verifier <NUM> determines that there has been a fraudulent act.

As has been described above, in proving the validity of their own attribute information to the verifier <NUM> of the second DID infrastructure <NUM>, the holder <NUM> sends not only the second VC <NUM> with a replaced signature, but also the first VC <NUM>, from the holder terminal <NUM> to the verifier terminal <NUM>. Herewith, when the GW <NUM> in charge of the signature replacement has wrongly issued the signature, the verifier <NUM> verifies the signature <NUM> of the first VC <NUM> to thereby confirm that fraud has been committed. That is, it facilitates detection of fraud on the GW <NUM>, which is expected to contribute to deterring fraudulent acts on the GW <NUM>.

For example, when there is some distrust for the operation of the GW <NUM>, the verifier <NUM> requests verification of the signature <NUM> from verifiers' devices (e.g., 900a, 900b, and so on) belonging to the first DID infrastructure <NUM>, other than the GW <NUM>, to thereby check for the legitimacy of the operation of the GW <NUM>. At this time, for example, the verifier <NUM> requests verification of the signature <NUM> from multiple verifiers, and then confirms the validity of the signature <NUM> based on unanimous or majority verification results. In this manner, the verifier <NUM> is able to correctly determine the existence or nonexistence of fraud.

Note that, in selecting verifiers of the first DID infrastructure <NUM> to check for the existence of fraud, it is desirable to select the verifiers discretely such that there would be no collusion between them. For example, the verifier list <NUM> is acquired from a device (e.g., the GW 900a) different from the GW <NUM> having conducted signature replacement. This prevents interference with verifiers on the verifier list <NUM> from the intermediary operator running the GW <NUM>.

Note that the above-described process of checking for the existence of fraud (the first VC checking process) is provided only for securing verification means for deterring fraudulent acts on the GW <NUM>. That is, whether the verifier <NUM> causes the verifier terminal <NUM> to run the process of checking for the existence of fraud is decided on a voluntary basis.

The third embodiment is directed to also enabling determination of the existence or nonexistence of fraud committed by the holder <NUM>. That is, the second embodiment does not take into account fraudulent acts done by the holder <NUM>, and even if the process of checking the first VC <NUM> results in "Invalid", it is not possible to see whether fraud has been made on the GW <NUM> or by the holder <NUM>. For example, even if the holder <NUM> has falsified the signature <NUM> of the first VC <NUM> and the check results for the first VC <NUM> obtained by the verifier terminal <NUM> therefore indicate "Invalid", the verifier <NUM> is not able to distinguish it from the case where fraud has been committed on the GW <NUM>.

The second embodiment also needs preparation of communication channels and processing components for transmitting the first VC <NUM> and the second VC <NUM> to the verifier terminal <NUM>.

In view of the above, the third embodiment aims at allowing for distinction between fraud made on the GW <NUM> and fraud made by the holder <NUM> and also eliminating the need for a special mechanism for transmitting information from the holder terminal <NUM> to the verifier terminal <NUM>. The following description of the third embodiment focuses on differences from the above-described second embodiment.

<FIG> illustrates an example of a signature replacement method according to the third embodiment. In <FIG>, the processes up to transmitting a VC reissuance request from the holder terminal <NUM> to the GW <NUM> are the same as those in the second embodiment. In the third embodiment, upon reception of the VC reissuance request, the GW <NUM> verifies the signature <NUM> of the first VC <NUM> and then adds a signature 222a of the GW <NUM> to information including the first VC <NUM> to thereby generate a second VC 221a. For example, the second VC 221a includes the attribute information of the holder <NUM>, the first VC <NUM>, and the signature 222a. The GW <NUM> transmits the generated second VC 221a to the holder terminal <NUM>. The VC reissuance is made in this manner.

The holder terminal <NUM> manages the second VC 221a in the second wallet <NUM>. Then, when the holder <NUM> wants to prove their own attribute information to the verifier <NUM>, the holder terminal <NUM> transmits the second VC 221a managed in the second wallet <NUM> to the verifier terminal <NUM>.

Upon reception of the second VC 221a, the verifier terminal <NUM> acquires the public key <NUM> of the GW <NUM> from the decentralized PKI system <NUM> in the second DID infrastructure <NUM>. Then, the verifier terminal <NUM> verifies the signature 222a of the second VC 221a using the acquired public key <NUM>. If the signature 222a is valid, the verifier <NUM> determines that the attribute information of the holder <NUM> on the second VC 221a is correct. If having any doubts about the operation of the GW <NUM>, the verifier <NUM> instructs the verifier terminal <NUM> to run the process of checking the first VC <NUM>. In response, the verifier terminal <NUM> transmits a verification request to devices (or verifiers having the devices) capable of VC verification in the first DID infrastructure <NUM>, such as the GWs 900a, 900b and so on. Based on verification results returned in response to the verification request, the verifier terminal <NUM> determines whether the first VC <NUM> is valid.

<FIG> illustrates an example of a second VC containing a first VC. The second VC 221a includes the non-attribute information <NUM>, the attribute information <NUM>, the first VC <NUM>, and the signature 222a. The first VC <NUM> includes the non-attribute information <NUM>, the attribute information <NUM>, and the signature <NUM>. The signature 222a of the second VC 221a is a signature for certifying the contents of the non-attribute information <NUM>, the attribute information <NUM>, and the first VC <NUM>.

This makes it possible to reliably detect fraud committed on the GW <NUM>. For example, if the signature 222a of the second VC 221a is "Valid" and the signature <NUM> of the first VC <NUM> is "Invalid", a fraudulent act is found to have been done on the GW <NUM>. If both the signature 222a of the second VC 221a and the signature <NUM> of the first VC <NUM> are "Invalid", the holder <NUM> is determined to have falsified the signature <NUM> of the first VC <NUM>.

The GW <NUM> reissues the second VC 221a (including the non-attribute information <NUM>, the attribute information <NUM>, the first VC <NUM>, and the signature 222a) with the original first VC <NUM> (including the non-attribute information <NUM>, the attribute information <NUM>, and the signature <NUM>) embedded therein. This allows for management of the first VC <NUM> in the second wallet <NUM>. It also becomes possible to send the first VC <NUM> using an existing communication mechanism between the second wallet <NUM> and the verifier terminal <NUM>, specified in the second DID infrastructure <NUM>. This eliminates the need for adding a processing component used to send the first VC <NUM> from the holder terminal <NUM> to the verifier terminal <NUM>.

<FIG> is a block diagram illustrating an example of functions of each device according to the third embodiment. The verifier terminal <NUM> of the third embodiment includes a first VC reconstructing unit <NUM> in addition to the components of the second embodiment (see <FIG>). The third embodiment does not need the communication path used in the second embodiment to transmit the first VC <NUM> from the first wallet <NUM> of the holder terminal <NUM> to the verifier terminal <NUM>. The first VC reconstructing unit <NUM> extracts the first VC <NUM> from the second VC 221a stored in the second VC storing unit <NUM>. Then, the first VC reconstructing unit <NUM> stores the extracted first VC <NUM> in the first VC storing unit <NUM>.

Each component of <FIG> has the same function as the component with the same name of the second embodiment depicted in <FIG>. Note however that the second VC creating unit <NUM> of the third embodiment creates the second VC 221a containing the first VC <NUM> therein, unlike with the second embodiment.

<FIG> is a flowchart illustrating an example of procedures of a second VC creating process according to the third embodiment. The process in <FIG> is described below in the order of step numbers.

[Step S201] The second VC creating unit <NUM> acquires the first VC <NUM>, the private key <NUM> of the GW <NUM>, and the attribute item name list.

[Step S202] For each item name on the attribute item name list, the second VC creating unit <NUM> copies the item value of the item name from the first VC <NUM> into the second VC 221a.

[Step S203] The second VC creating unit <NUM> sets, in the second VC 221a, the item values of non-attribute information according to the VC issuance procedures defined for the second DID infrastructure <NUM>.

[Step S204] The second VC creating unit <NUM> adds an item name read as "originalCredential" to the second VC 221a and enters the first VC <NUM> as it is as the item value of the added item name "originalCredential".

[Step S205] The second VC creating unit <NUM> creates the signature 222a for the attribute information <NUM> and the first VC <NUM> using the private key <NUM> of the GW <NUM> according to signature creation procedures defined for the second DID infrastructure <NUM>. The second VC creating unit <NUM> puts the created signature 222a in the second VC 221a.

[Step S206] The second VC creating unit <NUM> outputs the created second VC 221a. For example, the second VC creating unit <NUM> stores the second VC 221a in the second VC storing unit <NUM>.

The second VC 221a containing the first VC <NUM> therein is created in this manner.

<FIG> illustrates an example of a second VC containing a first VC. The example of <FIG> depicts the first VC <NUM> and the second VC 221a created using the Verifiable Credentials Data Model (VCDM) <NUM>. In the second VC 221a, the item name "originalCredential" is included in the item name "credentialSubject", as illustrated in <FIG>. "credentialSubject" is an item for setting information to be signed. The item value of the item name "originalCredential" includes the entire first VC <NUM>. Because the item representing the first VC <NUM> is placed within "credentialSubject", the signature 222a is affixed to the information including the first VC <NUM>.

The second VC 221a complies with the specifications of the second DID infrastructure <NUM> and is manageable in the second wallet <NUM>. The second wallet <NUM> is able to send the second VC 221a containing the first VC <NUM> therein to the verifier terminal <NUM> in the second DID infrastructure <NUM> using a communication method specified in the second DID infrastructure <NUM>. In the verifier terminal <NUM>, the first VC reconstructing unit <NUM> extracts the first VC <NUM> from the received second VC 221a.

<FIG> is a flowchart illustrating an example of procedures of a first VC reconstructing process. The process in <FIG> is described below in the order of step numbers.

[Step S211] The first VC reconstructing unit <NUM> acquires the second VC 221a from the second VC storing unit <NUM>.

[Step S212] The first VC reconstructing unit <NUM> acquires the item value of the item name "originalCredential" of the second VC 221a. The acquired item value represents the first VC <NUM>.

[Step S213] The first VC reconstructing unit <NUM> outputs the first VC <NUM>. For example, the first VC reconstructing unit <NUM> stores the first VC <NUM> in the first VC storing unit <NUM>.

In this way, the first VC <NUM> is handed over to the verifier terminal <NUM> using the existing communication system of the second DID infrastructure <NUM>. Then, whether a fraudulent act has taken place on the GW <NUM> is correctly determined using the first VC <NUM>.

The fourth embodiment is directed to reducing the data amount of the second VC of the third embodiment. In the second and third embodiments, the amount of data transmitted from the holder terminal <NUM> to the verifier terminal <NUM> increases by the amount of data in the first VC <NUM>. The first VC <NUM> may contain a large amount of data, such as a face image. If the amount of data transmitted from the holder terminal <NUM> to the verifier terminal <NUM> is too large, it causes a processing delay for the holder <NUM> in proving their own attribute information. In view of this, the fourth embodiment aims at deleting, amongst the items included in the attribute information <NUM> of the first VC <NUM>, items overlapping with those in the attribute information <NUM> of the second VC 221a.

<FIG> illustrates a first example of a method of reducing the amount of data in the second VC. In the example of <FIG>, amongst the items included in the attribute information <NUM> of the first VC <NUM>, "name" and "face image" are redundantly included in the attribute information <NUM> of the second VC 221a. Note here that each item whose item name and item value match between the first VC <NUM> and the second VC 221a is identified as an overlapping item.

In the fourth embodiment, the second VC creating unit <NUM> creates, based on the second VC 221a depicted in the third embodiment, a second VC 221b from which overlapping items have been deleted. For example, overlapping attribute information <NUM> is set in the second VC 221b as a new item. The item name of the overlapping attribute information <NUM> is, for example, "Same Attr. The item value of the overlapping attribute information <NUM> is set to the item name of each item that is redundantly included in the attribute information <NUM> of the first VC <NUM> and the attribute information <NUM> of the second VC 221a. The second VC 221b also includes the first VC 211a from which overlapping items have been deleted. In the example of <FIG>, the first VC 211a is obtained by deleting the items "name" and "face image" from the first VC <NUM>.

The second VC 221b from which overlapping items have thus been deleted is transmitted from the holder terminal <NUM> to the verifier terminal <NUM>. The verifier terminal <NUM> is able to reconstruct the original first VC <NUM> by referring to the overlapping attribute information <NUM>. For example, the verifier terminal <NUM> acquires items indicated by the overlapping attribute information <NUM> from the attribute information <NUM> of the second VC 221b and adds them to the first VC 211a included in the second VC 221b to thereby create the original first VC <NUM>.

As described above, utilizing the fact that the attribute information <NUM>, such as a name and face image, is copied to the second VC 221a without being changed on the GW <NUM>, the fourth embodiment removes items overlapping with those of the second VC 221a from the first VC 211a contained in the second VC 221b to be created. This reduces not only the amount of data of the second VC 221b managed in the second wallet <NUM> but also the amount of data communicated between the second wallet <NUM> and the verifier terminal <NUM>. Note that the second VC 221b is provided with the overlapping attribute information <NUM>, which facilitates reconstruction of the original first VC <NUM>.

Next, the process of creating the second VC 221b with overlapping items removed therefrom is described in detail with reference to <FIG>.

<FIG> is a flowchart illustrating an example of procedures of a second VC creating process according to the fourth embodiment. Note that, amongst the process steps of <FIG>, steps S301 to <NUM>, S307, and S308 are the same as steps S201 to S206, respectively, in the third embodiment depicted in <FIG>. Therefore, with reference to <FIG>, the following describes steps different from those of the third embodiment, i.e., steps S305 and S306.

[Step S305] The second VC creating unit <NUM> adds an item name read as "Same Attr. " to the second VC 221b and enters, as an item value corresponding to the added item name, item names enumerated in the attribute item name list.

[Step S306] The second VC creating unit <NUM> deletes items corresponding to the item names enumerated in the attribute item name list from the first VC set as the item value of the item name "originalCredential".

Thus, interposing steps S305 and S306 in the second VC creating process allows for creating the second VC 221b with overlapping items removed therefrom. Next, the process of reconstructing the first VC <NUM> from the second VC 221b is described in detail with reference to <FIG>.

<FIG> is a flowchart illustrating an example of procedures of a first VC reconstructing process according to the fourth embodiment. The process in <FIG> is described below in the order of step numbers.

[Step S311] The first VC reconstructing unit <NUM> acquires the second VC 221b and the attribute item name list. For example, the first VC reconstructing unit <NUM> acquires the second VC 221b from the second VC storing unit <NUM>. The first VC reconstructing unit <NUM> also acquires the attribute item name list from the attribute item name list storing unit <NUM> of the GW <NUM>.

[Step S312] The first VC reconstructing unit <NUM> acquires the item value of the item name "originalCredential" of the second VC 221b. The first VC reconstructing unit <NUM> sets the acquired item value as a first VC'.

[Step S313] The first VC reconstructing unit <NUM> adds item names written as the item value of the item name "Same Attr. " in the second VC 221b to the acquired item value (the first VC').

[Step S314] For each of the item names added to the first VC', the first VC reconstructing unit <NUM> transcribes the item value of the same item name in the second VC 221b. The first VC' obtained after transcription of the item values is the reconstructed first VC <NUM>.

[Step S315] The first VC reconstructing unit <NUM> outputs the reconstructed first VC <NUM>.

Thus, the first VC <NUM> is reconstructed even from the second VC 221b with overlapping items removed therefrom.

The fifth embodiment is directed to deleting overlapping items by a method different from that of the fourth embodiment. Specifically, according to the fifth embodiment, the non-attribute information <NUM> in the first VC <NUM> is set as an item of the second VC with information indicating that it is an item in the original VC.

<FIG> illustrates a second example of the method of reducing the amount of data in the second VC. In the example of <FIG>, the item of the non-attribute information <NUM> of the first VC <NUM> is copied to a second VC 221c with the word "original" added to the head of the item name, to thereby form non-overlapping information <NUM>. The signature <NUM> of the first VC <NUM> is also set in the second VC 221c as a signature 212a of the original first VC <NUM> after the word "original" is added to the head of the item name.

When reconstructing the first VC <NUM> from the second VC 221c, the non-overlapping information <NUM> in the second VC 221c is copied to the first VC <NUM> to be reconstructed. At this time, the word "original" is deleted from the item name of the item included in the non-overlapping information <NUM>. In addition, the attribute information <NUM> in the second VC 221c is copied to the first VC <NUM> to be reconstructed. Further, the signature 212a of the first VC <NUM> included in the second VC 221c is copied to the first VC <NUM> to be reconstructed. At this time, the word "original" is deleted from the item name of the item included in the signature 212a of the first VC <NUM>.

Thus, in the fifth embodiment, the attribute information <NUM>, such as a name and face image, is copied only once to the second VC 221c without being changed on the GW <NUM>, to thereby exclude overlapping items between the second VC 221a and the first VC <NUM>. This results in a reduced amount of data in the second VC 221c managed in the second wallet <NUM> as well as a reduced amount of data communicated between the second wallet <NUM> and the verifier terminal <NUM>. Note that addition of the word "original" to the head of the item name of each of the non-overlapping information <NUM> and the signature 212a of the first VC <NUM> prevents duplication of the item names in the second VC 221c, which facilitates reconstruction of the original first VC <NUM>.

Next, the process of creating the second VC 221c with overlapping items removed therefrom is described in detail with reference to <FIG>.

<FIG> is a flowchart illustrating an example of procedures of a second VC creating process according to the fifth embodiment. The process in <FIG> is described below in the order of step numbers.

[Step S401] The second VC creating unit <NUM> acquires the first VC <NUM>, the private key <NUM> of the GW <NUM>, and the attribute item name list.

[Step S402] For each item name on the attribute item name list, the second VC creating unit <NUM> copies the item value of the item name from the first VC <NUM> into the second VC 221c.

[Step S403] The second VC creating unit <NUM> sets, in the second VC 221c, the item value of each item not included in the attribute item name list according to the VC issuance procedures defined for the second DID infrastructure <NUM>.

[Step S404] The second VC creating unit <NUM> copies, amongst the items on the first VC <NUM>, the item value of each item name not included in the attribute item name list to the second VC 221c. At this time, the word "original" is added to the head of the item name. Herewith, the non-overlapping information <NUM> and the signature 212a are added to the second VC 221c.

[Step S405] The second VC creating unit <NUM> creates the signature 222c for the attribute information <NUM>, the non-overlapping information <NUM>, and the signature 212a using the private key <NUM> of the GW <NUM> according to the signature creating procedures defined for the second DID infrastructure <NUM>. The second VC creating unit <NUM> puts the created signature 222c in the second VC 221c.

[Step S406] The second VC creating unit <NUM> outputs the created second VC 221c. For example, the second VC creating unit <NUM> stores the second VC 221c in the second VC storing unit <NUM>.

The second VC 221c with overlapping items removed therefrom is created in this manner.

<FIG> illustrates an example of the second VC with overlapping items removed therefrom. The second VC 221c includes, amongst the items of the first VC <NUM>, copies of items whose item names are not on the attribute item name list. For each of these items, the word "original" is added to the head of the item name.

Next, the process of reconstructing the first VC <NUM> from the second VC 221c is described in detail with reference to <FIG>.

<FIG> is a flowchart illustrating an example of procedures of a first VC reconstructing process according to the fifth embodiment. The process in <FIG> is described below in the order of step numbers.

[Step S411] The first VC reconstructing unit <NUM> acquires the second VC 221c and the attribute item name list.

[Step S412] The first VC reconstructing unit <NUM> rewrites, with the item value of each item name prefixed with "original" in the second VC 221c, the item value of the same item name without "original". For example, the item value of the item name "DID" is rewritten with that of the item name "original DID".

[Step S413] The first VC reconstructing unit <NUM> deletes, from the second VC 221c, each item name prefixed with "original" and its corresponding item value.

[Step S414] The first VC reconstructing unit <NUM> sets the second VC 221c obtained after the deletion in step S413 as the reconstructed first VC <NUM>.

[Step S415] The first VC reconstructing unit <NUM> outputs the reconstructed first VC <NUM>.

Thus, the first VC <NUM> is reconstructed even from the second VC 221c with overlapping items removed therefrom.

The sixth embodiment is directed to enabling transmission of a verification request in a way that is suited for each verifier when the verifier terminal <NUM> requests verification of the first VC <NUM> from verifiers in the first DID infrastructure <NUM>. In that case, a method of sending a verification request is specified for each verifier, for example, in a verifier list.

<FIG> illustrates an example of a verifier list including verification request sending methods. In a verifier list 971a of <FIG>, each DID for the second DID infrastructure <NUM> (i.e., each second DID infrastructure-dedicated DID), the sending method, and the destination are registered in association with the service name of a verifier who verifies VCs in the first DID infrastructure <NUM>. Each field under the item "sending method" contains how to send a verification request. For example, when the verification request sending method is e-mail, "Mail" is entered. On the other hand, "Web" is entered when the verification request sending method is data upload via the Web. Each field under the item "destination" contains a destination of the verification request. When the sending method is "Mail", an e-mail address is entered. When the sending method is "Web", a uniform resource locator (URL) is entered.

With reference to the verifier list 971a, the verifier terminal <NUM> is able to send a verification request in a way that is suitable for each verifier.

<FIG> is a flowchart illustrating an example of procedures of a first VC checking process when sending a verification request by a method specified for each request destination. Note that, amongst the process steps of <FIG>, steps S501 and <NUM>, and steps S504 to S506 are the same as steps S131 and S132, and steps S134 to S136, respectively, in the second embodiment depicted in <FIG>. That is, the only difference from the second embodiment is Step S503, which is as follows.

[Step S503] The first VC checking unit <NUM> sends a verification request to each of the selected n number of verifiers by the corresponding sending method specified in the verifier list 971a.

Thus, a verification request is sent by a sending method specified in advance for each verifier.

According to the second to sixth embodiments, the attribute information on VCs is recognized based on the attribute item name list; however, if it may be recognized in any other way, there is no need to use the attribute item name list. For example, if how to give each item name of attribute information is predetermined in a VC description format, items with item names complying with predetermined rules are determined as attribute information.

While, as described above, the embodiments have been exemplified, the configurations of individual portions illustrated in the embodiments may be replaced with others having the same functions. In addition, other constituent elements or processes may be added thereto. Furthermore, two or more compositions (features) of the embodiments may be combined together.

Claim 1:
A computer program that causes a computer to execute a process comprising:
acquiring a first verifiable credential, VC, (<NUM>) that proves validity of attribute information of a holder by a first signature (8a) verifiable by verification procedures of a first decentralized identifiers, DID, infrastructure (<NUM>) and a second VC (<NUM>) that proves the validity of the attribute information of the holder by a second signature (9a) verifiable by verification procedures of a second DID infrastructure (<NUM>) which have different signature and verification scheme from the first DID infrastructure (<NUM>), the first VC (<NUM>) being issued by an issuer device (<NUM>) that manages the attribute information of the holder, the second VC (<NUM>) being issued, in response to a request for reissuance based on the first VC (<NUM>), by a re-signing device capable of verifying the first signature (8a) contained in the first VC (<NUM>) by the verification procedures of the first DID infrastructure (<NUM>);
verifying the second signature (9a) contained in the second VC (<NUM>) by the verification procedures of the second DID infrastructure (<NUM>);
transmitting a verification request for verifying the first signature (8a) contained in the first VC (<NUM>) to a verification device (7a, 7b) capable of verifying the first signature (8a) contained in the first VC (<NUM>) by the verification procedures of the first DID infrastructure (<NUM>); and
acquiring, from the verification device (7a, 7b), verification results of the first signature (8a) contained in the first VC (<NUM>).