VC issuing system, VC issuance request device, VC issuing device, VC issuing method, VC issuance request generation method, and program

Abstract

A Verifiable Credential (VC) issuing system according to the disclosed technology is for issuing an event VC in which an event involving a plurality of terminals is recorded, and includes a starting point terminal (first terminal), an intermediate terminal ((k)th terminal), an issuance request terminal ((n)th terminal), and a VC issuing server. The first terminal generates first data using one or more verifiable pieces of qualification information possessed by said terminal itself and identification information of the terminal itself. When n is an integer of 3 or greater and k = 2, 3,..., n -1, the (k)th terminal acquires (k-1)th data, generates (k)th data by adding thereto information of said terminal itself and information indicating reception from the (k-1)th terminal, and transmits the (k)th data to the (k+1)th terminal. The (n)th terminal acquires (n-1)th data, and generates an issuance request by adding thereto identification information of said terminal itself and information indicating reception from the (n-1)th terminal. The VC issuing server issues, from the first terminal to the (n)th terminal, an event VC in which an event involving the first through (n)th terminals is recorded, on the basis of the issuance request.

Description

VC issuing system, VC issuing request device, VC issuing device, VC issuing method, VC issuing request generating method, and program

[0001] The disclosed technology relates to generating verifiable credentials.

[0002] The W3C has proposed the Verifiable Credentials Data Model v2.0 (Non-Patent Document 1) with the aim of realizing proactive management of personal information. Hereinafter, Verifiable Credentials will be abbreviated as VC. Figure 1 shows the roles and information flow in the Verifiable Credentials Data Model v2.0. VC is verifiable credential information. VC is issued by an issuer and held by a holder, who then presents it to a verifier. The verifier can verify that the VC was issued by a legitimate issuer by verifying the signature. There are also VC specifications that allow for Verifiable Presentation (VP), in which the holder presents only a portion of the VC (selective disclosure) rather than the entire VC when presenting it to the verifier.

[0003] W3C, "Verifiable Credentials Data Model v2.0", [Retrieved May 28, 2024], Internet<https: / / www.w3.org / TR / vc-data-model-2.0 / > .

[0004] When managing evidence of an event involving multiple parties in a decentralized manner, it is possible to record and manage records of interactions between the parties and connections between multiple parties via an intermediary (introducer) on a distributed ledger. However, transaction fees are incurred for updating the distributed ledger. When managing interaction records using VC, each party must present the facts of their interaction to the issuer and have VC issued, meaning multiple parties must each request the issuance of VC. We would like to realize a VC issuance method that (1) keeps distributed ledger transaction fees low, (2) ensures the reliability of the evidence, (3) maintains records of the involvement of multiple parties, (4) maintains inheritance relationships such as introduction relationships, and (5) allows all parties to verify the same evidence.

[0005] To solve the above problem, the VC issuing system according to the disclosed technology is a system for issuing an event VC recording an event involving multiple terminals, and includes an originating terminal (first terminal), an intermediate terminal (kth terminal), an issuance request terminal (nth terminal), and a VC issuing server. The first terminal generates first data using one or more verifiable credentials held by the first terminal and its own identification information. Where n is an integer greater than or equal to 3, k = 2, 3, ..., n-1, the kth terminal acquires the k-1th data, generates kth data by adding its own identification information and information indicating that it was received from the k-1th terminal, and transmits the kth data to the k+1th terminal. The nth terminal acquires the n-1th data, and generates an issuance request by adding its own identification information and information indicating that it was received from the n-1th terminal. Based on the issuance request, the VC issuing server issues an event VC recording an event involving the nth terminal from the first terminal to the nth terminal.

[0006] If there is no intermediate terminal, the issuance request terminal acquires the first data and generates an issuance request to which its own identification information and information indicating that it was received from the first terminal are added.

[0007] By including information about VC issuance in VC, NFT, or SBT, it is possible to issue VC to multiple parties with a single VC issuance request, triggered by the act of reading.

[0008] A diagram showing roles and information flow in the Verifiable Credentials Data Model v2.0. A diagram showing an example of the configuration of a VC issuing system according to the first embodiment. A functional block diagram showing an example of the configuration of a terminal, a VC issuing server, and a VP reading terminal. A flowchart explaining an example of the operations of a terminal, a VC issuing server, and a VP reading terminal according to the first embodiment. A diagram showing an example of the configuration of a VC issuing system according to a second embodiment. A flowchart explaining an example of the operations of a terminal and a VC issuing server according to the second embodiment. A diagram showing an example of the functional configuration of a computer.

