Wallet device and wallet management method

Abstract

This wallet device for managing credential information includes a wallet management unit for determining that credential information is to be reacquired when a public key of hardware associated with the wallet device is different from a public key included in the qualification information held by the wallet device.

Description

Wallet device and wallet management method

[0001] The present invention relates to a cloud wallet technology for managing digital identities.

[0002] In recent years, the concept of Self-Sovereign Identity (SSI) and the technologies to realize it (W3C Decentralized Identifiers (DID), W3C Verifiable Credentials (VC), etc.) have been considered as a new approach to identity management, in which users manage their own identifiers and identities and control who provides them, without relying on centralized identity providers (ID providers).

[0003] In the world of SSI, there are three parties: Holder, Issuer, and Verifier. A Holder is a user who manages / holds their own digital identity. An Issuer certifies attribute information (name, age, address, etc.) and qualification information (employee of a certain company, membership of a certain service, etc.) to a user, etc., and then issues an attribute / qualification certificate (VC). A Verifier verifies the Holder's attributes, qualifications, etc. by requesting and receiving the attribute / qualification certificate (VC) required to provide a service from the Holder, and makes decisions on providing the service, etc.

[0004] Various binding methods have been studied to show that this VC has been issued to a Holder and presented by that Holder. One of them is a method of showing the association between a VC and a Holder by binding the VC to a device (hardware) equipped with a wallet for storing the VC held by the Holder (Non-Patent Document 1).

[0005] Device binding draft, https: / / github.com / decentralized-identity / wallet-security / blob / main / work_items / device_binding.md, Internet, retrieved April 16, 2024

[0006] In the technology disclosed in Non-Patent Document 1, it is assumed that the device equipped with the wallet that is the target of binding with VC is a terminal held by the user. Meanwhile, it is expected that cloud wallets, which operate in the cloud, will become widespread in the future.

[0007] However, in the case of cloud, there is a possibility that the hardware on which the wallet operates may be changed, making it difficult to apply the technology disclosed in Non-Patent Document 1 to cloud wallets. In other words, with the technology disclosed in Non-Patent Document 1, if the hardware on which the wallet operates is changed, the VC and the hardware will no longer correspond, and authentication by the verifier will fail.

[0008] The present invention has been made in consideration of the above points, and aims to provide a technology that enables appropriate authentication using qualification information such as VC even when the hardware on which the wallet operates is changed.

[0009] According to the disclosed technology, there is provided a wallet device that manages credential information, the wallet device including a wallet management unit that determines to re-acquire the credential information when a public key of hardware associated with the wallet device differs from a public key included in the credential information held by the wallet device.

[0010] The disclosed technology provides a technology that enables appropriate authentication using qualification information such as VC even when the hardware on which the wallet operates is changed.

[0011] 1 is a diagram showing an image of association in technology. A diagram for explaining the problem. A diagram showing a hardware binding sequence based on Non-Patent Document 1. A diagram showing a hardware binding sequence based on Non-Patent Document 1. A diagram showing a hardware binding sequence based on Non-Patent Document 1. A diagram for explaining an overview of the operation according to this embodiment. A diagram showing an example of a procedure when reissuing at wallet startup. A diagram showing an example of a procedure when reissuing at wallet startup. A diagram showing an example of a procedure when reissuing at wallet startup. A diagram showing an example of a procedure when reissuing at VC presentation. A diagram showing an example of a procedure when reissuing at VC presentation. A diagram showing an example of a procedure when reissuing at VC presentation. A diagram showing an example of a configuration of a cloud wallet device 100. A diagram showing an example of an operating procedure in Example 1. A diagram showing an example of an operating procedure in Example 2. A diagram showing an example of a hardware configuration of the device.

[0012] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applied is not limited to the following embodiment.

[0013] Below, we will explain a technology that enables appropriate authentication using credentials such as VC even when the device equipped with the wallet is not a terminal owned by the Holder but is hardware that can be changed in the cloud. First, we will explain in more detail the conventional technology and its problems, and then we will explain the technology related to this embodiment.

[0014] (Regarding conventional technology and issues) The Identity Foundation (DIF) Wallet Security Working Group (https: / / github.com / decentralized-identity / wallet-security) has been studying Device Binding (Non-Patent Document 1: https: / / github.com / decentralized-identity / wallet-security / blob / main / work_items / device_binding.md). An illustration of the association in this technology is shown in Figure 1. In the conventional binding method shown in Figure 1, binding between the VC, device, and Holder is performed by including in the VC a public key generated by the hardware of the device on which the wallet operates.

