Server, information management system equipped therewith, and information management method

Abstract

To enhance fraud prevention on verifiable credentials (VC).SOLUTION: An issuer server 1 includes: a communication apparatus 14 which is configured to communicate with a holder terminal 2; and a processor 11 which issues verifiable credentials (VC) in accordance with an issuance request from the holder terminal 2. The issuance request includes attribute information of a holder and a decentralized identifier (DID) of the holder. The processor 11 sets a valid period to the verifiable credentials on the basis of the attribute information of the holder and associates the set valid period with the decentralized identifier.SELECTED DRAWING: Figure 15

Description

Technical Field

[0001] The present disclosure relates to a server, an information management system including the same, and an information management method, and more particularly to a technology for realizing distributed identity.

Background Art

[0002] In recent years, distributed identity has attracted attention. Distributed identity is a mechanism in which a holder secures control rights over its own attribute information and shares necessary information among the attribute information with others within the range permitted by the holder. In distributed identity, verifiable credential (VC) issued from an issuer is associated with a decentralized identifier (DID) of the holder. The holder can use the service provided by the verifier by presenting the VC to the verifier. An example of such a system and method is disclosed in, for example, Japanese Patent Application Laid-Open No. 2018-537022 (Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] Generally, technologies such as electronic signatures are introduced to prevent fraud on VC (such as forgery of VC). However, with the progress of encryption technology, the risk of fraud on VC may increase. Strengthening the mechanism for preventing fraud on VC is required.

[0005] This disclosure was made to address the above-mentioned issues, and one of its purposes is to strengthen fraud prevention against venture capital. [Means for solving the problem]

[0006] (1) The server relating to the first aspect of this disclosure comprises a communication device configured to communicate with a holder's communication terminal and a processor that issues verifiable credentials (VC) in response to an issuance request from the communication terminal. The issuance request includes attribute information of the holder and a first distributed identifier which is the holder's distributed identifier (DID). The processor sets an expiration period for the verifiable credentials based on the holder's attribute information and associates the set expiration period with the first distributed identifier.

[0007] In the configuration described in (1) above, when the validity period expires, the server will reissue (update) verifiable credentials in response to a reissuance request from the communication terminal. This ensures that the verifiable credentials include an electronic signature generated using the latest encryption technology. Therefore, protection against fraudulent activity related to verifiable credentials can be strengthened.

[0008] (2) Attribute information includes information entered by the holder and information from the holder's identification documents. The processor issues verifiable credentials if the holder's identity is successfully verified by matching the attribute information entered by the holder with the information from the identification documents.

[0009] According to the configuration described in (2) above, verifiable credentials can be issued after ensuring the identity of the holder is verified.

[0010] (3) The processor determines, based on the holder's attribute information, which of several groups with different credit ratings the holder belongs to, and extends the validity period if the holder belongs to a high-credit rating group compared to if the holder belongs to a low-credit rating group.

[0011] In the configuration described in (3) above, the validity period is set shorter if the holder's trustworthiness is low. This increases the frequency of updating verifiable credentials as their validity period expires earlier. When verifiable credentials are updated, the identity of holders with low trustworthiness can be verified again. Therefore, fraud prevention against verifiable credentials can be further strengthened.

[0012] (4) The system relating to the second aspect of this disclosure comprises the above-mentioned server and a verifier server that verifies verifiable credentials from a communication terminal.

[0013] (5) The server and the verifier server have access to a distributed ledger network that includes the distributed ledger. The server registers a public key corresponding to its private key in the distributed ledger. The server includes a second distributed identifier, which is the server's distributed identifier, and the digital signature generated using the private key in its verifiable credentials. When the verifier server receives verifiable credentials from a communication terminal, it retrieves the public key from the distributed ledger based on the second distributed identifier included in the verifiable credentials and verifies the digital signature using the public key.

[0014] (6) The information management method relating to the third aspect of this disclosure includes the step of issuing verifiable credentials in response to an issuance request from a holder's communication terminal. The issuance request includes the holder's attribute information and the holder's distributed identifier. The issuance step includes the step of setting an expiration period for the verifiable credentials based on the holder's attribute information and the step of associating the expiration period with the distributed identifier.

[0015] According to the configurations in (4) and (5) above and the method in (6) above, fraud prevention against VCs can be strengthened, similar to the configuration in (1) above. [Effects of the Invention]

[0016] This disclosure will strengthen the prevention of fraud against venture capital firms. [Brief explanation of the drawing]

