User device for obtaining verifiable claims, system including the user device, and method for obtaining verifiable claims

Abstract

To provide a technology for making it difficult to perform name-based aggregation, eliminating limitation of a claim submission destination, and suppressing an amount of information held by a user device.SOLUTION: A user device comprises: holding means for holding confidential information; generation means for generating a generation source; calculation means for calculating a commitment corresponding to the generation source on the basis of the generation source and the confidential information; and acquisition means for transmitting an acquisition request including the generation source and the commitment corresponding to the generation source to a first external device to acquire a verifiable claim (VC) including the generation source and the commitment corresponding to the generation source. A value of the generation source to be used for acquiring the VC by the acquisition means differs from values of the generation source that have been used for acquiring the VC by the acquisition means in the past.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] This disclosure relates to Verifiable Claims. [Background technology]

[0002] Non-Patent Document 1 discloses "verifiable credentials." Verifiable credentials may also be referred to as verifiable claims (VCs). In the following description, verifiable claims and verifiable credentials will be simply referred to as "claims." A claim includes personal information of its owner. Examples of personal information included in a claim may include the claim owner's date of birth, educational background, medical history, assets, etc. A claim is issued by an organization that can guarantee the personal information included in the claim (hereinafter referred to as a Claims Provider (CP)), such as a local government, school, hospital, or bank. When an owner submits a claim including the personal information to an organization that needs to verify the personal information (hereinafter referred to as an RP (Relying Party)), the RP can verify that the owner meets certain conditions. Specifically, for example, the RP can verify that the owner is over a certain age and has assets above a certain amount.

[0003] Note that a claim includes, for example, a signature generated with the private key of the CP that issues the claim. By verifying the signature included in the presented claim with the public key of the CP that issued the claim, the RP can confirm that the presented claim was issued by the CP and that the content of the presented claim has not been tampered with. In addition, a decentralized identifier (DID) may be included in the claim so that the RP can determine whether the person who submitted the claim to the RP is the legitimate owner of the claim. A DID is a unique identifier for the owner, and its value can be obtained by the owner becoming an identity provider. When issuing a claim, the CP includes the value of the DID in the claim. This associates the claim with the DID.

[0004] The personal information that a CP can guarantee depends on its content, so there may be multiple CPs for each type of personal information (age, educational background, assets, etc.). Also, there may be multiple RPs because there are various institutions that need to verify personal information. [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] "Verifiable Credentials Data Model 1.0", [online], November 19, 2019, W3C, [Retrieved June 18, 2021], Internet<URL:https: / / www.w3.org / TR / vc-data-model / > Summary of the Invention [Problem to be solved by the invention]

[0006] FIG. 1 shows N (where N is an integer equal to or greater than 1) CPs #1 to #N and M (where M is an integer equal to or greater than 1) RPs #1 to #M. The user device in FIG. 1 is a device used by a claim owner (hereinafter referred to as a user) to obtain a claim from a CP and present it to an RP. The user device may be, for example, a smartphone, a tablet, or a personal computer (PC). The user device receives and stores a claim VC#n from CP#n (n is an integer from 1 to N). It is assumed that claims VC#1 to VC#N are associated with the same DID. In this case, the user device needs to use the same DID between RP#1 to RP#M.

[0007] However, using the same DID with all RPs causes the problem of name matching. For example, in Figure 1, RP#2 receives VC#2, and RP#M receives VC#1 and VC#N. If the DID used by a user is the same regardless of the RP, RP#2 and RP#M can cooperate (collude) to determine that the user who submitted VC#1, VC#2, and VC#N is the same. In this way, RPs can cooperate with each other to identify various complaints from a certain user, allowing the RP to illegally obtain various personal information about that user.

[0008] For this reason, it is possible to use a different DID for each RP, as shown in Figure 2. In the following description, it is assumed that a user uses a DID with value DID#m for RP#m (m is an integer between 1 and M). Furthermore, a claim associated with DID#m obtained from CP#n is denoted as VC#n(DID#m). A user device obtains two VC#1(DID#1) and VC#1(DID#M) from CP#1. The user device presents VC#1(DID#1) to RP#1 and VC#1(DID#M) to RP#M. In this way, by using different DID values ​​for each RP, it becomes difficult to identify claims from the same user even when RPs cooperate with each other, and the problem of "name matching" can be alleviated.

