Presentation system, presentation program, and presentation method

Abstract

To provide a model for optimizing identity management for each service.SOLUTION: A presentation system includes acquisition means, issuance means, and presentation means. The acquisition means acquires holding information held by a user of a service in accordance with use of the service. The issuance means issues verifiable personal information to a user on the basis of a user ID that is a distributed identifier associated with a wallet of the user, a provider ID that is a distributed identifier associated with a provider that provides a service, and held information, the verifiable personal information proving that the user holds the held information. The presentation means receives, from the user, selection of the held information desired to be presented to the predetermined opposite party among the held information included in the personal information, and presents only the selected held information desired to be presented to the predetermined opposite party.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a presentation system, a presentation program, and a presentation method. [Background technology]

[0002] A method has been proposed for mutual authentication that utilizes the user's Decentralized Identity (DID), which is an application program installed on the user's mobile device. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Special Publication No. 2024-507304 Summary of the Invention [Problem to be solved by the invention]

[0004] However, the above-mentioned conventional technology provides a DID-based online mutual authentication technology that first checks whether the service requesting user authentication is a legitimate service and then transmits the user's authentication value to the corresponding service.

[0005] As described above, the above-mentioned conventional technologies aim to verify the authenticity of service providers that provide specific services, and do not disclose a method for solving issues related to identity management for each service. Therefore, the above-mentioned conventional technologies do not necessarily provide a model that optimizes identity management for each service.

[0006] The present invention proposes a presentation system, a presentation program, and a presentation method that can provide a model that optimizes identity management for each service. [Means for solving the problem]

[0007] The presentation system of the present invention comprises an acquisition means for acquiring held information held by a user of the service in response to use of the service; an issuance means for issuing verifiable personal information to the user that serves as proof that the user holds the held information based on a user ID which is a decentralized identifier linked to the user's wallet, a provider ID which is a decentralized identifier linked to a provider that provides the service, and the held information; and a presentation means for accepting from the user a selection of held information included in the personal information that the user wishes to present to a specified recipient, and presenting only the selected held information that the user wishes to present to the specified recipient.

[0008] The presentation program of the present invention causes a computer possessed by a presentation system to function as an acquisition means for acquiring held information held by a user of the service in response to use of the service, an issuance means for issuing verifiable personal information to the user that serves as proof that the user holds the held information based on a user ID which is a decentralized identifier linked to the user's wallet, a provider ID which is a decentralized identifier linked to the provider of the service, and the held information, and a presentation means for accepting from the user a selection of held information that the user wishes to present to a specified recipient from the held information included in the personal information, and presenting only the selected held information that the user wishes to present to the specified recipient.

[0009] The presentation method of the present invention is a presentation method executed by a presentation system, and includes: an acquisition step of acquiring held information held by a user of the service in response to use of the service; an issuance step of issuing verifiable personal information to the user that serves as proof that the user holds the held information, based on a user ID which is a decentralized identifier linked to the user's wallet, a provider ID which is a decentralized identifier linked to a provider that provides the service, and the held information; and a presentation step of accepting from the user a selection of held information that the user wishes to present to a specified recipient from the held information included in the personal information, and presenting only the selected held information that the user wishes to present to the specified recipient. [Effects of the Invention]

[0010] According to the present invention, a model for optimizing identity management for each service can be provided. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram showing an outline of the proposed technology of the present invention. [Figure 2] FIG. 2 is a diagram showing a specific example of information processing implemented by the presentation system according to the embodiment. [Figure 3] FIG. 3 is a diagram for explaining an outline of information processing corresponding to the token issuance timing. [Figure 4] FIG. 4 is a diagram showing the procedure (1) of information processing executed by the presentation system. [Figure 5] FIG. 5 provides an overview of information processing corresponding to the timing of a user request. [Figure 6] FIG. 6 is a diagram showing the procedure (2) of information processing executed by the presentation system. [Figure 7] FIG. 7 is a diagram showing an application example of the proposed technique of the present invention. [Figure 8] FIG. 8 is a hardware configuration diagram illustrating an example of a computer according to the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0012] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. In this specification and drawings, components having substantially the same functional configurations are designated by the same reference numerals, and redundant description will be omitted.

[0013] One or more embodiments (including examples, modifications, and application examples) described below can be implemented independently. However, at least a portion of the embodiments described below may be implemented in appropriate combination with at least a portion of another embodiment. These embodiments may include novel features that are different from each other. Therefore, these embodiments may contribute to solving different purposes or problems and may produce different effects from each other.

[0014] (Embodiment) 1. Introduction A collection of an identifier that identifies an entity using a service, a password corresponding to the identifier, and personal attribute information linked to the identifier and password (e.g., name, date of birth, occupation, etc.) is called a digital identity (hereinafter referred to as "identity").

[0015] Identity is used in a variety of ways on the Internet. For example, when using services or making transactions online, identity is becoming increasingly important in verifying the identity of customers and providing what they need, and various approaches are being taken.

[0016] For example, with the development of blockchain technology and the widespread adoption of web3 services, tokens are no longer just a common means of value exchange as crypto assets, but are also being used in the context of forming and sharing identities. However, there are various challenges in using tokens as identities. Below, we will explain the challenges related to identity management from the perspective of web3 services.

[0017] Challenges related to identity management include "data silos," "complex asset management through wallets," and "privacy risks."

[0018] "Data silos" refers to a situation in which personal data and tokens are managed separately and siloed across different blockchains, limiting the scope of token use and data distribution. Under such restrictions, it becomes difficult to provide cross-sectional services that can be created by aggregating personal reputations, activity histories, and hobby preferences. Furthermore, if the network goes down, recorded tokens may be lost, potentially compromising convenience and security for users.

[0019] "Wallet-based asset management complexity" refers to a situation in which the use of multiple wallets complicates asset management, such as tokens, resulting in a poor user experience when using services. To give a specific example, due to privacy concerns and the need to protect against hacking and other risks, users tend to use multiple wallets and wallet addresses. Furthermore, the proliferation of wallets offered by various providers limits wallet options depending on the service used and the user's environment, contributing to the increase in the number of wallets owned by users. As a result, the increase in the number of wallets owned makes it difficult for users to centrally manage which tokens are stored in which wallets, in addition to managing the wallets themselves, which can lead to cumbersome operations, for example, when using token-gate services.