[0015] However, it is difficult to apply the conventional technology disclosed in Non-Patent Document 1 to a configuration in which a wallet operates in the cloud. The reason is that in the case of a cloud, the hardware on which the wallet operates may be changed, and the wallet may be operating on hardware different from that when the VC was issued.

[0016] The above problem will be described with reference to Fig. 2. The upper part of Fig. 2 shows the procedure in the technology disclosed in Non-Patent Document 1, and the lower part shows the procedure when this technology is implemented in a cloud environment.

[0017] In the upper part, S1 (step 1), the user (holder) device transmits a public key generated from the hardware to the issuer. In S2, the issuer issues a VC including the public key to the device. In S3, the device presents the VC including the public key to the verifier. In S4, the verifier authenticates the device by a challenge-response using the public key.

[0018] The bottom part of Figure 2 shows the case where the wallet is cloud-based. Here, we assume that the server (a hardware example) on which the wallet runs when the VC is issued is different from the server on which the wallet runs when the VC is authenticated. In this case, the public key will be different between when the VC is issued and when the VC is authenticated, so authentication will fail.

[0019] (Example of Hardware Binding) Here, in order to explain the problem more clearly, the sequence of hardware binding based on Non-Patent Document 1 will be explained with reference to Figures 3 to 5. Note that Non-Patent Document 1 itself is publicly known, but Figures 3 to 5 themselves are not publicly known. Furthermore, in the explanation of Figures 3 to 5, "three-party authentication" may be replaced with "certification," "two-party authentication" with "authentication," "proof" with "attestation," and "credentials" with "credential." Furthermore, in the explanation of Figures 3 to 5, it is assumed that the wallet 10 is an application that runs on a device (terminal) held by a user.

[0020] In FIG. 3, steps S11 to S13 are the initial setting steps, and steps S14 to S20 are the authentication / certification steps.

[0021] 3, the certifying entity 40 performs a wallet audit and three-party authentication for the wallet 10. The certifying entity 40 is an entity that performs authentication, and may be called an "authentication device."

[0022] In S12, the Certifying entity 40 registers the wallet and the three-party certificate in the Trust registry 50. The Trust registry 50 is a trusted storage device and may also be referred to as a "storage device." In S13, the Issuer 20 requests the Trust registry 50 for wallet information that the Issuer 20 requires.

[0023] At S14, the user installs the wallet on the device. At S15, the wallet 10 requests a wallet two-party authentication VC from the Certifying entity 40. At S16, application attestation (SafetyNet / DeviceChecker) is performed between the wallet 10 and the Certifying entity 40. At S17, the wallet 10 generates a hardware-backed key.

[0024] In S18, the wallet 10 transmits the wallet certificate, the key, and the key certificate to the certifying entity 40. In S19, the certifying entity 40 checks the certificates of the app and the key. In S20, the certifying entity 40 issues wallet bilateral authentication credentials to the wallet 10.

[0025] Through the above-described process, the wallet 10 is bound to the hardware and two-party authentication is performed. In this method, since the wallet 10 and the hardware are bound, if the wallet 10 is moved to another piece of hardware, two-party authentication must be obtained again.

[0026] The issuance sequence based on Non-Patent Document 1 will be described with reference to Fig. 4. In S31, the Issuer 20 requests the wallet function from the wallet 10. In S32, the wallet 10 notifies the Issuer 20 of the wallet security function.

[0027] In S33, Issuer 20 requests wallet bilateral authentication credentials from wallet 10. In S34, wallet 10 presents the wallet bilateral authentication credentials to Issuer 20.

[0028] In S35, the Issuer 20 requests a challenge from the wallet 10. In S36, the wallet 10 presents the Issuer 20 with a challenge response using a hardware key.

[0029] In S37, Issuer 20 checks the two-party authentication of the wallet and checks the challenge response.

[0030] In S38, Issuer 20 proposes issuing credentials bound to a hardware key to the wallet 10. In S39, the wallet 10 requests Issuer 20 to issue credentials bound to a hardware key. In S40, Issuer 20 issues credentials bound to a hardware key to the wallet 10.