[0009] However, for example, in the situation shown in Figure 2, when a user submits VC#2 to RP#1, the user device must first request CP#2 to generate VC#2 (DID#1) and acquire VC#2 (DID#1). While it is possible to acquire all combinations (i.e., N x M) of claims in advance, it is not desirable to acquire, retain, and manage a large number of claims that may or may not be used (presented to an RP) in the future. In this way, in the configuration shown in Figure 2, claims can only be presented to a specific RP. Considering user convenience, it is desirable that the acquired claims can be submitted to any RP.

[0010] For this reason, for example, a configuration in which the user's public key is included in the claim can be considered. In this case, when a claim is presented, the RP transmits a challenge to the user device. The user device generates a signature for the challenge using the private key of the public key pair included in the claim and transmits it to the RP. The RP can determine whether the user is the legitimate owner of the claim by verifying the signature with the public key included in the claim. With this configuration, the acquired claim is not tied to a specific RP.

[0011] However, in this case, the user must include different public keys in each claim, which means that the user device must manage a private key for each public key included in each claim, increasing the amount of information that must be kept secret in the user device.

[0012] The present invention provides a technology that makes it difficult to perform name matching, removes restrictions on where claims can be submitted, and reduces the amount of information held by a user device. [Means for solving the problem]

[0013] According to one aspect of the present disclosure, a user device includes a storage means for storing secret information, a generation means for generating a generator, a calculation means for calculating a commitment corresponding to the generator based on the generator and the secret information, and an acquisition means for acquiring a verifiable claim (VC) including the generator and the commitment corresponding to the generator by sending an acquisition request including the generator and the commitment corresponding to the generator to a first external device, wherein the value of the generator used by the acquisition means to acquire the new VC is different from the value of the generator used by the acquisition means to acquire the VC in the past. [Effects of the Invention]

[0014] According to the present invention, it is possible to make it difficult to perform name matching, to eliminate restrictions on where claims can be submitted, and to reduce the amount of information held by a user device. [Brief explanation of the drawings]

[0015] [Figure 1] An explanatory diagram of when the same DID is used for each RP. [Figure 2] An explanatory diagram of a case where a different DID is used for each RP. [Figure 3] FIG. 1 is a diagram illustrating the configuration of a system according to an embodiment. [Figure 4] FIG. 10 is a sequence diagram of a complaint acquisition process according to an embodiment. [Figure 5] FIG. 10 is a sequence diagram of a claim presentation process according to an embodiment. [Figure 6] FIG. 2 is a functional block diagram of a user device according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0016] Hereinafter, the embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the scope of the invention as claimed, and not all combinations of features described in the embodiments are necessarily essential to the invention. Two or more of the features described in the embodiments may be arbitrarily combined. Furthermore, the same reference numerals are used for the same or similar components, and redundant explanations will be omitted.

[0017] First Embodiment FIG. 3 is a configuration diagram of a system according to this embodiment. A user device 1, multiple CPs 2, and multiple RPs 3 are connected to a network 4. The user device 1 is configured to be able to communicate with multiple CPs 2 and multiple RPs 3 via the network 4. In FIG. 1, the number of CPs 2 is N (N is an integer equal to or greater than 1), and the number of RPs 3 is M (M is an integer equal to or greater than 1). In the following description, when distinguishing between individual CPs 2, they are represented as CP#n (n is an integer from 1 to N), and when distinguishing between individual RPs 3, they are represented as RP#m (m is an integer from 1 to M). The user device 1 acquires and stores claims from CPs 2 in response to a user operation. The user device 1 also presents the stored claims to an RP 3 in response to a user operation. In FIG. 3, the number of combinations of CPs 2 and RPs 3 is N×M. In the following description, it is assumed, as an example, that the user device 1 acquires N×M claims in advance. The user device acquires M claims from each CP 3.

[0018] FIG. 4 is a sequence diagram of the claim acquisition process. The user device 1 holds secret information w (S10). In S11, the user device 1 generates a prime number p. Note that all operations in the following description are modulo operations of the prime number p, but to simplify the description, the fact that they are modulo operations, i.e., the notation "mod p" (congruence), will be omitted. Also, while this disclosure shows an implementation based on the discrete logarithm problem, those skilled in the art will understand that implementations based on different difficulties, such as the discrete logarithm problem on an elliptic curve, are also possible without replacing the roles of the devices. In S12, the user device 1 generates N×M generators g, the same as the number of claims to be acquired. nm Note that all generators g nm The values ​​of are different. nm may be generated randomly, for example, without any regularity. Alternatively, the user device 1 may record the generation sources used in the past and select a generation source g so as not to overlap. In S13, the user device nm and the value corresponding to the secret information w. nm =g nm w Generate.

