Data management system, service system, and data management method

Abstract

To calculate a charging amount for access to a registry for verifying presentation information.SOLUTION: The first client holds a decryption key for decrypting encrypted presentation information in which presentation information is encrypted, the second client holds the encrypted presentation information, the service system includes a registry in which verification information of the presentation information is stored, receives a request for transmission of the decryption key from the second client, and transmits a request for transmission of the decryption key to the first client in response to the request, On the basis of reception of a response to the transmission request from the first client, the number of uses of the registry by the second client is added to update the registry use trail data, and a charging amount to the user of the second client is determined on the basis of the updated registry use trail data.SELECTED DRAWING: Figure 10

Description

[Technical Field]

[0001] The present invention relates to a data management system, a service system, and a data management method. [Background technology]

[0002] With the use of blockchain technology, a concept called Self-Sovereign Identity (SSI) has emerged as a method of digital identity management. SSI provides self-sovereign identity management in which users can control and selectively disclose identity information such as personal information and certificates, and is attracting attention as one of the elements needed to realize Web 3.0.

[0003] The basic system of SSI includes the following entities: an Issuer that issues certificates, etc.; a Holder that receives and holds the issued certificates, etc.; a Verifier that verifies the certificates when presented with them; and a Verifiable Data Registry (VDR) that holds data, etc. used to verify the certificates.

[0004] Within this basic system, DIDs (Decentralized Identifiers), VCs (Verifiable Credentials), and VPs (Verifiable Presentations) play important roles. Public DID information related to SSI, schema information, and credential definitions are written in the VDR in the DID Document format.

[0005] In traditional paper-based certificate issuance, issuers charge holders an issuance fee and issue certificates in return for the fee. In the Web 3.0 era, in order to put SSI systems into practical use, issuers need to eliminate analog paper-based certificate issuance and promote SSI, which enables digital certificate issuance. To realize an SSI system, a compensation management mechanism that is different from the traditional paper certificate issuance procedures and billing methods is required.

[0006] JP 2019-200556 A (Patent Document 1) is a background technology in this technical field. This publication describes that each of a predetermined number of nodes in a distributed ledger system executes a first smart contract that manages the transaction processing history in the distributed ledger, and executes a second smart contract that calculates, for a managed system jointly used by multiple organizations, at least one of the consumption rate of the managed system by each of the multiple organizations and the contribution rate to the managed system based on the processing history stored in the distributed ledger, and stores the calculation results in the distributed ledger (see Abstract). [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Japanese Patent Application Publication No. 2019-200556 Summary of the Invention [Problem to be solved by the invention]

[0008] The technology described in Patent Document 1 writes participants' system usage history as evidence in a distributed ledger for reward management, and calculates reward amounts and charges from that evidence.

[0009] In SSI systems, the VDR is generally implemented so that it is open to all users of the SSI system. Therefore, when the technology described in Patent Document 1 is applied to calculating charges based on VDR usage history for VP verification, when collecting usage trails of the SSI system, it is not possible to determine whether access to the VDR is for VP verification, and it is not possible to count trails such as the number of times the verifier referenced the VDR for VP verification.

[0010] Therefore, one aspect of the present invention calculates a fee for accessing a registry for verifying presented information. [Means for solving the problem]

[0011] The data management system comprises a first client, a second client, and a service system, wherein the first client holds encrypted presentation information in which presentation information indicating attributes of a user of the first client is encrypted, and a decryption key for decrypting the encrypted presentation information, the service system has a registry in which verification information used to verify the presentation information is stored, and holds registry usage trail data indicating the usage history of the registry by the second client, the first client transmits the encrypted presentation information to the second client, the second client requests the service system to transmit the decryption key, the service system transmits a request to transmit the decryption key to the first client in response to the request, the first client transmits a response to the transmission request to the service system and transmits the decryption key to the second client in response to the transmission request, the service system adds a first count indicating the number of uses of the registry by the second client based on the response, updates the registry usage trail data based on the first count, and determines the amount to be charged to the user of the second client based on the updated registry usage trail data. [Effects of the Invention]

[0012] According to one aspect of the present invention, a charge for accessing a registry for verifying submitted information can be calculated.

[0013] Problems, configurations, and effects other than those described above will become clear from the following description of the embodiments. [Brief explanation of the drawings]

[0014] [Figure 1] 1 is a block diagram showing an example of the configuration of a data management system according to a first embodiment. [Figure 2] 1 is a block diagram illustrating an example of a functional configuration of an SSI service system according to a first embodiment. [Figure 3] FIG. 2 is a block diagram illustrating an example of a functional configuration of an Issuer SSI client according to the first embodiment. [Figure 4] 1 is a block diagram illustrating an example of a functional configuration of a Holder SSI client according to a first embodiment. [Figure 5] FIG. 2 is a block diagram illustrating an example of a functional configuration of a Verifier SSI client according to the first embodiment. [Figure 6] FIG. 2 is a block diagram illustrating an example of the hardware configuration of a computer according to the first embodiment. [Figure 7] FIG. 10 is a diagram illustrating an example of a data configuration of VC usage trail data in the first embodiment. [Figure 8] FIG. 2 is a diagram illustrating an example of the data configuration of VDR usage trail data in the first embodiment. [Figure 9] FIG. 10 is a diagram illustrating an example of the data configuration of payment status trail data in the first embodiment. [Figure 10] FIG. 4 is a sequence diagram illustrating an example of the overall processing by the data management system according to the first embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0015] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. Note that the following description and drawings are examples for explaining the present invention, and appropriate omissions and simplifications have been made for clarity of explanation. Furthermore, not all combinations of features described in the embodiments are necessarily essential to the solution of the invention. The present invention is not limited to the embodiments, and all application examples consistent with the concept of the present invention are included in the technical scope of the present invention. Those skilled in the art can make various additions and modifications to the present invention within the scope of the present invention. The present invention can also be implemented in various other forms. Unless otherwise specified, each component may be plural or singular.

