Information processing method, server device, and program

Abstract

To provide an information processing method, a server device, and a program that can reduce the occurrence of costs for continuously maintaining a verifiable credential (VC) even when a VC holder is no longer under the control of a VC issuer.SOLUTION: In response to a holder's instructions, an ID wallet application (APP) obtains the holder's decentralized identifier (DID) and identity verification information, generates a key pair of a private key and public key unique to the holder, sends a DID document update request including the DID, the identity verification information, and the public key to a DID issuer server 3, and upon receiving a DID document update response in response to the DID document update request, sends a verifiable credential (VC) reissue request to a VC Issuer server 4, and upon receiving a VC reissue notification in response to the VC reissue request, obtains a reissued VC.SELECTED DRAWING: Figure 8

Description

Technical Field

[0001] The present invention relates to the technical field of systems and the like that can issue verifiable digital certificates using a decentralized identity infrastructure.

Background Art

[0002] In recent years, as a means of identifying an entity (person, organization, device, etc.) and proving the attributes associated therewith, a decentralized identity (hereinafter referred to as DID (Decentralized Identifier)) infrastructure has been spreading. The DID infrastructure has its specifications defined mainly by the W3C (World Wide Web Consortium) and is applied in various industries. A DID is composed of a Scheme, a DID Method, and a DID Method-Specific Identifier. The DID Method describes the identifier of the registry where the DID is registered (stored), and the DID Method-Specific Identifier describes the unique identifier for each individual person, organization, or device, etc. numbered in the registry. When the entity is a person, the owner (user) of the DID is called the "Holder". When requested by the Holder to issue a DID, the DID Issuer creates a new DID and further creates a DID document. The DID document includes the Holder's DID, the public key associated with the DID, and the information of the DID Issuer, and is registered in the registry.

[0003] The attributes of the Holder identified by the DID can be expressed as verifiable digital certificates (also referred to as verifiable qualification information, hereinafter referred to as VC (Verifiable credential)) as disclosed in, for example, Patent Document 1. The VC is digital data for proving the attributes of the Holder, and is applied to, for example, identity cards, licenses, academic backgrounds, work histories, test scores, etc. The Holder's VC includes the Holder's DID, the Holder's attribute information, the DID of the issuer of the VC (hereinafter referred to as "VC Issuer"), and the digital signature (electronic signature) of the VC Issuer. Thus, when the Holder (the Holder of the DID and the VC) discloses the VC to the Verifier, who is the party to whom the Holder wishes to show his / her own attributes, the Verifier can interpret the VC to obtain the public key of the VC Issuer. Then, the Verifier uses the public key of the VC Issuer to verify the VC (i.e., verify the digital signature), evaluates the credibility of the Holder's attributes, and provides the Holder with an action corresponding to the attributes.

[0004] By the way, the private key associated with the Holder's DID (i.e., the private key of the asymmetric encryption method) is used to generate a digital signature for Holder authentication (i.e., the Holder's digital signature) executed when the DID document is registered in the registry, or to generate a digital signature of a VP (Verifiable presentation) in which the Holder selects and discloses specific elements from the VC. If the Holder's private key leaks, it may lead to an incident where someone pretends to be the original Holder and discloses attribute information to improperly enjoy the service. Therefore, a high level of security must be applied to the storage of the private key. For this reason, a device called an ID wallet that implements security measures in both hardware and software is required for storing the Holder's private key, and for this, for example, an IC (Integrated Circuit) card or a secure element of a smartphone is used.

[0005] For example, when applying DID and VC to a student's enrollment certificate, since not all students can always carry a smartphone that meets specific security criteria, it is appropriate to select an IC card that is cheaper than a smartphone for the ID wallet that stores the private key associated with the student's DID, distribute it to all students, and use it as a student ID. For example, when providing services on the condition that the user is a student of the school, such as the access control of the school library and student discounts, if the facility providing the service has a function to verify the VC, the student can store the VC in the secure element of the student ID and prove that they are a student of the school by disclosing the VC to the facility side, thus being able to properly enjoy the service. Furthermore, when a student conducts job hunting activities during the school term, the student can also generate VCs for enrollment certificates and expected graduation certificates, store them in the secure element of the student ID, which is the ID wallet, and disclose them to the employing company, which is the Verifier. Since the private key associated with the DID is stored in such a student ID, when disclosing the VC, the student can execute Holder authentication using the private key to show the Verifier that they are the issuer of the VC, or only disclose the necessary attribute information by VP.

[0006] After that, when a student graduates, usually the school will collect the student ID card, invalidate it, and discard it. However, when the school provides a VC for graduation certification to the graduate, the issue becomes how to maintain the ID wallet for storing the VC and furthermore the DID document that is the starting point for them. First, regarding the ID wallet, if the school distributes a new ID wallet to replace the student ID card to the graduate, the cost of distributing smartphones will be enormous. Therefore, it is assumed that an IC card will be selected. However, the data retention capacity of the non-volatile semiconductor memory used in a general IC card is about 10 years, and it is necessary to update the IC card every 10 years. Not only such card issuance costs but also costs related to tracking the residential address and confirming the survival of the graduate are involved. Therefore, the school's policy of distributing a new ID wallet to students is not appropriate. Thus, although the graduate needs to prepare their own ID wallet, issuing and obtaining a dedicated IC card only for graduation certification is not realistic from the perspective of the manufacturing cost of IC cards based on mass production. Therefore, it is desirable for the graduate to prepare their own smartphone equipped with security and store the VC in the secure element of the smartphone.

[0007] Next, regarding DID documents, the generated cryptographic keys are not permanently used. For example, in NIST SP800-57, the usage period of the private key for signatures is set to 1 to 3 years. If following this standard, the key pair associated with a DID issued during school will be updated during the school term if the term is long, and the DID document including the public key associated with the DID will also be updated accordingly. Furthermore, if we want graduates to use VCs such as graduation certificates after graduation, it is necessary to continuously update the DID document. Since the generation of the key pair associated with the DID and the issuance of the public key certificate are carried out using a dedicated device, the cost associated with the use of that device will continuously occur. Finally, regarding VCs, NIST SP800-57 mentioned above recommends that the usage period of the public key used when verifying digital signatures be several years. For example, the electronic certificate written on the My Number Card has a validity period of 5 years, which can be said to be a general usage period. If we want graduates to continuously use VCs, although the actual frequency of VC use is low (for example, once every 10 years, when changing jobs), it is necessary to update the VCs every few years (for example, every 5 years). Since digital signatures are carried out using a dedicated device, the cost associated with the use of that device will continuously occur.

Prior Art Documents

Patent Documents

[0008]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0009] As described above, when a school continuously provides graduation certificates using VCs to its graduates, a significant cost is required regardless of the actual usage frequency, and there is a problem that neither the school nor the graduates can provide value commensurate with the cost. Here, the relationship between the school and the students is taken as an example, but similarly, there are the same problems in use cases where the Holder of the VC is removed from the management of the VC Issuer and the cost borne by the VC Issuer to continuously maintain the VC does not match the utilization value of the VC.

[0010] Therefore, the present invention has been made in view of the above problems and the like, and an object thereof is to provide an information processing method, a server device, and a program capable of reducing the occurrence of costs for continuously maintaining a VC even when the Holder of the VC is removed from the management of the VC Issuer.