[0019] In step S14, the user device 1 receives a prime number p and a generator g 11 ~g 1M and Commetment Com 11 ~com 1M In response to the claim generation request, CP#1 generates a total of M claims, VC#11 to VC#1M. Claim VC#1m includes the prime number p and the generator g in addition to the personal information of the user guaranteed by CP#1. 1m and commitment 1m In addition, Claim VC#1m may also include a signature generated with the private key of CP#1. In S15, CP#1 transmits the generated Claim VC#11 to VC#1M to user device 1. User device 1 stores the received Claim VC#11 to VC#1M.

[0020] In S16, the user device 1 transmits a claim generation request to the CP#2. This claim generation request includes a prime number p, a generator g 21 ~g 2M and Commetment Com 21 ~com 2M In response to the claim generation request, CP#2 generates a total of M claims, VC#21 to VC#2M. The claim VC#2m includes the prime number p and the generator g in addition to the personal information of the user guaranteed by CP#2. 2m and commitment 2m and VC#2m. Claim VC#2m may also include a signature generated with CP#2's private key. CP#2 transmits the generated claims VC#21 to VC#2M to user device 1 in S17. User device 1 stores the received claims VC#21 to VC#2M. Thereafter, user device 1 repeats the process of transmitting claim generation requests to each CP and obtaining M claims. Therefore, user device 1 obtains N×M claims at the end of S19.

[0021] 4 can be performed at any timing before the complaint is received, not when the complaint is received. In this case, the generated values ​​are stored in the user device 1.

[0022] Next, the process when the user device 1 presents the claim VC#nm acquired from CP#n to RP#m will be described with reference to FIG. 5. The user device 1 generates a value r in S20. For example, the user device 1 can generate the value r randomly. It is desirable to select a value that has not been used in the past for RP#m as the value r, so the user device 1 may record the values ​​r used and select a value that does not overlap. Below, the value r will also be referred to as a random value r. Next, in S21, the user device 1 obtains a proof based on the random value r. The proof includes a value x and a value c. The value x is calculated as follows: x=g nm r and the value c is calculated by c=rw*Hash(x). Hash(·) is an arbitrary hash function assuming a random oracle. In S22, the user device 1 notifies the RP#m of the proof, that is, the value x and the value c, together with the claim VC#nm. As mentioned above, VC#nm contains the nm , g nm and p.

[0023] In S23, RP#m is Z=g nm c *com nm Hash(x) The hash function used in S23 is the same as the hash function used in S21. For example, the hash function used in S21 and S23 is determined by either the user device 1 or RP#m and notified to the other in any manner. RP#m compares Z with x in S24. Here, c=rw*Hash(x), and c nm =g nm w Therefore, Z=g nm c *com nm Hash(x) =gnm r-w*Hash(x) *g nm w*Hash(x) =g nm r =x This becomes:

[0024] In other words, Z=x is a nm This means that the secret information w used to generate Z is the same as the secret information w used to calculate the value c. Therefore, if you submit a proof that contains the value c that makes Z=x, then you can use the nm It can be determined that the claim VC#nm obtained by presenting it to CP#n is the same as the claim VC#nm obtained by the RP#m. Therefore, if Z=x, RP#m determines in S25 that the claim VC#nm has been presented by a legitimate owner. On the other hand, if Z≠x, user device 1 determines in S25 that the claim VC#nm has been presented by an illegitimate owner. Note that in the processing of FIG. 5, the processing up to S21 can be performed at any timing before the claim is presented, not when the claim is presented. In this case, the generated value is stored in user device 1.

[0025] In the above explanation, for ease of understanding, when presenting a claim acquired from CP#n to RP#m, user device 1 presents VC#nm out of the M claims acquired from CP#n. However, this does not mean that the M claims, VC#n1 to VC#nM, acquired by user device 1 from CP#n correspond one-to-one to RP#1 to RP#M, and that once the RP3 to be presented is determined, the claim presented to that RP3 is accordingly limited to a specific one of the M claims.