[0016] In the following explanation, various types of information may be described using expressions such as "table," "list," and "queue," but the various types of information may also be expressed using data structures other than these. To indicate that the information is not dependent on the data structure, "XX table," "XX list," etc. may be referred to as "XX information." When describing the content of each piece of information, expressions such as "identification information," "identifier," "name," "ID," and "number" are used, but these are interchangeable.

[0017] A system for storing, managing, and sharing confidential data using a distributed ledger in this embodiment will be described below. [Example]

[0018] 1 is a block diagram showing an example of the configuration of a data management system 1. Participants in the data management system 1 are one or more SSI system administrators, one or more issuers, one or more holders, and one or more verifiers.

[0019] The data management system 1 manages SSI (Self-Sovereign Identity) and also manages rewards to issuers for using VC (Verifiable Credential) and charges to verifiers for using VDR (Verifiable Data Registry).

[0020] The data management system 1 includes, for example, an SSI service system 2 owned by one or more SSI system administrators, an Issuer SSI client 3 (an example of a third client) owned by each of one or more Issuers, a Holder SSI client 4 (an example of a first client) owned by each of one or more Holders, and a Verifier SSI client 5 (an example of a second client) owned by each of one or more Verifiers.

[0021] The SSI service system 2, the Issuer SSI client 3, the Holder SSI client 4, and the Verifier SSI client 5 are connected to one another via a network 10 such as the Internet. Each of the Issuer, Holder, and Verifier has one or more users who operate their own clients.

[0022] The SSI service system 2 is realized by a public blockchain system or a permissioned blockchain system using an existing framework such as Hyperledger (registered trademark) Indy or Hyperledger (registered trademark) Aries, and the VDR is implemented on the blockchain.

[0023] Furthermore, the SSI management process in the data management system 1 is implemented by an existing framework such as Hyperledger (registered trademark) Indy or Hyperledger (registered trademark) Aries. The SSI management process includes, for example, a VDR management process by the SSI service system 2, a VC issuance process by the Issuer SSI client 3 to the Holder SSI client 4, a VP (Verifiable Presentation) generation process by the Holder SSI client 4 and a VP presentation process to the Verifier SSI client 5, a VP verification process by the Verifier SSI client 5, and a wallet management process by the Issuer SSI client 3, the Holder SSI client 4, and the Verifier SSI client 5.

[0024] 2 is a block diagram showing an example of the functional configuration of the SSI service system 2. The SSI service system 2 is, for example, a blockchain system including multiple SSI service nodes 20 scattered across multiple bases.

[0025] The SSI service node 20 has, for example, functional units such as a VDR management unit 2011, a VDR usage control unit 2012, a VC usage count management unit 2013, a VC usage trail management unit 2014, a VDR usage trail management unit 2015, and a payment status management unit 2016. The programs for operating each functional unit of the SSI service node 20 are implemented, for example, by smart contracts on the blockchain (written in the distributed ledger 2020).

[0026] The SSI service node 20 also has a distributed ledger 2020 implemented by a blockchain. The distributed ledger 2020 holds data written by each functional unit implemented by a smart contract. The distributed ledger 2020 stores, for example, a VDR 2021, VC usage trail data 2022, VDR usage trail data 2023, and payment status trail data 2024.

[0027] The VDR management unit 2011 registers data in the VDR 2021 in response to requests from the Issuer SSI client 3, Holder SSI client 4, and Verifier SSI client 5, or obtains data from the VDR 2021 and sends it to the client.

[0028] The VDR usage control unit 2012 controls the use of the VDR 2021 for VP verification by the Verifier SSI client 5. The VDR usage control unit 2012 counts the number of times the VDR 2021 is used for VP verification by the Verifier SSI client 5, and generates evidence indicated by the count.

[0029] The VC usage count management unit 2013 counts the number of times a VC issued by each Issuer SSI client 3 has been used and generates a trail indicating the count. The VC usage trail management unit 2014 updates the VC usage trail data 2022 based on the trail generated by the VC usage count management unit 2013. The VDR usage trail management unit 2015 updates the VDR usage trail data 2023 based on the trail generated by the VDR usage control unit 2012.

[0030] The payment status management unit 2016 determines the amount of remuneration to the Issuer by referring to the VC usage trail data 2022, and determines the amount to be charged to the Verifier by referring to the VDR usage trail data 2023. The payment status management unit 2016 generates information indicating the payment status, including the payment status of remuneration to the Issuer and the collection status of charges from the Verifier, and updates the payment status trail data 2024.

[0031] The VDR 2021 holds, for example, DIDs (Decentralized Identifiers) that identify each Issuer, each Holder, and each Verifier, and information necessary for VP verification processing by the Verifier (for example, the public key of the key pair associated with the DID). Note that each Issuer, each Holder, and each Verifier may hold multiple DIDs.

[0032] The VC usage trail data 2022 holds a trail showing the number of times a VC issued by each Issuer SSI client 3 has been used. The VDR usage trail data 2023 holds a trail showing the number of times each Verifier SSI client 5 has used the VDR 2021 for VP verification. The payment status trail data 2024 holds a trail showing the payment status, including the payment status of remuneration to the Issuer and the collection status of charges from the Verifier.

[0033] In addition, the SSI service system 2 may be composed of a single SSI service node 20 (i.e., the SSI service system 2 may be equivalent to the SSI service node 20), in which case, since the SSI service system 2 is not a blockchain system, each data does not need to be written to the distributed ledger 2020, and each functional unit does not need to operate by a smart contract.

