Terminal device, certification information generation method, verification method and program

Abstract

To verify information on distribution objects by taking into account the relevance among distribution processes.SOLUTION: A terminal device uses first certification information for certifying a first distribution object to generate second certification information for certifying a second distribution object based on at least the first distribution object, and registers second verification information corresponding to the second certification information. Here, the second certification information includes at least information for specifying the first certification information. Alternatively, the first verification information corresponding to the first certification information is registered.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to a technique for verifying the correctness of a distribution process, and more particularly to a technique for performing verification taking into account the relevance of the distribution process. [Background technology]

[0002] The world is made up of the interconnection of things (tangible or intangible) that are the subject of distribution. For example, in a supply chain, things that have been distributed from upstream are processed by combining or adding, and the new things obtained as a result are distributed downstream. At the same time, there is a need to verify the correctness (authenticity) of information about the distributed things (e.g., design information, bill of materials (BOM), inspection results, etc.). For example, if an attacker in the supply chain maliciously tampers with information about parts in a product, it is necessary to be able to detect the tampering as well as to detect at what point in the supply chain the information was tampered with, and to clarify the scope of responsibility.

[0003] Verifiable Credentials (VC) on Blockchain (BC) is known as one of the mechanisms for verifying the authenticity of information (see, for example, Non-Patent Document 1). By setting the subject of VC certification to be information on the object to be circulated, the correctness of this information can be verified. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] Manu Sporny, Dave Longley, and David Chadwick,"W3C Recommendation: Verifiable Credentials Data Model v1.1",[online],March 3, 2022,[Retrieved August 28, 2023],Internet<https: / / www.w3.org / TR / vc-data-model / > Summary of the Invention [Problem to be solved by the invention]

[0005] However, the conventional system has a problem that it is not possible to verify information on distribution objects taking into account the relevance of the distribution process. For example, in a supply chain, new items are created by combining and processing distributed items, so it is necessary to perform verification taking into account the relevance of the items to be distributed. However, VCs are independent of each other, and the relevance between VCs is not expressed. In addition, although there is a system called VP (Verifiable Presentation) that can present multiple VCs together (for example, see 4.10 Presentations in Non-Patent Document 1), VP cannot express the hierarchical relevance of the distribution process. Such a problem is not limited to the use of VCs, but is common to the verification of the correctness of the distribution process.

[0006] The present invention provides a technique that enables verification of information on a distribution object, taking into account the relevance of the distribution process. [Means for solving the problem]

[0007] A terminal device uses first certification information for certifying a first distribution target to generate second certification information for certifying a second distribution target based on at least the first distribution target, and registers second verification information corresponding to the second certification information. Here, the second certification information includes at least information for identifying the first certification information. Also, the first verification information corresponding to the first certification information is registered. Effect of the Invention

[0008] This makes it possible to verify information about distribution objects while taking into account the relevance of the distribution process. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a block diagram illustrating a functional configuration of a distribution object certification system according to an embodiment. [Diagram 2] FIG. 2 is a block diagram illustrating a functional configuration of the terminal device according to the embodiment. [Diagram 3] FIG. 3 is a flow diagram illustrating a hierarchical VC issuing process according to the embodiment. [Figure 4] FIG. 4 is a flow diagram illustrating the hierarchical VC verification process of the embodiment. [Diagram 5] FIG. 5 is a flow diagram illustrating hierarchical VC recursive verification with VC-i as an argument according to the embodiment. [Figure 6] Fig. 6A is a diagram illustrating a hierarchical VC issuing process according to an embodiment, and Fig. 6B is a diagram illustrating a configuration of proof information according to an embodiment. [Figure 7] 7A is a diagram illustrating a data registry on a blockchain according to an embodiment. FIG. 7B is a diagram illustrating verification information according to an embodiment. [Figure 8] FIG. 8 is a diagram illustrating a verification result of the embodiment. [Figure 9] FIG. 9 is a diagram illustrating a hierarchical VC issuing process according to the embodiment. [Figure 10] FIG. 10 is a diagram illustrating the configuration of the certification information VC according to the embodiment. [Figure 11] FIG. 11 is a diagram illustrating a hierarchical VC issuing process according to the embodiment. [Figure 12] FIG. 12 is a diagram illustrating the verification results of the embodiment. [Figure 13] FIG. 13 is a diagram illustrating a state in which fraud has occurred in the hierarchical VC issuing process of the embodiment. [Figure 14] FIG. 14 is a diagram illustrating a verification result when the fraud illustrated in FIG. 13 is committed. [Figure 15] FIG. 15 is a diagram illustrating a state in which fraud has occurred in the hierarchical VC issuing process of the embodiment. [Figure 16] FIG. 16 is a diagram illustrating a verification result when the fraud illustrated in FIG. 15 is committed. [Figure 17]FIG. 17 is a diagram illustrating a state in which fraud has occurred in the hierarchical VC issuing process of the embodiment. [Figure 18] FIG. 18 is a diagram illustrating a verification result when the fraud illustrated in FIG. 17 is committed. [Figure 19] FIG. 19 is a diagram illustrating a verification result when the status of the verification information is invalid according to the embodiment. [Figure 20] Fig. 20A is a diagram for illustrating a correctly performed hierarchical VC issuance process, and Fig. 20B is a diagram for illustrating a verification result when the hierarchical VC issuance process of Fig. 20A is performed. [Figure 21] Fig. 21A is a diagram for illustrating the hierarchical VC issuance process in which the fraud illustrated in Fig. 13 has been performed. Fig. 21B is a diagram for illustrating the verification result when the hierarchical VC issuance process in Fig. 21A has been performed. [Figure 22] Fig. 22A is a diagram for illustrating the hierarchical VC issuance process in which the fraud illustrated in Fig. 15 has been performed. Fig. 22B is a diagram for illustrating the verification result when the hierarchical VC issuance process in Fig. 22A has been performed. [Figure 23] Fig. 23A is a diagram for illustrating the hierarchical VC issuance process in which the fraud illustrated in Fig. 17 has been performed. Fig. 23B is a diagram for illustrating the verification result when the hierarchical VC issuance process in Fig. 23A has been performed. [Figure 24] Fig. 24A is a diagram illustrating a state in which the hierarchical VC issuance process is performed correctly but the status of the verification information is set to invalid afterwards. Fig. 24B is a diagram illustrating a verification result when the status of the verification information is set to invalid as in Fig. 24A. [Diagram 25] FIG. 25 is a diagram illustrating a hardware configuration of the terminal device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, an embodiment of the present invention will be described. [overview] First, an outline of the embodiment will be described. In the embodiment described below, a terminal device uses first certification information for certifying a first distribution target, generates second certification information for certifying a second distribution target based on at least the first distribution target, and registers second verification information corresponding to the second certification information. Here, the second certification information includes at least information for identifying the first certification information. In addition, the first verification information corresponding to the first certification information is registered. Here, the second distribution target is based on at least the first distribution target, and has a relationship with the first distribution target in the distribution process. In addition, the second certification information certifies such a second distribution target, and includes at least information for identifying the first certification information for certifying the first distribution target. In addition, the first verification information corresponding to the first certification information is registered, and further, the second verification information corresponding to the second certification information is registered. Thereby, at least it is possible to verify whether the second certification information corresponds to the second verification information, and it is possible to verify whether the first certification information corresponds to the first verification information. As a result, it is possible to verify information for a distribution target taking into account the relationship in the distribution process.

[0011] Also, preferably, the first certification information includes a first identifier that identifies the recipient of the first distribution object, and the second certification information includes a second identifier that identifies at least one of the provider of the second distribution object, the generator of the second certification information, or the registrant of the second verification information corresponding to the second certification information. In this case, it is possible to verify at least whether the first identifier corresponds to the second identifier. This makes it possible to verify whether the provider of the second distribution object, the generator of the second certification information, or the registrant of the second verification information corresponding to the second certification information is the true recipient of the first distribution object. This makes it possible to verify information on the distribution object, further taking into account the relevance of the distribution process.