[0017] [Figure 1]It is a diagram showing the overall configuration of an information management system according to an embodiment of the present disclosure. [Figure 2] It is a block diagram showing a typical configuration example of an issuer server. [Figure 3] It is a conceptual diagram for explaining the relevance of information in a decentralized identity. [Figure 4] It is a conceptual diagram for explaining the relevance of information in a DID issued by an issuer server. [Figure 5] It is a conceptual diagram for explaining an overview of a series of processes related to VC in an information management system. [Figure 6] It is FIG. 1 showing an example of an image displayed on a holder terminal. [Figure 7] It is FIG. 2 showing an example of an image displayed on a holder terminal. [Figure 8] It is FIG. 3 showing an example of an image displayed on a holder terminal. [Figure 9] It is FIG. 4 showing an example of an image displayed on a holder terminal. [Figure 10] It is FIG. 5 showing an example of an image displayed on a holder terminal. [Figure 11] It is FIG. 6 showing an example of an image displayed on a holder terminal. [Figure 12] It is FIG. 7 showing an example of an image displayed on a holder terminal. [Figure 13] It is FIG. 8 showing an example of an image displayed on a holder terminal. [Figure 14] It is FIG. 9 showing an example of an image displayed on a holder terminal. [Figure 15] It is a sequence chart showing a processing procedure related to VC according to the present embodiment. [Figure 16] It is a flowchart showing in more detail the processing related to setting the VC expiration period.

Mode for Carrying Out the Invention

[0018] The embodiments of this disclosure will be described in detail below with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals, and their descriptions will not be repeated.

[0019] [Embodiment] <Overall Structure> Figure 1 shows the overall configuration of an information management system according to an embodiment of the present disclosure. The information management system 100 is configured to manage information using distributed identity (DID). The information management system 100 comprises an issuer server 1, a holder terminal 2, a verifier server 3, and a plurality of nodes 4. The components of the information management system 100 are connected to each other via a network NW such as the Internet, enabling communication between them.

[0020] Issuer Server 1 is a server operated by the issuer of verifiable credentials (VC). The issuer of VC is preferably an entity (such as a financial institution) with the capability and track record to perform identity verification. The issuer of VC may also be a government agency. Issuer Server 1 corresponds to the "server" in this disclosure.

[0021] Holder terminal 2 is a communication terminal operated by a holder (a user possessing attribute information). Holder terminal 2 is typically a mobile terminal. Mobile terminals include, for example, smartphones, tablets, notebook PCs (personal computers), and wearable devices (such as smartwatches). Holder terminal 2 may also be a fixed terminal such as a desktop PC. Holder terminal 2 corresponds to the "communication terminal" in this disclosure. Holder terminal 2 has software (hereinafter referred to as the "wallet app") installed for performing various DID-related processes (described later).

[0022] Verifier Server 3 is a server operated by a VC verifier. A VC verifier is a service provider that provides services to holders. The type of service is not particularly limited, but a verifier could be, for example, an insurance company (such as a life insurance company).

[0023] Multiple nodes 4 manage the DID using public distributed ledger technology. The following describes an example in which blockchain is used. Blockchain-based software is installed on each node 4. A blockchain network is formed by multiple nodes 4 communicating with each other via the network. The distributed ledger technology is not limited to blockchain and may include other distributed ledger technologies such as CORDA®. Decentralized Public Key Infrastructure (DPKI) software is also installed on multiple nodes 4. As described later, multiple nodes 4 accept registration of public keys from issuer server 1 or holder terminal 2 and provide public keys to verifier server 3.

[0024] Note that for simplicity, Figure 1 only shows one issuer server 1, one holder terminal 2, one verifier server 3, and four nodes 4, but the number of these devices is arbitrary. There may be many holder terminals 2. Also, the number of nodes that make up the blockchain network is usually much larger. Furthermore, issuer server 1 and / or verifier server 3 may also have node functionality and be part of the blockchain network.

[0025] Figure 2 is a block diagram showing a typical configuration example of issuer server 1. Issuer server 1 includes a processing unit (server body) 11, an input device 12, an output device 13, and a communication device 14. The processing unit 11 includes a processor 111, memory 112, storage 113, and a network interface 114. The components of issuer server 1 are connected to each other via a communication bus so that they can communicate with one another.