[0034] 3 is a block diagram showing an example of the functional configuration of the issuer SSI client 3. The issuer SSI client 3 includes, for example, a user interface unit 3011 and an issuer SSI processing unit 3012, both of which are functional units.

[0035] The issuer SSI client 3 includes, for example, an SSI DB (DataBase) 3020. The SSI DB 3020 stores, for example, a wallet 3021 and log data 3022.

[0036] The user interface unit 3011 controls the user interface of the Issuer SSI client 3 (for example, displays the user interface and accepts input via the user interface).

[0037] The Issuer SSI processing unit 3012 executes the processing of SSI management that is to be performed by the Issuer SSI client 3. Specifically, for example, in response to a request from a Holder SSI client 4, the Issuer SSI processing unit 3012 issues a VC (an example of credential information) including attribute information of the Holder and the DID of the Issuer, assigns a digital signature to the VC using a private key in a key pair linked to the Issuer's DID, and sends the digital signature to the Holder SSI client 4. Also, for example, the Issuer SSI processing unit 3012 sends information related to the issuance of the VC to the SSI service system 2 and requests that it be registered in the VDR 2021.

[0038] The wallet 3021 stores, for example, the issuer's DID, the private key of the key pair associated with the DID, and VCs previously issued by the issuer SSI processing unit 3012. The log data 3022 stores, for example, a log of the processing performed by the issuer SSI client 3.

[0039] 4 is a block diagram showing an example of the functional configuration of the Holder SSI client 4. The Issuer SSI client 3 has, for example, a user interface unit 4011, a Holder SSI processing unit 4012, a key pair generation unit 4013, a key management unit 4014, and a VC usage trail writing unit 4015, all of which are functional units.

[0040] The Holder SSI client 4 includes, for example, an SSI DB 4020. The SSI DB 4020 stores, for example, a Wallet 4021 and log data 4022.

[0041] The user interface unit 4011 controls the user interface of the Holder SSI client 4. The Holder SSI processing unit 4012 executes the processing of SSI management processing that is to be performed by the Holder SSI client 4. Specifically, for example, the Holder SSI processing unit 4012 selects necessary attribute information from the attribute information of the Holder included in one or more VCs issued by the Issuer SSI client 3, for example, according to input from the Holder, and generates a VP (an example of presentation information) that includes the digital signature of the Issuer SSI client 3 and the DID of the Issuer included in the VC, the selected attribute information, and the DID of the Holder. Furthermore, the Holder SSI processing unit 4012 affixes a digital signature to the generated VP using a private key in a key pair linked to the Holder's DID, and then transmits the VP to the Verifier SSI client 5.

[0042] The key pair generation unit 4013 generates a key pair of a private key and a public key used for VC usage management and VDP usage management. The key management unit 4014 encrypts the VP with the public key in the key pair generated by the key pair generation unit 4013. In addition, the key management unit 4014 transmits the private key (an example of a decryption key) in the key pair generated by the key pair generation unit 4013 to the Verifier SSI client 5 (which verifies the VP) in response to a request from the SSI service system 2. The VC usage trail writing unit 4015 requests the SSI service system 2 to count the VC usage history.

[0043] The Wallet 4021 stores, for example, the Holder's DID, the private key of the key pair associated with the DID, and VCs previously received from the Issuer SSI client 3. The log data 4022 stores, for example, a log of processing performed by the Holder SSI client 4.

[0044] 5 is a block diagram showing an example of the functional configuration of the Verifier SSI client 5. The Verifier SSI client 5 has, for example, a user interface unit 5011, a Verifier SSI processing unit 5012, a private key request unit 5013, and a VP decryption unit 5014, which are all functional units.

[0045] The Verifier SSI client 5 includes, for example, an SSI DB 5020. The SSI DB 5020 stores, for example, a wallet 5021 and log data 5022.

[0046] The user interface unit 5011 controls the user interface of the Verifier SSI client 5. The Verifier SSI processing unit 5012 executes the SSI management processing that is performed by the Verifier SSI client 5. Specifically, for example, the Verifier SSI processing unit 5012 requests the SSI service system 2 to transmit a public key linked to the DID of the Issuer indicated by the VP received from the Holder SSI client 4 and a public key for the DID of the Holder indicated by the VP. The Verifier SSI processing unit 5012 verifies the digital signature of the Issuer indicated by the VP using the public key linked to the DID of the Issuer, and verifies the digital signature of the Holder indicated by the VP using the public key linked to the DID of the Holder.

[0047] The private key request unit 5013 requests the SSI service system 2 to transmit the private key used to encrypt the VP by the key management unit 4014 of the Holder SSI client 4. The VP decryption unit 5014 decrypts the encrypted VP.

[0048] The Wallet 5021 stores, for example, the Verifier's DID, the private key of the key pair associated with the DID, and VPs previously received from the Holder SSI client 4. The log data 5022 stores, for example, a log of the processing performed by the Verifier SSI client 5.

[0049] 6 is a block diagram showing an example of the hardware configuration of the computer 100. Each of the SSI service node 20, the Issuer SSI client 3, the Holder SSI client 4, and the Verifier SSI client 5 is configured by the computer 100.

[0050] The computer 100 includes a CPU (Central Processing Unit) 101, a memory 102, an auxiliary storage device 103, a communication device 104, an input device 105, and a display device 106, which are connected to one another by an internal communication line such as a bus.