Means for Solving the Problems

[0011] In order to solve the above problems, the invention according to claim 1 is an information processing method implemented in a communication system including a first registry for registering a DID (Decentralized Identifier) capable of identifying a user and a DID document including public key information of the user, a second registry for registering a VC (Verifiable Credential) for proving the attributes of the user, the VC including the DID, attribute information of the user, and a first digital signature of the issuer of the VC, a first information processing device managed by the issuer of the DID and accessible to the first registry, a second information processing device managed by the issuer of the VC and accessible to the second registry, and a third information processing device capable of communicating between the first information processing device and the second information processing device. The method includes: a personal identification information acquisition step in which the third information processing device acquires the DID and the user's personal identification information from the outside in response to the user's instruction; a step in which the third information processing device generates a key pair of a private key and a public key unique to the user; a step in which the third information processing device transmits a DID document update request including the acquired DID, the acquired personal identification information, and the public key in the generated key pair to the first information processing device; a step in which the third information processing device receives a DID document update response indicating that the DID document has been updated by the first information processing device in response to the DID document update request; a step in which the third information processing device transmits a VC update request including the location information of the VC to the second information processing device; a step in which the third information processing device receives a VC update response indicating that the VC has been updated by the second information processing device in response to the VC update request; and a step in which the third information processing device acquires the updated VC from the second registry.

[0012] The invention according to claim 2 is the information processing method according to claim 1, further comprising the steps of: generating a second digital signature of the user by using input data including all or part of a plurality of element data in the attribute information included in the updated VC and the private key in the generated key pair; generating a VP (Verifiable Presentation) including the DID, the first digital signature, and the second digital signature from the updated VC; and disclosing the generated VP to a verifier.

[0013] The invention according to claim 3 is the information processing method according to claim 2, further comprising the steps of: presenting a plurality of element data in the attribute information included in the updated VC to the user in a selectable manner; generating a second digital signature of the user by using the input data including the element data selected by the user as the disclosure target to the verifier from among the presented plurality of element data and the private key in the generated key pair; generating a VP including the element data selected by the user, the DID, the first digital signature, and the second digital signature from the updated VC; and disclosing the generated VP to the verifier.

[0014] The invention according to claim 4 is the information processing method according to claim 3, wherein the input data includes the element data selected by the user and data in which the element data not selected by the user is concealed so as not to be disclosed.

[0015] The invention according to claim 5 is the information processing method according to claim 3, wherein the information processing method further includes a step in which the third information processing device obtains a public key for verifying the first digital signature based on the VC, and verifies the first digital signature included in the updated VC obtained from the second registry using the public key for verification. In the presenting step, when the verification result of the first digital signature is valid, a plurality of element data in the attribute information included in the updated VC are presented to the user in a selectable manner.

[0016] The invention according to claim 6 is the information processing method according to any one of claims 1 to 5, wherein the first information processing device manages personal registration information of the user, and when receiving the DID document update request, collates the personal registration information with the identity confirmation information. When both match, the DID document registered in the first registry is updated, and a DID document update response is transmitted to the third information processing device.

[0017] The invention according to claim 7 is the information processing method according to any one of claims 1 to 5, wherein when the second information processing device receives the VC update request, it updates the VC registered in the second registry and transmits a VC update response to the third information processing device.

[0018] The invention according to claim 8 is the information processing method according to any one of claims 1 to 5, further comprising: a step in which the third information processing device receives the personal identification means information indicating one or more candidates for the personal identification means transmitted from the first information processing device; and a step in which the third information processing device selects one or more personal identification means that can be handled by the third information processing device based on the received personal identification means information, and presents the selected personal identification means to the user in a selectable manner. In the personal identification information acquisition step, personal identification information of the user is acquired by executing processing corresponding to the personal identification means selected according to the instruction of the user among the personal identification means presented to the user in a selectable manner.

[0019] The invention according to claim 9 is a communication system comprising a first registry for registering a DID document including a DID capable of identifying a user and public key information of the user, a second registry for registering a VC for proving the attributes of the user, the VC including the DID, attribute information of the user, and a first digital signature of the issuer of the VC, a first information processing device managed by the issuer of the DID and accessible to the first registry, a second information processing device managed by the issuer of the VC and accessible to the second registry, and a terminal used by the user, and a server device capable of communicating between the first information processing device, the second information processing device, and the terminal, the server device comprising: a first acquisition means for acquiring the DID and the personal identification information of the user from the terminal; a second acquisition means for acquiring, from the terminal, a public key of a key pair generated by the terminal and unique to the user, the key pair including a secret key and a public key; a first transmission means for transmitting a DID document update request including the acquired DID, the acquired personal identification information, and the acquired public key to the first information processing device; a first reception means for receiving, from the first information processing device, a DID document update response indicating that the DID document has been updated in response to the DID document update request; a second transmission means for transmitting a VC update request including the location information of the VC to the second information processing device; a second reception means for receiving, from the second information processing device, a VC update response indicating that the VC has been updated in response to the VC update request; a third acquisition means for acquiring the updated VC from the second registry; and a third transmission means for transmitting the updated VC acquired from the second registry to the terminal.

[0020] In the communication system according to claim 10, which includes a first registry for registering a DID document including a DID that can identify a user and the public key information of the user, and a second registry for registering a VC for proving the attributes of the user, the VC including the DID, the attribute information of the user, and the first digital signature of the issuer of the VC, a first information processing device managed by the issuer of the DID and accessible to the first registry, and a second information processing device managed by the issuer of the VC and accessible to the second registry, a computer included in a terminal used by the user causes, in response to an instruction from the user, the steps of: externally acquiring the DID and the user's identity confirmation information; generating a key pair of a private key and a public key unique to the user; transmitting a DID document update request including the acquired DID, the acquired identity confirmation information, and the public key included in the generated key pair to the first information processing device; receiving a DID document update response indicating that the public key information in the DID document has been updated by the first information processing device in response to the DID document update request; transmitting a VC update request including the location information of the VC to the second information processing device; receiving a VC update response indicating that the VC has been updated by the second information processing device in response to the VC update request; and acquiring the updated VC from the second registry.

Effect of the Invention

[0021] According to the present invention, even when the Holder of the VC is outside the management of the VC Issuer, it is possible to reduce the occurrence of costs for continuously maintaining the VC.

Brief Description of the Drawings

[0022]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Embodiments for Carrying Out the Invention

[0023] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. The embodiments described below are embodiments when the present invention is applied to a VC issuance & management system.

[0024] [1. Configuration and Functions of the VC Issuance & Management System S] First, referring to FIG. 1, the configuration and overview of the functions of the VC issuance & management system S in this embodiment will be described. FIG. 1 is a diagram showing an example of the overall configuration of the VC issuance & management system S. As shown in FIG. 1, the VC issuance & management system S includes a Holder terminal 1, an ID wallet backend server 2 (an example of a server device), a DID Issuer server 3 (an example of a first information processing device), a VC Issuer server 4 (an example of a second information processing device), a Verifier terminal 5, a DID registry 6 (an example of a first registry), a VC registry 7 (an example of a second registry), etc., and these are connected to a communication network NW. The communication network NW is composed of, for example, the Internet, a mobile communication network, and its radio base stations, etc. Note that either both or one of the Holder terminal 1 and the ID wallet backend server 2 constitutes a third information processing device.