[0026] For example, user device 1 has acquired a total of M claims, VC#11 to VC#1M, from CP#1. When user device 1 presents the claims acquired from CP#1 to RP#1, user device 1 can select any one of VC#11 to VC#1M. In other words, user device 1 can present VC#12 or VC#1M to CP#1, rather than VC#11. This is because claims in this embodiment are not associated with DIDs but with the commitment cO included in the claim, and whether or not the claim is a legitimate owner is determined by the Schnorr protocol applying the Fiat-Shamir Heuristic, i.e., non-interactive zero-knowledge proof (NIZK), using the commitment cO and proofs (x and c). In other words, in this embodiment, the recipients to which multiple claims acquired from a certain CP2 are presented are not fixed.

[0027] In other words, as described in the background art, if a different DID is used for each RP3 and a claim is associated with the DID, the presentation destination of the issued claim is fixed. For example, a claim associated with the DID used with RP#1 can only be presented to RP#1. In other words, if a different DID is used for each RP3 and a claim is associated with the DID, the claim acquisition process becomes a process for presenting a claim to a specific RP3. On the other hand, in this embodiment, the claim acquisition process and the claim presentation process are independent, and the acquired claim is not associated with a specific RP3. For example, a claim acquired with the intention of presenting it to RP#1 can be presented to an RP3 other than RP#1.

[0028] Therefore, by generating a claim as in this embodiment, it is possible to prevent waste, such as acquiring and storing a claim that can only be presented to a specific RP3 in advance, and then not using it as a result. Furthermore, the claim acquisition process and the claim presentation process can be independent. Furthermore, since the information presented to the RP3 for authentication is a value generated based on a generator g and a random value r, which are different values, it is difficult to perform name matching even if the RP3s cooperate with each other. Furthermore, the only information that the user device 1 needs to keep secret is the secret information w, and the amount of information is small.

[0029] In the above description, the user device 1 acquires N×M claims in advance, but this is merely an example, and the number of claims that the user device 1 acquires in advance from each CP2 is arbitrary. For example, the user device 1 can determine the number of claims to acquire in advance from each CP2 depending on the number (or expected number) of recipients of personal information guaranteed by each CP2. As a non-limiting specific example, the user device 1 can acquire five claims in advance: three claims from CP#1 and two claims from CP#2. Thereafter, as needed, the user device 1 can acquire any number of claims in advance from each CP2. However, even when the advance acquisition process is performed multiple times, the value of the generator g included in each acquired claim is different. The value of the commitment cоm included in a claim corresponds to the value of the generator g included in the same claim.

[0030] If a claim has been presented to a certain RP3 in the past, the user device 1 controls the random value r generated in S20 of Fig. 5 so that it is different from the value used previously. This is because if the random value r is the same, the value of the proof will also be the same, making impersonation possible. Therefore, if the random value r generated in S20 is the same as the one used when the same claim was previously presented to the same RP3, the user device 1 repeats generating the random value r until a value different from the value used previously is generated. Furthermore, the RP3 is configured to reject authentication when the same claim as previously presented is presented and the value of the proof is the same as that previously presented.

[0031] RP3 can also be configured to notify user device 1 of doubt rather than refusing authentication even when the same claim as previously presented is presented together with the same proof. In this case, user device 1 does not need to manage the random value r used in the past, and when challenged by RP3, selects a different random value r and recalculates the proof (S21 in FIG. 5) and re-notifies the proof (S22 in FIG. 5). Such doubt can be raised when RP3 has previously received and proven the same value x for the same VC#nm.

[0032] Also, an interactive zero-knowledge proof procedure in which RP3 notifies the user device 1 of the challenge value chal can be implemented instead of the processes of S22 to S25 or added to the processes of S22 to S25. In this case, the user device 1 notifies RP3 of c'=rw*chal. Then, RP3 calculates x and Z=g nm c´ *com nm chal Authentication is performed by comparing the

[0033] Second Embodiment Next, the second embodiment will be described, focusing on the differences from the first embodiment. In the first embodiment, the user device 1 nm com nm =gnm w In other words, the value corresponding to the same secret information w is used to generate all the comments. nm To generate the secret information w, the user device 1 first generates derived secret information w#nm based on the secret information w as follows: w#nm=Hash(w;g nm ) Note that this hash function may be different from the hash function used in the process of FIG. 5. Then, the user device 1 obtains the commitment com nm com nm =g nm w#nm Therefore, the user device 1 uses the derived secret information w#nm instead of the secret information w in the calculation of the value c in FIG. nm Since the values ​​of are all different, the values ​​of the derived secret information w#nm are also different. This makes the values ​​of the secret information w random, making it more difficult to perform name matching.