[0051] The CPU 101 is an example of a processor, and executes programs stored in the memory 102. The memory 102 includes a ROM (Read Only Memory), which is a nonvolatile storage element, and a RAM (Random Access Memory), which is a volatile storage element. The ROM stores unchanging programs (e.g., a BIOS (Basic Input / Output System)). The RAM is a high-speed, volatile storage element such as a DRAM (Dynamic Random Access Memory), and temporarily stores programs executed by the CPU 101 and data used when the programs are executed.

[0052] The auxiliary storage device 103 is a large-capacity, non-volatile storage device such as a magnetic storage device (HDD (Hard Disk Drive)) or a flash memory (SSD (Solid State Drive)), and stores programs to be executed by the CPU 101 and data to be used when the programs are executed. That is, the programs are read from the auxiliary storage device 103, loaded into the memory 102, and executed by the CPU 101.

[0053] The communication device 104 is a network interface device that controls communication with other computers 100 according to a predetermined protocol. The communication device 104 may also include a serial interface such as a USB (Universal Serial Bus).

[0054] The input device 105 is a device such as a keyboard or mouse that receives input from an operator. The display device 106 is a device such as a display or printer that outputs the results of program execution in a format that can be viewed by the operator.

[0055] A part or all of the programs executed by the CPU 101 may be provided to the computer 100 from a removable medium (such as a CD-ROM or flash memory) which is a non-transitory storage medium, or from an external computer equipped with a non-transitory storage device via the network 10, and may be stored in the non-volatile auxiliary storage device 103 which is a non-transitory storage medium. For this reason, the computer 100 may have an interface for reading data from removable media.

[0056] The SSI service node 20 is a computer system configured on one physical computer 100 or on multiple logically or physically configured computers 100, and may operate in separate threads on the same computer 100, or may operate on a virtual computer constructed on multiple physical computer resources. The same applies to the Issuer SSI client 3, Holder SSI client 4, and Verifier SSI client 5.

[0057] The CPU 101 of the computer 100 constituting the SSI service node 20 includes each functional unit of the SSI service node 20. This also applies to the Issuer SSI client 3, the Holder SSI client 4, and the Verifier SSI client 5.

[0058] For example, the CPU 101 of the computer 100 constituting the SSI service node 20 functions as a VDR management unit 2011 by operating in accordance with a VDR management program loaded into memory 102 of the computer 100 constituting the SSI service node 20, and functions as a VDR usage control unit 2012 by operating in accordance with a VDR usage control program loaded into memory 102 of the computer 100 constituting the SSI service node 20.

[0059] The same relationship exists between the programs and the functional units of the other functional units included in the CPU 101 of the computer 100 that constitutes the SSI service node 20. The same relationship exists between the programs and the functional units included in the CPU 101 of the computer 100 that constitutes the Issuer SSI client 3, the CPU 101 of the computer 100 that constitutes the Holder SSI client 4, and the CPU 101 of the computer 100 that constitutes the Verifier SSI client 5, which will be described later.

[0060] In addition, some or all of the functions of the functional units included in the SSI service node 20, Issuer SSI client 3, Holder SSI client 4, and Verifier SSI client 5 may be realized by dedicated circuits such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field-Programmable Gate Array).

[0061] The auxiliary storage device 103 of the computer 100 constituting the SSI service node 20 provides a storage area for realizing the distributed ledger 2020. The auxiliary storage device 103 of the computer 100 constituting the Issuer SSI client 3 provides a storage area for realizing the SSI DB 3020. The auxiliary storage device 103 of the computer 100 constituting the Holder SSI client 4 provides a storage area for realizing the SSI DB 4020. The auxiliary storage device 103 of the computer 100 constituting the Verifier SSI client 5 provides a storage area for realizing the SSI DB 5020.

[0062] In addition, some or all of the information of the data held by the SSI service node 20, Issuer SSI client 3, Holder SSI client 4, and Verifier SSI client 5 shown in Figures 2 to 5 may each be stored in memory 102 or in an external database server, etc.

[0063] 7 is a diagram showing an example of the data configuration of the VC usage trail data 2022. The VC usage trail data 2022 is data that is read and written by the VC usage trail management unit 2014.

[0064] The VC usage trail data 2022 includes, for example, columns 70 and 71. Column 70 indicates an identifier for identifying an Issuer. Column 71 indicates the number of times a VC issued by the Issuer has been used (for example, the number of times VP verification has been performed by a Verifier), for each Issuer. In the example of FIG. 7, column 71 indicates the most recent VC usage count and the VC usage count from the immediately preceding timing.

[0065] In addition, the VC usage trail data 2022 may store a weight for determining the reward to the Issuer, and in this case, the number of times the issued VC has been used may be shown for each combination of the Issuer and the importance. The importance of the issued VC and the cost incurred in issuing the VC are both examples of the weight.

[0066] 8 is a diagram showing an example of the data configuration of the VDR usage trail data 2023. The VDR usage trail data 2023 is data that is read and written by the VDR usage trail management unit 2015.

[0067] The VDR usage trail data 2023 includes, for example, columns 80 and 81. Column 80 indicates an identifier that identifies the verifier. Column 81 indicates the number of times the verifier has used the VDR (for example, the number of times the verifier referenced data written in the VDR to perform VP verification presented by the holder). In the example of FIG. 8, column 81 indicates the most recent number of times the VDR was used and the number of times the VDR was used one time before.

[0068] 9 is a diagram showing an example of the data configuration of the payment status trail data 2024. The payment status trail data 2024 is data that is read and written by the payment status management unit 2016.