[0025] The Holder terminal 1 is a terminal used by a Holder (user). For example, a smartphone or the like is applied to the Holder terminal 1. An ID wallet APP (APP indicates an application) is installed on the Holder terminal 1. The ID wallet APP is an application for managing a DID (Holder's DID) that can identify the Holder and a VC (Holder's VC) for proving the Holder's attributes. The ID wallet backend server 2 is a server computer that communicates with the Holder terminal 1 and operates in conjunction with the ID wallet APP, acting as the backend of the ID wallet APP. Also, the ID wallet backend server 2 can communicate with the DID Issuer server 3, the VC Issuer server 4, etc. Note that a part of the functions of the ID wallet APP may be incorporated into the ID wallet backend server 2, or a part of the functions of the ID wallet backend server 2 may be incorporated into the ID wallet APP.

[0026] The DID Issuer server 3 is a server computer managed by the DID Issuer (the issuer of the DID) and is accessible to the DID registry 6. Also, the DID Issuer server 3 manages the personal registration information of the Holder to whom the DID has been issued. The VC Issuer server 4 is a server computer managed by the VC Issuer (the issuer of the VC) and is accessible to the VC registry 7. The Verifier terminal 5 is a terminal used by the Verifier (the verifier of the VP). For the Verifier terminal 5, for example, a smartphone, a tablet, or a personal computer, etc. are applicable. As a preferred example, the DID Issuer and the VC Issuer can be a school (such as a school administrator, etc.), the Holder can be a graduate of the school, and the Verifier can be a company (such as a company administrator, etc.).

[0027] In the DID registry 6, the DID document of the Holder is registered by the DID Issuer server 3. The DID document of the Holder includes the Holder's DID, the Holder's public key information, and the information of the DID Issuer. The public key information includes the Holder's public key or the location information of the public key (such as link information like a URL or a blockchain address, etc.). The DID document of the Holder may be stored, for example, in a student ID card (IC card) distributed to the student who is the Holder during their school attendance. Furthermore, in the DID registry 6, the DID document of the VC Issuer may be registered by the DID Issuer server 3. The DID document of the VC Issuer includes the DID of the VC Issuer, the public key of the VC Issuer, and the information of the DID Issuer.

[0028] In the VC registry 7, the VC of the Holder is registered by the VC Issuer server 4. The Holder's VC includes the Holder's DID, the Holder's attribute information, the DID of the VC Issuer, the digital signature of the VC Issuer (an example of the first digital signature), and the expiration date of the VC, etc. The Holder's VC may include the location information of the public key for verifying the digital signature of the VC Issuer (that is, the public key of the VC Issuer), etc. The Holder's attribute information includes, for example, the Holder's personal information. The digital signature of the VC Issuer is generated using the private key that forms a key pair with the public key of the VC Issuer. When the student who is the Holder graduates, graduation certificate data may be added (the VC is updated) to the attribute information in the VC.

[0029] For the DID registry 6 and the VC registry 7, a blockchain (decentralized ledger) based on a peer-to-peer network composed of a plurality of nodes (computers) connected to the communication network NW can be applied. The same blockchain may be applied to the DID registry 6 and the VC registry 7, or different blockchains (for example, the blockchain of Bitcoin and the blockchain of Ethereum) may be applied. The DID registries for registering the Holder's DID document and the VC Issuer's DID document may be different. Note that, instead of a blockchain, a predetermined server or the like may be used for the DID registry 6 and the VC registry 7.

[0030] (1-1. Configuration and Function of the Holder Terminal 1) Next, with reference to FIG. 2, the configuration and function overview of the Holder terminal 1 will be described. FIG. 2 is a diagram showing an example of the schematic configuration of the Holder terminal 1. As shown in FIG. 2, the Holder terminal 1 includes a short-range wireless communication unit 11, a communication unit 12, an operation / display unit 13, a storage unit 14, and an information processing unit 15 (an example of a computer), etc., and may also include a camera. The short-range wireless communication unit 11 includes an antenna and can perform short-range wireless communication within a range where, for example, NFC (Near Field radio Communication) technology (or UWB (Ultra-Wide Band) technology) can be used. For example, the ID wallet APP can perform short-range wireless communication with contactless IC cards such as a My Number card, an IC driver's license, or an IC passport. The communication unit 12 is connected to the communication network NW and is responsible for controlling the communication performed with the DID Issuer server 3. Note that the communication unit 12 may include wireless communication equipment for connecting to a radio base station of a mobile communication network.

[0031] The operation / display unit 13 has, for example, an input function for receiving instructions by, for example, the finger or pen of the Holder, and a display function for displaying various screens on the display. The storage unit 14 is composed of, for example, an SSD (Solid State Drive), a non-volatile semiconductor memory, etc. The storage unit 14 stores the OS (Operating System) installed in the Holder terminal 1, the ID wallet APP (an example of the program of the present invention) operating on the OS, and a terminal identifier that can identify the Holder terminal 1. Also, the storage unit 14 is configured to store the key pair of the Holder, the DID of the Holder, and the VC of the Holder by the ID wallet APP. The information processing unit 15 includes a RAM (Random Access Memory), a CPU (Central Processing Unit), etc., and executes various processes as the ID wallet APP. Here, an overview of the processes performed by the ID wallet APP will be described.

[0032] The ID wallet APP obtains the Holder's DID from the outside according to the Holder's instructions. For example, the ID wallet APP obtains the DID input by the Holder via the operation / display unit 13. Alternatively, the ID wallet APP may obtain the VC based on the location information read by the camera (the location information of the VC), obtain the Holder's DID from the obtained VC via the ID wallet backend server 2. Also, the ID wallet APP obtains the Holder's identity verification information from the outside according to the Holder's instructions. For example, the ID wallet APP may obtain the Holder's identity verification information from a contactless IC card such as a My Number card, an IC driver's license, or an IC passport via the short-range wireless communication unit 11. Alternatively, the ID wallet APP may obtain the identity verification information from a license or the like photographed by the camera.

[0033] For example, when the ID wallet APP obtains the Holder's DID, it generates a key pair of a private key and a public key unique to the Holder, and sends a DID document update request including the obtained DID, the obtained identity verification information, and the public key included in the generated key pair to the DID Issuer server 3. Such a DID document update request is sent to the DID Issuer server 3 via, for example, the ID wallet backend server 2. When the ID wallet APP receives a DID document update response indicating that the DID document has been updated (for example, the public key information has been updated) by the DID Issuer server 3 in response to the DID document update request, it sends a VC reissue request (VC update request) including the location information of the Holder's VC to the VC Issuer server 4. Such a VC reissue request is sent to the VC Issuer server 4 via, for example, the ID wallet backend server 2.