[0034] <Configuration of user device> A functional block diagram of the user device 1 in each of the above embodiments is shown in Fig. 6. The functional blocks shown in Fig. 6 can be realized by causing an appropriate program to be executed on one or more processors of a device such as a smartphone, tablet, or PC that includes one or more processors and one or more memory devices.

[0035] The generator management unit 10 generates a generator g. The generator management unit 10 stores the value of the generator g that was previously generated and used for a claim, and when generating a new generator g, it manages the generator g so as not to generate a generator g with the same value as a generator g used previously. Furthermore, to prevent any regularity in the generation of the generator g, the generator management unit 10 generates the generator g, for example, randomly. For example, the generator management unit 10 generates a random value and determines whether the value is the same as a value previously used for a claim. If the generated value is not the same as a value previously used for a claim, the generator management unit 10 sets the generated value as a new generator g. On the other hand, if the generated value is the same as a value previously used for a claim, the generator management unit 10 selects a value different from the value previously used for the claim.

[0036] The random value management unit 11 generates a random value r to be used when presenting a claim to RP3 (S20 in FIG. 5). In one example, the random value management unit 11 manages and holds the value of the random value r used when presenting the claim to RP3. When presenting the claim to RP3, the random value management unit 11 manages the generation of the random value r so as not to use a random value r that was previously used when presenting the claim to RP3. As described above, the random value management unit 11 can also be configured to regenerate the random value r when RP3 notifies it of doubts about the proof. The prime number management unit 12 generates and holds a prime number p.

[0037] The claim acquisition unit 13 performs processing to request a claim from each CP 2 and acquire the claim. As described above, when acquiring a claim, the claim acquisition unit 12 notifies the CP 2 of the prime number p, the generator g, and the commitment com.

[0038] The confidential information holding unit 14 holds the confidential information w, and the complaint holding unit 15 stores the complaint acquired from CP2 in a memory device. The complaint itself can be stored not only in a memory device inside the user device 1, but also in a memory device of a device external to the user device 1. The external device can be a peripheral device connectable to the user device 1. The external device can also be a device that can communicate with the user device 1 via the network 4. In other words, the complaint holding unit 15 stores the complaint in a storage device inside or outside the user device 1.

[0039] The claim presenting unit 16 presents the claim to the RP 3. As described above, the claim presenting unit 15 presents the proof (x, c) to the RP 3 together with the claim.

[0040] The calculation unit 17 calculates the commitment c OM and the values ​​x and c. In the second embodiment, the calculation unit 17 also generates derived secret information based on the secret information w and the generator g. The communication unit 18 performs communication processing with the CP2 and the RP3 via the network 4.

[0041] The user device 1 according to the present invention can be realized by a program that, when executed by one or more processors in a device having one or more processors, causes the device to operate as the user device 1. These computer programs can be stored in a computer-readable storage medium or distributed via a network.

[0042] In the above embodiment, the user device 1 is described as a device independent of the CP2 and RP3 (for example, the functions of the user device 1 are implemented as an application installed on a smartphone or personal computer). However, some of the functions of the user device 1 may be located in the CP2 or the RP3. For example, if the CP2 is implemented as a system including a web application server, all of the functions of the user device 1 may be implemented on the CP2 side, and the processes of the functions of the user device 1 implemented on the CP2 side and the processes of the functions originally implemented on the CP2 may be executed independently and inaccessible, and the information on the user device 1 and the generated information may be stored by the CP2 as user-specific information. Note that if some functions are to remain on the user side, they may be implemented as a web browser plug-in.

[0043] The invention is not limited to the above-described embodiment, and various modifications and variations are possible within the scope of the gist of the invention. [Explanation of symbols]

[0044] 14: Confidential information storage unit, 10: Generator management unit, 17: Calculation unit, 13: Claim acquisition unit

Claims

