VC issue system, VC issue request device, VC issue device, VC issue method, VC issue request generation method, and program
The VC issuing system addresses high transaction fees and reliability issues in decentralized VC management by generating a single VC for multiple parties, using NFTs and SBTs to record interactions and verify identities, thus reducing costs and ensuring reliable evidence sharing.
Patent Information
- Application Number
- PCT/JP2024/020742
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-06-06
- Publication Date
- 2025-12-11
AI Technical Summary
Existing methods for managing verifiable credentials (VCs) in decentralized systems incur high transaction fees on distributed ledgers, require multiple parties to request issuance individually, and lack mechanisms for ensuring evidence reliability and maintaining party relationships.
A VC issuing system that involves an originating terminal, intermediate terminals, and a VC issuing server to generate and distribute a single VC to multiple parties, utilizing NFTs or SBTs to record and verify interactions, ensuring reliability through signature verification and maintaining group relationships.
Reduces distributed ledger transaction fees, ensures reliable evidence management, and maintains group interaction records, allowing verification by non-participating parties.
Smart Images

Figure JP2024020742_11122025_PF_FP_ABST
Abstract
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 to the verifier (selective disclosure), rather than disclosing the entire VC.
[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 through 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 the 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 parties other than the parties to verify the evidence.
[0005] To solve the above problem, the VC issuing system according to the disclosed technology is a system for issuing an event VC that records an event involving multiple terminals, and includes an originating terminal (first terminal), an intermediate terminal (kth terminal), an issuance request terminal (nth terminal), related party terminals (n+1th to n+mth terminals), 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 the identification information of the n+1th to n+mth terminals, 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 that records events in which the first terminal through the n-th terminal are involved to the first terminal through the n+m-th terminal.
[0006] If there is no intermediate terminal, the issuance request terminal acquires the first data and generates an issuance request to which identification information of the issuance request terminal itself and the related party terminal 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, a single VC issuance request can be triggered by the act of reading, allowing VC to be issued to multiple parties in the group to which the party belongs.
[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] Assume that three terminals A, B, and C form a group. In the first embodiment, a VC recording an event in which terminal A and terminal B jointly participated is shared by all of terminals A, B, and C. 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 related party terminal 206, 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 terminal 201, the reading terminal 202, and the related party terminal 206. The read terminal terminal 201, the reading terminal 202, and the related party terminal 206 each include a starting data generation unit 211, a data transfer unit 212, an information addition unit 213, a communication unit 214, a VP generation unit 215, and a terminal identifier storage unit 216. FIG. 3(b) is a diagram showing an example of the configuration of the VC issuing server 203. The VC issuing server 203 comprises a communication unit 221, a common VC generating 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, reading terminal 201, related party terminal 206, VC issuing server 203, and VP reading terminal 204. The following explanation will be given using Figs. 2, 3, and 4.
[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 read terminal 201, the reading terminal 202, and the related party terminal 206 form a group, and the terminal identifiers of the other terminals in the group are acquired in advance using a DID or the like and stored in the terminal identifier storage unit 216 (step S400). 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 it is an additional VC 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 DIDs of the reading terminal 202 and the related party terminal 206 to the information represented by the acquired origin QR code (including the DID of the read terminal 201), includes the related party terminal in the issuance destination information, and generates 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 (step S404). 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 and the related party terminal 206 in addition to the reading terminal 202 that requested the issuance (step S406). Normally, a VC is transmitted to a single requester, but the VC issuing server 203 acts as the issuer and distributes the same VC to multiple parties. Since the VC issuance request includes issuance destination information, the VC issuing server 203 does not need to separately manage which terminals are related in addition to the terminal that requested the issuance. By distributing the VC to people other than the parties involved in the joint action, contact information between individual members of the group can be shared with the entire group. When issuing a shared 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, the reading terminal 202 terminal, and the related party terminal 206. 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 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 is 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 was 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 or near-field communication (NFC) may also be used. In the above embodiment, the DIDs of related terminals not involved in the joint action were included in the issuance request by the reading terminal, but all DIDs of a group consisting of non-reading terminals, reading terminals, and related terminals may be registered in advance in the VC issuing server.
[0019] [Second Embodiment] In the first embodiment, for ease of understanding, a common VC was issued to three terminals. In the second embodiment, a configuration and procedure for issuing a common VC to a large number of terminals will be described. 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 506) and a VC issuing server 511 are communicably connected via a communication network 205. Note that 502' and 503' are drawn 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 of FIG. 3(a). An example of the functional configuration of each VC issuing server is also the same as that of 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 server 511. 5, 3, and 6, the procedure in which the nth terminal 504 requests the VC issuing server 511 to issue a common VC, and the VC issuing server 511 issues the common VC to the 1st terminal through the n+mth terminal will be described below. In the following example, the 1st terminal through the nth terminal are party terminals, and the n+1th terminal through the n+mth terminal are related party terminals.
[0020] The first terminal 501 to the (n+m)th terminal 506 form a group, and the terminal identifiers of the other terminals in the group are acquired in advance using DID or the like and stored in the terminal identifier storage unit 216 (step S600). 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 DID or the like, and a list of additional VC issuers (issuer list). The first terminal itself is registered in the issuer 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), the DID of the nth terminal 503, and the DIDs of the (n+1)th to (n+m)th terminals to the information represented by the acquired (n-1)th QR code, generates a VC issuance request including the related party terminals in the issuance destination list, and sends it to the VC issuance server 511 by the communication unit 214 (step S605). Note that the VC issuance request includes information on multiple terminals including the reading route.
[0024] The communication unit 221 of the VC issuing server 511 receives the VC issuance request. The common VC generation unit 222 of the VC issuing server 511 generates a common VC based on the received VC issuance request (step S606). Then, based on the issuance destination list included in the VC issuance request, the common VC is sent not only to the n-th terminal 504 that is the issuance requester, but also to the first terminal to the n-1-th terminal and the n+1-th terminal to the n+m-th terminal (step S607).
[0025] The above is a description of the second embodiment. In the above embodiment, transmission data was 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. In the above embodiment, the DIDs of related party terminals not involved in the joint action were included in the issuance request by the nth terminal, but all DIDs of the group consisting of the first terminal through the n+mth terminal may be registered in the VC issuing server in advance.
[0026] [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.
[0027] [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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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 a 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).
[0034] 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.
[0035] 20 VC issuing system 201 Read terminal 202 Reading terminal 203 VC issuing server 204 VP reading terminal 205 Communication network 206 Related party terminal 211 Starting point data generating unit 212, 231 Data transfer unit 213 Information adding unit 214, 221, 232 Communication unit 215 VP generating unit 216 Terminal identifier storage 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)th terminal 511 VC issuing server 2000 Computer 2010 Control unit 2020 Recording unit 2030 Input unit 2040 Output unit 2050 Display section
Claims
1. A system for issuing verifiable event information to a group of a first terminal, a second terminal, and a third terminal, 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 the identification information of the third terminal 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, the second terminal, and the third terminal based on the issuance request.
2. A system for issuing verifiable event information to n+m terminals forming a group, wherein when n terminals in the group act together, the VC issuing system includes: a first terminal that generates first data using one or more verifiable credentials that it possesses and its own identification information; a kth terminal, where n is an integer greater than or equal to 3 and k=2, 3, ..., n-1, that 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 sends the kth data to the k+1th terminal; an nth terminal that acquires the n-1th data, and generates an issuance request from itself and the n+1th terminal to which the identification information of the n+mth terminal 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 n+mth terminal based on the issuance request.
3. A device that requests a VC issuance server to issue verifiable event information to a group of terminals, the group consisting of a first terminal group and a VC issuance request device that are involved in a joint action, and a second terminal group that are not involved in the joint action, the VC issuance request device comprising: a data acquisition unit that receives data including identification information and order information of the first terminal group and one or more verifiable qualification information held by the terminal that is the starting point of the order; and an information addition unit that adds the identification information and order information of the VC issuance request device itself and the identification information of the second terminal group to the data to generate a VC issuance request.
4. A device for issuing verifiable event information to a group of terminals, the group consisting of a first group of terminals involved in a joint action and a second group of terminals not involved in the joint action, comprising: a data acquisition unit that receives a VC issuance request including identification information and order information of the first group of terminals, one or more verifiable qualification information held by the terminal that is the origin of the order, and identification information of the second group of terminals; and a VC generation unit that generates an event VC that records an event in which the first group of terminals was involved based on the VC issuance request; and sends the event VC to all of the terminals that make up the group.
5. A method in which a VC issuing system issues verifiable event information to n+m terminals forming a group, when n terminals in the group act together, the VC issuing method comprising: 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 and 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 from the n terminal to which the identification information of the n+mth 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+mth terminal based on the issuance request.
6. A method for generating a request for issuing verifiable event information to a group of terminals by a VC issuance request device, wherein the group consists of a first group of terminals and the VC issuance request device that are involved in a joint action, and a second group of terminals that are not involved in the joint action, a data acquisition unit acquires data including identification information and order information of the first group of terminals and one or more verifiable credentials held by the terminal that is the starting point of the order, and an information addition unit adds the identification information and order information of the VC issuance request device itself and the identification information of the second group of terminals to the data to generate a VC issuance request.
7. A method in which a VC issuing device issues verifiable event information to a group of terminals, the group consisting of a first group of terminals involved in a joint action and a second group of terminals not involved in the joint action, a data acquisition unit receives a VC issuance request including identification information and order information of the first group of terminals, one or more verifiable credentials held by the terminal that is the origin of the order, and identification information of the second group of terminals, a VC generation unit generates an event VC that records an event in which the first group of terminals was involved based on the VC issuance request, and sends the event VC to all of the terminals in the group.
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.
Citation Information
Patent Citations
Digital multisignature system using id information
JP1991103961A
Generation of a non-fungible token
WO2024037870A1