[0034] When the ID wallet APP receives a VC reissue notice (update response) indicating that the Holder's VC has been reissued (e.g., the digital signature of the VC Issuer has been updated) by the VC Issuer server 4 in response to the above VC reissue request, the ID wallet APP obtains the reissued VC from the VC registry 7 via the ID wallet backend server 2. The ID wallet APP generates the Holder's digital signature (an example of the second digital signature) using a predetermined cryptographic algorithm with the input data including all or part of a plurality of element data in the attribute information contained in the reissued (updated) VC and the private key in the generated key pair. The ID wallet APP generates a VP (Holder's VP) including the Holder's DID, the VC Issuer's DID, the VC Issuer's digital signature, and the Holder's digital signature from the reissued VC, and discloses the generated VP to the Verifier, for example, through the Verifier terminal 5.

[0035] Here, before generating the Holder VP, the ID wallet APP may present a plurality of element data (for example, data such as name, date of birth, address, educational background, work history, etc.) in the attribute information included in the reissued VC to the Holder in a selectable manner (for example, display on the display) via, for example, the operation and display unit 13. In this case, the ID wallet APP uses the input data including the element data (for example, data of name and educational background) selected by the Holder as the disclosure target to the Verifier from among the plurality of presented element data, and the private key in the generated key pair to generate the digital signature of the Holder by a predetermined cryptographic algorithm. For example, the digital signature is generated by signing the input data from which the element data to be concealed (that is, the element data not selected by the Holder) has been removed with the private key of the Holder. Then, the ID wallet APP generates a VP including the element data selected by the Holder, the DID of the Holder, the DID of the VC Issuer, the digital signature of the VC Issuer, and the digital signature of the Holder from the reissued VC, and discloses the generated VP to the Verifier.

[0036] Thus, if there is information in the attribute information included in the Holder's VC that does not need to be disclosed to the Verifier, the information that does not need to be disclosed can be concealed, preventing the Holder's privacy from being compromised. Note that the above input data may include, in addition to the element data selected by the Holder, data in which the element data not selected by the Holder is concealed so as not to be disclosed. For example, the input data may include the selected element data and the hash value of the unselected element data. In this case, the digital signature is generated by signing the input data in which the selected element data and the hash value of the unselected element data are mixed with the Holder's private key. When the Verifier verifies this, first, the signature (signed with the VC Issuer's private key) with only the hash value as the input data is verified using the VC Issuer's public key to confirm the validity of the VC that forms the basis of the VP. Then, the validity of the VP can be confirmed by verifying the signature for the input data in which the selected element data and the hash value of the unselected element data are mixed using the Holder's public key.

[0037] (1-2. Configuration and functions of the ID wallet backend server 2) Next, with reference to FIG. 3, an overview of the configuration and functions of the ID wallet backend server 2 will be described. FIG. 3 is a diagram showing an example of the general configuration of the ID wallet backend server 2. As shown in FIG. 3, it includes a communication unit 21, a storage unit 22, an information processing unit 23, etc. The communication unit 21 is connected to the communication network NW and is responsible for controlling the communication performed between the Holder terminal 1, the DID Issuer server 3, the VC Issuer server 4, the Verifier terminal 5, etc. The storage unit 22 is composed of, for example, an HDD (Hard Disk Drive), an SSD, etc. The storage unit 22 stores the OS installed in the ID wallet backend server 2 and the ID wallet backend APP operating on the OS. Also, the storage unit 22 is configured to store the public key of the Holder, the DID of the Holder, and the VC of the Holder by the server application. The information processing unit 23 includes a RAM, a CPU, etc., and functions as the first to third acquisition means, the first to third transmission means, and the first to second reception means in the present invention by interacting with the ID wallet APP according to the ID wallet backend APP, and executes various processes.

[0038] The information processing unit 23 acquires the DID of the Holder and the personal identification information of the Holder from the Holder terminal 1, and acquires the public key (the public key of the Holder) included in the key pair generated by the ID wallet APP in response to the acquisition of the personal identification information from the Holder terminal 1. The information processing unit 23 transmits a DID document update request including the acquired DID, the acquired personal identification information, and the acquired public key to the DID Issuer server 3. When the information processing unit 23 receives a DID document update response indicating that the DID document has been updated by the DID Issuer server 3 in response to the DID document update request, it transmits the above VC reissue request from the ID wallet APP to the VC Issuer server 4. When the information processing unit 23 receives a VC reissue notification indicating that the VC has been reissued by the VC Issuer server 4 in response to the VC reissue request, it acquires the reissued VC from the VC registry 7 and transmits the acquired VC to the Holder terminal 1.

[0039] [2. Operation example of VC issuance & management system S] Next, with reference to FIGS. 4 to 9, an operation example of the VC issuance & management system S according to the present embodiment will be described. FIG. 4 is a sequence diagram showing an operation example when a secure session is established between the ID wallet APP of the Holder terminal 1 and the ID wallet backend APP of the ID wallet backend server 2. FIG. 5 is a sequence diagram showing an operation example when the DID of the Holder is acquired by the ID wallet APP of the Holder terminal 1. FIG. 6 is a sequence diagram showing an operation example when the Holder's personal verification information is acquired by the ID wallet APP of the Holder terminal 1. FIG. 7 is a sequence diagram showing an operation example when the DID document of the Holder is updated. FIG. 8 is a sequence diagram showing an operation example when the VC of the Holder is reissued (updated). FIG. 9 is a sequence diagram showing an operation example when the VP of the Holder is disclosed to the Verifier. In the operation example described below, it is assumed that the DID of the Holder has already been issued and registered in the DID registry 6, and the VC of the Holder has already been issued and registered in the VC registry 7.

[0040] (2.1. Operation example when a secure session is established) First, with reference to FIG. 4, an operation example when a secure session is established will be described. A Holder who has come outside the management of the VC Issuer installs the ID wallet APP on their own Holder terminal 1. For example, a Holder who is a graduate of a school installs the ID wallet APP on their own Holder terminal 1 when changing jobs several years after graduation. Note that the timing of installing the ID wallet APP may also be before graduation. When the installation of the ID wallet APP is completed, a Wallet private key is generated from a pre-stored Pre-shared key and a terminal identifier (or an individual identifier similar thereto) and stored in the storage unit 14. The Wallet private key is an encryption key for the secure session and is different from the key pair described above.

[0041] Upon receiving an instruction to start a secure session from the Holder, the ID wallet APP of the Holder terminal 1 shall obtain a terminal identifier (or a similar individual identifier) from the storage unit 14 and send a session start request including the terminal identifier to the ID wallet backend server 2 in order to establish a secure session with the ID wallet backend APP (step S1).

[0042] Next, upon receiving the session start request from the Holder terminal 1, the ID wallet backend APP of the ID wallet backend server 2 shall generate a Wallet private key from the pre-stored Pre-shared key and the terminal identifier and temporarily store it (step S2). Next, the ID wallet backend APP shall generate and temporarily store session information (B) including a dynamic value such as a random number (step S3). Next, the ID wallet backend APP shall send the session information (B) generated in step S3 to the Holder terminal 1 (step S4).

[0043] Next, upon receiving the session information (B) from the ID wallet backend server 2, the ID wallet APP of the Holder terminal 1 shall generate a signature (A) by signing the session information (B) with the Wallet private key and temporarily store it (step S5). Next, the ID wallet APP shall generate and temporarily store session information (A) including a dynamic value such as a random number (step S6). Next, the ID wallet APP shall send the signature (A) generated in step S5 and the session information (A) generated in step S6 to the ID wallet backend server 2 (step S7).