1. a means for retaining confidential information; A generating means for generating a generator; A calculation means for calculating a commitment corresponding to the origin based on the origin and the secret information; an acquisition means for acquiring a verifiable claim (VC) including the origin and the commitment corresponding to the origin by sending an acquisition request including the origin and the commitment corresponding to the origin to a first external device; Equipped with The user equipment, wherein the value of the origin used by the acquisition means to acquire the new VC is different from the value of the origin used by the acquisition means to acquire the VC in the past.

2. The user device of claim 1, wherein the calculation means calculates an output value of a hash function that takes as input the value of the generator and a value corresponding to the secret information, and calculates a commitment corresponding to the generator based on the output value and the value of the generator.

3. The method further includes a presentation unit that presents the VC acquired by the acquisition unit together with a proof of the VC to a second external device; the proof of VC includes a first value and a second value; the calculation means calculates the first value based on the origin and a third value included in the VC presented by the presentation means, and calculates the second value based on a hash value of the first value, the third value, and a value corresponding to the secret information; The user device described in claim 1 or 2, wherein when the presentation means presents a first VC to the second external device, if the presentation means has previously presented the first VC to the second external device, the calculation means makes the third value used to calculate the first value and the second value different from the third value used when the presentation means previously presented the first VC to the second external device.

4. 1. A system including a user device and one or more first external devices, The user device a means for retaining confidential information; A generating means for generating a generator; A calculation means for calculating a commitment corresponding to the origin based on the origin and the secret information; a first sending means for sending, to at least one first external device among the one or more first external devices, an acquisition request including one or more origins and a commitment corresponding to each of the one or more origins; Equipped with the one or more first external devices, a second sending means for sending, in response to receiving the acquisition request, to the user device, a verifiable claim (VC) corresponding to each of the one or more origins included in the received acquisition request, the VC corresponding to the origin including the origin and a commitment corresponding to the origin; Preparation, A system in which the values ​​of the one or more origins included in the acquisition request sent by the first sending means to the at least one first external device are different from each other and are different from the values ​​of the one or more origins included in the acquisition request previously sent by the first sending means.

5. further comprising one or more second external devices; The user device a presenting means for presenting a group of VCs including a first value and a second value to one second external device among the one or more second external devices, together with the VCs acquired in response to the acquisition request transmitted to the at least one first external device; the one or more second external devices, a determination means for determining whether a user of the user device is the owner of the VC based on the origin and the commitment included in the VC and the proof when the VC and a proof of the VC are presented from the user device; The system of claim 4, wherein the first value is a value based on the origin and a third value included in the VC to be presented to the one second external device, and the second value is a value based on a hash value of the first value, the third value, and a value corresponding to the secret information.

6. 1. A method in a user device, comprising: sending, to a first external device, a retrieval request including one or more origins and a commitment corresponding to each of the one or more origins, the commitment corresponding to each origin being generated based on the origin and secret information held by the user device; receiving, in response to sending the retrieval request, from the first external device, a verifiable claim (VC) corresponding to each of the one or more origins, the VC corresponding to the origin including the origin and a commitment corresponding to the origin; Including, A method in which the values ​​of the one or more origins included in the acquisition request are different from each other and are different from values ​​of the one or more origins included in acquisition requests previously sent by the user device.

7. transmitting one VC among the VCs corresponding to each of the one or more origins and a proof corresponding to the one VC to a second external device; 7. The method of claim 6, wherein the proof corresponding to the one VC includes a first value based on the generator and a random value included in the one VC, and a second value based on a hash value of the first value, the random value, and a value corresponding to the secret information.

8. a user device transmitting, to a first external device, an acquisition request including one or more origins and a commitment corresponding to each of the one or more origins, the commitment corresponding to each origin being generated based on the origin and secret information held by the user device; In response to receiving the retrieval request, the first external device sends to the user device a verifiable claim (VC) corresponding to each of the one or more origins, the VC corresponding to the origin including the origin and a commitment corresponding to the origin; The user device transmits, to a second external device, one VC among the VCs corresponding to each of the one or more origins and a proof corresponding to the one VC; The second external device determines whether a user of the user device is an owner of the one VC based on the origin and the commitment included in the one VC and a proof corresponding to the one VC; The values ​​of the one or more origins included in the acquisition request are different from each other and are different from the values ​​of the one or more origins included in the acquisition request previously transmitted by the user device, A method in which the proof corresponding to the one VC includes a first value based on the generator and a random value included in the one VC, and a second value based on a hash value of the first value, the random value, and a value corresponding to the secret information.

Images