[0069] The payment status trail data 2024 includes, for example, columns 90 and 91. Column 90 shows identifiers for identifying the Issuer, Verifier, and SSI system administrator. Column 91 shows the payment status. Specifically, for example, column 91 shows the amount of remuneration to the Issuer calculated from the VC usage trail data 2022, the amount charged to the Verifier calculated from the VDR usage trail data 2023, and the amount of intermediate margin etc. paid to the SSI system administrator calculated from the VC usage trail data 2022 and the VDR usage trail data 2023, as well as the payment status of these amounts.

[0070] Fig. 10 is a sequence diagram showing an example of the overall processing by the data management system 1. Before the processing in Fig. 10 starts, it is assumed that the Issuer SSI client 3 issues a VC to the Holder SSI client 4, and the Holder SSI client 4 generates a VP based on the issued VC.

[0071] 10 starts, the Holder SSI client 4 has already stored the VC in the Wallet 3021. Also, before the processing in Fig. 10 starts, the schema information and credential definition information related to the VC have already been stored in the VDR 2021 in the SSI service system 2.

[0072] The Verifier SSI client 5 acquires information regarding the unpaid usage fee (billing amount) for the Verifier indicated by the payment status trail data 2024 from the SSI service system 2, settles the unpaid usage fee, and requests the SSI service system 2 to update the payment status (S10). The payment status management unit 2016 acquires information indicating the payment status and updates the payment status trail data 2024 based on that information (S11).

[0073] In addition, for example, payments to the Verifier, compensation to the Issuer, and the intermediate margin earned by the SSI system administrator are settled by, for example, bank transfer or cryptocurrency transaction.

[0074] The Verifier SSI processing unit 5012 of the Verifier SSI client 5 requests the Holder SSI client 4 to present the VP (S12). The key pair generation unit 4013 of the Holder SSI client 4 generates a key pair of a public key and a private key according to a predetermined algorithm of public key encryption (S13). The key management unit 4014 of the Holder SSI client 4 encrypts the VP using the public key generated in step S13 (S14).

[0075] The VC usage trail writing unit 4015 of the Holder SSI client 4 sends a report indicating that the VCs used to generate the VP encrypted in step S14 have been used, the report including the identifier of the Issuer that generated each of the VCs, to the SSI service system 2 (S15). The VC usage count management unit 2013 of the SSI service system 2 increments the count of the VC usage history corresponding to the Issuer identifier indicated in the report sent in step S15 (S16). Note that if multiple VCs of a certain Issuer were used to generate the VP, the VDR usage control unit 2012 adds the count of the VC usage history of the Issuer by the number of those VCs.

[0076] In addition, if the importance and / or issuance cost of the VC are described in the VC, in step S15, the VC usage trail writing unit 4015 of the Holder SSI client 4 also sends the importance and / or issuance cost to the SSI service system 2, and in step S16, the VC usage count management unit 2013 increments the count of the VC usage history corresponding to the importance and / or issuance cost and the Issuer identifier.

[0077] The Holder SSI processing unit 4012 of the Holder SSI client 4 transmits the VP encrypted in step S14 to the Verifier SSI client 5 that transmitted the presentation request in step S12 (S17).

[0078] The private key request unit 5013 of the Verifier SSI client 5 sends a private key transmission request to the SSI service system 2, which transmission request includes the Holder identifier of the Holder SSI client 4 that submitted the encrypted VP and the identifier of the Verifier (S18). The VDR usage control unit 2012 of the SSI service system 2 performs payment information determination for the Verifier SSI client 5 that sent the private key request (S19).

[0079] In determining the payment information in step S19, the VDR usage control unit 2012 requests the VC usage count management unit 2013 to send information indicating the payment status of the verifier corresponding to the verifier SSI client 5 that sent the request to send the private key. The payment status management unit 2016 obtains the payment status of the verifier from the payment status trail data 2024 and sends it to the VDR usage control unit 2012 (S20).

[0080] If the VDR usage control unit 2012 determines that the Verifier has an unpaid billing amount by referring to the payment status of the Verifier (S19: FALSE), it outputs an error and terminates the process (S21). The VDR usage control unit 2012 may output the error to the Holder SSI client 4 and the Verifier SSI client 5. Even if the process terminates with an error in step S21, it is desirable to execute the process of step S27 described below.

[0081] If the VDR usage control unit 2012 determines by referring to the payment status of the verifier that all charges for the verifier have been paid (S19: TRUE), it sends a private key transmission request to the Holder SSI client 4 (S22). The Holder SSI client 4 receives the private key transmission request sent in step S22 (S23).

[0082] The key management unit 4014 of the Holder SSI client 4 sends an approval notice indicating that the request to send the private key has been approved to the SSI service system 2, which approval notice includes the Verifier identifier of the Verifier SSI client 5 to which the private key is to be sent and the number of VCs used to generate the VP (S24), sends the private key of the key pair generated in step S13 to the Verifier SSI client 5 (S26), and deletes the private key (S27).

[0083] The VP decryption unit 5014 of the Verifier SSI client 5 decrypts the encrypted VP using the private key sent in step S26 (S28). Note that, after the processing of step S28 is completed, it is desirable that the VP decryption unit 5014 of the Verifier SSI client 5 deletes the private key.

[0084] The Verifier SSI processing unit 5012 of the Verifier SSI client 5 requests the SSI service system 2 to obtain and transmit the information necessary for VP verification from the VDR 2021, and upon receiving the information necessary for VP verification, verifies the VP decrypted in step S28 using that information (S29). From step S29 onwards, the Verifier SSI processing unit 5012 of the Verifier SSI client 5 performs known processing in the SSI system as necessary.

[0085] The SSI service system 2 receives the permission notice sent in step S24 (S25). When the VDR usage control unit 2012 of the SSI service system 2 receives the permission notice in step S25, it increments the count of the VDR usage history corresponding to the Verifier identifier indicated in the permission notice received in step S25 (S30). Note that if multiple VCs are used to generate the VP, the VDR usage control unit 2012 adds the count of the VDR usage history by the number of those VCs.