[0044] Next, when the ID wallet backend APP of the ID wallet backend server 2 receives the signature (A) and the session information (A) from the Holder terminal 1, it verifies the signature (A) with the Wallet private key generated in step S2 (step S8). When the signature (A) is valid (appropriate), it generates a signature (B) by signing the session information (A) with the Wallet private key, stores it temporarily (step S9). If the signature (A) is not valid, the ID wallet backend APP interrupts the process. Next, the ID wallet backend APP sends the signature (B) generated in step S9 to the Holder terminal 1 (step S10).

[0045] Next, when the ID wallet APP of the Holder terminal 1 receives the signature (B) from the ID wallet backend server 2, it verifies the signature (B) with the Wallet private key (step S11). When the signature (B) is valid, it starts a secure session. If the signature (B) is not valid, the ID wallet APP interrupts the process. After the secure session is established, both the ID wallet APP and the ID wallet backend APP perform encrypted communication using the session key (Wallet master key) generated from the session information (B), the session information (A), and the Pre-shared key.

[0046] (2.2. Example of operations when the Holder's DID is obtained) Next, with reference to FIG. 5, an example of the operation when the DID of the Holder is acquired will be described. When a secure session is established as described above, in order to associate the DID of the Holder with the ID wallet APP, the ID wallet APP of the Holder terminal 1 requests the Holder to input the DID. The Holder may directly input his / her own DID (data string) via the operation / display unit 13 of the Holder terminal 1. Here, however, an example will be taken in which the DID is traced from the location information (location information of the VC) read by the camera of the Holder terminal 1. For example, a two-dimensional code such as a QR code (registered trademark) displayed on a graduation certificate held by the Holder who is a graduate of a school is read by the camera of the Holder terminal 1. The location information of the Holder's VC is encoded in such a two-dimensional code.

[0047] The Holder terminal 1 extracts the location information of the VC from the read two-dimensional code and passes it to the ID wallet APP. Thereby, when the ID wallet APP acquires (for example, stores in the RAM) the location information of the Holder's VC (step S21), it sets the VC validity information as unconfirmed (step S22). Next, the ID wallet APP sends a DID acquisition request including the location information acquired in step S21 to the ID wallet backend server 2 (step S23).

[0048] Next, when the ID wallet backend APP of the ID wallet backend server 2 receives the DID acquisition request from the Holder terminal 1, it acquires the VC from the VC registry 7 based on the location information included in the DID acquisition request (that is, by tracing the location information of the Holder's VC) (step S24). Next, the ID wallet backend APP acquires (for example, stores in the RAM) the DID of the Holder from the VC acquired in step S24 (step S25).

[0049] Next, the ID wallet backend APP acquires the DID document of the Holder from the DID registry 6 based on the DID Method indicated by the DID obtained in step S25 (step S26). Next, the ID wallet backend APP accesses the DID Issuer server 3 based on the information of the DID Issuer included in the DID document acquired in step S26, and transmits a personal authentication means acquisition request including the DID obtained in step S25 to the DID Issuer server 3 (step S27).

[0050] Next, when the DID Issuer server 3 receives the personal authentication means acquisition request from the ID wallet backend server 2, it transmits personal authentication means information indicating one or more candidates for personal authentication means necessary when updating the DID document associated with (included in) the DID included in the personal authentication means acquisition request to the ID wallet backend server 2 (step S28). Such personal authentication means information indicates, as candidates for personal authentication means, for example, a My Number card, an IC driving license, and an IC passport (travel document). Note that the DID Issuer server 3 may specify candidates for personal authentication means based on the DID. Next, when the ID wallet backend APP of the ID wallet backend server 2 receives the personal authentication means information from the DID Issuer server 3, it transmits an initial setting request including the personal authentication means information and the DID obtained in step S25 to the Holder terminal 1 (step S29).

[0051] Next, when the ID wallet APP of the Holder terminal 1 receives an initial setting request from the ID wallet backend server 2, it records the DID of the Holder included in the initial setting request (step S30). For example, it is recorded in a recording area managed by the ID wallet APP in the storage unit 14. In this way, the DID of the Holder is associated with the ID wallet APP of the Holder. Next, the ID wallet APP sets the DID recorded in step S30 to an unusable state (i.e., non-active) (step S31).

[0052] (2.3. Example of operation when the Holder's identity verification information is acquired) Next, with reference to FIG. 6, an example of the operation when the Holder's identity verification information is acquired will be described. The ID wallet APP of the Holder terminal 1 interprets the identity verification means information included in the received initial setting request, and selects (extracts) one or more candidates for the identity verification means that can be executed (i.e., can be handled by the Holder terminal 1 based on the identity verification means information) in comparison with the identity verification means supported by the ID wallet APP, and requests the Holder to select the selected candidate (step S41). For example, the ID wallet APP may present the selected candidate (identity verification means) to the Holder in a selectable manner (e.g., display on the display) via the operation / display unit 13.

[0053] For example, although the DID Issuer server 3 showed three types, namely the My Number card, the IC driver's license, and the IC passport, as candidates for the means of personal identification, if the ID wallet APP did not support the reading of the IC passport due to the hardware and software restrictions of the Holder terminal 1, the ID wallet APP would present the My Number card and the IC driver's license to the Holder as selection candidates. For example, if the Holder selects the My Number card as the means of personal identification (step S42), the ID wallet APP starts the personal identification process for the My Number card (that is, the process corresponding to the means of personal identification selected according to the user's instruction) (step S43), displays a PIN input screen on the display, and requests the Holder to input a PIN (personal identification number) (step S44).

[0054] When the Holder inputs a PIN on the PIN input screen via the operation and display unit 13 in response to the request for PIN input (step S45), the ID wallet APP temporarily stores the input PIN (step S46). Next, the ID wallet APP requests the Holder to present the My Number card (for example, requests the Holder to hold it in front of the Holder terminal 1) (step S47). When the Holder holds the My Number card in front of the Holder terminal 1 (presents the My Number card) in response to the request to present the My Number card (step S48), short-range wireless communication is started between the short-range wireless communication unit 11 of the Holder terminal 1 and the My Number card. Next, the ID wallet APP creates a personal identification command including the PIN temporarily stored in step S46 (step S49), and transmits the personal identification command to the My Number card via the short-range wireless communication unit 11 (step S50).

[0055] Next, when the My Number Card receives the identity verification command from the Holder terminal 1, it extracts the PIN from the identity verification command and compares the extracted PIN with the PIN stored in the My Number Card (step S51). Next, when the My Number Card succeeds in the PIN comparison (i.e., the PINs match), it changes its internal state to a read permission state that permits the reading of the signature electronic certificate containing the identity verification information. On the other hand, if the PIN comparison fails, the reading of the signature electronic certificate is prohibited. Next, the My Number Card transmits a response indicating the execution result (PIN comparison result) of the identity verification command to the Holder terminal 1 (step S52).

[0056] Next, when the ID wallet APP receives the response from the My Number Card via the short-range wireless communication unit 11, it checks the execution result of the identity verification command (step S53). When the execution result indicates success, it transmits a read command for the signature electronic certificate to the My Number Card via the short-range wireless communication unit 11 (step S54). Next, when the My Number Card receives the read command from the Holder terminal 1, it checks its internal state. If it is in the read permission state, it reads the signature electronic certificate from the non-volatile memory (step S55) and transmits a response containing the signature electronic certificate to the Holder terminal 1 (step S56).

[0057] Next, when the ID wallet APP receives the response from the My Number Card via the short-range wireless communication unit 11, it acquires (e.g., stores in the RAM) the signature electronic certificate included in the response (step S57) and notifies the Holder that the reading is complete. In this way, the ID wallet APP obtains the Holder's identity verification information from the outside by executing the identity verification process for the My Number Card.

[0058] (2.4. Example of operation when the Holder's DID document is updated) Next, with reference to FIG. 7, an example of the operation when the DID document of the Holder is updated will be described. When the ID wallet APP of the Holder terminal 1 acquires a signature electronic certificate in which the personal verification information is described, it generates a key pair of a private key and a public key unique to the Holder (a key pair individually assigned to the Holder) (step S61), and records the private key (the private key of the Holder) included in the key pair (step S62). For example, it is recorded in a secure recording area managed by the ID wallet APP in the storage unit 14. Note that the generation of the key pair of the private key and the public key unique to the Holder may be performed before the acquisition of the signature electronic certificate.

[0059] Next, the ID wallet APP transmits a DID document update request including the DID recorded in step S30, the signature electronic certificate acquired in step S57, and the public key (the new public key of the Holder) included in the key pair generated in step S61 to the ID wallet backend server 2 (step S63). Here, the ID wallet APP may extract the personal verification information (for example, the name and date of birth of the Holder) from the signature electronic certificate, and transmit a DID document update request including the DID of the Holder, the personal verification information, and the public key of the Holder to the ID wallet backend server 2.

[0060] Next, when the ID wallet backend APP of the ID wallet backend server 2 receives a DID document update request from the Holder terminal 1, it transmits the DID document update request to the DID Issuer server 3 (step S64). Here, when the signature electronic certificate is included in the DID document update request, the ID wallet backend APP may extract the personal verification information from the signature electronic certificate, create update information including the DID of the Holder, the personal verification information, and the public key of the Holder, and transmit a DID document update request including the update information to the DID Issuer server 3.

[0061] Next, when the DID Issuer server 3 receives a DID document update request from the ID wallet backend server 2, it identifies the personal registration information (such as name and date of birth) managed by the DID Issuer server 3 based on the DID included in the DID document update request (step S65). Next, the DID Issuer server 3 collates the personal registration information identified in step S65 with the identity verification information included in the received DID document update request (step S66). Then, if the DID Issuer server 3 determines in step S66 that both (i.e., the personal registration information and the identity verification information) match, it approves the DID document update request, accesses the DID registry 6 based on the DID Method indicated in the DID included in the received DID document update request, obtains the DID document registered therein, updates the DID document, and re-registers (re-registers) it in the DID registry 6 (step S67).

[0062] Here, when the DID document includes a public key (the old public key of the Holder), the DID Issuer server 3 updates the DID document by updating (e.g., overwriting) the public key included in the DID document with the public key (the new public key of the Holder) included in the DID document update request. On the other hand, when the DID document includes the location information of the public key (the old public key of the Holder), the public key (the new public key of the Holder) included in the DID document update request is registered in a public key storage destination (e.g., a predetermined server or blockchain), and the DID document is updated (e.g., overwritten) by updating the location information (the location information of the old public key of the Holder) included in the DID document with the location information of the registered public key.

[0063] Next, when the DID Issuer server 3 successfully updates the DID document, it sends a DID document update response indicating success to the ID wallet backend server 2 in response to the DID document update request from the ID wallet backend server 2 (step S68). On the other hand, when the DID Issuer server 3 fails to update the DID document, it sends an update error response indicating failure to the ID wallet backend server 2. Next, when the ID wallet backend APP of the ID wallet backend server 2 receives the DID document update response from the DID Issuer server 3, it sends the DID document update response to the Holder terminal 1 (step S69).

[0064] Next, when the ID wallet APP of the Holder terminal 1 receives the DID document update response from the ID wallet backend server 2, it changes the setting of the DID set to the unusable state in step S31 to the usable state (active) (step S70). Through the above processing, the ID wallet APP will obtain a valid DID and DID document. Thereby, the VC reissuance procedure is set to be executable.

[0065] Note that the ID wallet APP may notify the Holder via the operation / display unit 13 that it has successfully obtained the DID and DID document and that the DID has become usable. Also, if a fee is incurred for subsequent VC reissuance (update), the ID wallet APP may notify the Holder to prompt registration of the necessary payment information. And when the Holder successfully registers the payment information, the VC reissuance procedure may be set to be executable.

[0066] (2.5. Operational example when the Holder's VC is reissued) Next, with reference to FIG. 8, an operation example when the VC of the Holder is reissued will be described. After the VC reissue procedure is set to be executable, the ID wallet APP of the Holder terminal 1 transmits a VC reissue request (VC update request) including the location information of the Holder's VC to the ID wallet backend server 2 in response to a VC reissue instruction from the Holder (step S81). When charging the Holder for the cost of VC reissue, the above settlement information is included in the VC reissue request.

[0067] Next, when the ID wallet backend APP of the ID wallet backend server 2 receives a VC reissue request from the Holder terminal 1, it transmits the VC reissue request to the VC Issuer server 4 (step S82). Next, when the VC Issuer server 4 receives a VC reissue request from the Holder terminal 1 or the ID wallet backend server 2, it accesses the VC registry 7 based on the location information included in the VC reissue request, acquires the VC registered therein (for example, the VC with an expired expiration date), updates the VC, and updates and registers (re-registers) it in the VC registry 7 (step S83).

[0068] Here, the VC Issuer server 4 generates a new digital signature by signing the attribute information to be proven by the VC with a new private key (the private key of the VC Issuer), and updates (for example, overwrites) the old digital signature included in the VC with the generated digital signature to update the Holder's VC (at this time, the expiration date of the VC may also be updated to a future date). If the Holder's VC contains the location information of the public key for verifying the digital signature of the VC Issuer, the old digital signature included in the VC is updated with the location information of the new public key that forms a key pair with the new private key used for the above signature (at this time, the expiration date of the VC may also be updated to a future date). Also, when billing the Holder for the cost of updating the VC, after the update registration to the VC registry 7 is completed, the VC Issuer server 4 executes a process to collect the necessary fees from the Holder using the payment information included in the above VC reissue request.

[0069] Next, when the update of the VC is successful, the VC Issuer server 4 sends a VC reissue notice indicating that the VC has been updated to the ID wallet backend server 2 (step S84). On the other hand, when the update of the VC fails, the VC Issuer server 4 sends an update error notice indicating the update failure to the ID wallet backend server 2. Next, when the ID wallet backend APP of the ID wallet backend server 2 receives the VC reissue notice from the VC Issuer server 4, it sends the VC reissue notice to the Holder terminal 1 (step S85).

[0070] Next, when the ID wallet APP of the Holder terminal 1 receives the VC reissuance notice from the ID wallet backend server 2, it sends a VC verification request to the ID wallet backend server 2 (step S86). Note that the VC verification request may include the location information of the Holder's VC. Next, when the ID wallet backend APP of the ID wallet backend server 2 receives the VC verification request from the Holder terminal 1, it acquires the updated VC from the VC registry 7 based on the location information of the Holder's VC (step S87). Next, the ID wallet backend APP acquires the public key for verifying the digital signature of the VC Issuer based on the VC acquired in step S87 (step S88).

[0071] Here, if the VC acquired in step S87 contains the location information of the public key for verifying the digital signature of the VC Issuer, the ID wallet backend APP acquires the location information of the public key for verification from the VC and acquires the public key for verification based on the location information. On the other hand, if the VC acquired in step S87 does not contain the location information of the public key for verifying the digital signature of the VC Issuer, the ID wallet backend APP acquires the public key for verification from the VC Issuer server 4 by sending a public key acquisition request including the VC acquired in step S87 to the VC Issuer server 4.

[0072] Next, the ID wallet backend APP verifies the digital signature included in the VC (updated VC) obtained in step S87 using the verification public key obtained in step S88 (step S89). Next, when the verification result of the digital signature is valid (verification successful) (for example, the digital signature could be decrypted), the ID wallet backend APP sends a verification result indicating successful VC verification to the Holder terminal 1 (step S90). At this time, summary information may be added to and sent with the verification result. Such summary information includes information such as the name of the VC Issuer, expiration date, and display image. Note that the ID wallet backend APP may send a verification result indicating successful VC verification to the Holder terminal 1 when the verification result of the digital signature is valid and within the expiration date (i.e., the current date and time is within the expiration date).

[0073] Next, when the ID wallet APP of the Holder terminal 1 receives a verification result indicating successful VC verification from the ID wallet backend server 2, it sets the VC validity information to "confirmed" (step S91). Thus, when the VC validity information is set to "confirmed", the ID wallet APP can present multiple element data in the attribute information included in the updated VC in a selectable manner to the Holder, and can display the summary information on the display if the summary information has been obtained.

[0074] (2.6. Example of operations when the Holder's VP is disclosed to the Verifier) Next, with reference to FIG. 9, an example of operations when the Holder's VP is disclosed to the Verifier will be described. After the VC validity information is set to "confirmed", in response to a VC presentation instruction from the Holder, the ID wallet APP of the Holder terminal 1 sends a VC acquisition request including the location information of the Holder's VC to the ID wallet backend server 2 in order to acquire the VC that serves as the basis for VP generation (step S101).

[0075] Next, when the ID wallet backend APP of the ID wallet backend server 2 receives a VC acquisition request from the Holder terminal 1, it sends the VC verified in step S89 to the Holder terminal 1 (step S102). If a VC acquisition request is received after a predetermined period has elapsed since the VC validity information was set to confirmed, the ID wallet backend APP may acquire the VC and the public key for verifying the digital signature again, and verify the digital signature included in the acquired VC using the acquired public key for verification. In this case, the ID wallet backend APP sends the verified VC to the Holder terminal 1 when the verification result of the digital signature is valid.

[0076] Next, when the ID wallet APP of the Holder terminal 1 receives the VC from the ID wallet backend server 2, it presents a plurality of element data in the attribute information included in the VC to the Holder so that they can be selected, for example, via the operation / display unit 13 (step S103). When the Holder selects the element data to be disclosed to the Verifier (a number of element data less than the number of presented element data) from among the presented plurality of element data (step S104), the ID wallet APP generates a digital signature of the Holder using the input data including the selected element data (for example, data of name and academic background) and the private key (Holder's private key) recorded in step S62 (step S105). That is, the ID wallet APP generates a digital signature of the Holder by signing the input data configured to exclude the element data not selected by the Holder using the private key of the Holder.

[0077] Next, the ID wallet APP generates a VP that includes the element data selected in step S104, the DID of the Holder, the DID of the VC Issuer, the digital signature of the VC Issuer included in the verified VC, and the digital signature of the Holder generated in step S105 (step S106). Thereby, when the Holder discloses the VC to the Verifier, if information (element data) that does not need to be disclosed to the Verifier is included in the VC, the Holder can generate a VP with the information that does not need to be disclosed hidden and disclose it to the Verifier. Note that the generated VP may include the location information of the public key for verifying the digital signature of the VC Issuer. Next, the ID wallet APP requests the Holder to specify a method for disclosing the VP, for example, via the operation / display unit 13 (step S107). In response to this request, when the Holder specifies a method for disclosing the VP generated in step S106 (step S108), the ID wallet APP discloses the VP to the Verifier according to the specification (step S109).

[0078] For example, the ID wallet APP converts the VP into a two-dimensional code by encoding it, and displays the two-dimensional code on the display via the operation / display unit 13. Thereby, the Verifier terminal 5 acquires the VP by reading and decoding the two-dimensional code with the camera of the Verifier terminal 5 in response to the instruction of the Verifier. Alternatively, the ID wallet APP may directly transmit the VP to the Verifier terminal 5 by the short-range wireless communication unit 11, so that the Verifier terminal 5 acquires the VP. Alternatively, the ID wallet APP may transmit the VP to the Verifier terminal 5 by email (sent to the Verifier's email address), so that the Verifier terminal 5 acquires the VP. Alternatively, the ID wallet APP may temporarily upload the VP to a cloud storage service and transmit the URL for downloading it to the Verifier terminal 5 by email, so that the Verifier terminal 5 acquires the VP. Note that the ID wallet APP may transmit the VP to the Verifier terminal 5 via the ID wallet backend server 2.

[0079] In this way, the Verifier terminal 5 that has obtained the VP acquires the DID document of the VC Issuer from the DID registry 6 based on the DID of the VC Issuer included in the VP (or the location information of the public key for verifying the digital signature of the VC Issuer), and verifies the digital signature of the VC Issuer included in the VP using the public key included in the obtained DID document (step S110). Thereby, the validity of the VC underlying the VP can be verified. Further, the Verifier terminal 5 acquires the DID document of the Holder from the DID registry 6 based on the DID of the Holder included in the VP, and verifies the digital signature of the Holder included in the VP (Holder authentication) using the public key included in the obtained DID document (step S111). Thereby, the validity of the VP can be verified. Then, when the verification result of the digital signature of the VC Issuer is valid and the verification result of the digital signature of the Holder is valid, the Verifier evaluates the validity of the attributes of the Holder and performs an action (for example, employment) based on the attributes.

[0080] As described above, according to the above embodiment, the ID wallet APP acquires the Holder's DID and identity verification information in response to the Holder's instruction, generates a key pair of a private key and a public key unique to the Holder, and sends a DID document update request including the DID, the identity verification information, and the public key to the DID Issuer server 3. When receiving a DID document update response in response to the DID document update request, it sends a VC reissue request to the VC Issuer server 4. When receiving a VC reissue notification in response to the VC reissue request, it is configured to acquire the reissued VC. Therefore, even when the Holder is outside the management of the VC Issuer, the occurrence of costs for continuously maintaining the VC can be reduced. Further, according to the above embodiment, the ID wallet APP generates a digital signature of the Holder using input data including all or part of a plurality of element data in the attribute information included in the reissued VC and the private key in the generated key pair, generates a VP including the digital signature of the VC Issuer and the digital signature of the Holder, and is configured to disclose the generated VP to the Verifier. Therefore, even when the Holder is outside the management of the VC Issuer, a VP can be quickly generated from the reissued VC and disclosed to the Verifier. Also, according to the above embodiment, since the VP disclosed to the Verifier includes the digital signature of the Holder, it can be guaranteed that the attribute information included in the VP belongs to the Holder. Further, since information that does not need to be disclosed in the VP disclosed to the Verifier can be concealed, the privacy of the Holder can be prevented from being impaired.Furthermore, according to the above embodiment, the DID Issuer provides the ID Wallet APP with the identity verification means information indicating candidates for identity verification means suitable for updating the DID document. The ID Wallet APP selects candidates for executable identity verification means from the provided identity verification means information, and the ID wallet APP presents the candidates for the identity verification means to the Holder so that the Holder can select them. Therefore, the Holder can flexibly select the identity verification means he / she has on hand, and the usability related to the reissuance of the VC can be improved.

[0081] In addition, in the above embodiment, the function of the ID wallet backend APP may be configured to be incorporated into the ID wallet APP. In this case, the ID wallet APP communicates directly with the DID Issuer server 3 and the VC Issuer server 4. For example, the ID wallet APP may directly send a DID document update request to the VC Issuer server 4 in FIG. 7, or may directly send a VC reissuance request to the VC Issuer server 4 in FIG. 8. Also, in the above embodiment, the case where the DID is included in the DID document is described as an example, but the DID may exist outside the DID document, and the DID and the DID document may be associated with each other and registered in the DID registry 6.

Explanation of Signs

[0082] 1 Holder terminal 2 ID wallet backend server 3 DID Issuer server 4 VC Issuer server 5 Verifier terminal 6 DID registry 7 VC registry 11 Near-field wireless communication unit 12 Communication unit 13 Operation / display unit 14 Storage unit 15 Information processing unit 21 Communication Unit 22 Memory Unit 23 Information Processing Unit SVC Issuance & Management System

Claims

1. A first registry for registering a DID (Decentralized Identifier) that can identify a user and a DID document including the public key information of the user, and a VC (Verifiable credential) for proving the attributes of the user, the VC including the DID, the attribute information of the user, and the first digital signature of the issuer of the VC. A second registry for registering the VC, a first information processing device managed by the issuer of the DID and accessible to the first registry, a second information processing device managed by the issuer of the VC and accessible to the second registry, and a third information processing device communicable between the first information processing device and the second information processing device. An information processing method implemented in a communication system, comprising: A personal identification information acquisition step in which the third information processing device acquires the DID and the user's personal identification information from the outside in response to an instruction from the user; A step in which the third information processing device generates a key pair of a secret key and a public key unique to the user; A step in which the third information processing device transmits a DID document update request including the acquired DID, the acquired personal identification information, and the public key in the generated key pair to the first information processing device; A step in which the third information processing device receives a DID document update response indicating that the DID document has been updated by the first information processing device in response to the DID document update request; A step in which the third information processing device transmits a VC update request including the location information of the VC to the second information processing device; A step in which the third information processing device receives a VC update response indicating that the VC has been updated by the second information processing device in response to the VC update request; A step in which the third information processing device acquires the updated VC from the second registry; An information processing method characterized by including the above.

2. A step of generating a second digital signature of the user using input data including all or part of a plurality of element data in the attribute information included in the updated VC and the secret key in the generated key pair; Generating a VP (Verifiable Presentation) including the DID, the first digital signature, and the second digital signature from the updated VC; Disclosing the generated VP to a verifier; The information processing method according to claim 1, further comprising the above.

3. A presenting step of presenting a plurality of element data in the attribute information included in the updated VC in a selectable manner to the user; Generating a second digital signature of the user using the input data including the element data selected by the user as a disclosure target to the verifier from among the presented plurality of element data and the private key in the generated key pair; Generating a VP including the element data selected by the user, the DID, the first digital signature, and the second digital signature from the updated VC; Disclosing the generated VP to the verifier; The information processing method according to claim 2, further comprising the above.

4. The information processing method according to claim 3, wherein the input data includes the element data selected by the user and data obtained by concealing, in a non-disclosable manner, the element data not selected by the user.

5. The information processing method further includes a step in which the third information processing device obtains a public key for verifying the first digital signature based on the VC, and verifies the first digital signature included in the updated VC obtained from the second registry using the public key for verification. In the presenting step, when the verification result of the first digital signature is valid, a plurality of element data in the attribute information included in the updated VC are presented to the user in a selectable manner. The information processing method according to claim 3.

6. The first information processing device manages the personal registration information of the user. When receiving the DID document update request, it collates the personal registration information and the identity confirmation information. If both match, it updates the DID document registered in the first registry and transmits a DID document update response to the third information processing device. The information processing method according to any one of claims 1 to 5.

7. When receiving the VC update request, the second information processing device updates the VC registered in the second registry and transmits the VC update response to the third information processing device. The information processing method according to any one of claims 1 to 5, characterized in that.

8. The third information processing device receiving the personal identification means information indicating one or more candidates for the personal identification means transmitted from the first information processing device; The third information processing device selecting one or more personal identification means that can be handled by the third information processing device based on the received personal identification means information, and presenting the selected personal identification means to the user so that it can be selected; Further comprising In the personal identification information acquisition step, the personal identification information of the user is acquired by executing processing corresponding to the personal identification means selected according to the instruction of the user among the personal identification means presented to the user so that it can be selected. The information processing method according to any one of claims 1 to 5, characterized in that.

9. A first registry for registering a DID document including a DID capable of identifying a user and the public key information of the user, and a VC for proving the attributes of the user, the VC including the DID, the attribute information of the user, and the first digital signature of the issuer of the VC. A second registry for registering the VC, a first information processing device managed by the issuer of the DID and accessible to the first registry, a second information processing device managed by the issuer of the VC and accessible to the second registry, and a terminal used by the user. A server device capable of communicating between the first information processing device, the second information processing device, and the terminal in a communication system including A first acquisition means for acquiring the DID and the personal identification information of the user from the terminal; A second acquisition means for acquiring the public key of a key pair generated by the terminal, which is a key pair of a secret key and a public key unique to the user, from the terminal; A first transmission means for transmitting a DID document update request including the acquired DID, the acquired personal identification information, and the acquired public key to the first information processing device; A first reception means for receiving a DID document update response indicating that the DID document has been updated by the first information processing device in response to the DID document update request; second transmission means for transmitting a VC update request including the location information of the VC to the second information processing device; second receiving means for receiving a VC update response indicating that the VC has been updated by the second information processing device in response to the VC update request; third acquisition means for acquiring the updated VC from the second registry; third transmission means for transmitting the updated VC acquired from the second registry to the terminal; A server device characterized by comprising.

10. In a communication system comprising a first registry for registering a DID document including a DID capable of identifying a user and public key information of the user, and a second registry for registering a VC for proving the attributes of the user, the VC including the DID, the attribute information of the user, and a first digital signature of the issuer of the VC, a first information processing device managed by the issuer of the DID and accessible to the first registry, and a second information processing device managed by the issuer of the VC and accessible to the second registry, in a computer included in a terminal used by the user, in response to an instruction from the user, obtaining the DID and the user's personal identification information from the outside; generating a key pair of a private key and a public key unique to the user; transmitting a DID document update request including the acquired DID, the acquired personal identification information, and the public key included in the generated key pair to the first information processing device; receiving a DID document update response indicating that the public key information in the DID document has been updated by the first information processing device in response to the DID document update request; transmitting a VC update request including the location information of the VC to the second information processing device; receiving a VC update response indicating that the VC has been updated by the second information processing device in response to the VC update request; acquiring the updated VC from the second registry; A program characterized by causing the above to be executed.

Images