[0031] In steps S38 to S40 above, the VC (referred to as "credentials" in Figure 4) is bound to the hardware and issued. In this method, since the wallet and VC are bound to the hardware, if the wallet is moved to another piece of hardware, it is necessary to re-acquire the wallet two-party authentication and VC.

[0032] Next, the verification sequence will be described with reference to Fig. 5. In S51, the verifier 30 requests the wallet function from the wallet 10. In S52, the wallet 10 notifies the verifier 30 of the wallet security function.

[0033] Next, steps S53 to S55 are performed as optional steps. In S53, the verifier 30 requests wallet bilateral authentication credential information from the wallet 10. In S54, the wallet 10 displays the wallet bilateral authentication credential information to the verifier 30. In S55, the verifier 30 checks the wallet bilateral authentication.

[0034] In S56, the verifier 30 requests the wallet 10 to display the credential information bound to the hardware key. In S57, the wallet 10 displays the credential information bound to the hardware key to the verifier 30. In S58, a challenge-response procedure is executed between the verifier 30 and the wallet 10. Here, the "challenge-response procedure" refers to the exchange of a challenge request and a challenge response.

[0035] In steps S56 and S57, verification is performed using the credentials bound to the hardware. However, since the wallet and the credentials are bound to the hardware, if the wallet is moved to another hardware, the verification of the credentials will fail.

[0036] The following describes a technique according to the present embodiment for solving the above problems.

[0037] (Technology related to this embodiment) In this embodiment, the wallet re-acquires a VC including a new public key for the hardware (HW) (the issuer re-issues the VC) at the timing of (1) or (2) below.

[0038] (1) When the wallet is started on different hardware.

[0039] (2) When a VC is presented from a wallet, it is discovered that the public key included in the VC is different from the public key of the current hardware.

[0040] An overview of the operation when re-acquiring a VC at timing (1) above is shown in Figure 6. In Figure 6, when the VC is issued in S1 and S2, the user's wallet operates on HW1. Then, in S3, the wallet starts up on HW2. Therefore, in S4, a VC including the public key of HW2 is reissued. Then, in S5, a VC including the public key of HW2 is presented, and authentication is successful in S6.

[0041] Below, we will explain, with reference to Figures 7 to 12, how VC reacquisition (reissuance) at timing (1) above and VC reacquisition (reissuance) at timing (2) are performed within the above-mentioned hardware binding processing (Figures 3 to 5).

[0042] In Figures 7 to 12, the "wallet 10" in Figures 3 to 5 is replaced with a "cloud wallet device 100." The cloud wallet device 100 is a device realized by running a wallet application (wallet AP) on the cloud. The cloud wallet device 100 may also be called a "wallet device," a "cloud wallet system," a "wallet," etc. The wallet AP may also be called a "wallet instance."

[0043] The cloud wallet device 100 is linked to hardware (HW). Linking the cloud wallet device 100 to HW means, for example, that the cloud wallet device 100 (wallet AP) starts (operates) on the HW. When the cloud wallet device 100 starts (operates) on the HW, the cloud wallet device 100 uses the public key and private key corresponding to the HW.

[0044] Furthermore, the cloud wallet device 100 being linked to HW may mean that the cloud wallet device 100 does not start up (operate) on the HW, but the public key and private key used by the cloud wallet device 100 correspond to the HW. The configuration of the cloud wallet device 100 will be described later with reference to FIG. 13 .

[0045] ((1) Reissuing when wallet is started) First, the processing procedure for "(1) Reissuing when wallet is started" will be described with reference to FIGS.

[0046] S101 to S103 in Fig. 7 are the same as S11 to S13 in Fig. 3. In S104, the cloud wallet operator starts up a wallet instance on a server (example of hardware). S105 to S110 in Fig. 7 are the same as S15 to S20 in Fig. 3.

[0047] The issuance sequence is shown in Figure 8. In this embodiment, when the cloud wallet device 100 detects that the hardware linked to the cloud wallet device 100 has changed when the cloud wallet device 100 is started up, the authentication / certification process (S105 to S110) in Figure 7 (A) is executed. This proves that the cloud wallet device 100 is bound to the new hardware after the change. S121 to S130 in Figure 8 are the same as S31 to S40 in Figure 4.

[0048] The verification sequence is shown in Figure 9. When the cloud wallet device 100 detects that the hardware linked to the cloud wallet device 100 has changed when the cloud wallet device 100 is started up, the authentication / certification process (S105 to S110) in Figure 7 (A) and the issuance process (S121 to S130) in Figure 8 (B) are executed. This allows the cloud wallet device 100 to hold a VC that includes the public key of the new hardware after the change. S141 to S148 in Figure 9 are the same as S51 to S58 in Figure 5.