[0020] "Privacy risk" refers to the risk of unintentionally compromising personal privacy when a user's wallet address becomes known to others when using decentralized applications or web3 services. For example, because wallet addresses are fixed, service providers can access all tokens and transaction details associated with a user's wallet address. Furthermore, as tokens become more diverse in their uses, they have become information that forms identities. Once a certain number of tokens are collected, their characteristics can be ascertained. For example, if a collection of tokens is linked to a social networking site or web2 service, individuals may be identified. Furthermore, users may have separate public and private wallets. If users transfer tokens between these wallets, tracking their transaction history based on the public wallet address can reveal not only the private wallet address but also the contents of the private wallet.

[0021] For these reasons, while the benefit of web3 services is the use of data that is premised on anonymity and public information, there is a demand for a certain level of privacy protection as tokens themselves tend to become identities. For example, there are needs such as wanting to maintain a persona within a community (only wanting to share the aspects of oneself that one wants to show) and not wanting the service to know more about one's token holdings than necessary.

[0022] Therefore, in consideration of the above-mentioned issues and needs, the inventor of the present invention came up with the idea that adding an identity layer that allows users to sovereignly and centrally manage the shared scope of token holding information without changing the structure of existing tokens or blockchain infrastructure itself would enable safer and more convenient service use. The proposed technology of the present invention makes it possible to provide a model that optimizes identity management for each service.

[0023] The technology proposed by the present invention will be described in detail below with reference to the drawings, but the technology proposed by the present invention is applicable not only to web3 type services but also to web2 type services. In other words, the technology proposed by the present invention is not a limited technology specialized for web3 type services, but can be applied to various types of services.

[0024] In the following embodiments, the token will be described as a non-fungible token (NFT), but may be a fungible token (FT). Furthermore, the term "service" also includes the concept of an application that provides the service.

[0025] 2. Overview of the Invention DID (Decentralized Identifier) ​​and VC (Verifiable Credentials) are known as mechanisms for proving one's identity and information about oneself without relying on a centralized ID issuer (platform). In DID / VC, each business participating in the trust framework and the user's application (wallet) have a DID, and the user can store data (VC) in their wallet that is identity information with a digital signature from the information issuer. Furthermore, when the user shares the stored data (VC) with a business, the business can verify that the data was issued by a legitimate issuer by verifying the signature attached to the VC. Furthermore, a distributed database (blockchain) is used to realize such a mechanism.

[0026] The technology proposed by the present invention uses DID / VC as its core technology. Specifically, as shown in Figure 1, the technology proposed by the present invention establishes a layer for managing identities in web2 type services or web3 type services. Figure 1 is a diagram showing an overview of the technology proposed by the present invention. Figure 1 shows the layer structure related to the technology proposed by the present invention.

[0027] According to the example of Figure 1, the layer structure of the proposed technology of the present invention includes layer L1, which corresponds to the infrastructure, layer L2, which stores data accumulated by using an application (service), layer L3, which corresponds to the application (service), and layer L4, which corresponds to the access rights for a user to obtain all data linked to their ID, and further includes layer L5, which centrally manages the identities formed by these layers.

[0028] The establishment of Layer L5 will enable centralized identity federation that is not dependent on platform technology, including not only web3-type services but also web2-type services, as shown in Figure 1. As a result, multiple wallet addresses and accounts can be aggregated into a DID that belongs to an individual user. In addition, the information held by a user can be converted into a VC, which can be proven to the other party while maintaining privacy off-chain.

[0029] Here, Figure 1 shows an example in which one user U uses service SV2 (an application that provides service SV2) as a web2 type service, and performs various activities and has qualifications within service SV2. Activity record information and qualification information correspond to the information possessed by user U in accordance with the use of service SA2. As shown in Figure 1, activity record information and qualification information are managed in a database DB on the service SV2 side, linked to account web2ID, which is user U's account (ID) for web2.

[0030] 1 also shows an example in which user U uses two types of web3 type services and uses multiple wallet addresses within the same service. Specifically, user U uses service SV31 (an application that provides service SV31) and service SV32 (an application that provides service SV32). Furthermore, user U has, for example, a public wallet address and a private wallet address within one service SV31.

[0031] More specifically, the example shows that user U associates some tokens corresponding to activities and contributions within service SV31 with wallet address AD1, while other tokens are associated with a different wallet address AD2 and stored in wallet WL31. The tokens stored in wallet WL31 correspond to the information held by user U in accordance with the use of service SA31. The information on the tokens stored in wallet WL31 is managed in the corresponding blockchain BC31, as shown in Figure 1.

[0032] In addition, user U also uses another service SV32 different from service SV31, and tokens corresponding to activities and contributions within service SV32 are stored in wallet WL32, which corresponds to service SV32 and is identified by wallet address AD3. The tokens stored in wallet WL32 correspond to information held by user U in response to use of service SA32. The information on the tokens stored in wallet WL32 is managed by the corresponding blockchain BC32.

[0033] In this way, User U may use multiple different services or use multiple different accounts for the same service. As the number of services and accounts used increases, the problems of "data siloization," "complex asset management using wallets," and "privacy risks" mentioned above are likely to become more pronounced.

[0034] However, by establishing Layer L5, the account web2ID, wallet address AD1, wallet address AD2, and wallet address AD3 can be linked to a single DID held by the user. Furthermore, this linking allows user U to present his / her own data and tokens, which are held information converted into VC, to decentralized applications and other services, as shown in Figure 1. Specifically, user U can selectively present only the necessary amount of data and tokens to desired recipients without disclosing account web2ID, wallet address AD1, wallet address AD2, and wallet address AD3, while keeping other data and tokens confidential.

[0035] Thus, the feature of the proposed technology of the present invention is that a VC based on the user U's DID, the service provider's DID, and the user U's held information is issued to the user, and the user is allowed to select the held information that they wish to present to a specified recipient from the held information included in the issued VC, thereby enabling selective presentation of only the selected held information to the recipient.

[0036] Here, issuing a VC based on held information can be rephrased as converting held information into VC. Here, VC refers to verifiable personal information (attribute information) that proves that user U actually holds the held information. Figure 1 shows a list of held information that will be converted into VC. According to the example in Figure 1, in the case of web3, the VC includes token information linked to the wallet address, such as information about the issuer that issued the token, a timestamp when the token was issued, the type of token, the token content, and the amount of tokens held by user U. According to the example in Figure 1, the VC also includes user U's DID, a digital signature generated using user U's private key, the service provider's DID, and a digital signature generated using the service provider's private key.