[0012] The first distribution object is a tangible object, an intangible object, or a combination of a tangible object and an intangible object that is a distribution object. Examples of distribution objects that are tangible objects include products and distribution items such as electronic devices, electronic parts, materials, medicines, clothing, bags, and food products. Examples of distribution objects that are intangible objects include products and distribution items such as programs, image data, and sound source data. The distribution object may be free of charge or may be paid for. The second distribution object may be the first distribution object itself, or may be the first distribution object that has been processed. The first distribution object that has been processed may be the first distribution object that has been modified by modifying, improving, correcting, deleting, or the like, or may be the first distribution object that has been combined with or added to other objects, or may be the first distribution object that has been modified by combining or adding other objects to the first distribution object and then modified, improved, or corrected. The other object may be a distribution object other than the first distribution object, or may be a tangible object, an intangible object, or a combination of a tangible object and an intangible object that is not a distribution object.

[0013] The first certification information may be any information for verifying the first distribution target. The first certification information, for example, certifies information about the first distribution target. The second certification information may be any information for verifying the second distribution target. The second certification information, for example, certifies information about the second distribution target. The first certification information and the second certification information are, for example, verifiable credentials (VC), but this does not limit the present invention. Information for identifying the first certification information may be the first certification information itself, information that can restore the first certification information (for example, a ciphertext of the first certification information, etc.), or a link destination (for example, an address, etc.) from which the first certification information can be obtained.

[0014] The first verification information is information corresponding to the first certification information, and may be any information as long as the authenticity of the first certification information can be verified. Similarly, the second verification information is information corresponding to the second certification information, and may be any information as long as the authenticity of the second certification information can be verified. The first verification information may include, for example, a hash value of the first certification information, or may include a ciphertext of the first certification information. Similarly, the second verification information may include, for example, a hash value of the second certification information, or may include a ciphertext of the second certification information. The registration of the first verification information and the second verification information includes a process of storing the first verification information and the second verification information in a public storage area. The public storage area may be any area. For example, the public storage area is a globally public area. However, if the distribution range (for example, a region such as a country) of the distribution object is limited, the public storage area may be an area that is publicly available within that distribution range. A specific example of the public storage area is a storage area configured on a blockchain, for example, a verifiable data registry on a blockchain. However, these do not limit the present invention.

[0015] The destination of the first distribution target may be a specific destination or may be any destination. When the destination of the first distribution target is a specific destination, the first identifier is an identifier that identifies the specific destination. When the destination of the first distribution target may be any of a plurality of specific destinations, the first identifier may be an array of identifiers that identify these plurality of specific destinations. On the other hand, when the destination of the first distribution target is any destination, the first identifier is an identifier that does not identify a specific destination, but indicates that the first distribution target is provided to any destination. The identifier that identifies a specific destination and the array of identifiers that identify a plurality of specific destinations are, for example, globally unique. However, when the distribution range of the distribution target is limited, the identifier that identifies a specific destination and the array of identifiers that identify a plurality of specific destinations may each be unique within the distribution range. A specific example of each of the identifier that identifies a specific destination and the array of identifiers that identify a plurality of specific destinations is DID (Decentralized Identifiers) (see, for example, Reference 1, etc.). Also, a specific example of an identifier that indicates that the first distribution target is provided to any destination is "*", etc. However, these do not limit the present invention. Reference 1: Manu Sporny, Dave Longley, Markus Sabadello, Drummond Reed, Orie Steele, and Christopher Allen, "W3C Recommendation: Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and representations", [online], July 19, 2022, [Retrieved September 1, 2023], Internet<https: / / www.w3.org / TR / did-core / >

[0016] The second identifier may identify the provider of the second distribution object, the generator of the second proof information, or the registrant of the second verification information corresponding to the second proof information, or may identify a combination of these. The second identifier is, for example, globally unique. However, if the distribution range of the distribution object is limited, the second identifier may be unique within that distribution range.

[0017] [First embodiment] Hereinafter, a first embodiment will be described with reference to the drawings. In this embodiment, an example will be shown in which the distribution object is a product and the identifier is a DID (for example, see Reference 1, etc.). However, these do not limit the present invention.

[0018] <Configuration> As illustrated in FIG. 1, the distribution object certification system 1 of this embodiment has terminal devices 11-1, ..., 11-N communicably connected to the cloud 12. Here, N is an integer of 2 or more. The terminal device 11-n (where n=1, ..., N) is a device used by a user 1000-n who handles a product (distribution object) Pn. In reality, the subject who handles the product Pn is a corporation such as a company or an organization such as various groups, a member of a corporation or various groups, or other individuals, and the subject who operates the terminal device 11-n is an employee of the company, etc., but in the following, for the sake of simplicity, the subject who handles the product Pn and the subject who operates the terminal device 11-n are considered to be the same. The cloud 12 is equipped with a blockchain 120, and the blockchain 120 is provided with a verifiable data registry 121. The cloud 12 is configured, for example, on the Internet.

[0019] As illustrated in FIG. 2, the terminal device 11-n of this embodiment has a key information memory unit 111a-n, a proof information memory unit 111b-n, a verification result memory unit 111c-n, an input unit 112-n, a proof information generation unit 113-n, a verification unit 114-n, a verification result storage unit 115-n, a registration processing unit 116-n, and an output unit 117-n.

[0020] <Pre-processing> As a pre-processing step, the DID (user DID) of the user 1000-n is stored in the certification information storage unit 111b-n of the terminal device 11-n (FIG. 2) (see, for example, Reference 1, etc.). The user DID of the user 1000-n may correspond to the user's address assigned to the terminal device 11-n (user 1000-n). For example, the user DID (did) may be expressed as follows using the user's address in the blockchain (BC Address): [Format]did:{methodName}:{ChainID or ChainName}:{BC Address} [Example] did:ethr:12345: 0x1234567890123456789012345678901234567890

[0021] In addition, a private key SK-n for generating a signature (electronic signature) is stored in the key information storage unit 111a-n of the terminal device 11-n (FIG. 2). The private key SK-n is a private key issued to the terminal device 11-n, and is, for example, a private key conforming to a public key cryptosystem or the like. For example, the private key SK-n may correspond to a user address assigned to the terminal device 11-n. Note that a public key PK-n corresponding to the private key SK-n is necessary for signature verification. The public key PK-n corresponding to the private key SK-n is stored, for example, in the verifiable data registry 121 of the block chain 120. However, if the public key PK-n can be identified from some information (for example, a message to be signed and a signature value), it is not necessary to store the public key PK-n in the verifiable data registry 121. For example, if the block chain 120 is conforming to the Ethereum system, the public key PK-n can be identified if there is a message to be signed and a signature value, so there is no need to store the public key PK-n in the verifiable data registry 121. In addition, if the public key PK-n obtained from the message to be signed and the signature value corresponds to the user address assigned to terminal device 11-n, it is also possible to perform signature verification by checking the consistency between the user address calculated from public key PK-n and the user address corresponding to the user DID of user 1000-n.

[0022] <Hierarchical VC issuing process> The hierarchical VC issuing process of this embodiment will be described with reference to Figs. 1 to 3, Figs. 6A, 6B, 7A, and 7B. In this embodiment, a supply chain is assumed in which a user 1000-n provides a product Pn to a downstream user 1000-ω(n). Here, n ∈ {1, ..., N} and ω(n) ∈ {1, ..., N}. The user 1000-ω(n) may be a specific destination or an arbitrary destination. The specific destination may be a single destination or multiple destinations. An example of a specific destination is a destination of delivery of the product Pn that has placed an order for the product Pn. An example of an arbitrary destination is a destination in the case where the product Pn is an OSS (Open Source Software) product or a mass-produced product. The user 1000-n may (I) generate the product Pn without using a product (upstream product) provided by an upstream user and provide it to the downstream user 1000-ω(n), or (II) generate the product Pn from the upstream user 1000-ρ 1 (n),…,1000-ρ θ(n) Product P-ρ provided by (n) 1 (n),…,P-ρ θ(n) (n) to generate a product Pn by processing such as combining, adding, modifying (including deleting) them and provide it to a downstream user 1000-ω(n), or (III) to an upstream user 1000-ρ 1 (n),…,1000-ρ θ(n) Product P-ρ provided by (n) 1 (n),…,P-ρ θ(n) (n) may be directly provided to downstream user 1000-ω(n) as product Pn. Here, ρ 1 (n),…,ρ θ(n) (n)∈{1,…,N}, and θ(n) is an integer 0≦θ(n)≦N that represents the number of upstream products used to generate product Pn. Note that θ(n)=0 represents (I) the case where product Pn is generated without using any upstream products. In addition, product Pn generated as in (I) and (II) will be called a "new product," and product Pn in (III) will be called an "existing product." [Table 1]