[0049] ((2) Reissuing When VC is Presented) Next, with reference to FIGS. 10 to 12, a hardware binding processing procedure in the case of "(2) Reissuing When VC is Presented" will be described.

[0050] S151 to S153 in Fig. 10 are the same as S11 to S13 in Fig. 3. In S154, the cloud wallet operator starts up a wallet instance on the server. S155 to S160 in Fig. 10 are the same as S15 to S20 in Fig. 3.

[0051] The issuing sequence is shown in Fig. 11. Steps S171 to S180 in Fig. 11 are the same as steps S31 to S40 in Fig. 4.

[0052] The verification sequence is shown in Fig. 12. Steps S191 to S196 in Fig. 12 are the same as steps S51 to S56 in Fig. 5.

[0053] The cloud wallet device 100, triggered by the request of S196, checks whether the hardware linked to the cloud wallet device 100 has changed, and if it detects that the hardware has changed, it executes the authentication / certification process (S156 to S160) in Fig. 10 (A) and the issuance process (S171 to S180) in Fig. 11 (B). This allows the cloud wallet device 100 to hold a VC that includes the public key of the new hardware after the change. S197 to S198 in Fig. 12 are the same as S57 to S58 in Fig. 5.

[0054] (System Configuration Example) Fig. 13 shows a configuration example of the cloud wallet device 100 in this embodiment. Fig. 13 also shows the Holder 12, Issuer 20, and Verifier 30 that communicate with the cloud wallet device 100. The Holder 12 is, for example, a terminal held by a user. The Issuer 20 and Verifier 30 are, for example, each a server.

[0055] As shown in Fig. 13, the cloud wallet device 100 includes hardware (HWj) associated with the cloud wallet device 100. In Fig. 13, PBLC_key indicates a public key, PRVT_key indicates a private key (which may also be called a secret key), PBLC_keyj indicates a public key of HWj, and PRVT_keyj indicates a private key of HWj.

[0056] The cloud wallet device 100 also includes a wallet management unit 130 , a VC request unit 110 , a VC receiving unit 120 , a VC presenting unit 140 , a VC authenticating unit 150 , a VC issuance receiving unit 170 , and a VC issuance notifying unit 180 .

[0057] Furthermore, the cloud wallet device 100 that has performed the VC issuance process holds the VC including the public key. In this embodiment, when the HW linked to the cloud wallet device 100 is changed, the VC already held by the cloud wallet device 100 is assumed to be inherited by the changed HW.

[0058] For example, if a cloud wallet device 100 operating on HW-A holds VC-A, and the HW is changed so that the cloud wallet device 100 operates on HW-B, the cloud wallet device 100 operating on HW-B will hold VC-A.

[0059] The wallet management unit 130 manages the cloud wallet device 100. The VC request unit 110 requests the issuer 20 to issue a VC. The VC reception unit 120 receives the VC issued by the issuer 20.

[0060] The VC presentation unit 140 presents to the Verifier 30 a VC including the public key of the HW 160 linked to the cloud wallet device 100 (for example, the HW on which the cloud wallet device 100 is running). The VC authentication unit 150 sends and receives a challenge request / challenge response. The VC issuance reception unit 170 receives a VC issuance request from the Holder 12. The VC issuance notification unit 150 notifies the Holder 12 that the VC has been issued.

[0061] The wallet management unit 130 determines whether the public key in the VC held by the cloud wallet device 100 is different from the public key of the HW 160 linked to the cloud wallet device 100, and if they are different, re-acquires the VC using the public key of the HW 160 linked to the cloud wallet device 100. Regarding re-acquisition of the VC, more specifically, the wallet management unit 130 instructs the VC request unit 110 and the VC receiving unit 120 to re-acquire, but "instructing to re-acquire" may be considered as "performing re-acquisition."

[0062] FIG. 13 shows the process of issuing and verifying a VC when the public key of HWi (=HWj) is used.

[0063] Hereinafter, a specific example of a procedure for updating a VC when a wallet is started will be described as Example 1, and a specific example of a procedure for updating a VC when a VC is presented will be described as Example 2.