[0037] Although not shown in Figure 1, in the case of web2, the VC will contain data linked to the account web2ID, rather than token information linked to the wallet address.

[0038] Here, as an example of when user U uses multiple different services, we will use the example of service SV31 and service SV32 to explain a specific example of a situation in which only the desired held information from the held information that has been converted into VC is presented to a specified recipient (service SAx).

[0039] According to the presentation system 1 relating to the proposed technology of the present invention, information on tokens issued in accordance with the activities and contributions of user U within service SV31 is obtained from blockchain BC31. Specifically, the presentation system 1 obtains token information of user U corresponding to service SV31 using wallet address AD1 and wallet address AD2 as keys.

[0040] In addition, the presentation system 1 obtains information on tokens issued in response to the activities and contributions of the user U in the service SV32 from the blockchain BC32. Specifically, the presentation system 1 obtains the token information of the user U corresponding to the service SV32 using the wallet address AD3 as a key.

[0041] In this state, the presentation system 1 issues personal information VC31 in which the token information (held information) has been converted into VC based on the DID of user U, the DID of service SV31, and the token information acquired from the blockchain BC31. The personal information VC31 includes the DID of user U, an electronic signature generated using the private key of user U, the DID of service SV31, an electronic signature generated using the private key of service SV31, and the token information acquired from the blockchain BC31.

[0042] Furthermore, the presentation system 1 issues personal information VC32 in which the token information (held information) is converted into VC based on the DID of user U, the DID on the service SV32 side, and the token information acquired from the blockchain BC32. The personal information VC32 includes the DID of user U, an electronic signature generated using the private key of user U, the DID on the service SV32 side, an electronic signature generated using the private key on the service SV32 side, and the token information acquired from the blockchain BC32.

[0043] The personal information VC31 and the personal information VC32 are linked to the DID of the user U. That is, the presentation system 1 manages the personal information VC31 and the personal information VC32 by linking them to a single DID owned by the user U. Here, the presentation system 1 accepts a selection of only what range of held information corresponding to which service is to be presented to the service SAx from among the held information (token information) included in the personal information VC31 and the held information (token information) included in the personal information VC32.

[0044] As an example, the presentation system 1 can accept a selection from the user U such that, among the information on tokens issued by using the service SA31, only the information on tokens for the most recent month is to be presented to the service SAx. When such a selection is accepted, the presentation system 1 presents to the service SAx only the information on tokens for the range selected by the user U. On the service SAx side, the authenticity of the presented token information is verified using the corresponding public key.

[0045] Next, as an example of a case where user U uses multiple different accounts (IDs), we will use the example of wallet address AD1 and wallet address AD2 to explain a specific example of a situation in which only the desired information held from the information held that has been converted into VC is presented to a specified recipient (service SAx).

[0046] The presentation system 1 acquires from the blockchain BC31 information on tokens that are linked to a wallet address AD1 among information on tokens that have been issued in response to the activities and contributions of the user U within the service SV31. The presentation system 1 also acquires from the blockchain BC31 information on tokens that are linked to a wallet address AD2 among information on tokens that have been issued in response to the activities and contributions of the user U within the service SV31.

[0047] In this state, the presentation system 1 issues personal information VC31 in which the token information (held information) has been converted into VC based on the DID of user U, the DID on the service SV31 side, and the token information acquired from the blockchain BC31. The personal information VC31 includes the DID of user U, an electronic signature generated using the private key of user U, the DID on the service SV31 side, an electronic signature generated using the private key on the service SV31 side, and the token information acquired from the blockchain BC31. In other words, the personal information VC31 includes both the token information linked to the wallet address AD1 and the token information linked to the wallet address AD2.

[0048] The personal information VC31 is linked to the DID of the user U. In other words, the presentation system 1 manages the personal information VC31 by linking it to a single DID owned by the user U. Here, the presentation system 1 accepts a selection of only what range of held information (token information) included in the personal information VC31 corresponds to which service and is to be presented to the service SAx.

[0049] As an example, the presentation system 1 can receive a selection from the user U that, among the information on tokens issued by using the service SA31, only the information on tokens for January to March 2024 should be presented to the service SAx. When such a selection is received, the presentation system 1 presents only the range of tokens selected by the user U to the service SAx. On the service SAx side, the authenticity of the presented token information is verified using the corresponding public key.

[0050] In the above example, the presentation system 1 allows the user to select a period, but the period is not limited to a period. For example, the period that the presentation system 1 allows the user to select may be the type of token, the content of the token, or the amount of tokens held by the user U.

[0051] 3. Information Processing According to the Present Invention A more detailed specific example of information processing realized by the presentation system 1 (information processing according to the present invention) will be described with reference to Fig. 2. Fig. 2 is a diagram showing a specific example of information processing realized by the presentation system 1 according to the embodiment. Fig. 2 shows a scene in which a user U participating in "Project-A," "Project-B," and "Project-C" selectively discloses only any of the information held by the user U in each project to a community of a desired recipient.

[0052] In the example of Figure 2, "Project-A" and "Project-C" are web3 projects. For example, "Project-A" and "Project-C" are services that issue tokens, sell tokens, and provide experiences using tokens. Examples of such web3 services include community services where users can earn tokens based on their activities (for example, a community where fans who support a particular object gather), or services that provide experiences using tokens (for example, music experiences).

[0053] On the other hand, "Project-B" is a web2 project. For example, "Project-B" may be a community service (e.g., a social networking service (SNS)), a blog, a search service, etc.

[0054] In the example of Fig. 2, user U stores tokens issued by service SA31 in accordance with the contributions made to "Project-A" (which corresponds to service SA31 in Fig. 1) in wallet WL31, which is an application installed in the user's terminal device 10. Specifically, the tokens are linked to wallet address AD1 of wallet WL31. The tokens linked to wallet address AD1 are user U's possession information HL1.

[0055] Furthermore, user U has an account web2ID for accessing service SA2 so that he can check data indicating his contributions to "Project-B" (which corresponds to service SA2 in FIG. 1) from his own terminal device 10. For example, in the RDB on the service SA2 side, data indicating user U's contributions is managed in a state linked to account web2ID. The data linked to account web2ID is user U's owned information HL2.