[0086] When a predetermined trigger occurs, the VDR usage control unit 2012 sends a trail indicating the count value of each verifier's VDR usage history to the VDR usage trail management unit 2015 (S31). Specifically, for example, the VDR usage control unit 2012 may send the trail every time a predetermined time has elapsed, or may send the trail every time the VDR usage history count value reaches a predetermined value (for example, every time the total number of usages of all verifiers reaches a predetermined value, or every time the number of usages of each of all verifiers reaches a predetermined value). Following step S31, the VDR usage control unit 2012 initializes (for example, updates to 0) the count value of each verifier's VDR usage history (S32).

[0087] When a predetermined opportunity arrives, the VC usage count management unit 2013 transmits a trail indicating the count value of the usage history in which the VC of each issuer has been used to the VC usage trail management unit 2014 (S33). Specifically, for example, the VC usage count management unit 2013 may transmit the trail every time a predetermined time has elapsed, or may transmit the trail every time the count value of the VC usage history reaches a predetermined value (for example, every time the total value of the usage counts of all issuers reaches a predetermined value, or every time the usage count of each of all issuers reaches a predetermined value). Following step S33, the VC usage count management unit 2013 initializes (for example, updates to 0) the count value of the VC usage history corresponding to each issuer (S36).

[0088] In order to make it difficult to link VC usage with VDR usage (i.e., to link which issuer's VC-based VP was presented to which verifier), it is desirable that the predetermined time and the predetermined value in steps S31 and S33 be sufficiently large. For example, the predetermined time is determined based on an actual or estimated value of the number of past VC usages or VDR usages per unit time (e.g., the time until the actual or estimated value reaches a predetermined value is determined as the predetermined time). Furthermore, the predetermined triggers in steps S31 and S33 may be different (e.g., the predetermined time or the predetermined value may be different, or one may be a trigger based on time and the other based on a count value), or they may be the same.

[0089] The VC usage trail management unit 2014 updates the VC usage trail data 2022 based on the trail sent in step S33 (S34). Specifically, for example, the VC usage trail management unit 2014 calculates the sum of the value of the latest VC usage count for each Issuer indicated in column 71 of the VC usage trail data 2022 and the count value indicated by the trail sent in step S33, determines the value of the latest VC usage count as the new value of the VC usage count at the timing immediately before, and determines the calculated sum as the new value of the latest VC usage count.

[0090] The VDR usage trail management unit 2015 updates the VDR usage trail data 2023 based on the trail sent in step S31 (S35). Specifically, for example, the VDR usage trail management unit 2015 calculates the sum of the value of the most recent VDR usage count for each verifier indicated in column 81 of the VDR usage trail data 2023 and the count value indicated by the trail sent in step S31, determines the value of the most recent VDR usage count as the new value of the VDR usage count at the previous timing, and determines the calculated sum as the new value of the most recent VDR usage count.

[0091] The payment status management unit 2016 of the SSI service system 2 calculates the amount of compensation to the Issuer and the amount charged to the Verifier based on the VC usage trail data 2022 updated in step S34 and the VDR usage trail data 2023 updated in step S35, and stores the calculated values ​​in the payment status trail data 2024 (S37).

[0092] Specifically, for example, the payment status management unit 2016 determines, for each issuer, the value obtained by subtracting the value of the number of VC usages at the immediately preceding timing from the value of the most recent number of VC usages, multiplying the result by a predetermined value, as the amount of remuneration to that issuer. Also, for example, the payment status management unit 2016 determines, for each verifier, the value obtained by subtracting the value of the number of VDR usages at the immediately preceding timing from the value of the most recent number of VDR usages, multiplied by a predetermined value, as the amount of charge to that verifier.

[0093] Also, for example, the payment status management unit 2016 may further calculate the margin to be paid to the SSI system administrator in step S37 and store the calculated value in the payment status trail data 2024. Specifically, for example, the payment status management unit 2016 determines the margin to be paid to the SSI system administrator to be a value obtained by subtracting the total number of VC usages at the immediately previous timing from the latest total number of VC usages indicated by the VC usage trail data 2022, and multiplying this value by a predetermined value (or a value obtained by subtracting the total number of VDR usages at the immediately previous timing from the latest total number of VDR usages indicated by the VDR usage trail data 2023, and multiplying this value by a predetermined value).

[0094] In the example of Figure 10, the private key is sent directly from the Holder SSI client 4 to the Verifier SSI client 5, but the private key may also be sent from the Holder SSI client 4 to the Verifier SSI client 5 via the SSI service system 2.

[0095] 10 in this case will be described. The key management unit 4014 of the Holder SSI client 4 calculates a hash value of the private key in the key pair generated in step S13. In step S17, the Holder SSI processing unit 4012 sends the encrypted VP and the hash value to the Verifier SSI client 5, and further sends the private key and the hash value to the SSI service system 2. Then, the processing of steps S23, S24, and S26 by the Holder SSI client 4 is omitted.

[0096] In step S18, the private key request unit 5013 of the Verifier SSI client 5 includes the received hash value in the private key request. In step S21, in addition to outputting an error, the VDR usage control unit 2012 identifies a hash value received from the Holder SSI client 4 that matches the hash value included in the private key request, and deletes the private key corresponding to the identified hash value.

[0097] In step S19, if the VDR usage control unit 2012 determines that all charges for the Verifier whose payment information is being judged have been paid, it identifies the hash value received from the Holder SSI client 4 that matches the hash value included in the private key request, sends the private key corresponding to the identified hash value to the Verifier SSI client 5, and deletes the private key. Steps S22 and S25 are omitted.

[0098] 10, the VP is encrypted and decrypted using a public key encryption algorithm, but the VP may be encrypted and decrypted using a predetermined common key encryption algorithm. In this case, a common key is generated in step S13, and the private key and public key in steps S14, S18, and S22 to S28 are replaced with the common key.

[0099] In the example of Figure 10, the VC usage reporting process of step S15, which is the trigger for the VC usage history counting process of step S16, is executed following the process of step S14, but the process of step S15 may be executed at any timing between after the process of step S13 is executed and before the process of step S26 is executed.

[0100] Furthermore, in generating the key pair in step S13, a predetermined biometric authentication algorithm such as PBI (Public Biometric Infrastructure) may be used instead of a public key encryption algorithm. For example, when the PBI algorithm is used, in step S13, the Holder SSI client 4 acquires the Holder's biometric information, generates a key pair of a private key and a public key by performing one-way transformation on the biometric information, and deletes the private key. Furthermore, in step S26, the Holder SSI client 4 acquires the Holder's biometric information, generates a private key by performing one-way transformation on the biometric information, and transmits the generated private key to the Verifier SSI client 5.

[0101] Furthermore, for example, the CPU 101 of the computer 100 constituting the SSI service node 20 may have a TEE (Trusted Execution Environment), and the CPU 101 may use the TEE to create a trusted area in the memory 102 of the computer 100, which is a hardware storage area and is isolated from other areas (security is ensured). In this case, processing by at least one of the VDR usage control unit 2012, the VC usage count management unit 2013, the VC usage trail management unit 2014, and the VDR usage trail management unit 2015 may be executed within the trusted area. In other words, at least one of the VC usage trail data 2022, the VDR usage trail data 2023, and the payment status trail data 2024 is encrypted outside the trusted area, and when processing using this data is performed, the data is decrypted within the trusted area before the processing is performed, and after the processing is performed, the data is re-encrypted and written outside the trusted area. This allows the VC usage trail, the VDR usage trail, and / or the payment status, etc., to be kept confidential.

[0102] In this embodiment, the SSI service system 2 manages both the VC usage trail and the VDR usage trail, but it may manage only one of them. If the SSI service system 2 manages only the VC usage trail, the processes of steps S10, S11, S19, S20, S21, S24, S25, S30, S31, S32, and S35 are not required, and the amount charged to the verifier is not calculated in step S37 (i.e., the verifier is not charged).

[0103] Furthermore, if the SSI service system 2 only manages VDR usage trails, the processing of steps S15, S16, S33, S34, and S36 is unnecessary, and the amount of remuneration to the Issuer is not calculated in step S37 (i.e., no remuneration is paid to the Issuer).

[0104] As described above, this embodiment relates to a method for managing the number of times a Verifier uses a VDR, and in particular to a system and method for realizing the safe management of private keys and the transparent handling of usage fees in the process of presenting and verifying a VP.

[0105] In this embodiment, in steps S13 and S14, when the Holder SSI client 4 presents a VP, a temporary key pair is generated and the VP is encrypted using the open key in that key pair, thereby ensuring the security of the VP contents.

[0106] Furthermore, the Holder SSI client 4 submits the encrypted VP to the Verifier SSI client 5, and in step S15 notifies the VC usage count management unit 2013 of the information of the Issuer that issued the VC used to generate the VP, and the VC usage count management unit 2013 increments the count indicating that the VC of that Issuer has been used. This allows the VC usage history to be properly managed, and enables the SSI system administrator to monitor the VC usage history.

[0107] Furthermore, the settlement status management unit 2016 uses smart contracts to manage the remuneration paid to the issuer, the fee charged to the verifier, and the intermediate margin paid to the system administrator, as well as the management of these settlements.In order for the verifier SSI client 5 to obtain the private key for decrypting the encrypted VP, in step S19 the VDR usage control unit 2012 checks whether the verifier has paid the usage fee (fee).

[0108] If it is confirmed that the Verifier has paid the usage fee, the VDR usage control unit 2012 requests the Holder SSI client 4 to send the private key, and the Holder SSI client 4 sends the private key to the Verifier SSI client 5 in accordance with the request, allowing the Verifier SSI client 5 to decrypt the encrypted VP and perform VP verification.

[0109] When the Holder SSI client 4 notifies the VDR usage control unit 2012 of its approval for the request to send the private key, the VDR usage control unit 2012 increments the count of the number of times the VDR has been used by the Verifier to which the private key is to be sent. This allows the VDR usage status by each Verifier to be accurately tracked.

[0110] In this embodiment, the verifier is charged, but the holder, who is a general user, is not charged, which makes it easier for holders, including the majority of general users, to understand the system and ultimately promotes the widespread issuance of digital certificates using SSI.

[0111] Furthermore, in this embodiment, the VC usage history counted by the VC usage count management unit 2013 and the VDR usage history counted by the VDR usage control unit 2012 are not reflected in the VC usage trail data 2022 and the VDR usage trail data 2023 each time they are counted, but are reflected after a predetermined opportunity arrives (after a sufficiently long predetermined time has passed and the count value has reached a sufficiently large predetermined value). As a result, even if the VC usage trail data 2022 and the VDR usage trail data 2023 are referenced by a third party, it is difficult for the third party to guess which Issuer issued the VC (VP generated from it) that was presented to which Verifier.

[0112] In this way, this embodiment can significantly improve the reliability and efficiency of digital identity management by realizing secure presentation and verification of VP, secure management of private keys, and transparent management of usage fees and incentives.

[0113] The present invention is not limited to the above-described embodiments, but includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

[0114] Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations, functions, etc. may also be implemented in software, with a processor interpreting and executing a program that implements each function. Information such as the programs, tables, and files that implement each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.

[0115] In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected. [Explanation of symbols]

[0116] 1 Data management system, 2 SSI service system, 3 Issuer SSI client, 4 Holder SSI client, 5 Verifier SSI client, 100 Computer, 101 CPU, 102 Memory, 103 Auxiliary storage device, 104 Communication device, 2011 VDR management unit, 2012 VDR usage control unit, 2013 VC usage count management unit, 2014 VC usage trail management unit, 2015 VDR usage trail management unit, 2015, 2016 Payment status management unit, 2021 VDR, 2022 VC usage trail data, 2023 VDR usage trail data, 2024 Payment status trail data, 4014 Key management unit, 4015 VC usage trail writing unit, 5013 Private key request unit, 5014 VP decryption unit

Claims

1. 1. A data management system comprising: A first client, a second client, and a service system, the first client holds encrypted presentation information in which presentation information indicating an attribute of a user of the first client is encrypted, and a decryption key for decrypting the encrypted presentation information; The service system includes: a registry storing verification information used to verify the presented information; maintaining registry usage trail data indicating a usage history of the registry by the second client; The first client transmits the encrypted presentation information to the second client; the second client requests the service system to transmit the decryption key; the service system transmits a request to transmit the decryption key to the first client in response to the request; The first client Sending a response to the transmission request to the service system; transmitting the decryption key to the second client in response to the transmission request; The service system includes: incrementing a first count indicative of the number of uses of the registry by the second client based on the response; updating the registry usage trail data based on the first count; A data management system that determines a charge amount to be charged to the user of the second client based on the updated registry usage trail data.

2. 2. The data management system according to claim 1, the presented information is information generated based on qualification information indicating attributes of a user of the first client issued by a third client, the service system holds credential information usage trail data indicating a history of usage of the credential information issued by the third client; The first client transmits a usage report of the qualification information to the service system in conjunction with transmitting the encrypted presentation information to the second client; The service system includes: incrementing a second count indicating the number of times the credential issued by the third client has been used based on the usage report; updating the credential usage trail data based on the second count; A data management system that determines a remuneration amount to be paid to the user of the third client based on the updated credential usage trail data.

3. 3. The data management system according to claim 2, a plurality of said second clients; the presented information is information generated based on the qualification information issued by each of one or more clients included in the plurality of third clients, The service system includes: updating the registry usage trail data based on the first count when a value added to the first count since the last update of the registry usage trail data reaches a predetermined value and / or when a predetermined time has elapsed since the last update of the registry usage trail data; A data management system that updates the credential information usage trail data based on the second count when the value added to the second count since the last update of the credential information usage trail data reaches a predetermined value and / or when a predetermined time has elapsed since the last update of the credential information usage trail data.

4. 3. The data management system according to claim 2, A data management system in which the service system determines an intermediate margin to be paid to users of the service system based on at least one of the updated registry usage trail data and the updated credential usage trail data.

5. 2. The data management system according to claim 1, The service system includes: Retaining payment status trail data indicating the payment status of the charge amount; Upon receiving the request, refer to the payment status trail data to determine whether the amount charged to the second client has been paid; a data management system that transmits the transmission request to the first client in response to the request when it is determined that the amount charged to the second client has been paid;

6. 2. The data management system according to claim 1, The second client Decrypting the encrypted presentation information using the decryption key to obtain the presentation information; obtaining verification information corresponding to the obtained presentation information from the registry of the service system; The data management system verifies the acquired presentation information using the acquired verification information.

7. 2. The data management system according to claim 1, The encrypted presentation information is encrypted with a public key in a PBI (Public Biometric Infrastructure) algorithm, A data management system in which the decryption key is a private key that forms a key pair with the public key.

8. 2. The data management system according to claim 1, a trusted region based on a TEE (Trusted Execution Environment) is included in a memory included in the service system; The registry usage trail data is encrypted outside the trusted area, A data management system in which the service system decrypts the registry usage trail data within the trust realm and updates it based on the first count.

9. A service system, a processor and a storage device; connected to a first client and a second client, the first client holds a decryption key for decrypting encrypted presentation information in which presentation information indicating an attribute of a user of the first client is encrypted; The second client holds the encrypted presentation information, The storage device a registry storing verification information used to verify the presented information; maintaining registry usage trail data indicating a usage history of the registry by the second client; The processor: receiving a request for transmission of the decryption key from the second client; transmitting a request to transmit the decryption key to the first client in response to the request; receiving a response to the transmission request from the first client; incrementing a first count indicative of the number of uses of the registry by the second client based on the response; updating the registry usage trail data based on the first count; A service system that determines a charge amount for the user of the second client based on the updated registry usage trail data.

10. A data management method by a data management system, the data management system includes a first client, a second client, and a service system; the first client holds encrypted presentation information in which presentation information indicating an attribute of a user of the first client is encrypted, and a decryption key for decrypting the encrypted presentation information; The service system includes: a registry storing verification information used to verify the presented information; maintaining registry usage trail data indicating a usage history of the registry by the second client; The data management method includes: The first client transmits the encrypted presentation information to the second client; the second client requests the service system to transmit the decryption key; the service system transmits a request to transmit the decryption key to the first client in response to the request; The first client transmits a response to the transmission request to the service system; the first client transmits the decryption key to the second client in response to the transmission request; the service system incrementing a first count indicating the number of uses of the registry by the second client based on the response; The service system updates the registry usage trail data based on the first count; A data management method in which the service system determines a charge amount to be charged to the user of the second client based on the updated registry usage trail data.

Images