[0064] (Example 1: VC update performed when wallet is started) First, Example 1 will be described with reference to Fig. 14. Fig. 14 is a diagram showing an example of a sequence when a VC is issued and when content is used. S201 to S205 correspond to the operation when a VC is issued, and S206 to S212 correspond to the operation when content is used.

[0065] In S201, a VC issuance request is sent from Holder 12. In S202, a wallet application (wallet AP) is started. Here, the wallet AP is started on the HWi. In other words, the cloud wallet device 100 operates on the HWi.

[0066] In S203, the cloud wallet device 100 sends a VC issuance request to the Issuer 20. This VC issuance request includes public key i, which is the public key of HWi. In S204, the Issuer 20 issues a VC including public key i to the cloud wallet device 100. In S205, Next, the operation when using content will be explained. In S206, the wallet AP (cloud wallet device 100) is started. Here, it is assumed that the wallet AP is started on HWj. In other words, the cloud wallet device 100 operates on HWj. In addition, the VC already acquired by the cloud wallet device 100 operating on HWi is taken over by the cloud wallet device 100 operating on HWj.

[0067] When the cloud wallet device 100 detects that the public key in the VC it ​​already holds does not match the public key of the HW on which the cloud wallet device 100 is currently running, it decides to reacquire all VCs.

[0068] The cloud wallet device 100 executes S207 and S208 for each VC to be reacquired. In S207, the cloud wallet device 100 sends a VC issuance request to the Issuer 20. This VC issuance request includes public key j, which is the public key of HWj. In S208, the Issuer 20 issues a VC including public key j to the cloud wallet device 100.

[0069] In S209, the Holder 12 transmits a content request to the cloud wallet device 100.

[0070] In S210, the cloud wallet device 100 transmits a content request to the verifier 30. The content request includes a VC including the public key j of the HWj on which the cloud wallet device 100 is running.

[0071] In S211, a challenge request / challenge response is exchanged between the cloud wallet device 100 and the verifier 30. Specifically, the verifier 30 sends the cloud wallet device 100 a challenge request including encrypted authentication data encrypted using public key j. The cloud wallet device 100 decrypts the authentication data using private key j corresponding to public key j, and sends the verifier 30 a challenge response including the decrypted authentication data. The verifier 30 checks the challenge response and confirms that it is OK. If it is OK, it means that it has been confirmed that the binding between the HW on which the cloud wallet device 100 runs and the VC is correct.

[0072] In S212, the Verifier 30 provides the content to the Holder 12.

[0073] (Embodiment 2: VC update performed when VC is presented) Next, embodiment 2 will be described with reference to Fig. 15. Fig. 15 is a diagram showing an example of a sequence when a VC is issued and when content is used. S221 to S255 correspond to the operation when a VC is issued, and S226 to S233 correspond to the operation when content is used.

[0074] In S221, a VC issuance request is sent from Holder 12. In S222, a wallet application (wallet AP) is started. Here, the wallet AP is started on the HWi. In other words, the cloud wallet device 100 operates on the HWi.

[0075] In S223, the cloud wallet device 100 sends a VC issuance request to the Issuer 20. This VC issuance request includes public key i, which is the public key of HWi. In S224, the Issuer 20 issues a VC including public key i to the cloud wallet device 100. In S225, the cloud wallet device 100 sends a VC issuance notification to the Holder 12.

[0076] Next, the operation when using content will be explained. In S226, the wallet AP (cloud wallet device 100) is started. Here, it is assumed that the wallet AP is started on HWj. In other words, the cloud wallet device 100 operates on HWj. Furthermore, the VC already acquired by the cloud wallet device 100 operating on HWi is taken over by the cloud wallet device 100 operating on HWj.

[0077] In S227, the Holder 12 transmits a content request to the cloud wallet device 100.

[0078] In S228, when the cloud wallet device 100 detects that the public key in the VC already held does not match the public key of the HW on which the cloud wallet device 100 is currently running, it decides to re-acquire the VC corresponding to the content related to the content request in S227.

[0079] The cloud wallet device 100 executes S229 and S230 for the VC to be reacquired. In S229, the cloud wallet device 100 sends a VC issuance request to the Issuer 20. This VC issuance request includes public key j, which is the public key of HWj. In S230, the Issuer 20 issues a VC including public key j to the cloud wallet device 100.

[0080] In S231, the cloud wallet device 100 transmits a content request to the verifier 30. The content request includes a VC including the public key j of the HWj on which the wallet (cloud wallet device 100) is running.