[0056] Furthermore, user U stores tokens issued by service SA32 in accordance with his or her contributions to "Project-C" (which corresponds to service SA32 in FIG. 1) in wallet WL32, which is an application installed on his or her terminal device 10. Specifically, the tokens are linked to wallet address AD3 of wallet WL32. The tokens linked to wallet address AD3 are user U's possession information HL3.

[0057] Here, the wallet VCWL is installed in the user's terminal device 10 as a VC wallet, which is an application related to issuing a DID and converting held information into VC.

[0058] In this state, for example, when the presentation system 1 receives access from the wallet VCWL, it converts the held information HL1 into VC. Specifically, the presentation system 1 generates verifiable personal information VC_HL1 that proves that the user U holds the held information HL1, and issues the generated personal information VC_HL1 to the wallet VCWL.

[0059] Furthermore, the presentation system 1 converts the held information HL2 into VC. Specifically, the presentation system 1 generates verifiable personal information VC_HL2 that serves as proof that the user U holds the held information HL2, and issues the generated personal information VC_HL2 to the wallet VCWL.

[0060] Furthermore, the presentation system 1 converts the held information HL3 into VC. Specifically, the presentation system 1 generates verifiable personal information VC_HL3 that serves as proof that the user U holds the held information HL3, and issues the generated personal information VC_HL3 to the wallet VCWL.

[0061] As shown in FIG. 2, the wallet VCWL, which is one function included in the presentation system 1, links personal information VC_HL1, personal information VC_HL2, and personal information VC_HL3 to the DID of the user U (the DID issued to the wallet VCWL).

[0062] Here, if personal information VCn is a single verifiable personal information that combines personal information VC_HL1, personal information VC_HL2, and personal information VC_HL3 using user U's DID as a key, personal information VCn also includes user U's DID, an electronic signature generated using user U's private key, the DID on the service SV31 side, an electronic signature generated using the private key on the service SV31 side, the DID on the service SV32 side, and an electronic signature generated using the private key on the service SV32 side.

[0063] In this state, the wallet VCWL receives a selection from the user U of the held information that the user wishes to present, that is, which of the personal information VC_HL1, personal information VC_HL2, and personal information VC_HL3 should be presented to which other service.

[0064] Figure 2 shows communities C1, C2, and C3 as a service that allows participation or provides benefits only to those whose possessed information meets certain conditions, and shows an example of a request from each of these communities to present possessed information.

[0065] For example, assume that community C1 defines a condition CD1 that states, "Participation is permitted for those who hold N1 or more tokens issued during the P1 period." In this case, a user U who wishes to participate in community C1 selects only the personal information included in personal information VCn that satisfies condition CD1 and inputs it into wallet VCWL. FIG. 2 shows an example in which user U selects personal information VC_HL1 from personal information VCn. In this example, wallet VCWL selectively presents only personal information VC_HL1 to community C1, as shown in FIG. 2. Furthermore, community C1 verifies whether personal information VC_HL1 satisfies condition CD1, and permits user U to participate if condition CD1 is satisfied.

[0066] Assume that community C2 defines a condition CD2 that "those whose contribution record during the P2 period is equal to or greater than N2 will be permitted to participate." In this case, a user U who wishes to participate in community C2 selects the amount of personal information included in personal information VCn that satisfies the condition CD2 and inputs it into wallet VCWL. FIG. 2 shows an example in which user U selects personal information VC_HL2 from personal information VCn. In this example, wallet VCWL selectively presents only personal information VC_HL2 to community C2, as shown in FIG. 2. Furthermore, community C2 verifies whether personal information VC_HL2 satisfies condition CD2, and if condition CD2 is satisfied, permits user U to participate.

[0067] Assume that community C3 defines condition CD3 as "a predetermined benefit will be given to a person who holds N3 types of tokens issued during the P3 period." In this case, user U, who wants to earn points, selects the amount of personal information included in personal information VCn that satisfies condition CD3 and inputs it into wallet VCWL. FIG. 2 shows an example in which user U selects personal information VC_HL3 from personal information VCn. In this example, wallet VCWL selectively presents only personal information VC_HL3 to community C3, as shown in FIG. 2. Furthermore, community C3 verifies whether personal information VC_HL1 satisfies condition CD3, and if condition CD3 is met, grants a benefit to user U.

[0068] [4. Timing of VC Issuance (1)] <4-1. Overview> In the presentation system 1, there are two patterns for the timing of issuing a VC, and the flow of information processing differs for each pattern. Therefore, below, an overview of each pattern and the flow of information processing for each pattern will be explained. Specifically, there are two patterns: a token issuance timing where a VC is issued in response to the issuance of a token, and a user request timing where a VC is issued in response to a user generation request.

[0069] An overview of information processing corresponding to the token issuance timing will be explained using Figure 3. Figure 3 shows a scene in which information processing is performed between a provider IS that provides a web3 type service SA31, a user U who is a customer receiving the service, and a provider VR that provides a web3 type service SA32 to a person who has information that satisfies predetermined conditions.

[0070] Furthermore, the provider IS corresponds to the issuer that issues the VC. The user U corresponds to the holder that owns the VC. The provider VR corresponds to the verifier that verifies whether the VC presented by the user U is trustworthy. Furthermore, in the example of Figure 3, from the perspective of the user U, the provider IS is the "provider" and the provider VR is the "counterparty."

[0071] First, when a provider IS receives a token issuance request from a user U, the provider IS issues a token to the user U in accordance with the contract (step S1). The issued token is stored in a token wallet owned by the user U.

[0072] In addition, the provider IS issues a VC to the user U in response to the issuance of the token (step S2). That is, the provider IS issues a VC at the same time as the token. The issued VC is stored in the VC wallet owned by the user U.

[0073] In this state, the user U presents the VC selected by the user from among the issued VCs to the provider VR at an arbitrary timing (for example, at a timing requested by the provider VR) (step S3).

[0074] The provider VR verifies whether the VC presented by the user U is trustworthy (step S4). If the provider VR obtains a verification result that the VC presented by the user U is trustworthy, the provider VR provides the service SV32 to the user U (step S5).

[0075] <4-2. Information processing procedures> Next, a procedure of information processing will be described when the outline explained in Fig. 3 is applied to the presentation system 1. Fig. 4 is a diagram showing a procedure (1) of information processing executed by the presentation system 1.