[0023] In the hierarchical VC issuance process, a user 1000-n who provides a product Pn to a downstream user 1000-ω(n) uses a terminal device 11-n to generate proof information VC-n for proving the product Pn, and registers verification information VI-n corresponding to the proof information VC-n in the verifiable data registry 121 of the blockchain 120. The hierarchical VC issuance process is executed, for example, every time the user 1000-n provides the product Pn to the user 1000-ω(n), and the obtained proof information VC-n is provided to the user 1000-ω(n) together with the product Pn. The proof information VC-n may be provided online or may be stored in a recording medium and provided. However, when the product Pn is provided to an arbitrary destination such as an OSS product, the hierarchical VC issuance process may be executed once before the start of provision of the product Pn, and the proof information VC-n obtained thereby may be made public online.

[0024] A specific example of the hierarchical VC issuing process is given below. Step S1121-n: As shown in FIG. 3, the input unit 112-n of the terminal device 11-n (FIG. 2) receives certification information VC-ρ required for generating certification information VC-n (second certification information). 1 (n),…,VC-ρ θ(n) (n) (first certification information) and other information info-n are input and stored in the certification information storage unit 111b-n. Here, the certification information VC-n is information for certifying the product Pn (second distribution target), and the certification information VC-ρ 1 (n),…,VC-ρ θ(n) (n) is the upstream product P-ρ of product Pn 1 (n),…,P-ρ θ(n) (n) is the information to prove. Proof information VC-n, VC-ρ 1 (n),…,VC-ρ θ(n) An example of (n) is VC, but it may be other information. 1 (n),…,VC-ρ θ(n)(n) is the product Pn and its upstream product P-ρ 1 (n),…,P-ρ θ(n) (n), i.e., the certificate information VC-ρ 1 (n),…,VC-ρ θ(n) (n) is entered only if the product Pn is a new product of (II) or an existing product of (III). If the product Pn is a new product of (I), the certification information VC-ρ 1 (n),…,VC-ρ θ(n) (n) is not entered. Note that the proof information VC-ρ 1 (n),…,VC-ρ θ(n) (n) are the terminal devices 11-ρ 1 (n),…,11-ρ θ(n) (n) is generated, and the product P-ρ 1 (n),…,P-ρ θ(n) The information info-n is provided to user 1000-n together with (n). The information info-n is, for example, information specifying the recipient of product Pn, the validity period start date and time, the validity period end date and time, the validity period of the certification information, information specifying any certification object such as configuration information or design information of product Pn (unique certification information), information specifying whether product Pn is a new product (I) (II) or an existing product (III), information specifying whether product Pn is a product (I), (II), or (III), etc. As mentioned above, the recipient of product Pn may be a specific recipient or any recipient. Note that the certification information VC-ρ 1 (n),…,VC-ρ θ(n) If (n) and the information info-n are already stored in the certification information storage unit 111b-n, the process of step S1121-n may be omitted.

[0025] Step S1131-n: The proof information generating unit 113-n determines whether the product Pn is a product P-ρ 1 (n),…,P-ρ θ(n)(n). In other words, it is determined whether the product Pn is an existing product (III). The certification information generating unit 113-n may perform this determination using information info-n stored in the certification information storage unit 111b-n, or may perform this determination based on preset information. Here, the product Pn is determined to be the same as the product P-ρ 1 (n),…,P-ρ θ(n) If it is not the same as product P-ρ(n), the process proceeds to step S1132-n. 1 (n),…,P-ρ θ(n) If it is the same as (n), the process proceeds to step S1133-n.

[0026] Step S1132-n: The proof information generation unit 113-n issues a DID (product DID) that identifies the product Pn (see, for example, Reference 1, etc.). For example, the proof information generation unit 113-n issues a product DID using a newly issued BC Address. Also, the product information of the product Pn may be registered in the verifiable data registry 121 using the product DID of the product Pn as a key. For example, the following product information may be registered: [Table 2] Although it is not essential to register product information, the reliability of verification can be further improved by registering absolutely universal product information (product name, manufacturer DID, product name, etc.) in the verifiable data registry 121 and using this in the hierarchical VC verification described later. Note that only those who have a secret key SK-n corresponding to a product DID may be able to register product information of a product Pn corresponding to that product DID. The product DID of the product Pn is stored in the proof information generation unit 113-n. Next, proceed to step S1133-n.