[0081] In S232, a challenge request / challenge response is exchanged between the cloud wallet device 100 and the verifier 30. Specifically, the verifier 30 sends the cloud wallet device 100 a challenge request including encrypted authentication data encrypted using public key j. The cloud wallet device 100 decrypts the authentication data using private key j corresponding to public key j, and sends the verifier 30 a challenge response including the decrypted authentication data. The verifier 30 checks the challenge response and confirms that it is OK. If it is OK, it means that it has been confirmed that the binding between the HW on which the cloud wallet device 100 runs and the VC is correct.

[0082] In S233, the Verifier 30 provides the content to the Holder 12.

[0083] (Hardware Configuration Example) The cloud wallet device 100 (which may also be called a wallet device) described in this embodiment can be realized, for example, by having a computer execute a program. This computer may be a physical computer or a virtual machine on the cloud.

[0084] That is, the cloud wallet device 100 can be realized by using hardware resources such as a CPU and memory built into a computer to execute a program corresponding to the processing performed by the cloud wallet device 100. The program can be recorded on a computer-readable recording medium (such as a portable memory) and can be saved or distributed. The program can also be provided via a network such as the Internet or email.

[0085] Fig. 16 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 16 includes a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, and the like, all of which are interconnected via a bus B. The computer may further include a GPU.

[0086] The program that realizes the processing on the computer is provided by a recording medium 1001, such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

[0087] The memory device 1003 reads and stores the program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes functions related to the cloud wallet device 100 in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network, etc. The display device 1006 displays a GUI (Graphical User Interface) or the like according to the program. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, etc., and is used to input various operation instructions. The output device 1008 outputs the results of calculations.

[0088] (Summary of the embodiment, effects, etc.) As explained above, the technology described in this embodiment makes it possible to properly perform authentication using qualification information such as VC even when the hardware on which the wallet operates is changed.

[0089] The following additional notes are provided regarding the above-described embodiments.

[0090] <Additional Notes> (Additional Item 1) A wallet device that manages credential information, comprising: a wallet management unit that determines to re-acquire the credential information when a public key of hardware associated with the wallet device differs from a public key included in the credential information held by the wallet device. (Additional Item 2) The wallet device according to Additional Item 1, wherein the wallet management unit determines, when the wallet device is started, whether the public key of the hardware differs from a public key included in the credential information held by the wallet device, and if they differ, determines to re-acquire the credential information. (Additional Item 3) The wallet device according to Additional Item 1, wherein, when an event occurs that requires the presentation of the credential information, the wallet management unit determines whether the public key of the hardware differs from a public key included in the credential information held by the wallet device, and if they differ, determines to re-acquire the credential information. (Supplementary Item 4) A wallet management method executed by a wallet device that manages credential information, the wallet management method determining to re-acquire the credential information when a public key of hardware associated with the wallet device differs from a public key included in the credential information held by the wallet device.

[0091] Although the present embodiment has been described above, the present invention is not limited to such a specific embodiment, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims.

[0092] 12 Holder 20 Issuer 30 Verifier 40 Certifying entity 50 Trust registry 10 Wallet 100 Cloud wallet device 110 VC request unit 120 VC receiving unit 130 Wallet management unit 140 VC presentation unit 150 VC authentication unit 160 Hardware 170 VC issuance receiving unit 180 VC issuance notification unit 1000 Drive device 1001 Recording medium 1002 Auxiliary storage device 1003 Memory device 1004 CPU 1005 Interface device 1006 Display device 1007 Input device 1008 Output device

Claims

1. A wallet device that manages credential information, comprising: a wallet management unit that determines to re-acquire the credential information when a public key of hardware associated with the wallet device differs from a public key included in the credential information held by the wallet device.

2. The wallet device according to claim 1, wherein, when the wallet device is started up, the wallet management unit determines whether the public key of the hardware differs from the public key included in the credential information held by the wallet device, and if they differ, decides to re-acquire the credential information.

3. The wallet device according to claim 1, wherein, when an event occurs that requires the presentation of the credentials, the wallet management unit determines whether the public key of the hardware differs from the public key included in the credentials held by the wallet device, and if they differ, decides to re-acquire the credentials.

4. A wallet management method executed by a wallet device that manages credential information, the wallet management method determining to re-acquire the credential information when a public key of hardware associated with the wallet device differs from a public key included in the credential information held by the wallet device.

Images