[0076] 4, the presentation system 1 is composed of a wallet 10 of a user U (which can also be said to be a terminal device 10 of the user U), a DID / VC platform 30, an issuer system 50 on the provider IS side, a verifier system 70 on the provider VR side, and a blockchain BC. These components included in the presentation system 1 will be described in more detail.

[0077] (Wallet 10) The wallet 10 is composed of applications such as a token wallet 11 that stores tokens and a VC wallet 12 that stores VC, and each wallet has a wallet address 13. The wallet 10 is also linked to a DID 14 of a user U. For example, the wallet 10 can request the DID / VC platform 30 to generate a DID in response to an operation by the user U, and holds the DID generated by the DID / VC platform 30 as the DID 14 of the user U.

[0078] (DID / VC base 30) The DID / VC infrastructure 30 is a device (platform) that controls DIDs and VCs. According to the example of Fig. 4, the DID / VC infrastructure 30 includes a VC issuing unit 31, a VC verifying unit 32, a key pair generating unit 33, a management unit 34, a TK verifying unit 35, and a signature unit 36. These processing units may be realized by a presentation program according to the embodiment.

[0079] The VC issuing unit 31 issues a VC. The VC verifying unit 32 verifies the validity of the VC. The key pair generating unit 33 generates a pair of a public key and a private key. For example, the key pair generating unit 33 generates a DID and also generates a pair of a public key and a private key corresponding to the generated DID.

[0080] The management unit 34 manages the DID by linking it with an account (e.g., an ID or wallet address). The TK verification unit 35 verifies the validity of the token. The signature unit 36 ​​generates a digital signature using the private key generated by the key pair generation unit 33.

[0081] (Issuer System 50) The issuer system 50 (providing device) includes a token issuing unit 51 and an API execution unit 52. These processing units may be realized by a presentation program according to the embodiment.

[0082] The token issuing unit 51 issues a token. The API executing unit 52 calls an external platform, that is, the DID / VC platform 30, by API, to realize the function of the VC issuing unit 31. In other words, the API executing unit 52 executes the VC issuing API.

[0083] Furthermore, the DID 53 of the provider IS is linked to the issuer system 50. For example, the issuer system 50 can request the DID / VC infrastructure 30 to generate a DID in response to an operation by the provider IS, and stores the DID generated by the DID / VC infrastructure 30 as the DID 53 of the provider IS.

[0084] (Verifier System 70) The verifier system 70 (requester device) includes an API execution unit 71 and a control unit 72. These processing units may be realized by a presentation program according to the embodiment.

[0085] The API execution unit 71 calls an external platform, i.e., the DID / VC platform 30, via API to realize the functions of the VC verification unit 32. In other words, the API execution unit 71 executes the VC verification API. When the conditions are met, the control unit 72 provides the utility expected by the user U and executes the contract on the blockchain.

[0086] Furthermore, the DID 73 of the provider VR is linked to the Verifier system 70. For example, the Verifier system 70 can request the DID / VC infrastructure 30 to generate a DID in response to an operation by the provider VR, and stores the DID generated by the DID / VC infrastructure 30 as the DID 73 of the provider VR.

[0087] The following describes the procedure of information processing executed by the presentation system 1. The procedure of information processing shown in Fig. 4 is the procedure when the retained information (token) is generated on the service SA31 side (provider IS side), that is, when the token is issued.

[0088] As shown in Fig. 4, it is assumed that the wallet 10 transmits a token issuance request to the Issuer system 50 in response to an operation by the user U (step S41). In this case, the token issuing unit 51 issues a token to the wallet 10 in accordance with the contract (step S42). For example, the token issuing unit 51 issues a token according to the contribution record of the user U in the service SV31. The issued token is stored in the token wallet 11.

[0089] In this way, at the same time that the token issuance unit 51 issues the token, the API execution unit 52 executes the VC issuance API (step S43). Specifically, the API execution unit 52 issues a VC to the wallet 10 by calling the VC issuance unit 31 through API cooperation with the DID / VC platform 30 (step S44).

[0090] For example, the called VC issuing unit 31 acquires information on the token issued by the token issuing unit 51 from the blockchain BC31. Specifically, the VC issuing unit 31 acquires token information of the user U corresponding to the service SV31 using the wallet address linked to the token wallet 11 as a key. Then, the VC issuing unit 31 issues personal information VC31 in which the token information (held information) has been converted into VC based on the DID14 of the user U, the DID53 of the provider IS, and the token information acquired from the blockchain BC31. For example, the VC issuing unit 31 issues personal information VC31 to which an electronic signature generated in response to the execution of the VC issuing API and generated by the signature unit 36 ​​using the private key of the provider IS has been added. The issued personal information VC31 is stored in the VC wallet 12.

[0091] For this reason, the information that has been converted into VC at the time of step S44 is DID 14 of user U, DID 53 of provider IS, token information, and an electronic signature generated using the private key of provider IS. The token information also includes a timestamp when the token was issued, the type of token, the contents of the token, the amount of tokens held by user U, etc.

[0092] In this state, it is assumed that the Verifier system 70 transmits a request to present VC (held information that is a token converted into VC) to the wallet 10 in response to an operation by the provider VR (step S51).

[0093] Having confirmed the presentation request, the user U selects from the personal information VC31 only the personal information VC31 that satisfies the conditions included in the presentation request. In this case, the wallet 10 accepts from the user a selection of token information that the user wishes to present to the provider VR from the information of tokens converted into VC included in the personal information VC31, and performs selective presentation by presenting only the information of the selected tokens to the provider VR (step S52). For example, the wallet 10 presents data (information of tokens converted into VC) to which an electronic signature generated in accordance with the selection by the user U and generated by the signature unit 36 ​​using the private key of the user U has been added.

[0094] For this reason, at the time of step S52, the information that has been converted into VC includes not only user U's DID14, provider IS's DID53, token information, and an electronic signature generated using provider IS's private key, but also an electronic signature generated using user U's private key.

[0095] When the API execution unit 71 receives the selective presentation, it executes the VC verification API (step S53). Specifically, the API execution unit 71 verifies whether the information of the VC-converted token is trustworthy by calling the VC verification unit 32 through API cooperation with the DID / VC platform 30. For example, the called VC verification unit 32 accesses the blockchain BC, acquires the public keys of the user U and the provider IS, and uses the public keys to verify the validity of the data issued (presented) by the wallet 10 (step S54). As a result, the control unit 72 acquires the verification result of the validity (step S55).