[0009] Hereinafter, embodiments of the disclosed technology will be described in detail. Note that components having the same functions are assigned the same numbers, and duplicated descriptions will be omitted.

[0010] [First Embodiment] In the first embodiment, a VC is simultaneously issued to two terminals jointly involved in a predetermined action. FIG. 2 is a diagram showing an example of the configuration of a VC issuing system according to the first embodiment. In the VC issuing system 20, a read terminal 201, a reading terminal 202, a VC issuing server 203, and a VP reading terminal 204 are communicably connected via a communication network 205. FIG. 3(a) is a functional block diagram showing an example of the configuration of the read terminal 201 and the reading terminal 202. The read terminal 201 and the reading terminal 202 each include an origin data generation unit 211, a data transfer unit 212, an information addition unit 213, a communication unit 214, and a VP generation unit 215. FIG. 3(b) is a diagram showing an example of the configuration of the VC issuing server 203. The VC issuing server 203 includes a communication unit 221, a common VC generation unit 222, and a verification unit 223. FIG. 3(c) is a diagram showing an example of the configuration of the VP reading terminal 204. The VP reading terminal 204 comprises a data transfer unit 231, a communication unit 232, and a verification unit 233. Fig. 4 is a flowchart explaining an example of the operations of the read terminal 202, the reading terminal 201, the VC issuing server 203, and the VP reading terminal 204. The following explanation will be given using Figs.

[0011] [Terminology] NFT: Abbreviation for Non-Fungible Token. Non-fungible digital data created based on blockchain. NFTs come in a variety of forms, and a variety of tangible and intangible things, such as digital art, digital fashion, and game items, have been made into NFTs. SBT: Abbreviation for SoulBound Token. A non-transferable NFT. NFTs are digital assets that exist on the blockchain and are used to prove ownership in fields such as art and games, but because NFTs can be bought, sold, and transferred by anyone, they are not suitable for proving an individual's abilities or background. DID: Abbreviation for Decentralized Identifiers. Like VC, this was proposed by the W3C with the aim of realizing an ID that does not require centralized management.

[0012] The origin data generation unit 211 of the read terminal 201 generates one piece of origin data from information recorded in one or more VCs, NFTs, or SBTs. For example, origin data (origin QR code) is generated using a QR code (registered trademark) (step S401). The origin QR code includes the terminal identifier of the read terminal 201 itself, using a DID or the like, and information indicating that the VC is an additional issue destination (issue destination information). At this time, a signature may be added to prove that the user is the user of the read terminal 201.

[0013] The data exchange unit 212 of the read terminal 201 displays the originating QR code on a liquid crystal screen or the like, and the data exchange unit 212 of the reading terminal 202 reads the originating QR code (step S402). This joint action by the parties is the starting point, and the VC issuance sequence starts.

[0014] The information addition unit 213 of the reading terminal 202 adds the DID of the reading terminal 202 to the information represented by the acquired origin QR code (including the DID of the read terminal 201) to generate a VC issuance request (step S403). At this time, a signature to prove that the user is the reading terminal 202 may be added. The communication unit 214 of the reading terminal 202 transmits the VC issuance request to the VC issuing server 203 (step S404).

[0015] The communication unit 221 of the VC issuing server 203 receives the VC issuance request. The common VC generation unit 222 of the VC issuing server 203 generates a common VC based on the received VC issuance request (step S405). Then, based on the issuance destination information included in the VC issuance request, the common VC is transmitted to the read terminal 201 as well as the reading terminal 202 that requested the issuance (step S406). Normally, a VC is transmitted to one requester, but the VC issuing server 203 acts as the issuer and distributes the same VC to multiple people. Since the VC issuance request includes issuance destination information, the VC issuing server 203 does not need to separately manage which terminals are involved in addition to the terminal that requested the issuance. When issuing a common VC, the VC issuing server 203 may verify the DID in the VC issuance request in the verification unit 223 to confirm the identity of the read terminal 201 and the reading terminal 202. There may be a link with the person on the VC issuing server side (for example, the read terminal 201 and the reading terminal 202 are registered as users of the VC issuing server). The person's identity may be confirmed using another VC.