[0027] Step S1133-n: The certification information generating unit 113-n generates the certification information VC-ρ body-n from the information (information info-n, certification information VC-ρ 1(n),…,VC-ρ θ(n) The information required for generating the VCbody-n includes the information info-n and the user DID, and the certification information storage unit 111b-n stores certification information VC-ρ 1 (n),…,VC-ρ θ(n) If (n) is stored, further proof information VC-ρ 1 (n),…,VC-ρ θ(n) 6B includes, for example, a user DID (issue:userDID-n) 100a-n for identifying a user 1000-n who is the issuer of the certification information VC-n, an expiration date and time (issuanceDate:XXXX) 100b-n for the certification information VC-n, an expiration date and time (expirationDate:XXXX) 100c-n for the certification information VC-n, a product DID (id:productDID-n) 100d-n for the product Pn, a user DID (issuedTo:userDID-ω(n)) 100e-n for identifying a user 1000-ω(n) to whom the product Pn is provided, unique certification information (originalInfo:product-n) 100f-n for the product Pn, and certification information VC-ρ 1 (n),…,VC-ρ θ(n) (n) to identify the inheritance information list (inheritances:[VC-ρ 1 (n),...,VC-ρ θ(n)The certificate information VC-n includes a validity period start date and time 100b-n, which is a date and time based on the generation date and time of the body VCbody-n (e.g., the generation date and time of the body VCbody-n, a date and time earlier than the generation date and time, or a date and time later than the generation date and time), or a date and time specified by the information info-n. The validity period end date and time of the certificate information VC-n is generally a date and time later than the validity period start date and time 100b-n of the certificate information VC-n, and may be a date and time specified by the generation date and time of the body VCbody-n and the information info-n, or may be a date and time specified by the information info-n. As described above, the certificate information VC-ρ 1 (n),…,VC-ρ θ(n) The information to identify (n) is the proof information VC-ρ 1 (n),…,VC-ρ θ(n) (n) itself, or the proof information VC-ρ 1 (n),…,VC-ρ θ(n) (n) can be restored by using information (e.g., proof information VC-ρ 1 (n),…,VC-ρ θ(n) For example, the encrypted proof information VC-ρ encoded and serialized using JWT (JSON Web Token) etc. 1 (n),…,VC-ρ θ(n) (n)) or proof information VC-ρ 1 (n),…,VC-ρ θ(n) However, the certificate information VC-ρ may be a link destination from which the certificate information VC-ρ can be obtained (for example, a URI (Uniform Resource Identifier) ​​of an external storage). 1 (n),…,VC-ρ θ(n) The information for identifying (n) is the proof information VC-ρ 1 (n),…,VC-ρ θ(n) If the link destination is one where (n) can be obtained, the certification information VC-ρ 1 (n),…,VC-ρ θ(n)In order to guarantee the authenticity of (n), the registered (recorded) certification information VC-ρ 1 (n),…,VC-ρ θ(n) It is more preferable that the system be configured so that (n) is immutable (for example, IPFS (InterPlanetary File System) where the URI is determined by the hash value of the data to be stored). 1 (n),…,VC-ρ θ(n) If (n) does not exist (i.e., product Pn is a new product of (I)), the inheritance certification information list 100g-n is an empty array (inheritances:[]). Also, if the product DID of product Pn does not exist (i.e., product Pn is an existing product of (III)), the product DID 100d-n of product Pn is the product DID of the upstream product P-ρ 1 (n),…,P-ρ θ(n) The user DID 100e-n of the terminal device 11-ω(n) is the DID that is the identifier of the destination of the product Pn specified by the information info-n. If the destination of the product Pn is an arbitrary destination, the user DID 100e-n of the terminal device 11-ω(n) is an identifier (for example, "*" (issuedTo:*), etc.) that indicates that the product Pn will be provided to an arbitrary destination. [Table 3]

[0028] In addition, the upstream product P-ρ 1 (n),…,P-ρ θ(n) (n) corresponds to the "first distribution target" and is the proof information VC-ρ 1 (n),…,VC-ρ θ(n) (n) corresponds to "first certification information for certifying the first distribution object", the product Pn may correspond to "second distribution object based on at least the first distribution object", and the certification information VC-n may correspond to "second certification information for certifying the second distribution object". Certification information VC-ρ 1 (n),…,VC-ρ θ(n) (n) (first proof information) is the product P-ρ 1(n),…,P-ρ θ(n) (n) A user DID (issuedTo:userDID-n) 100e-ρ that identifies a user 1000-n to whom (n) (the first distribution target) is provided 1 (n),…,100e-ρ θ(n) (n) (first identifier) ​​or an identifier (such as "*") indicating that the information is provided to an arbitrary destination. The certification information VC-n (second certification information) includes at least the certification information VC-ρ 1 (n),…,VC-ρ θ(n) (n) (first certification information) includes an inherited certification information list 100g-n (information) for identifying the certification information VC-n. Furthermore, the certification information VC-n (second certification information) includes a user DID 100a-n (a second identifier for identifying at least one of the provider of the second distribution object, the generator of the second certification information, or the registrant of the second verification information corresponding to the second certification information) for identifying the user 1000-n who is the issuer of the certification information VC-n.

[0029] Step S1134-n: The proof information generating unit 113-n extracts the private key SK-n from the key information storing unit 111a-n, and generates and assigns an electronic signature VCproof-n for the body VCbody-n using the private key SK-n. For example, the proof information generating unit 113-n generates a hash value hash(VCbody-n) of the body VCbody-n, and generates an encrypted text for the hash value hash(VCbody-n) using the private key SK-n, and generates an electronic signature VCproof-n including the encrypted text. The proof information generating unit 113-n outputs a set of the body VCbody-n and the electronic signature VCproof-n as proof information VC-n. The proof information VC-n is stored in the proof information storing unit 111b-n. The proof information VC-n stored in the proof information storing unit 111b-n is read out when the product Pn is provided, and is output from the output unit 117-n. The output proof information VC-n is provided to the destination when the product Pn is provided. Usually, the proof information VC-n is provided to the recipient after the following verification information VI-n is registered in the verifiable data registry 121. Note that the proof information VC-n may be provided to the recipient in plain text, or may be provided to the recipient in an encrypted form (for example, encoded by JWT or the like and serialized).

[0030] Step S1135-n: The registration processing unit 116-n extracts the proof information VC-n from the proof information storage unit 111b-n, and registers (stores) the verification information VI-n corresponding to the proof information VC-n in the verifiable data registry 121 (FIG. 7A) on the block chain 120 of the cloud 12. The verification information VI-n includes, for example, a hash value of the proof information VC-n. For example, as illustrated in FIG. 7B, the verification information VI-n includes, for example, a hash value (key:hash(VCbody-n)) 101a-n of the body VCbody-n of the certification information VC-n, a user DID (issue:userDID-n) 101b-n that identifies the user 1000-n who is the issuer of the certification information VC-n, a product DID (id:productDID-n) 101c-n of the product Pn, the start date and time of the validity period (issue date) (issuanceDate:XXXX) 101d-n of the certification information VC-n, the end date and time of the validity period (expirationDate:XXXX) 101e-n of the certification information VC-n, and a status (status:XXXX) 101f-n that indicates the validity of the certification information VC-n. The user DID 101b-n, the product DID 101c-n of the product Pn, the validity start date and time 101d-n of the certification information VC-n, and the validity end date and time 101e-n of the certification information VC-n are, for example, the user DID 100a-n, the product DID 100d-n of the product Pn, the validity start date and time 100b-n of the certification information VC-n, and the validity end date and time 100c-n of the certification information VC-n included in the body VCbody-n of the certification information VC-n. The status 101f-n indicates whether the certification information VC-n is valid (True) or invalid (False). The initial value of the status 101f-n is valid (True). For example, a user 1000-n who is the issuer of proof information VC-n can use a terminal device 11-n to access the verifiable data registry 121 and switch the status 101f-n of the proof information VC-n registered in the verifiable data registry 121 to invalid (False) at any time. Verification information VI-n is registered in the verifiable data registry 121 on the blockchain 120 using a hash value (key:hash(VC-n)) 101a-n as a key.For example, when registering and updating the verification information VI-n (updating the status 101f-n), the following restrictions are imposed on the verifiable data registry 121 side. When registering verification information VI-n: Registration is accepted only if the address corresponding to the user DID (issue:userDID-n) 101b-n of the entered verification information VI-n matches the address calculated from the signature value of the transaction to register the information in the verifiable data registry 121 on the blockchain 120. When updating the verification information VI-n: The update of the verification information VI-n is accepted only when the address calculated from the signature value of the transaction for updating the information in the verifiable data registry 121 on the blockchain 120 matches the address corresponding to the user DID (issure:userDID-n) 101b-n of the verification information VI-n on the verifiable data registry 121 identified using the hash value (key:hash(VC-n)) 101a-n as a key. For example, the only property that can be updated when updating the verification information VI-n is the status 101f-n. However, this does not limit the present invention.

[0031] The verification information VI-n corresponding to the proof information VC-n corresponds to the "second verification information corresponding to the second proof information" and is registered in the verifiable data registry 121. 1 (n),…,P-ρ θ(n) (n) proof information VC-ρ 1 (n),…,VC-ρ θ(n) (n) may correspond to the "first proof information", and the proof information VC-ρ 1 (n),…,VC-ρ θ(n) Verification information VI-ρ corresponding to (n) 1 (n),…,VI-ρ θ(n) (n) may correspond to "first verification information corresponding to the first proof information." 1 (n),…,VI-ρ θ(n) (n) (first verification information) is also registered in the verifiable data registry 121.

[0032] <Hierarchical VC verification process> The hierarchical VC verification process of this embodiment will be described with reference to Figs. 1, 2, and 4 to 8. The hierarchical VC verification process of this embodiment may be executed before the hierarchical VC issuance process is performed, during the hierarchical VC issuance process, after the hierarchical VC issuance process is performed, or at a timing unrelated to the hierarchical VC issuance process. Moreover, the hierarchical VC verification process may be executed every time the hierarchical VC issuance process is performed, or may not be executed. Moreover, the hierarchical VC verification process may be executed in all the terminal devices 11-1, ..., 11-N, or the hierarchical VC verification process may be executed only in one of the terminal devices 11-n (where n ∈ {1, ..., N}). Here, as an example, when the terminal device 11-n executes the hierarchical VC issuance process, the terminal device 11-n issues proof information VC-i (where i ∈ {VC-ρ 1 (n),…,VC-ρ θ(n)}) will be described. However, this does not limit the present invention, and the terminal device 11-n may execute the hierarchical VC verification process of other proof information VC-m (here, m∈{1, ..., N}) at other timing.

[0033] Step S1141-n: As shown in Fig. 4, the verification unit 114-n of the terminal device 11-n (Fig. 2) that performs the hierarchical VC verification process extracts the proof information VC-i that is the target of the hierarchical VC verification process from the proof information storage unit 111b-n. The verification unit 114-n calls and performs <hierarchical VC recursive verification with the proof information VC-i as an argument>, and the verification result storage unit 115-n stores the returned result as the verification result RE-i of the proof information VC-i in the verification result storage unit 111c-n.

[0034] As described above, the proof information VC-i may correspond to "second proof information for proving a second distribution object based on at least the first distribution object." The verification result RE-i may correspond to "verification result of the second proof information." Proof information VC-ρ 1 (i),…,VC-ρ θ(i)(i) (First proof information) is the product P-ρ 1 (i),…,P-ρ θ(i) (i) A user DID (issuedTo:userDID-i) 100e-ρ that identifies a user 1000-i to whom (the first distribution target) is to be provided 1 (i),…,100e-ρ θ(i) (i) (first identifier) ​​or an identifier (such as “*”) indicating that the information is provided to any recipient (first identifier). The certification information VC-i (second certification information) may include at least the certification information VC-ρ 1 (i),…,VC-ρ θ(i) (i) includes an inherited certification information list 100g-i (information) for identifying (first certification information). Furthermore, the certification information VC-i (second certification information) includes a user DID 100a-i (a second identifier that identifies at least one of the provider of the second distribution target, the generator of the second certification information, or the registrant of the second verification information corresponding to the second certification information) that identifies the user 1000-i who is the issuer of the certification information VC-i. The verification information VI-i corresponding to the certification information VC-i corresponds to the "second verification information corresponding to the second certification information" and is registered in the verifiable data registry 121. In addition, the upstream product P-ρ of the product Pi 1 (i),…,P-ρ θ(i) Proof information VC-ρ of (i) 1 (i),…,VC-ρ θ(i) (i) may correspond to the "first proof", and the proof VC-ρ 1 (i),…,VC-ρ θ(i) Verification information VI-ρ corresponding to (i) 1 (i),…,VI-ρ θ(i) (i) may correspond to "first verification information corresponding to the first proof information". 1 (i),…,VI-ρ θ(i) (i) (first verification information) is also registered in the verifiable data registry 121.

[0035] Step S1142-n: The verification result RE-i of the proof information VC-i stored in the verification result storage unit 111c-n is sent to the output unit 117-n, and the output unit 117-n outputs the verification result of the proof information VC-i.

[0036] <Hierarchical VC recursive verification with VC-i as an argument (step S1141-n)> Step S1141a-n: The verification unit 114-n obtains the proof information VC-i from the proof information storage unit 111b-n. When the proof information VC-i is encrypted, the verification unit 114-n decrypts (decodes) the ciphertext of the proof information VC-i to obtain the proof information VC-i.

[0037] Step S1141b-n: The verification unit 114-n initializes the verification result (for example, verification result object) RE-i of the proof information VC-i. For example, the verification unit 114-n sets the initial value of the verification result of the proof information VC-i as follows. (1) Product DID (productDid): The DID of product P-i (2) Authenticity verification result (credentialExists): null (3) Expiration date verification result (isNotExpired): null (4) Status verification result (isNotRevoked): null (5) Issuer signature value verification result (issuerSignatureValid): null (6) Issuer authenticity verification result (issuerAuthorityValid): null (7) Product information (productInfo): null (8) List of inheritance proof information verification results (inheritances): [] Here, (1) product DID is a field in which the product DID of the certification information VC-i (i.e., product DID 100d-i (credentialSubject.id) in FIG. 6B) is set. (2) authenticity verification result is a field in which the verification result of whether the certification information VC-i is authentic is set. (3) expiration date verification result is a field in which whether the certification information VC-i is within the expiration date is set. (4) status verification result is a field in which the status of the verification information VI-i corresponding to the certification information VC-i is set to be valid or invalid. (5) issuer signature value verification result is a field in which the signature verification result of the certification information VC-i is set. (6) issuer validity verification result is a field in which whether the issuer of the certification information VC-i is valid or invalid is set. The initial values ​​of all of these fields are null. (7) product information is a field in which product information of the product Pi registered in the verifiable data registry 121 exists. The initial value is null. (8) The inherited certification information verification result list is the certification information VC-ρ specified in the inherited certification information list of the certification information VC-i. 1 (i),…,VC-ρ θ(i) This is the field where the verification result of (i) is set, and the initial value is an empty array (inheritances:[]).

[0038] Step S1141c-n: (a) The verification unit 114-n generates a hash value hash(VCbody-i) of the body VCbody-i of the proof information VC-i. (b) The verification unit 114-n obtains verification information VI-i from the verifiable data registry 121 using the hash value hash(VCbody-i) as a key, and obtains the following information (FIG. 7B). ·User DID(issure:userDID-i)101b-i Product DID (id:productDID-i) 101c-i · Validity start date and time (issuaiceDate:XXXX) 101d-i · Expiration date and time (expirationDate:XXXX) 101e-i Status(status:XXXX)101f-i (c) The verification unit 114-n sets the following in each field (each property) of the verification result of the certification information VC-i. Authenticity verification result: If the verification information VI-i can be obtained from the verifiable data registry 121 using the hash value hash(VCbody-i) as a key in the process of (b), (2) assigns True to the authenticity verification result, and if not, (2) assigns False to the authenticity verification result (verification of authenticity of certification information VI-i). As a result, for example, the certification information VC-i of product Pi and the certification information VC-ρ 1 (i),…,VC-ρ θ(i) It is possible to verify that (i) has not been tampered with. · Validity verification result: If the date and time when the process of step S1141c-n is performed is equal to or greater than the date and time specified by the validity start date and time 101d-i and is less than the date and time specified by the validity end date and time 101e-i, (3) assign True to the validity verification result, otherwise (3) assign False to the validity verification result. Note that if the verification information VI-i has not been acquired, (3) assign False to the validity verification result (validation of validity of verification information VI-i). As a result, the certification information VC-i of product Pi and the certification information VC-ρ included in the certification information VC-i are 1 (i),…,VC-ρ θ(i) It can be verified that (i) is within the validity period. Status verification result: If the status shown in the status 101f-i is valid, (4) True is substituted for the status verification result. If the status is invalid, (4) False is substituted for the status verification result. If the verification information VI-i has not been acquired, (4) False is substituted for the status verification result (status verification of the verification information VI-i). As a result, the certification information VC-i of the product Pi and the certification information VC-ρ 1 (i),…,VC-ρ θ(i) You can know whether (i) is valid or not. Issuer signature value verification result: If the verification result of the electronic signature VCproof-i for the body VCbody-i of the proof information VC-i is correct, (5) substitute True for the Issuer signature value verification result. If the verification result is incorrect, (5) substitute False for the Issuer signature value verification result. The verification unit 114-n performs this signature verification using, for example, a public key PK-i acquired from the verifiable data registry 121 of the block chain 120. However, if the public key PK-i can be specified from some information (for example, the body VCbody-i and the electronic signature VCproof-i), the verification unit 114-n may perform this signature verification using the specified public key PK-i. For example, as in the Ethereum method, if the public key PK-i corresponds to the address of the user assigned to the terminal device 11-i, this signature verification may be performed based on the consistency between the address of the user calculated from the public key PK-i and the address of the user corresponding to the user DID 101b-i (signature verification of the verification information VI-i). Product information: If the product information of product Pi can be obtained from the verifiable data registry 121 using the product DID of product Pi as a key, it is substituted for (7) Product information. If the product information cannot be obtained, it may be left as null or may be set as an empty object or an empty string. Alternatively, if the obtained product information of product Pi corresponds to the unique certification information 100f-i of product Pi in the verification information VI-i (for example, it matches), True may be substituted for (7) Product information, and if not, False may be substituted for (7) Product information.

[0039] That is, the verification unit 114-n verifies at least whether or not the certification information VC-i (second certification information) corresponds to the verification information VI-i (second verification information).

[0040] Step S1141d-n: The verification unit 114-n checks the inheritance certificate list (inheritances:[VC-ρ 1 (n),...,VC-ρ θ(n)(n)]) 100g-i is judged to have one or more elements (θ(n)≧1). If the number of elements is one or more, proceed to step S1141e-n. On the other hand, if the number of elements is not one or more, (6) Issuer validity verification result is substituted with True, and then proceed to step S1141f-n.

[0041] Step S1141e-n: Each element VC-j∈{VC-ρ 1 (i),…,VC-ρ θ(i) For each of the items {i)}, the processes from step S1141ea-n to step S1141ed-n are repeated.

[0042] Step S1141ea-n: The verification unit 114-n checks whether the proof information VC-j ∈ {VC-ρ 1 (i),…,VC-ρ θ(i) (i)}. When the proof information VC-j is described in the proof information VC-i, the verification unit 114-n obtains the proof information VC-j from the proof information VC-i. When the link destination of the element VC-j is described in the proof information VC-i, the verification unit 114-n obtains the proof information VC-j from the link destination. When the proof information VC-j is encrypted, the verification unit 114-n decrypts the ciphertext of the proof information VC-j to obtain the proof information VC-j.

[0043] Step S1141eb-n: The verification unit 114-n substitutes True into the (6) Issuer validity verification result when the user DID (the first identifier) that identifies the user 1000-ω(j), which is the provider of the product P-j represented by the user DID100e-j of the proof information VC-j, matches the user DID (the second identifier) that identifies the user 1000-i, which is the issuer of the proof information VC-i represented by the user DID100a-i of the proof information VC-i, or when the proof information VC-j is an identifier (for example, “*”) indicating that the product P-j is provided to an arbitrary provider. Otherwise, it substitutes False into the (6) Issuer validity verification result (verification of the validity of the proof information VC-i). That is, the verification unit 114-n verifies at least whether the first identifier corresponds to the second identifier. Thereby, it can be verified that the proof information VC-i of the product P-i and the proof information VC-ρ 1 (i),…,VC-ρ θ(i) (i) have been properly issued

[0044] Step S1141ec-n: The verification unit 114-n calls and executes <hierarchical VC recursive verification with VC-j as an argument>. This process is the process in which i in <hierarchical VC recursive verification with VC-i as an argument> is replaced with j. That is, the verification unit 114-n verifies at least whether the first proof information corresponds to the first verification information.

[0045] Step S1141ed-n: The verification unit 114-n adds the verification result RE-j of the proof information VC-j returned by <hierarchical VC recursive verification with VC-j as an argument> to the (8) inheritance proof information verification result list of the proof information VC-i.

[0046] When the above-mentioned step S1141e-n ends, it proceeds to step S1141f-n. Step S1141f-n: The verification unit 114-n returns the verification result RE-i of the proof information VC-i to the caller of <hierarchical VC recursive verification with VC-i as an argument>.

[0047] 8 illustrates an example of a verification result RE-i of the certification information VC-i. In this example, the verification result RE-i is substituted into each of the fields of the product DID (productDid) 102a-i, the authenticity verification result (credentialExists) 102b-i, the expiration date verification result (isNotExpired) 102c-i, the status verification result (isNotRevoked) 102d-i, the issuer signature value verification result (issuerSignatureValid) 102e-i, the issuer validity verification result (issuerAuthorityValid) 102f-i, and the product information (productInfo) 102g-i. In addition, the inheritance certification information verification result list (inheritances) 102h-i includes the certification information VC-ρ specified in the inheritance certification information list 100g-i of the certification information VC-i. 1 (i),VC-ρ 2 (i),VC-ρ 3 (i) Verification result of…RE-ρ 1 (i),RE-ρ 2 (i),RE-ρ 3 (i) ... are recursively substituted. For example, the proof information VC-ρ 1 (i) Inheritance Certification Information List 100g-ρ 1 If there is certification information specified in (i), the verification result of that certification information is also substituted into the certification information verification result list (inheritances) 102h-i.

[0048] [Second embodiment] In this embodiment, a specific example of the first embodiment will be illustrated. <Hierarchical VC issuing process> FIG. 9 illustrates an example of a hierarchical VC issuing process. Terminal device 11-1 of user 1000-1 who handles product P-1 generates proof information VC-1 (FIG. 3: steps S1121-1 to S1134-1), registers verification information VI-1 corresponding to the proof information VC-1 in the verifiable data registry 121 of the blockchain 120 (FIG. 3: step S1135-1), and provides the proof information VC-1 together with product P-1 to user 1000-3 who handles product P-3. The proof information VC-1 includes a user DID (issuer:userDID-1) that identifies user 1000-1 who is the issuer of the proof information VC-1, and an identifier (issuedTo:*) that indicates that product P-1 is provided to any destination.

[0049] Terminal device 11-2 of user 1000-2 who handles product P-2 generates certification information VC-2 (FIG. 3: steps S1121-2 to S1134-2), registers verification information VI-2 corresponding to the certification information VC-2 in the verifiable data registry 121 (FIG. 3: step S1135-2), and provides the certification information VC-2 together with product P-2 to user 1000-3 who handles product P-3. The certification information VC-2 includes a user DID (issuer:userDID-2) that identifies user 1000-2 who is the issuer of the certification information VC-2, and a user DID (issuedTo:userDID-3) that identifies user 1000-3 who is the recipient of product P-2.

[0050] Terminal device 11-3 of user 1000-3 who handles product P-3 generates certification information VC-3 (FIG. 3: steps S1121-3 to S1134-3), registers verification information VI-3 corresponding to the certification information VC-3 in verifiable data registry 121 (FIG. 3: step S1135-3), and provides the certification information VC-3 together with product P-3 to user 1000-4 who handles product P-4. The certification information VC-3 includes certification information VC-1 and VC-2, and includes a user DID (issuer:userDID-3) that identifies user 1000-3 who is the issuer of the certification information VC-3, and a user DID (issuedTo:userDID-4) that identifies user 1000-4 who is the recipient of product P-3.

[0051] Terminal device 11-4 of user 1000-4 who handles product P-4 generates certification information VC-4 (FIG. 3: steps S1121-4 to S1134-4), registers verification information VI-4 corresponding to the certification information VC-4 in verifiable data registry 121 (FIG. 3: step S1135-4), and provides the certification information VC-4 together with product P-5 to user 1000-5. The certification information VC-4 includes certification information VC-3, and includes a user DID (issuer:userDID-4) that identifies user 1000-4 who is the issuer of the certification information VC-4, and a user DID (issuedTo:userDID-5) that identifies user 1000-5 who is the recipient of product P-4.

[0052] An example of the certification information VC-n is shown in Fig. 10. The body VCbody-n of the certification information VC-n shown in Fig. 10 includes a user DID (issuer:did:ethr:12345:0x1234567890123456789012345678901234567890) 100a-n for identifying a user 1000-n who is the issuer of the certification information VC-n, a validity start date and time (issuance date and time) of the certification information VC-n, eDate:2023-04-13T15:00:00.000Z) 100b-n, expiration date and time of certification information VC-n (expirationDate:2023-12-31T15:00:00.000Z) 100c-n, product DID of product Pn (id:did:ethr:12345:0x2345678901234567890123456789 10 includes a user DID (issuedTo:did:ethr:12345:0x3456789012345678901234567890123456789012) 100e-n that identifies the user 1000-ω(n) to whom the product Pn is to be provided, unique proof information (originalInfo:{.......}) 100f-n of the product Pn, and an inheritance proof information list (inheritances:[eyJhbGciOiJFUzI1NksiLCJ0eXA...", "eyJhbGciOiJFUzI1NksiLCJ0eXAi..."]) 100g-n. The digital signature VCproof-n of the proof information VC-n shown in FIG. 10 is a digital signature for this body VCbody-n.

[0053] <Hierarchical VC verification process> An example of the hierarchical VC issuing process is illustrated in Fig. 11. Here, an example will be described in which a user 1000-5 verifies the proof information VC-4 using a terminal device 11-5.

[0054] The terminal device 11-5 of the user 1000-5 generates a hash value hash(VCbody-4) of the body VCbody-4 of the proof information VC-4, acquires the verification information VI-4 from the verifiable data registry 121 using the hash value hash(VCbody-4) as a key, verifies the authenticity of at least the proof information VC-4, and substitutes the result for the verification result (FIG. 5: steps S1141a-5 to S1141c-5). The terminal device 11-5 also acquires the proof information VC-3 from the succession proof information list of the proof information VC-4, verifies the authenticity of the proof information VC-4 using "issuedTo:userDID-4" of the proof information VC-3 and "issuer:userDID-4" of the proof information VC-4, and substitutes the result for the verification result. As a result of these, the verification result RE-4 of the proof information VC-4 is obtained (FIG. 5: steps S1141d-5 to S1141e-5).

[0055] Next, the terminal device 11-5 generates a hash value hash(VCbody-3) of the body VCbody-3 of the proof information VC-3, acquires the verification information VI-3 from the verifiable data registry 121 using the hash value hash(VCbody-3) as a key, verifies the authenticity of at least the proof information VC-3, and substitutes the result for the verification result (FIG. 5: steps S1141a-5 to S1141c-5). The terminal device 11-5 also acquires the proof information VC-1 and VC-2 from the inherited proof information list of the proof information VC-3, and verifies the authenticity of the proof information VC-3 using "issuedTo:*" of the proof information VC-1, "issuedTo:userDID-3" of the proof information VC-2, and "issuer:userDID-3" of the proof information VC-3, and substitutes the result for the verification result. As a result of these, the verification result RE-3 of the proof information VC-3 is obtained, and the verification result RE-3 is added to the successor proof information verification result list of the verification result RE-4 (FIG. 5: steps S1141d-5 to S1141e-5).

[0056] Next, the terminal device 11-5 generates a hash value hash(VCbody-2) of the body VCbody-2 of the proof information VC-2, obtains verification information VI-2 from the verifiable data registry 121 using the hash value hash(VCbody-2) as a key, verifies the authenticity of at least the proof information VC-2, and substitutes the result for the verification result (FIG. 5: steps S1141a-5 to S1141c-5). As a result, the verification result RE-2 of the proof information VC-2 is obtained, and the verification result RE-2 is added to the successor proof information verification result list of the verification result RE-3 (FIG. 5: steps S1141d-5 to S1141e-5).

[0057] Next, the terminal device 11-5 generates a hash value hash(VCbody-1) of the body VCbody-1 of the proof information VC-1, obtains the verification information VI-1 from the verifiable data registry 121 using the hash value hash(VCbody-1) as a key, verifies the authenticity of at least the proof information VC-1, and substitutes the result for the verification result (FIG. 5: steps S1141a-5 to S1141c-5). As a result, the verification result RE-1 of the proof information VC-1 is obtained, and the verification result RE-1 is added to the successor proof information verification result list of the verification result RE-3 (FIG. 5: steps S1141d-5 to S1141e-5). As a result of the above, the final verification result RE-4 is obtained.

[0058] An example of the verification result RE-i is shown in Fig. 12. In the verification result RE-i shown in Fig. 12, "did:ethr:12345:0xdddddddddddddddddddddddddddddddddddddddd" is assigned to the product DID (productDid) 102a-i, "true" is assigned to the authenticity verification result (credentialExists) 102b-i, "true" is assigned to the expiration date verification result (isNotExpired) 102c-i, "true" is assigned to the status verification result (isNotRevoked) 102d-i, "true" is assigned to the issuer signature value verification result (issuerSignatureValid) 102e-i, "true" is assigned to the issuer authenticity verification result (issuerAuthorityValid) 102f-i, and "did": "did:ethr:12345:0xdddddddddddddddddddddddddddddddddddddddddd",“manufacture": "did:ethr:12345:0x4 ... 1 (i)},{RE-ρ 2 (i)},{RE-ρ 3 (i)} …]}" is substituted.

[0059] <Example 1 of hierarchical VC verification results (Fig. 13 and Fig. 14)> Below, a hierarchical VC verification result will be illustrated using a concrete example of this embodiment. As shown in Fig. 13, in this example, user 1000-4 commits fraud in the hierarchical VC issuance process, generating proof information VC-3X by altering "originalInfo:product-3" in proof information VC-3 to "originalInfo:product-3X", and generating proof information VC-4 including the fraudulent proof information VC-3X. When hierarchical VC verification is performed on such proof information VC-4, the authenticity verification result of proof information VC-3X becomes False, as shown in Fig. 14. This makes it possible to detect that some fraud has occurred with respect to the proof information VC-4 issued by user 1000-4.

[0060] <Example 2 of hierarchical VC verification results (Fig. 15 and Fig. 16)> As shown in Fig. 15, in this example, a user 1000-X, who is different from the user 1000-4 to whom the original proof information VC-3 was originally provided, illegally obtains the proof information VC-3 and generates proof information VC-4. Therefore, the user DID that identifies the issuer of the proof information VC-4 is "issuer:userDID-X". When hierarchical VC verification is performed on such proof information VC-4, the result of the verification of the validity of the proof information VC-4 becomes False, as shown in Fig. 16. This makes it possible to detect that the user 1000-X has illegally used the proof information VC-3.

[0061] <Example 3 of hierarchical VC verification results (Fig. 17 and Fig. 18)> As illustrated in FIG. 17, in this example, a user 1000-3 commits fraud in a hierarchical VC issuance process, and generates proof information VC-1X by altering "originalInfo:product-1" of proof information VC-1 included in proof information VC-3 to "originalInfo:product-1X", and generates proof information VC-3 including the fraudulent proof information VC-1X. Furthermore, a user 1000-X, different from the user 1000-4, who is the original recipient of the original proof information VC-3, fraudulently obtains proof information VC-3 and generates proof information VC-4. Therefore, the user DID that identifies the issuer of proof information VC-4 is "issuer:userDID-X". When hierarchical VC verification is performed on such proof information VC-4, as illustrated in FIG. 18, the result of the validity verification of proof information VC-4 is False, and the result of the authenticity verification of proof information VC-1X is also False. This makes it possible to detect any irregularities in the certification information VC-3 issued by user 1000-3, and any irregularities in the use of certification information VC-3 by user 1000-X.

[0062] <Example 3 of hierarchical VC verification results (Fig. 19)> 19, in this example, the hierarchical VC issuance process was performed correctly, but the status of the proof information VC-1 was later invalidated (False) by the terminal device 11-1 of the user 1000-1. When the hierarchical VC verification is performed on such proof information VC-4, the status verification result of the proof information VC-1 becomes False.

[0063] <Timing of hierarchical VC verification> As described above, the hierarchical VC verification may be executed before the hierarchical VC issuance process is performed, may be executed during the hierarchical VC issuance process, may be executed after the hierarchical VC issuance process is performed, or may be executed at a timing unrelated to the hierarchical VC issuance process. In addition, the hierarchical VC verification process may be executed every time the hierarchical VC issuance process is performed, or may not be executed. FIG. 20A illustrates an example of a process in which the hierarchical VC verification process is executed every time the hierarchical VC issuance process is performed in the example of FIG. 11. FIG. 20B conceptually illustrates the verification result in this case. Note that when "true" is simply written, it indicates that all the verifications were normal.

[0064] <Example 1 of hierarchical VC verification results (Fig. 13, Fig. 14)> Fig. 21A illustrates a process in which a hierarchical VC verification process is executed every time a hierarchical VC issuance process is performed in the example 1 of the hierarchical VC verification result illustrated in Fig. 13 and Fig. 14. Fig. 21B conceptually illustrates the verification result in this case.

[0065] <Example 2 of hierarchical VC verification results (Fig. 15, Fig. 16)> Fig. 22A illustrates a process in which a hierarchical VC verification process is executed every time a hierarchical VC issuance process is performed in the example 2 of the hierarchical VC verification result illustrated in Fig. 15 and Fig. 16. Fig. 22B conceptually illustrates the verification result in this case.

[0066] <Example 3 of hierarchical VC verification results (Fig. 17 and Fig. 18)> Fig. 23A illustrates a process in which a hierarchical VC verification process is executed every time a hierarchical VC issuance process is performed in the example 3 of the hierarchical VC verification result illustrated in Fig. 17 and Fig. 18. Fig. 23B conceptually illustrates the verification result in this case.

[0067] <Example 3 of hierarchical VC verification results (Figure 19)> Fig. 24A illustrates an example of a process in which a hierarchical VC verification process is executed every time a hierarchical VC issuance process is performed in the example 3 of the hierarchical VC verification result illustrated in Fig. 19. Fig. 24B conceptually illustrates the verification result in this case.

[0068] [Hardware configuration] The terminal device 11-n in each embodiment is a device configured by a general-purpose or dedicated computer having a processor (hardware processor) such as a CPU (central processing unit) and a memory such as a RAM (random-access memory) and a ROM (read-only memory) executing a predetermined program. That is, the terminal device 11-n in each embodiment has, for example, a processing circuit configured to implement each unit that each device has. This computer may have one processor and memory, or may have multiple processors and memories. This program may be installed in the computer, or may be recorded in a ROM or the like in advance. In addition, some or all of the processing units may be configured using electronic circuits that realize processing functions by themselves, rather than electronic circuits that realize functional configurations by reading programs like a CPU. In addition, the electronic circuits that configure one device may include multiple CPUs.

[0069] FIG. 25 is a block diagram illustrating the hardware configuration of the terminal device 11-n in each embodiment. As illustrated in FIG. 25, the terminal device 11-n in this example has a CPU (Central Processing Unit) 10a, an input unit 10b, an output unit 10c, a RAM (Random Access Memory) 10d, a ROM (Read Only Memory) 10e, an auxiliary storage device 10f, a communication unit 10h, and a bus 10g. The CPU 10a in this example has a control unit 10aa, a calculation unit 10ab, and a register 10ac, and executes various calculation processes according to various programs loaded into the register 10ac. The input unit 10b is an input terminal, a keyboard, a mouse, a touch panel, etc., to which data is input. The output unit 10c is an output terminal, a display, etc., to which data is output. The communication unit 10h is a LAN card, etc., controlled by the CPU 10a that has loaded a predetermined program. The RAM 10d is a static random access memory (SRAM), a dynamic random access memory (DRAM), or the like, and has a program area 10da in which a predetermined program is stored, and a data area 10db in which various data is stored. The auxiliary storage device 10f is, for example, a hard disk, a magneto-optical disc (MO), a semiconductor memory, or the like, and has a program area 10fa in which a predetermined program is stored, and a data area 10fb in which various data is stored. The bus 10g connects the CPU 10a, the input unit 10b, the output unit 10c, the RAM 10d, the ROM 10e, and the auxiliary storage device 10f so that information can be exchanged. The CPU 10a writes the program stored in the program area 10fa of the auxiliary storage device 10f to the program area 10da of the RAM 10d according to the loaded OS (Operating System) program. Similarly, the CPU 10a writes various data stored in the data area 10fb of the auxiliary storage device 10f to the data area 10db of the RAM 10d. The addresses on the RAM 10d where these programs and data are written are stored in the register 10ac of the CPU 10a.The control unit 10aa of the CPU 10a sequentially reads out these addresses stored in the register 10ac, reads out the programs and data from the areas on the RAM 10d indicated by the read addresses, sequentially causes the calculation unit 10ab to execute the calculations indicated by the programs, and stores the calculation results in the register 10ac. With this configuration, the functional configuration of the terminal device 11-n is realized.

[0070] The above-mentioned program can be recorded on a computer-readable recording medium. An example of a computer-readable recording medium is a non-transitory recording medium. Examples of such a recording medium include a magnetic recording device, an optical disk, a magneto-optical recording medium, a semiconductor memory, and the like.

[0071] The distribution of this program is performed, for example, by selling, transferring, lending, etc., a portable recording medium such as a DVD or CD-ROM on which the program is recorded. Furthermore, the program may be stored in a storage device of a server computer, and the program may be distributed by transferring the program from the server computer to another computer via a network. As described above, a computer that executes such a program, for example, first temporarily stores in its own storage device the program recorded in the portable recording medium or the program transferred from the server computer. Then, when executing the process, the computer reads the program stored in its own storage device and executes the process according to the read program. As another execution form of the program, the computer may directly read the program from the portable recording medium and execute the process according to the program, and further, each time the program is transferred from the server computer to the computer, the computer may execute the process according to the received program. Furthermore, the server computer may not transfer the program to the computer, and the above-mentioned process may be executed by a so-called ASP (Application Service Provider) type service that realizes the processing function only by issuing an execution instruction and obtaining the result. In addition, the program in this embodiment includes information used for processing by an electronic computer and equivalent to a program (such as data that is not a direct instruction to a computer but has the nature of defining computer processing).

[0072] Here, the present device is configured by executing a predetermined program on a computer, but at least a part of the processing contents may be realized by hardware.

[0073] [Variations] The present invention is not limited to the above-mentioned embodiment. For example, at least one of the validity start date and time (issuanceDate:XXXX) 100b-n of the certification information VC-n, the validity end date and time (expirationDate:XXXX) 100c-n of the certification information VC-n, or the unique certification information (originalInfo:product-n) 100f-n of the product Pn may be omitted from the body VCbody-n of the certification information VC-n (FIG. 6B). Also, at least one of the validity start date and time (issue date) (issuanceDate:XXXX) 101d-n of the certification information VC-n, the validity end date and time (expirationDate:XXXX) 101e-n of the certification information VC-n, or the status (status:XXXX) 101f-n indicating the validity of the certification information VC-n may be omitted from the verification information VI-n (FIG. 7B). Also, at least one of the validity verification, status verification, signature verification, or validity verification described above may be omitted. In that case, these verification results are also omitted from the verification results.

[0074] The information stored in the verifiable data registry 121 on the cloud 12 may be stored on a server.

[0075] In the above embodiment, if the verification information VI-i can be obtained from the verifiable data registry 121 using the hash value hash(VCbody-i) as a key in the process of (b) of step S1141c-n, it is determined that the authenticity verification result is True, that is, the proof information VC-i is authentic. However, this does not limit the present invention, and as long as it is possible to verify whether the proof information VC-i corresponds to the verification information VI-i, it may be determined whether the proof information VC-i is authentic by other methods. For example, the proof information VC-i and the verification information VI-i may be compared, and if they match, it may be determined that the proof information VC-i is authentic, and if they do not match, it may be determined that the proof information VC-i is not authentic. In addition, for example, a function value of the proof information VC-i and a function value of the verification information VI-i may be compared, and if they match, it may be determined that the proof information VC-i is authentic, and if they do not match, it may be determined that the proof information VC-i is not authentic.

[0076] In addition, the various processes described above may not only be executed in chronological order as described, but may also be executed in parallel or individually depending on the processing capacity of the device that executes the processes or on the need of the device. Needless to say, other appropriate modifications are possible without departing from the spirit of the present invention. [Explanation of symbols]

[0077] 11 Terminal Equipment 113 Proof Information Generation Unit 114 Verification Department 115 Verification result storage section 12. Cloud 121 Verifiable Data Registry

Claims

1. a certification information generating unit that uses first certification information for certifying a first distribution object to generate second certification information for certifying a second distribution object based on at least the first distribution object; a registration processing unit that registers second verification information corresponding to the second certification information, the second certification information includes at least information for identifying the first certification information, A terminal device in which first verification information corresponding to the first certification information is registered.

2. a verification unit that verifies second certification information for verifying the second distribution object based on at least the first distribution object; a verification result storage unit for storing a verification result of the second certification information; having The second certification information includes at least information for identifying the first certification information for certifying the first distribution object, At least first verification information corresponding to the first certification information and second verification information corresponding to the second certification information are registered; The verification unit at least verifies whether the second certification information corresponds to the second verification information, and verifies whether the first certification information corresponds to the first verification information.

3. A method for generating certification information by a terminal device, comprising: a proof information generating step of generating second proof information for certifying a second distribution object based on at least the first distribution object by using first proof information for certifying a first distribution object by a proof information generating unit; a registration processing step of registering second verification information corresponding to the second certification information by a registration processing unit; the second certification information includes at least information for identifying the first certification information, a first verification information corresponding to the first certification information is registered;

4. A verification method by a terminal device, comprising: a verification step in which a verification unit verifies second certification information for certifying a second distribution object based on at least the first distribution object; a verification result storage step of storing a verification result of the second certification information by a verification result storage unit; The second certification information includes at least information for identifying the first certification information for certifying the first distribution object, At least first verification information corresponding to the first certification information and second verification information corresponding to the second certification information are registered; A verification method, wherein the verification step is at least a step of verifying whether the second certification information corresponds to the second verification information, and verifying whether the first certification information corresponds to the first verification information.

5. A program for causing a computer to function as the terminal device of claim 1 or 2.

Images