[0096] If the data issued (presented) by the wallet 10 is valid and reliable, the control unit 72 provides the user U with the service SA32.

[0097] 3 and 4, the token provider (provider IS) issues a set of VC when issuing a token, and the token provider certifies that it holds the VC at the time of issuing the token. This configuration has the advantage of high independence, since the token provider guarantees the legitimacy of the VC. On the other hand, there are also disadvantages, such as the fact that the owner of a token may change depending on the distribution (secondary distribution, tertiary distribution, etc.), making it unsuitable for situations requiring real-time performance, and the need to recover the token provider's system (issuer system 50) or introduce new functions.

[0098] The inventors of the present invention have also considered a configuration that can eliminate this disadvantage, in which a VC is issued in response to a user's generation request.

[0099] [5. Timing of VC Issuance (2)] <5-1. Overview> 3 and 4, the information processing corresponding to the token issuance timing, that is, issuing a VC in response to the issuance of a token, has been described. From here, the information processing corresponding to the user request timing, that is, issuing a VC in response to a user generation request, will be described.

[0100] Fig. 5 provides an overview of information processing corresponding to user request timing. Fig. 5 shows a scene in which information processing is performed between a user U, who is a customer receiving a service, and a provider VR that provides a web3 type service SA32 to those who possess information that satisfies predetermined conditions. In the example of Fig. 5, the provider IS is omitted, and the DID / VC infrastructure 30 shown in Fig. 4 is shown.

[0101] 5, the user U corresponds to a holder who owns the VC. The provider VR corresponds to a verifier who verifies whether the VC presented by the user U is trustworthy. The DID / VC infrastructure 30 plays the role of an issuer that issues the VC on behalf of the provider IS.

[0102] First, when the DID / VC infrastructure 30 receives a VC generation request from user U, it verifies the token issued to user U in accordance with the contract (step S1). The token issued to user U is a token stored in a token wallet owned by user U.

[0103] For example, if user U holds a token issued by provider IS in accordance with his or her contributions to service SA31, DID / VC infrastructure 30 verifies the legitimacy of the token being issued by provider IS.

[0104] If the token issued to user U is legitimate and reliable, the DID / VC infrastructure 30 issues a VC to user U (step S2). That is, the DID / VC infrastructure 30 issues a VC in response to a VC generation request from user U. The issued VC is stored in a VC wallet owned by user U. In this way, in a configuration in which a VC is issued in response to a user generation request, the system on the token provider side (for example, provider IS) can be omitted.

[0105] In this state, the user U presents the VC that he / she has selected from the issued VCs to the provider VR (step S3).

[0106] The provider VR verifies whether the VC presented by the user U is trustworthy (step S4). If the provider VR obtains a verification result that the VC presented by the user U is trustworthy, the provider VR provides the service SV32 to the user U (step S5).

[0107] <5-2. Information processing procedures> Next, an explanation will be given of the information processing procedure when the overview explained in Fig. 5 is applied to the presentation system 1. Fig. 6 is a diagram showing the information processing procedure (2) executed by the presentation system 1. Note that an overview explanation of the processing units assigned the same reference numerals as in the example of Fig. 4 will be omitted.

[0108] 6 shows the information processing procedure when user U transmits a VC generation request, that is, at the time of a user request. In this information processing, as explained in FIG. 5, the DID / VC infrastructure 30 plays the role of an issuer that issues a VC, so the token provider (provider IS) system (issuer system 50) can be omitted. On the other hand, the example of FIG. 6 is based on the premise that user U is issued a token by the provider IS according to his or her contribution performance in the service SA31, as in FIG. 4. In this example, external cooperation may be established between the issuer system 50 (provider device) and the DID / VC infrastructure 30 (platform).

[0109] As shown in Fig. 6, it is assumed that the wallet 10 transmits a token issuance request to the Issuer system 50 in response to an operation by the user U (step S61). In this case, the token issuing unit 51 issues a token to the wallet 10 in accordance with the contract (step S62). For example, the token issuing unit 51 issues a token according to the contribution record of the user U in the service SV31. The issued token is stored in the token wallet 11.

[0110] Next, the wallet 10 executes the VC issuing API (step S63). Specifically, the wallet 10 executes the process of issuing a VC by calling the VC issuing unit 31 etc. through API cooperation with the DID / VC platform 30.

[0111] In the process of issuing a VC, first, the TK verification unit 35 verifies the validity of the token issued by the token issuing unit 51 (step S64). For example, the TK verification unit 35 acquires information on the token held by the user U from the blockchain BC31. Specifically, the TK verification unit 35 acquires the token information held by the user U using the wallet address linked to the token wallet 11 as a key. Then, the TK verification unit 35 uses the public key to verify whether the token held by the user U is trustworthy. In the example of FIG. 6, the TK verification unit 35 uses the public key of the provider IS to verify whether the token held by the user U is a token provided by the provider IS.

[0112] The VC issuing unit 31 acquires the result of the verification of legitimacy, and if the token held by the user U is legitimate and reliable, issues a VC to the wallet 10 (step S65). For example, the VC issuing unit 31 issues personal information VC31 in which the token information (held information) has been converted into VC, based on the DID 14 of the user U, the DID 53 of the provider IS, and the information of the token that has been verified as legitimate. For example, the VC issuing unit 31 issues personal information VC31 to which an electronic signature generated in response to the execution of the VC issuing API and generated by the signature unit 36 ​​using the private key of the DID / VC platform 30 has been added. The issued personal information VC31 is stored in the VC wallet 12.

[0113] For this reason, the information that has been converted into VC at the time of step S65 is the DID 14 of the user U, the DID 53 of the provider IS, the token information, and the electronic signature generated using the private key of the DID / VC infrastructure 30. The token information also includes the timestamp when the token was issued, the type of token, the contents of the token, the amount of tokens held by the user U, etc.

[0114] In this state, it is assumed that the Verifier system 70 transmits a request to present VC (held information that is a token converted into VC) to the wallet 10 in response to an operation by the provider VR (step S71).

[0115] Having confirmed the presentation request, the user U selects from the personal information VC31 only the personal information VC31 that satisfies the conditions included in the presentation request. In this case, the wallet 10 accepts from the user a selection of token information that the user wishes to present to the provider VR from the VC-converted token information included in the personal information VC31, and performs selective presentation by presenting only the selected token information to the provider IS (step S72). For example, the wallet 10 presents data (VC-converted token information) to which an electronic signature, which is generated in accordance with the selection by the user U and is generated by the signature unit 36 ​​using the private key of the user U, has been added.