[0016] The VP generating unit 215 of the read terminal 201 selects necessary items from the received common VC to generate a VP (step S407), and presents it to the VP reading terminal 204 (e.g., a store) using the data sending / receiving unit 212 or the communication unit 214 (step S408). The verification unit 233 of the VP reading terminal 204 verifies the VP presented by the read terminal 201 (step S409), and confirms the identity of the read terminal 201 and its relationship with the reading terminal 202.

[0017] If there is an asymmetric relationship between the read terminal 201 and the reading terminal 202, for example, if user A of the reading terminal 202 is the introducer and user B of the read terminal 201 is the introducee (i.e., user A introduces a store to user B), the relationship between the introducer and the introducee may be recorded in the common VC. In this case, the introducer's signature may be attached. The VP reading terminal 204 can increase the number of loyal customers by verifying that the introduction is from a regular customer (user A). The store can also know which regular introductions are beneficial.

[0018] According to the first embodiment, the social reliability of the VC can be ensured by the reliability of the VC issuing server, and the specific reliability of the read terminal 201 can be ensured by the signature of the reading terminal 202. This concludes the description of the first embodiment. In the above embodiment, transmission data is exchanged by presenting and reading a QR code, but the method of exchanging transmission data is not limited to this as long as it is a means for exchanging information between nearby terminals. For example, two-dimensional barcodes, NFC (Near Field Communication), etc. may also be used.

[0019] [Second Embodiment] In the first embodiment, for ease of understanding, a common VC was issued to two terminals. In the second embodiment, a configuration and procedure for issuing a common VC to a large number of terminals will be described. In addition, after the common VC is issued, the number of parties to a joint action (event) may increase. In such a case, a VC containing information on all parties to the joint action is issued to the additional parties. FIG. 5 is a diagram showing an example of the configuration of a VC issuing system according to the second embodiment. In the VC issuing system 50, n+m terminals (a first terminal 501 to an n+m terminal 507), a first VC issuing server 511, and a second VC issuing server 512 are communicably connected via a communication network 205. Note that 502' to 506' are depicted to make it easy to imagine how a QR code is received, and the next QR code is generated and presented. An example of the functional configuration of each terminal is the same as that shown in FIG. 3(a). An example of the functional configuration of each VC issuing server is also the same as that shown in FIG. 3(b). FIG. 6 is a flowchart explaining an example of the operation of the first terminal to the n+m terminal and the VC issuing servers 511 and 512. 5, 3 and 6, the procedure will be explained below in which the nth terminal 504 requests the first VC issuing server 511 to issue a common VC, then m terminals become further parties, the n+mth terminal 507 requests the second VC issuing server 512 to issue a common VC, and each VC issuing server issues a common VC to multiple terminals.

[0020] [Issuance of First Common VC] The origin data generation unit 211 of the first terminal 501 generates one piece of origin data from information recorded in one or more VCs, NFTs, and SBTs. For example, the origin data (origin QR code) is generated using a QR code (step S601). The origin QR code includes the terminal identifier of the first terminal 501 itself, using a DID or the like, and a list of additional destinations of the VC (destination list). The first terminal itself is registered in the destination list.

[0021] The data exchange unit 212 of the first terminal 501 displays the origin QR code on a liquid crystal screen or the like, and the data exchange unit 212 of the second terminal 502 reads the origin QR code (step S602).

[0022] The information addition unit 213 of the second terminal 502 adds the reading order (first place) and the DID of the second terminal 502 to the information represented by the acquired origin QR code, adds the second terminal itself to the issue destination list, and generates a second QR code (step S603). The data exchange unit 212 of the second terminal 502 displays the second QR code on an LCD screen or the like, and a third terminal (not shown) reads the second QR code. The third terminal adds the reading order (second place) and the DID of the third terminal to the information represented by the acquired second QR code, adds the third terminal itself to the issue destination list, and generates a third QR code.

[0023] Repeating the same procedure, the data transfer unit 212 of the nth terminal 504 reads the (n-1)th QR code presented by the (n-1)th terminal 503 (step S604). The information addition unit 207 of the nth terminal 504 adds the reading order (n-1th place) and the DID of the nth terminal 503 to the information represented by the acquired (n-1)th QR code to generate a first VC issuance request, and sends it to the first VC issuance server 511 by the communication unit 214 (step S605). Note that the first VC issuance request includes information on multiple terminals including the reading route.