[0026] The processor 111 is, for example, a CPU (Central Processing Unit) or an MPU (Micro-Processing Unit). The memory 112 is volatile memory such as RAM (Random Access Memory). The storage 113 is rewritable non-volatile memory such as an HDD (Hard Disk Drive), SSD (Solid State Drive), or flash memory. The storage 113 stores a system program 51 including the OS (Operating System), a control program 52 including computer-readable code necessary for control calculations, VC data 53 for numerous folders of VCs, and a trust map 54 (described later). The storage area for the VC data 53 is also called the Identity Hub.

[0027] The processor 111 performs various processes by reading the system program 51 and the control program 52, loading them into memory 112, and executing them. The network interface 114 controls data communication between the issuer server 1 (arithmetic processing unit 11) and other devices (holder terminals 2, nodes 4, etc.) via the communication device 14.

[0028] In this specification, the term "processor" is not limited to processors that execute processing using stored programs, but may also include hardwired circuits such as ASICs (Application Specific Integrated Circuits) and FPGAs (Field-Programmable Gate Arrays). Therefore, the term "processor" can also be interpreted as processing circuitry in which processing is predefined by computer-readable code and / or hardwired circuits.

[0029] The input device 12 is a keyboard, mouse, or the like, and accepts input from an operator (such as an employee of the issuing company). The output device 13 is, for example, a display, and outputs various information (such as processing results) to the operator. The communication device 14 is configured to communicate with an external network NW, such as the Internet.

[0030] The holder terminal 2 and the verifier server 3 have essentially the same configuration as the publisher server 1, except for the data (programs, maps, etc.) stored in storage 113. Therefore, a detailed explanation of the configuration of the holder terminal 2 and the verifier server 3 will not be repeated.

[0031] <Decentralized Identity> Figure 3 is a conceptual diagram illustrating the relationships between information in a holder's decentralized identity. As mentioned above, the decentralized identifier (DID) 61 is an identifier used to manage a holder's decentralized identity. Hereafter, DID 61 will be referred to as "Holder DID".

[0032] When a holder DID is issued, a private key 62 is assigned and associated with the holder DID. The private key 62 is managed by the holder (the wallet app on the holder terminal 2), who is both the issuer and owner of the holder DID.

[0033] A holder DID is further associated with a metadata DID document 63. The DID document 63 includes a public key 631 corresponding to a private key 62, holder attribute information 632, and an endpoint 633 for accessing verifiable credentials (VC) 64. The holder DID and DID document 63 are registered on the blockchain.

[0034] Attribute information 632 can be classified into required fields that must be entered by the holder and optional fields that can be entered by the holder. Required fields include, for example, name, address, date of birth, telephone number, email address, and identity verification document information (driver's license information, passport information, etc.). Optional fields include, for example, bank account information, nationality, place of birth (which may also be place of origin), My Number card information (which varies by country, but may include My Number, Social Security Number, Taxpayer Number, etc.), overseas residency history, work history (occupation), and educational background. However, it should be noted that the distinction between required and optional fields here is merely illustrative.

[0035] Figure 4 is a conceptual diagram illustrating the relationships of information in a DID issued by Issuer Server 1. DID 71 is the distributed identifier of Issuer Server 1. To distinguish it from the Holder DID, DID 71 will be referred to as the "Issuer DID" below. The Issuer DID is associated with a private key 72 and a DID document 73. The DID document 73 contains a public key 731 corresponding to the private key 72. The Issuer DID and DID document 73 (public key 731) are also registered on the blockchain.

[0036] The holder DID corresponds to the "first distributed identifier" in this disclosure. The issuer DID corresponds to the "second distributed identifier" in this disclosure.

[0037] <vc> Figure 5 is a conceptual diagram illustrating the overview of a series of processes related to VC64 in the information management system 100. The numbers below correspond to the numbers indicated on the arrows in the figure. Figures 6 to 14 show examples of images displayed on the holder terminal 2 during each process. The series of processes will be explained below, divided into the DID registration phase, the VC issuance phase, and the VC utilization phase.

[0038] ≪DID Registration Phase≫ (1) DID registration The holder terminal 2 issues a holder DID and registers the holder DID and the DID document 63 on the blockchain. The DID document 63 includes the public key 631 and the holder's attribute information 632 (see Figure 3).

[0039] (2) Registration of DID and public key Issuer Server 1 issues an Issuer DID and registers the Issuer DID and DID Document 73 on the blockchain. DID Document 73 contains the public key 731 (see Figure 4).

[0040] ≪VC Issuance Phase≫ (3) Input of attribute information The holder launches the wallet app installed on holder terminal 2. The holder enters their own attribute information into the wallet app (see Figure 6). Holder terminal 2 (wallet app) confirms with the holder that the entered attribute information is correct (see Figure 7). If the holder confirms that the attribute information entered into holder terminal 2 is correct, holder terminal 2 saves the entered attribute information (see Figure 8). This process may be performed together with the registration of the DID as described in (1) above.

[0041] (4) Request to issue a VC The holder terminal 2 receives a holder operation requesting the issuance of a VC64 (see Figure 8). The holder terminal 2 then sends the VC issuance request to the issuer server 1. At this time, the holder terminal 2 sends to the issuer server 1 the information from the holder's attribute information that will be used for VC64 issuance (information entered or selected by the holder).

[0042] (5) KYC Issuer Server 1 performs online identity verification procedures, such as KYC (Know Your Customer) or eKYC (electronic Know Your Customer).

[0043] (6) VC issuance Once the issuer server 1 completes identity verification through KYC, it issues a VC64 for the attribute information that has been confirmed to be correct. The holder terminal 2 receives notification from the issuer server 1 that identity verification is complete and a VC64 has been issued (see Figure 9).

[0044] (7)VC storage The holder terminal 2 stores the VC64 issued by the issuer server 1. This allows the holder to view a certificate screen indicating that the issuer server 1 has completed verifying the holder's attribute information (i.e., the holder's identity has been verified) (see Figure 10).