[0116] For this reason, at the time of step S72, the information that has been converted into VC includes not only user U's DID 14, provider IS's DID 53, token information, and an electronic signature generated using the private key of the DID / VC base 30, but also an electronic signature generated using user U's private key.

[0117] When the API execution unit 71 receives the selective presentation, it executes the VC verification API (step S73). Specifically, the API execution unit 71 verifies whether the information of the VC-converted token is trustworthy by calling the VC verification unit 32 through API cooperation with the DID / VC infrastructure 30. For example, the called VC verification unit 32 accesses the blockchain BC, acquires the public keys of the user U and the DID / VC infrastructure 30, and uses the public keys to verify the validity of the data issued (presented) by the wallet 10 (step S74). As a result, the control unit 72 acquires the verification result of the validity (step S75).

[0118] If the data issued (presented) by the wallet 10 is valid and reliable, the control unit 72 provides the user U with the service SA32.

[0119] 5 and 6 are configured to convert token information held by user U into VC at the time of requesting generation of VC, and the platform certifies the fact of possession at the time of the request. With this configuration, although the DID / VC infrastructure 30 has no choice but to trust the platform to guarantee the legitimacy of the VC, it has the advantage that it is possible to certify information about tokens that user U himself owns at the time of the request, and that an organization that acts as an issuer (e.g., provider IS) is not required because VC is automatically generated from on-chain information.

[0120] 6. Other Embodiments The technology proposed by the present invention can also be applied to community services as a web3 type service. Figure 7 shows an application example of the technology proposed by the present invention. The example in Figure 7 shows the content applied to a community service based on the example in Figure 1.

[0121] Figure 7 shows a scene in which a user U who participates in "Community-C1," "Project-C2," and "Community-C3" selectively discloses only any of the information he or she holds in each community to the community of his or her choice.

[0122] In the example of Figure 7, "Community-C1" and "Community-C3" are web3 communities. For example, "Community-C1" and "Community-C3" are communities where fans who support a specific object gather, and where tokens are issued and sold.

[0123] On the other hand, "Community-C2" is a web2 community. For example, "Community-C2" may be a social networking site or blog where fans who support a particular subject gather.

[0124] In the example of Figure 7, user U stores tokens issued by service SA31 in accordance with his or her contributions to "community-C1" (which corresponds to service SA31 in Figure 1) in wallet WL31, which is an application installed in his or her terminal device 10. Specifically, the tokens are linked to wallet address AD1 of wallet WL31. The tokens linked to wallet address AD1 are user U's possession information HL1.

[0125] Furthermore, user U has an account web2ID for accessing service SA2 so that he can check data indicating his contributions to "community-C2" (which corresponds to service SA2 in FIG. 1) from his own terminal device 10. For example, in the RDB on the service SA2 side, data indicating user U's contributions is managed in a state linked to account web2ID. The data linked to account web2ID is user U's owned information HL2.

[0126] Furthermore, user U stores tokens issued by service SA32 in accordance with his or her contributions to "community-C3" (which corresponds to service SA32 in FIG. 1) in wallet WL32, which is an application installed on his or her terminal device 10. Specifically, the tokens are linked to wallet address AD3 of wallet WL32. The tokens linked to wallet address AD3 are user U's possession information HL3.

[0127] In this state, for example, when the presentation system 1 receives access from the wallet VCWL, it converts the held information HL1 into VC. Specifically, the presentation system 1 generates verifiable personal information VC_HL1 that proves that the user U holds the held information HL1, and issues the generated personal information VC_HL1 to the wallet VCWL.

[0128] Furthermore, the presentation system 1 converts the held information HL2 into VC. Specifically, the presentation system 1 generates verifiable personal information VC_HL2 that serves as proof that the user U holds the held information HL2, and issues the generated personal information VC_HL2 to the wallet VCWL.

[0129] Furthermore, the presentation system 1 converts the held information HL3 into VC. Specifically, the presentation system 1 generates verifiable personal information VC_HL3 that serves as proof that the user U holds the held information HL3, and issues the generated personal information VC_HL3 to the wallet VCWL.

[0130] As shown in FIG. 7, the wallet VCWL associates personal information VC_HL1, personal information VC_HL2, and personal information VC_HL3 with the DID of the user U (the DID issued to the wallet VCWL).

[0131] As in the example of Figure 2, if personal information VCn is a single verifiable personal information that combines personal information VC_HL1, personal information VC_HL2, and personal information VC_HL3 using user U's DID as a key, personal information VCn also includes user U's DID, an electronic signature generated using user U's private key, the DID on the service SV31 side, an electronic signature generated using the private key on the service SV31 side, the DID on the service SV32 side, an electronic signature generated using the private key on the service SV32 side, the DID on the service SV2 side, and an electronic signature generated using the private key on the service SV2 side.

[0132] In this state, the wallet VCWL receives from the user U a selection of the information held that the user wishes to present, that is, which of the personal information VC_HL1, personal information VC_HL2, and personal information VC_HL3 the user wishes to present to which other community.

[0133] Figure 7 shows "Community-C4" and "Community-C5" as services that allow participation or provide benefits only to those who have information that meets certain conditions, and shows examples of requests from each of these communities to present information that they have.

[0134] 7 shows an example in which a user U selects personal information VC_HL1 and personal information VC_HL2 from personal information VCn. In this example, the wallet VCWL selectively presents the personal information VC_HL1 and personal information VC_HL2 to the community-C4, as shown in FIG.

[0135] On the other hand, Fig. 7 shows an example in which the user U selects personal information VC_HL3 from the personal information VCn. In this example, the wallet VCWL selectively presents only the personal information VC_HL3 to the community-C5, as shown in Fig. 7.

[0136] [7. Hardware Configuration] The computer included in the presentation system 1 may be realized by a configuration as shown in Fig. 8. Fig. 8 is a hardware configuration diagram showing an example of a computer according to an embodiment. The computer 1000 includes a CPU 1100, a RAM 1200, a ROM 1300, a HDD 1400, a communication interface (I / F) 1500, an input / output interface (I / F) 1600, and a media interface (I / F) 1700.