[0024] The communication unit 221 of the first VC issuing server 511 receives the first VC issuance request. The common VC generation unit 222 of the first VC issuing server 511 generates the first common VC based on the received first VC issuance request (step S606). Then, based on the issuance destination list included in the first VC issuance request, the first common VC is transmitted not only to the n-th terminal 504 that requested the issuance but also to the first terminal to the n-1-th terminal (step S607).

[0025] The following describes the case where terminals n+1 to n+m join the parties after the issuance of the first shared VC. [Issuance of a Second Shared VC] The nth terminal 504 adds the reading order (n-1th place) and the DID of the nth terminal to the information represented by the acquired n-1th QR code, initializes the issuance destination list, registers the nth terminal itself, and generates the nth QR code (step S608). At this time, the signature of the first VC issuing server may be added to the nth QR code. To do this, for example, the VC issued by the first VC issuing server may be embedded in the nth QR code. The data exchange unit 212 of the nth terminal 504 displays the nth QR code on an LCD screen or the like, and the data exchange unit 212 of the n+1th terminal 505 reads the nth QR code (step S609).

[0026] The same procedure is repeated from the n+1th terminal to the n+mth terminal, and the information addition unit 207 of the n+mth terminal 507 adds the reading order (n+m-1th place) and the DID of the n+mth terminal 507 to the information represented by the acquired (n+m-1)th QR code to generate a second VC issuance request, and sends it to the second VC issuance server 512 via the communication unit 214 (step S612).

[0027] The communication unit 221 of the second VC issuing server 512 receives the second VC issuance request. The common VC generation unit 222 of the second VC issuing server 512 generates a second common VC based on the received second VC issuance request (step S613). Then, based on the issuance destination list included in the second VC issuance request, the second common VC is sent to the n-th terminal to the n+m-1-th terminal in addition to the n+m-th terminal 507 that requested the issuance (step S614).

[0028] The second common VC includes route information from the first terminal to the n-1th terminal, but the destination list described in the second VC issuance request does not list destinations related to the first terminal to the n-1th terminal, so the reliability of the information from the first terminal to the n-1th terminal is ensured by adding a signature from the first VC issuing server or a signature from the nth terminal.

[0029] This concludes the description of the second embodiment. In the above embodiment, transmission data is exchanged by presenting and reading a QR code, but the method of exchanging transmission data is not limited to this as long as it is a means for exchanging information between nearby terminals.

[0030] [Supplementary Note] The common VC generated in the first and second embodiments records an event involving multiple parties, and can be said to be an event record that proves the existence of the event.

[0031] [Program, Recording Medium] The functions realized by the components described in this specification may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (Central Processing Units), conventional circuits, and / or combinations thereof, programmed to realize the described functions. A processor includes transistors and other circuits and is considered to be circuitry or processing circuitry. A processor may be a programmed processor that executes a program stored in a memory.

[0032] In this specification, a circuitry, unit, or means is hardware that is programmed to realize or performs the described functions, which may be any hardware disclosed herein or any hardware known to be programmed to realize or perform the described functions.

[0033] If the hardware is a processor considered to be a type of circuitry, the circuitry, means, or unit is a combination of the hardware and software used to configure the hardware and / or processor.

[0034] The various processes described above can be implemented by loading a program that executes each step of the above method into the recording unit 2020 of the computer 2000 shown in Figure 7, and operating the control unit 2010, input unit 2030, output unit 2040, display unit 2050, etc.

[0035] The program describing the processing contents can be recorded on a computer-readable recording medium, which may be, for example, a magnetic recording device, an optical disk, a magneto-optical recording medium, a semiconductor memory, or any other suitable recording medium.

[0036] The program may be distributed by, for example, selling, transferring, lending, etc. portable recording media such as DVDs and CD-ROMs on which the program is recorded. Furthermore, the program may be stored in a storage device of a server computer, and then transferred from the server computer to other computers via a network, thereby distributing the program.

[0037] A computer that executes such a program may first temporarily store the program recorded on a portable recording medium or transferred from a server computer in its own storage device. Then, when executing a process, the computer reads the program stored on its own recording medium and executes the process in accordance with the read program. Alternatively, the computer may read the program directly from a portable recording medium and execute the process in accordance with the program. Furthermore, the computer may execute the process in accordance with the program each time a program is transferred from a server computer to the computer. Alternatively, the server computer may not transfer the program to the computer, but may instead execute the process through a so-called ASP (Application Service Provider) service, which realizes the processing function by issuing an execution instruction and obtaining the results. Furthermore, the server computer may execute the process at the terminal using a so-called SaaS (Software as a Service) service, which allows users to use part of the server computer along with the program. In this embodiment, the program includes information used for processing by an electronic computer that is equivalent to a program (such as data that is not a direct instruction to a computer but has properties that dictate computer processing).