[0045] ≪VC Utilization Phase≫ (8) Request for provision of attribute information If a holder wishes to receive services from a verifier, the verifier server 3 sends a request to the holder terminal 2 for the holder to provide its attribute information to the verifier (a request to share the holder's attribute information between the holder and the verifier). For example, the verifier server 3 sends a QR code (registered trademark) to the holder terminal 2 indicating the web page that the holder terminal 2 should access.

[0046] (9) VC presentation The holder terminal 2 reads the QR code received from the verifier server 3 and accesses the webpage indicated by the QR code (see Figure 11). The verifier's regulations regarding the handling of personal information (privacy policy) are then displayed on the holder terminal 2 (see Figure 12). In addition, the types of attribute information provided by the holder to the verifier (attribute information shared between the holder and the verifier) ​​are displayed on the holder terminal 2 (see Figure 13). Once the holder agrees to the verifier's privacy policy and the types of attribute information provided to the verifier, the holder terminal 2 presents VC64 to the verifier server 3.

[0047] (10) VC verification Verifier server 3 cryptographically verifies whether the VC64 presented by the holder is legitimate and issued by the issuer, using issuer server 1's public key 731.

[0048] (11) Service provision If the verification confirms the legitimacy of VC64, the verifier server 3 notifies the holder terminal 2 that the holder's identity verification is complete. As a result, information indicating that the holder's identity verification is complete is displayed on the holder terminal 2 (see Figure 14). Subsequently, the verifier server 3 begins providing services to the holder terminal 2.

[0049] <Setting the validity period> In the information management system 100 described above, it is desirable to strengthen the prevention of fraud against VC64. Therefore, in this embodiment, the issuer server 1 sets an effective period (or expiration date) for VC64. The effective period means the length of time during which VC64 is valid (for example, one year). The expiration date means the end of the time during which VC64 is valid (for example, December 31st, 23:59:59).

[0050] In the following, the validity period set for VC64 will be referred to as the "VC validity period," and will be explained accordingly. However, since setting a shorter validity period is equivalent to setting an earlier expiration date, the validity period can be changed to the expiration date. Note that the term "validity period" in this disclosure includes the concept of the expiration date.

[0051] Referring again to Figure 3, VC64 includes the issuer DID (DID71), the digital signature 641 generated using the issuer server 1's private key 72, and the VC validity period 642. As can be seen from Figure 3, the VC validity period 642 is associated with the holder DID by being included in VC64.

[0052] When the VC validity period 642 expires, as will be explained in detail later, the issuer server 1 reissues VC64. Therefore, the digital signature 641, generated using the latest encryption technology, is included in VC64. Thus, protection against fraud against VC64 is strengthened.

[0053] It is desirable for issuer server 1 to determine which of several groups, defined according to the level of trustworthiness, a holder belongs to based on the holder's attribute information. In this example, the multiple groups include groups 1 through 3. Holders belonging to group 1 have the highest trustworthiness. Holders belonging to group 2 have the next highest trustworthiness. Holders belonging to group 3 have the lowest trustworthiness. Furthermore, the VC validity period is longest in the order of group 1 through 3. In other words, the higher the trustworthiness of a holder, the longer the VC validity period. It can also be said that the lower the trustworthiness of a holder, the shorter the VC validity period.

[0054] If the holder's trustworthiness is low, setting a shorter VC validity period will cause the deadline for VC64 renewal (VC expiration date) to arrive earlier. When this deadline arrives and VC64 is reissued, the issuing server 1 can perform identity verification of the holder again. This strengthens the prevention of fraud against VC64. On the other hand, if the holder's trustworthiness is high, setting a longer VC validity period will reduce the administrative burden on the issuing server 1 of performing an excessive number of identity verifications of the holder.

[0055] <Processing Flow> Figure 15 is a sequence chart showing the processing procedure for VC64 according to this embodiment. In the figure, the left side shows the processing performed by the issuer server 1, the center shows the processing performed by the holder terminal 2 (wallet application), and the right side shows the processing performed by the verifier server 3. Hereafter, steps will be abbreviated as "S".

[0056] ≪DID Registration Phase≫ In S1, the holder terminal 2 registers the holder DID on the blockchain (one of the multiple nodes 4 that form the blockchain network). In S2, the issuer server 1 registers the issuer DID and public key 731 on the blockchain. These processes may be performed in advance. Furthermore, the order of these processes is not particularly limited and may be reversed.

[0057] ≪VC Issuance Phase≫ In S3, the holder terminal 2 registers the holder's attribute information in the wallet application according to the holder's operation (see Figures 6-8). This process may also be performed in advance.

[0058] In S4, the holder terminal 2 sends a VC issuance request to the issuer server 1 according to the operation performed by the holder. The VC issuance request includes the holder DID and attribute information (including identity verification document information) entered by the holder.

[0059] In S5, issuer server 1 performs Know Your Customer (KYC) verification of the holder. More specifically, issuer server 1 verifies that the attribute information entered by the holder (such as name, address, and date of birth) is correct (i.e., that the holder who made the VC issuance request is the person in question) by comparing it with the information on the identity verification documents. Issuer server 1 may also use a KYC service provided by an external vendor for the identity verification process. Here, we assume that the holder's identity verification has been successfully completed.

[0060] In S6, issuer server 1 sets the VC validity period based on the holder's attribute information.

[0061] Figure 16 is a flowchart that shows in more detail the process related to setting the VC validity period (process S6). The process shown in this flowchart is executed by Issuer Server 1.

[0062] Issuer Server 1 has, for example, a credit score map 54 (see Figure 2) in which the correspondence between attribute information and groups is defined according to the level of creditworthiness. The credit score map 54 may be created, for example, according to the risk classification from the perspective of anti-money laundering and countering the financing of terrorism, which is commonly implemented by financial institutions. More specifically, financial institutions are legally required to handle customers appropriately according to their risk classification. Therefore, financial institutions determine the risk classification (high risk, medium risk, low risk) based on the customer's attribute information when verifying the customer's identity during the first transaction. Thereafter, financial institutions review the risk classification when there are transactions that affect the customer's risk classification, and also review the risk classification periodically (continuous customer management). By creating the credit score map 54 according to such a risk classification, the issuer can create the credit score map 54 without incurring any additional administrative burden.

[0063] Issuer server 1 reads the credit score map 54 (S61). By referring to the credit score map 54, issuer server 1 determines the group to which the holder belongs based on the holder's attribute information (S62). Attribute information that can be used as arguments here includes, for example, age, address, bank account information, nationality, overseas residency history, and work history.

[0064] In S63, issuer server 1 determines which of the three groups the holder belongs to. If the holder belongs to the first group ("first group" in S63), issuer server 1 sets the VC validity period to T1 (S64). If the holder belongs to the second group ("second group" in S63), issuer server 1 sets the VC validity period to T2 (S65). If the holder belongs to the third group ("third group" in S63), issuer server 1 sets the VC validity period to T3 (S66). Here, T1 > T2 > T3.

[0065] Referring again to Figure 15, in S7, issuer server 1 issues VC64, for which the VC validity period was set in S6. More specifically, issuer server 1 associates the digital signature 641 and VC validity period 642 with the DID document 63 using the private key 72 corresponding to the public key 731 registered on the blockchain. Issuer server 1 notifies holder terminal 2 that identity verification is complete and the VC has been issued (see Figure 9). Holder terminal 2 saves the VC issued by issuer server 1 to its storage (S8). This allows holder terminal 2 to display the certificate screen (see Figure 10).

[0066] ≪VC Utilization Phase≫ In S9, holder terminal 2 requests the verifier server 3 to provide the verifier with the service.

[0067] In S10, the verifier server 3 requests holder terminal 2 to provide (share) the holder attribute information necessary for providing the service. More specifically, the verifier server 3 sends holder terminal 2 a link to the web page that holder terminal 2 should access or a QR code (registered trademark).

[0068] In S11, the holder terminal 2 reads the QR code received from the verifier server 3 (see Figure 11) and displays the verifier's privacy policy and the types of attribute information provided to the verifier (see Figures 12 and 13). When the holder terminal 2 accepts a holder operation indicating agreement to the displayed content, it presents the VC to the verifier server 3 (S12). More specifically, the holder terminal 2 sends the holder DID associated with VC64 to the verifier server 3.

[0069] In S13, the verifier server 3 verifies the VC presented by the holder terminal 2. More specifically, the verifier server 3 obtains the issuer's public key 731 by retrieving the DID document 73 from the blockchain (one of the multiple nodes 4 that make up the blockchain network) using the issuer DID contained in VC64 as an argument. Then, the verifier server 3 decrypts the digital signature 641 contained in VC64 with the issuer's public key 731. Once the VC verification is successfully completed, the verifier server 3 begins providing services to the holder terminal 2 (S14).

[0070] As described above, in this embodiment, a validity period (or expiration date) is set for VC64. When the validity period ends (the expiration date arrives), the issuer server 1 reissues (renews) VC64 in response to a request for another VC issuance from the holder terminal 2. Therefore, the digital signature 641 generated using the latest encryption technology is included in VC64. Thus, according to this embodiment, protection against fraud against VC64 can be strengthened.

[0071] Furthermore, in this embodiment, if the holder's trustworthiness is low, the VC validity period is set to be shorter. This causes the validity period to end earlier, increasing the frequency of VC64 updates. When updating VC64, the issuer server 1 can re-verify the identity of holders with low trustworthiness. This further strengthens the prevention of fraud against VC64. On the other hand, if the holder's trustworthiness is high, the VC validity period is set to be longer. This suppresses an excessive increase in the frequency of VC64 updates and reduces the administrative burden of verifying the identity of holders with high trustworthiness.

[0072] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of this disclosure is indicated by the claims rather than by the description of the embodiments above, and all modifications within the meaning and scope equivalent to the claims are intended to be included. [Explanation of Symbols]

[0073] 100 Information Management System, 1 Issuer Server, 11 Processing Unit, 111 Processor, 112 Memory, 113 Storage, 114 Network Interface, 12 Input Device, 13 Output Device, 14 Communication Device, 2 Holder Terminal, 3 Verifier Server, 4 Node, 51 System Program, 52 Control Program, 53 VC Data, 54 Trust Map, 61 DID (Holder DID), 62 Private Key, 63 DID Document, 631 Public Key, 632 Attribute Information, 633 Endpoint, 64 VC, 641 Digital Signature, 642 VC Validity Period, 71 DID (Issuer DID), 72 Private Key, 73 DID Document, 731 Public Key.< / vc>

Claims

1. An information management system, Equipped with a server, The aforementioned server, A communication device configured to communicate with the holder's communication terminal, The system includes a processor that issues verifiable credentials in response to an issuance request from the aforementioned communication terminal, The issuance request includes attribute information of the holder and a first distributed identifier which is the distributed identifier of the holder. The processor sets an expiration period for the verifiable credentials based on the attribute information of the holder, and associates the set expiration period with the first distributed identifier. The information management system further comprises a verifier server that verifies the verifiable credentials from the communication terminal, The aforementioned server and the aforementioned verifier server are both capable of accessing a distributed ledger network that includes a distributed ledger. The processor registers the public key corresponding to the private key in the distributed ledger. The processor includes a second distributed identifier, which is the distributed identifier of the server, and an electronic signature generated using the private key, in the verifiable credentials. An information management system in which, upon receiving the verifiable credentials from the communication terminal, the verifier server retrieves the public key from the distributed ledger based on the second distributed identifier contained in the verifiable credentials, and verifies the digital signature using the public key.

2. The attribute information includes the information entered by the holder and the identity verification document information of the holder. The information management system according to claim 1, wherein the processor issues the verifiable credentials when the identity of the holder is successfully verified by comparing the information input by the holder with the identity verification document information.

3. The aforementioned processor, Based on the attribute information of the holder, it is determined which of several groups with different credit ratings the holder belongs to. The information management system according to claim 2, wherein the effective period is extended when the holder belongs to the group with high creditworthiness compared to when the holder belongs to the group with low creditworthiness.

Images