[0137] The CPU 1100 operates and controls each unit based on programs stored in the ROM 1300 or the HDD 1400. The ROM 1300 stores a boot program executed by the CPU 1100 when the computer 1000 starts up, programs that depend on the hardware of the computer 1000, and the like.

[0138] The HDD 1400 stores programs executed by the CPU 1100, data used by such programs, etc. The communication interface 1500 receives data from other devices via a predetermined communication network and sends it to the CPU 1100, and transmits data generated by the CPU 1100 to other devices via the predetermined communication network.

[0139] The CPU 1100 controls an output device such as a display and an input device such as a keyboard via the input / output interface 1600. The CPU 1100 acquires data from the input device via the input / output interface 1600. The CPU 1100 also outputs generated data to the output device via the input / output interface 1600.

[0140] Media interface 1700 reads a program or data stored in recording medium 1800 and provides it to CPU 1100 via RAM 1200. CPU 1100 loads the program or data from recording medium 1800 onto RAM 1200 via media interface 1700 and executes the loaded program. Recording medium 1800 is, for example, an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase Change Rewritable Disc), a magneto-optical recording medium such as an MO (Magneto-Optical disk), a tape medium, a magnetic recording medium, or a semiconductor memory.

[0141] For example, when the computer 1000 functions as a computer included in the presentation system 1, the CPU 1100 of the computer 1000 realizes the functions of each processing unit by executing a program (presentation program) loaded onto the RAM 1200. The CPU 1100 of the computer 1000 reads and executes these programs from the recording medium 1800, but as another example, the CPU 1100 may obtain these programs from another device via a predetermined communication network.

[0142] [8. Other] Furthermore, among the processes described in each of the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using known methods. In addition, the information including the processing procedures, specific names, various data, and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified. For example, the various information shown in each drawing is not limited to the information shown in the drawings.

[0143] Furthermore, the components of each device shown in the figure are conceptual functional components and do not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc.

[0144] Furthermore, the above-described embodiments can be combined as appropriate within the scope of not causing any contradiction in the processing content.

[0145] Although some of the embodiments of the present application have been described in detail above with reference to the drawings, these are merely examples, and the present invention can be implemented in other forms that include the aspects described in the "present invention" section and that have been modified and improved in various ways based on the knowledge of those skilled in the art. [Explanation of symbols]

[0146] 1 Presentation System 10 Terminal Equipment 30 DID / VC base 50 Issuer System 70 Verifier System

Claims

1. an acquisition means for acquiring information held by a user of the service in response to the use of the service; an issuing means for issuing verifiable personal information to the user, which serves as proof that the user holds the held information, based on a user ID, which is a distributed identifier linked to the user's wallet, a provider ID, which is a distributed identifier linked to a provider that provides the service, and the held information; a presentation means for receiving from the user a selection of the retained information included in the personal information that the user desires to present to a predetermined recipient, and presenting to the predetermined recipient only the retained information that the user desires to present; A presentation system comprising:

2. When the user selects the desired retained information, the presenting means presents the verifiable personal information, to which a digital signature generated using the user's private key has been attached, to the predetermined party. The presentation system of claim 1 .

3. When the user uses a plurality of different services, the acquisition means acquires the retained information for each of the plurality of different services retained by the user in accordance with the use of each of the plurality of different services; the presentation means accepts a selection of which of a plurality of different services the retained information corresponding to which service is to be presented as the retained information desired to be presented to the predetermined recipient, in a state in which each of the verifiable personal information individually issued for each of a plurality of different services is managed in association with a single user ID, according to the retained information for each of the plurality of different services; The presentation system of claim 1 .

4. When the user uses a plurality of different accounts for one service, the acquiring means acquires the information held by the user for each of the plurality of different accounts; the presentation means, in a state in which the verifiable personal information, which includes all of the retained information for each of the plurality of different accounts and is issued in accordance with one service, is managed in association with a single user ID, accepts a selection of which of the plurality of different accounts the retained information corresponding to which account is to be presented as the retained information desired to be presented to the predetermined recipient; The presentation system of claim 1 .

5. The presentation system comprises: as the issuing means, a first issuing means for issuing the verifiable personal information when the retained information is generated on the service side; or a second issuing means for issuing the verifiable personal information when an issuance request is received from the user; and a provider device that belongs to the provider and generates the held information includes the first issuing means; a predetermined platform that is externally linked with the providing device and that accepts the issuance request includes the second issuing means; The presentation system of claim 1 .

6. the first issuing means issues the verifiable personal information to the user, to which a digital signature generated using the private key of the provider has been attached; the second issuing means issues to the user the verifiable personal information to which a digital signature generated using a private key of the predetermined platform has been attached; The presentation system of claim 5 .

7. the second issuing means verifies the validity of the retained information generated by the providing device, and when a verification result indicating validity is obtained, issues the verifiable personal information including the retained information generated by the providing device to the user. The presentation system of claim 5 .

8. The service provider is an operator of a community service, The acquisition means If the service used by the user is a WEB2 type community, the user's performance information in the WEB2 type community is acquired from a database as the retained information; If the service used by the user is a WEB3 type community, a token issued according to the user's performance in the WEB3 type community is obtained from the blockchain as the holding information; when the presentation means receives a presentation request from a community other than the community used by the user, the presentation means receives from the user a selection of the held information included in the personal information that the user desires to present to the other community; The presentation system of claim 1 .

9. The presentation system includes a computer, an acquisition means for acquiring information held by a user of the service in response to the use of the service; an issuing means for issuing verifiable personal information to the user, which serves as proof that the user holds the held information, based on a user ID, which is a distributed identifier linked to the user's wallet, a provider ID, which is a distributed identifier linked to a provider that provides the service, and the held information; a presentation means for receiving from the user a selection of the retained information included in the personal information that the user desires to present to a predetermined recipient, and presenting to the predetermined recipient only the retained information that the user desires to present; A presentation program to function as a

10. 1. A presentation method executed in a presentation system, comprising: an acquisition step of acquiring information held by a user of the service in response to the use of the service; an issuing step of issuing verifiable personal information to the user, which serves as proof that the user holds the held information, based on a user ID, which is a decentralized identifier linked to the user's wallet, a provider ID, which is a decentralized identifier linked to a provider that provides the service, and the held information; a presentation step of accepting from the user a selection of retained information that the user desires to present to a predetermined recipient from among the retained information included in the personal information, and presenting only the selected retained information to the predetermined recipient; Presentation methods including.

Images