[0038] Furthermore, in this embodiment, the device is configured by executing a predetermined program on a computer, but at least a part of the processing contents may be realized by hardware.

[0039] 20 VC issuing system 201 Readed terminal 202 Reading terminal 203 VC issuing server 204 VP reading terminal 205 Communication network 211 Starting point data generating unit 212, 231 Data transfer unit 213 Information adding unit 214, 221, 232 Communication unit 215 VP generating unit 222 Common VC generating unit 223, 233 Verification unit 50 VC issuing system 501 First terminal 502 Second terminal 503 (n-1)th terminal 504 nth terminal 505 (n+1)th terminal 506 (n+m-1)th terminal 507 (n+m)th terminal 511 First VC issuing server 512 Second VC issuing server 2000 Computer 2010 Control unit 2020 Recording unit 2030 Input unit 2040 Output unit 2050 Display unit

Claims

1. A system for issuing verifiable event information, comprising: a first terminal that generates first data using one or more verifiable credentials held by the first terminal and its own identification information; a second terminal that acquires the first data and generates an issuance request that adds its own identification information and information indicating that it was received from the first terminal; and a VC issuing server that issues an event VC that records an event in which the first terminal and the second terminal were involved to the first terminal and the second terminal based on the issuance request.

2. A system for issuing verifiable event information, comprising: a first terminal that generates first data using one or more verifiable credentials held by the first terminal and its own identification information; a kth terminal that acquires the k-1th data, where n is an integer greater than or equal to 3 and k=2, 3, ..., n-1, acquires the k-1th data, generates kth data to which its own identification information and information indicating that it was received from the k-1th terminal are added, and transmits the kth data to the k+1th terminal; an nth terminal that acquires the n-1th data, and generates an issuance request to which its own identification information and information indicating that it was received from the n-1th terminal are added; and a VC issuing server that issues an event VC that records an event in which the nth terminal was involved from the first terminal to the nth terminal based on the issuance request.

3. A device that requests a VC issuing server to issue verifiable event information, comprising: a data acquisition unit that receives data including identification information and sequence information of multiple terminals and one or more verifiable qualifications held by the terminal that is the starting point of the sequence; and an information addition unit that adds its own identification information and sequence information to the data to generate a VC issuance request.

4. A VC issuing device comprising: a data acquisition unit that receives a VC issuance request including identification information and sequence information of multiple terminals and one or more pieces of verifiable event information held by the terminal that is the starting point of the sequence; and a VC generation unit that generates an event VC that records an event in which the multiple terminals were involved based on the VC issuance request; and sends the event VC to all of the multiple terminals.

5. A method for a VC issuing system to issue verifiable event information, wherein a first terminal generates first data using one or more verifiable credentials held by the first terminal and identification information of the first terminal; where n is an integer greater than or equal to 3, k=2, 3, ..., n-1, a k-th terminal acquires the k-1th data and generates k-th data to which the identification information of the k terminal and information indicating that it was received from the k-1th terminal are added; the n-th terminal acquires the n-1th data and generates an issuance request to which the identification information of the n terminal and information indicating that it was received from the n-1th terminal are added; and a VC issuing server issues an event VC recording an event in which the n-th terminal was involved from the first terminal to the n-th terminal based on the issuance request.

6. A method for a VC issuance request device to generate a request to issue verifiable event information, wherein a data acquisition unit acquires data including identification information and sequence information of multiple terminals and one or more pieces of verifiable qualification information held by a terminal that is the starting point of the sequence, and an information addition unit adds the identification information and sequence information of the VC issuance request device itself to the data to generate a VC issuance request.

7. A method for a VC issuing device to issue verifiable event information, comprising: a data acquisition unit receiving a VC issuance request including identification information and sequence information of multiple terminals and one or more verifiable credentials held by the terminal that is the starting point of the sequence; a VC generation unit generating an event VC that records an event in which the multiple terminals were involved based on the VC issuance request; and sending the event VC to all of the multiple terminals.

8. A program for causing a computer to function as the VC issuing system according to claim 1 or 2, the VC issuing request device according to claim 3, or the VC issuing device according to claim 4.

Images