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 Art

[0002] A method of mutual authentication using a user-side DID (Decentralized Identity), which is an application program installed on a user's mobile terminal, has been proposed.

Prior Art Documents

Patent Documents

[0003] [[ID=二十一]] [[ID=二十二]]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, the above prior art provides an online mutual authentication technology based on DID, which first confirms 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 prior art aims to verify the authenticity of a service provider providing a specific service, and does not disclose a method for solving problems related to identity management for each service. Therefore, the above prior art may not be able to provide a model for optimizing 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 for optimizing identity management for each service.

Means for Solving the Problems

[0007] The presentation system according to the present invention comprises: acquisition means for acquiring information held by a user of a service in accordance with the use of the service; issuing means for issuing verifiable personal information to the user that serves as proof that the user possesses the 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 information held; and presentation means for receiving from the user a selection of the information held that the user wishes to present to a predetermined recipient from among the information held that is included in the personal information, and presenting only the selected information to be presented to the predetermined recipient.

[0008] The presentation program according to the present invention causes the computer of the presentation system to function as an acquisition means for acquiring information held by a user of the service in accordance with the use of the service; an issuing means for issuing verifiable personal information to the user that serves as proof that the user possesses the 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 information held; and a presentation means for receiving from the user a selection of the information held that the user wishes to present to a predetermined recipient from among the information held that is included in the personal information, and presenting only the selected information to be presented to the predetermined recipient.

[0009] The presentation method according to the present invention is a presentation method executed by a presentation system, and includes: an acquisition step of acquiring information held by a user of a service in accordance with the use of the service; an issuance step of issuing verifiable personal information to the user that serves as proof that the user holds the 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 information held; and a presentation step of receiving from the user a selection of the information held that the user wishes to present to a predetermined recipient from among the information held that is included in the personal information, and presenting only the selected information to be presented to the predetermined recipient. [Effects of the Invention]

[0010] According to the present invention, it is possible to provide a model that optimizes identity management for each service. [Brief explanation of the drawing]

[0011] [Figure 1] Figure 1 is a diagram illustrating the outline of the proposed technology of the present invention. [Figure 2] Figure 2 shows a specific example of information processing implemented in the presentation system according to the embodiment. [Figure 3] Figure 3 is a diagram illustrating the overview of information processing corresponding to the timing of token issuance. [Figure 4] Figure 4 shows the information processing procedure (1) performed by the presentation system. [Figure 5] Figure 5 illustrates the overview of information processing in response to user requests. [Figure 6] Figure 6 shows the information processing procedure (2) performed by the presentation system. [Figure 7] Figure 7 shows an example of an application of the proposed technology of the present invention. [Figure 8] Figure 8 is a hardware configuration diagram showing an example of a computer according to this embodiment. [Modes for carrying out the invention]

[0012] Embodiments of this disclosure will be described in detail below with reference to the attached drawings. In this specification and the drawings, components having substantially the same functional configuration are denoted by the same reference numerals, and redundant descriptions will be omitted.

[0013] One or more embodiments (including examples, variations, and application examples) described below can each be implemented independently. On the other hand, at least some of the multiple embodiments described below may be implemented in appropriate combination with at least some of other embodiments. These multiple embodiments may include different novel features. Therefore, these multiple embodiments can contribute to solving different objectives or problems and can exhibit different effects.

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

[0015] Identities are used in various forms on the Internet. For example, in the use and transactions of online services, the importance of identities has increased to confirm that customers are "themselves" and to provide what customers need, and various approaches have been taken.

[0016] For example, due to the development of blockchain technology and the penetration of web3-type services, tokens are not only used as a common means of value exchange as cryptographic assets but also increasingly used in the context of forming and sharing identities. On the other hand, there are various issues in the use of tokens as identities. Below, the issues related to identity management from the perspective of web3-type services will be explained.

[0017] Issues related to identity management include "data siloing", "complexification of asset management by wallets", and "privacy risks".

[0018] "Data siloing" refers to a situation where personal data and tokens are separately managed and siloed between different blockchains, and the scope of token utilization and data circulation are restricted. Under such restrictions, it becomes difficult to provide cross-cutting services and the like that are generated by aggregating an individual's reputation, activity history, hobby orientation, etc. Also, when the network stops, the recorded tokens are lost, and there is a possibility that the convenience and security for users may be impaired.

[0019] "Complication of asset management by wallets" refers to a situation where the management of assets such as tokens becomes complicated due to the use of multiple wallets, and the UX at the time of service use deteriorates. To give a specific example, due to concerns about privacy and countermeasures against risks such as hacking, there is a tendency for one user to use multiple wallets and wallet addresses separately. Also, the fact that the wallets provided by various businesses tend to be in disarray and the options for wallets are limited depending on the services used and the user environment is one of the reasons for the increase in the number of wallets owned by users. Thus, when the number of wallets owned increases, it becomes difficult for users to manage them uniformly, such as which tokens are stored in which wallet in addition to managing the wallets themselves, and there is a problem that, for example, complicated procedures occur when using token gate type services.

[0020] "Privacy risk" refers to the risk that an individual's privacy may be unintentionally compromised when their wallet address is revealed to others while 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 increasingly diverse in their uses, they are becoming information that forms an identity, and if a certain amount is collected, it becomes possible to understand an individual's characteristics from that collection. For example, if a collection of tokens is linked to social media or Web2 services, there is a risk that the individual could be identified. In addition, users may separate their wallets into public and private wallets, but if tokens are moved between these wallets, it becomes possible to track transaction history based on the public wallet address and access not only the private wallet address but also the contents of the private wallet.

[0021] From the above, while the use of data based on anonymity and public information is an advantage of Web3 services, there is a need to protect a certain level of privacy as tokens themselves tend to become part of one's identity. For example, there is a need to maintain a persona within a community (to share only the aspects one wants to show), and a need to prevent the service provider from knowing about the token ownership status more than necessary.

[0022] Therefore, in view of the above-mentioned problems and needs, the inventors of the present invention focused on the fact that, without changing the structure of existing tokens or blockchain infrastructure itself, adding an identity layer that allows users to sovereignly and centrally manage the scope of sharing of token ownership information would enable more secure and convenient service use, leading to the present invention. According to the proposed technology of the present invention, it becomes possible to provide a model that optimizes identity management for each service.

[0023] The proposed technology of the present invention will be described in detail below with reference to the drawings, but the proposed technology of the present invention is applicable not only to Web3 type services but also to Web2 type services. In other words, the proposed technology of the present invention is not a limited technology specific to Web3 type services, but is applicable to various forms of services.

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

[0025] [2. Outline of the present invention] Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) 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, as well as the user's application (wallet), has a DID, and users can store data (VCs) in their wallets that have the digital signature of the information issuer attached to their identity information. Furthermore, when a user shares data (VCs) with a business, the business can verify the signature attached to the VC to determine that the data was issued by a legitimate issuer. Decentralized databases (blockchains) are utilized to realize such a mechanism.

[0026] The proposed technology of the present invention uses DID / VC as its core technology. Specifically, as shown in Figure 1, the proposed technology of the present invention establishes an identity management layer in a web2 or web3 service. Figure 1 is a diagram illustrating the overview of the proposed technology of the present invention. Figure 1 shows the layer structure related to the proposed technology of the present invention.

[0027] As shown in the example in Figure 1, the layer structure of the proposed technology of the present invention includes a layer L1 corresponding to the infrastructure base, a layer L2 that stores data accumulated by using an application (service), a layer L3 corresponding to the application (service), a layer L4 corresponding to the access rights for a user to retrieve all data associated with their own ID, and further includes a layer L5 that centrally manages the identity formed by these layers.

[0028] With the establishment of Layer L5, as shown in Figure 1, it becomes possible to achieve unified identity linkage that is independent of platform technology, including not only Web3 services but also Web2 services. As a result, multiple wallet addresses and accounts can be consolidated into a DID belonging to the individual user. In addition, the user's possession information can be virtualized and proven to others off-chain while maintaining privacy.

[0029] Here, Figure 1 shows an example where a single user U is using Service SV2 (the application that provides Service SV2) as a web2 type service, and is performing various activities and acquiring qualifications within Service SV2. Activity record information and qualification information correspond to the information held by user U in accordance with their use of Service SV2. As shown in Figure 1, activity record information and qualification information are managed in the Service SV2 database DB, linked to user U's web2 account (ID), which is account web2ID.

[0030] Furthermore, Figure 1 shows an example where user U uses two types of web3 services and manages multiple wallet addresses within the same service. Specifically, user U uses service SV31 (the application that provides service SV31) and service SV32 (the application that provides service SV32). In addition, user U has, for example, a public wallet address and a private wallet address within a single service SV31.

[0031] More specifically, the example shows that user U stores some tokens linked to wallet address AD1, corresponding to their activities and contributions within service SV31, while other tokens are linked to a different wallet address AD2 and stored in wallet WL31. The tokens stored in wallet WL31 correspond to the holdings information that user U possesses based on their use of service SA31. The token information stored in wallet WL31 is managed on the corresponding blockchain BC31, as shown in Figure 1.

[0032] Furthermore, the example shows that user U also uses another service, SV32, which is different from service SV31, and stores tokens corresponding to activities and contributions within service SV32 in wallet WL32, which corresponds to service SV32 and is identified by wallet address AD3. The tokens stored in wallet WL32 correspond to the holdings information that user U possesses in accordance with the use of service SA32. The information of the tokens stored in wallet WL32 is managed on the corresponding blockchain BC32.

[0033] Thus, user U may use multiple different services or manage multiple different accounts within the same service. As the number of services and accounts used increases, the aforementioned problems of "data silos," "complexity of asset management through wallets," and "privacy risks" 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 their data, tokens, and other holdings, which are virtualized holdings, to decentralized applications and other services, as shown in Figure 1. Specifically, user U can selectively present only the necessary data and tokens to the desired recipient without disclosing their account web2ID, wallet address AD1, wallet address AD2, and wallet address AD3, while keeping other data and tokens confidential.

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

[0036] Here, the issuance of a VC based on the information held can be rephrased as the conversion of the information held into a VC. Furthermore, the VC referred to here is verifiable personal information (attribute information) that proves that user U actually holds the information. Figure 1 shows a list of the information held that will be converted into a VC. According to the example in Figure 1, in the case of web3, the VC includes information about the token associated with the wallet address, such as information about the issuer that issued the token, the timestamp when the token was issued, the type of token, the content of the token, and the amount of token held by user U. Also, according to the example in Figure 1, the VC also includes user U's DID, the digital signature generated using user U's private key, the service provider's DID, and the 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 information about tokens linked to the wallet address.

[0038] Here, as an example of a user U using multiple different services, we will explain a specific example of a scenario in which only the desired information from the VC-enabled information held is presented to a designated party (let's call it Service SAx), using the case where user U is using services SV31 and SV32.

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

[0040] Furthermore, presentation system 1 retrieves information about tokens issued in accordance with user U's activities and contributions within service SV32 from blockchain BC32. Specifically, presentation system 1 retrieves token information for user U corresponding to service SV32 using wallet address AD3 as the key.

[0041] In this state, the presentation system 1 issues personal information VC31, in which token information (ownership information) is virtualized, based on user U's DID, service SV31's DID, and token information obtained from blockchain BC31. Personal information VC31 includes user U's DID, a digital signature generated using user U's private key, service SV31's DID, a digital signature generated using service SV31's private key, and token information obtained from blockchain BC31.

[0042] Furthermore, the presentation system 1 issues personal information VC32, which is VC-encoded token information (ownership information), based on user U's DID, service SV32's DID, and token information obtained from blockchain BC32. Personal information VC32 includes user U's DID, an electronic signature generated using user U's private key, service SV32's DID, an electronic signature generated using service SV32's private key, and token information obtained from blockchain BC32.

[0043] Personal information VC31 and personal information VC32 are linked to user U's DID. In other words, presentation system 1 manages personal information VC31 and personal information VC32 by linking them to a single DID held by user U. Here, presentation system 1 accepts selections regarding which services and to what extent the retained information (token information) contained in personal information VC31 and personal information VC32 (token information) should be presented to service SAx.

[0044] For example, presentation system 1 can receive a selection from user U, such as wanting to present only the token information for the most recent month from the tokens issued using service SA31 to service SAx. If such a selection is received, presentation system 1 will present only the token information within the range selected by user U to service SAx. On the service SAx side, the legitimacy 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 explain a specific example of a scenario in which only the desired holdings information from the VC-enabled holdings is presented to a designated counterparty (let's call it service SAx), using the example of using wallet addresses AD1 and AD2.

[0046] Presentation System 1 retrieves information on tokens associated with wallet address AD1 from blockchain BC31, among the information on tokens issued in accordance with user U's activities and contributions within service SV31. Presentation System 1 also retrieves information on tokens associated with wallet address AD2 from blockchain BC31, among the information on tokens issued in accordance with user U's activities and contributions within service SV31.

[0047] In this state, the presentation system 1 issues personal information VC31, in which token information (holding information) is virtualized, based on user U's DID, service SV31's DID, and token information obtained from blockchain BC31. Personal information VC31 includes user U's DID, a digital signature generated using user U's private key, service SV31's DID, a digital signature generated using service SV31's private key, and token information obtained from blockchain BC31. In other words, personal information VC31 includes both token information associated with wallet address AD1 and token information associated with wallet address AD2.

[0048] Personal information VC31 is linked to user U's DID. In other words, presentation system 1 manages personal information VC31 by linking it to a single DID held by user U. Here, presentation system 1 accepts selections regarding which services and what scope of retained information (token information) contained in personal information VC31 should be presented to service SAx.

[0049] For example, presentation system 1 can receive a selection from user U, such as wanting to present only the token information for January to March 2024 from the tokens issued using service SA31 to service SAx. If such a selection is received, presentation system 1 will present only the tokens within the range selected by user U to service SAx. On the service SAx side, the legitimacy of the presented token information is verified using the corresponding public key.

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

[0051] [3. Information processing according to the present invention] A more detailed example of the information processing (information processing according to the present invention) implemented by the presentation system 1 is explained in Figure 2. Figure 2 is a diagram showing a specific example of the information processing implemented by the presentation system 1 according to the embodiment. Figure 2 shows a scenario in which user U, who participates in "Project-A," "Project-B," and "Project-C," selectively discloses only the information he or she possesses from his or her own information in each project to the desired target community.

[0052] According to the example in Figure 2, "Project-A" and "Project-C" are web3 projects. For example, "Project-A" and "Project-C" are services that provide token issuance, token sales, and 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 specific object gather), or services that provide experiences using tokens (for example, a music experience).

[0053] On the other hand, "Project-B" is a Web2 project. Examples of "Project-B" include community services (e.g., Social Networking Services: SNS), blogs, and search services.

[0054] In the example shown in Figure 2, user U stores tokens issued by service SA31 (corresponding to service SA31 in Figure 1) based on their contributions to "Project-A" in wallet WL31, an application installed on their 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 holding information HL1.

[0055] Furthermore, user U has a web2ID account to access service SA2 so that they can check data showing their contributions to "Project-B" (which corresponds to service SA2 in Figure 1) from their terminal device 10. For example, in the RDB on the service SA2 side, data showing user U's contributions is managed linked to the web2ID account. The data linked to the web2ID account is user U's personal information HL2.

[0056] Furthermore, user U stores tokens issued from service SA32 (corresponding to service SA32 in Figure 1) based on their contributions to "Project-C" in wallet WL32, an application installed on their 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 holding information HL3.

[0057] Here, the user's terminal device 10 has the wallet VCWL installed as a VC wallet application related to the issuance of DIDs and the conversion of owned information into VCs.

[0058] In this situation, for example, if presentation system 1 receives access from wallet VCWL, it converts the held information HL1 into VC. Specifically, presentation system 1 generates verifiable personal information VC_HL1, which serves as proof that user U possesses the held information HL1, and issues the generated personal information VC_HL1 to wallet VCWL.

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

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

[0061] As shown in Figure 2, the wallet VCWL, which is one of the functions included in the presentation system 1, associates personal information VC_HL1, personal information VC_HL2, and personal information VC_HL3 with user U's DID (the DID issued to wallet VCWL).

[0062] Here, if we define personal information VCn as a single verifiable piece of personal information that combines personal information VC_HL1, personal information VC_HL2, and personal information VC_HL3, using user U's DID as the key, then personal information VCn also includes user U's DID, the digital signature generated using user U's private key, the DID of service SV31, the digital signature generated using service SV31's private key, and the DID of service SV32, the digital signature generated using service SV32's private key.

[0063] In this situation, the wallet VCWL accepts a selection from user U regarding which of the personal information VC_HL1, personal information VC_HL2, and personal information VC_HL3 to disclose to which other services, and which other information the user wishes to disclose.

[0064] Figure 2 shows three communities, C1, C2, and C3, which are services that allow participation or grant benefits only to those who possess information that meets certain conditions, and illustrates examples of requests for the presentation of possessed information from each of these communities.

[0065] For example, suppose community C1 has a condition CD1 that states, "Participation is permitted to those who hold N1 or more tokens issued during period P1." In this case, user U, who wishes to join community C1, selects only the personal information contained in personal information VCn that satisfies condition CD1 and enters it into wallet VCWL. Figure 2 shows an example where user U selects personal information VC_HL1 from personal information VCn. In this example, as shown in Figure 2, wallet VCWL performs selective presentation, presenting only personal information VC_HL1 to community C1. Community C1 then verifies whether personal information VC_HL1 satisfies condition CD1, and if it does, permits user U to participate.

[0066] Let's assume that Community C2 has set a condition CD2 that "participation is permitted only to those whose contribution during the P2 period is equal to or greater than N2." In this case, user U, who wishes to participate in Community C2, selects only the personal information contained in personal information VCn that satisfies condition CD2 and enters it into wallet VCWL. Figure 2 shows an example where user U selects personal information VC_HL2 from personal information VCn. In this example, wallet VCWL performs selective presentation, as shown in Figure 2, by presenting only personal information VC_HL2 to community C2. Community C2 also verifies whether personal information VC_HL2 satisfies condition CD2, and if it does, permits user U to participate.

[0067] Community C3 has established condition CD3, which states that "certain benefits will be given to those who hold N3 types of tokens issued during the P3 period." In this case, user U, who wishes to earn points, selects only the personal information contained in personal information VCn that satisfies condition CD3 and enters it into wallet VCWL. Figure 2 shows an example where user U selects personal information VC_HL3 from personal information VCn. In this example, wallet VCWL makes a selective presentation, as shown in Figure 2, by presenting only personal information VC_HL3 to community C3. Community C3 also verifies whether personal information VC_HL1 satisfies condition CD3, and if it does, grants the benefit to user U.

[0068] [4. Timing of VC issuance (1)] <4-1. Overview> In Presentation System 1, there are two patterns for the timing of VC issuance, and the information processing flow differs for each pattern. Therefore, the following will explain the overview of each pattern and the information processing flow in each pattern. Specifically, there are two patterns: token issuance timing, in which VC is issued in response to token issuance, and user request timing, in which VC is issued in response to a user's generation request.

[0069] Figure 3 illustrates the overview of information processing corresponding to the timing of token issuance. Figure 3 shows a scenario in which information processing takes place between provider IS, which provides the web3 type service SA31, user U, which is the customer receiving the service, and provider VR, which provides the web3 type service SA32 to a person who possesses information that meets predetermined conditions.

[0070] Furthermore, Provider IS corresponds to the Issuer who issues the VC. User U corresponds to the Holder who owns the VC. Provider VR corresponds to the Verifier who verifies whether the VC presented by User U is trustworthy. In addition, in the example in Figure 3, from User U's perspective, Provider IS is the "provider" and Provider VR is the "recipient".

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

[0072] Furthermore, provider IS issues VC to user U in response to the issuance of tokens (step S2). In other words, provider IS issues VC at the same time as the tokens. The issued VC is stored in user U's VC wallet.

[0073] In this state, User U presents the VC of their choice from the issued VCs to the Provider VR at any time (for example, at the time requested by the Provider VR) (Step S3).

[0074] Provider VR verifies whether the VC presented by user U is trustworthy (step S4). If Provider VR verifies that the VC presented by user U is trustworthy, it provides service SV32 to user U (step S5).

[0075] <4-2. Information Processing Procedures> Next, we will explain the information processing procedure when the overview described in Figure 3 is implemented in presentation system 1. Figure 4 shows the information processing procedure (1) performed by presentation system 1.

[0076] According to the example in Figure 4, the presentation system 1 consists of user U's wallet 10 (which can also be called user U's terminal device 10), the DID / VC infrastructure 30, the provider IS's Issuer system 50, the provider VR's Verifier system 70, and the blockchain BC. These components included in the presentation system 1 will be explained in more detail below.

[0077] (Wallet 10) Wallet 10 consists of applications such as a token wallet 11 for storing tokens and a VC wallet 12 for storing VC, and each wallet has a wallet address 13. In addition, user U's DID 14 is associated with wallet 10. For example, wallet 10 can request the DID / VC infrastructure 30 to generate a DID in response to user U's actions, and the DID generated by the DID / VC infrastructure 30 is held as user U's DID 14.

[0078] (DID / VC base 30) The DID / VC platform 30 is a device (platform) that controls DID and VC. In the example shown in Figure 4, the DID / VC platform 30 includes a VC issuance unit 31, a VC verification unit 32, a key pair generation unit 33, a management unit 34, a TK verification unit 35, and a signature unit 36. These processing units may be implemented by the program presented in the embodiment.

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

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

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

[0082] The token issuing unit 51 issues tokens. The API execution unit 52 calls an external platform, namely the DID / VC infrastructure 30, via an API to implement the functions of the VC issuing unit 31. In other words, the API execution unit 52 executes the VC issuance API.

[0083] Furthermore, the Issuer system 50 is associated with the provider IS's DID 53. 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 the DID generated by the DID / VC infrastructure 30 is stored as the provider IS's DID 53.

[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 implemented by the presented program according to the embodiment.

[0085] The API execution unit 71 calls an external platform, namely the DID / VC infrastructure 30, via an API to implement the functions of the VC verification unit 32. In other words, the API execution unit 71 executes the VC verification API. The control unit 72, if the conditions are met, provides the utilities expected by user U or executes contracts on the blockchain.

[0086] Furthermore, the Verifier system 70 is associated with the provider VR's DID 73. For example, the Verifier system 70 can request the DID / VC infrastructure 30 to generate a DID in response to the provider VR's operation, and the DID generated by the DID / VC infrastructure 30 is stored as the provider VR's DID 73.

[0087] From here, we will explain the information processing procedure performed by the presentation system 1. The information processing procedure shown in Figure 4 represents the information processing procedure when the possessed information (token) is generated on the service SA31 side (provider IS side), that is, at the time of token issuance.

[0088] As shown in Figure 4, suppose that the wallet 10 sends a token issuance request to the Issuer system 50 in response to an operation by user U (step S41). In this case, the token issuance unit 51 issues tokens to the wallet 10 in accordance with the contract (step S42). For example, the token issuance unit 51 issues tokens corresponding to user U's contribution performance within service SV31. The issued tokens are stored in the token wallet 11.

[0089] Thus, as soon as the token is issued by the token issuance unit 51, the API execution unit 52 executes the VC issuance API (step S43). Specifically, the API execution unit 52 issues VC to the wallet 10 by calling the VC issuance unit 31 through API communication with the DID / VC infrastructure 30 (step S44).

[0090] For example, the called VC issuing unit 31 obtains information about the tokens issued by the token issuing unit 51 from the blockchain BC31. Specifically, the VC issuing unit 31 obtains the token information of user U corresponding to service SV31, using the wallet address associated with the token wallet 11 as the key. Then, based on user U's DID 14, provider IS's DID 53, and the token information obtained from blockchain BC31, the VC issuing unit 31 issues personal information VC31 in which the token information (holding information) has been virtualized. For example, the VC issuing unit 31 issues personal information VC31 with an electronic signature generated in response to the execution of the VC issuance API, which is an electronic signature generated by the signing unit 36 ​​using the provider IS's private key. The issued personal information VC31 is stored in the VC wallet 12.

[0091] Therefore, at step S44, the information that has been converted into a virtual key (VC) is User U's DID14, Provider IS's DID53, the token information, and the digital signature generated using Provider IS's private key. The token information also includes the timestamp when the token was issued, the type of token, the contents of the token, and the amount of tokens held by User U.

[0092] In this state, suppose that the Verifier system 70 sends a request to the wallet 10 to present VC (holding information which is VC-converted tokens) in response to an operation by the provider VR (step S51).

[0093] User U, having confirmed the disclosure request, selects from the personal information VC31 only those personal information VC31 that meet the conditions included in the disclosure request. In this case, wallet 10 accepts from the user the selection of information on the VC-enabled tokens included in the personal information VC31 that the user wishes to present to provider VR, and performs selective disclosure by presenting only the information on the selected tokens to provider VR (step S52). For example, wallet 10 presents data (information on the VC-enabled tokens) that has been digitally signed in response to the selection by user U, and which has been digitally signed by the signing unit 36 ​​using user U's private key.

[0094] Therefore, at step S52, the information that has been converted into a virtual key (VC) includes, in addition to the DID14 of user U, the DID53 of provider IS, the token information, and the digital signature generated using the private key of provider IS, the digital signature generated using the private key of user U.

[0095] If the API execution unit 71 receives a selective offer, it executes the VC verification API (step S53). Specifically, the API execution unit 71, through API communication with the DID / VC infrastructure 30, calls the VC verification unit 32 to verify whether the information of the VC-converted token is trustworthy. For example, the called VC verification unit 32 accesses the blockchain BC, obtains the public keys of user U and provider IS, and uses those public keys to verify the legitimacy of the data issued (offered) by wallet 10 (step S54). As a result, the control unit 72 obtains the legitimacy verification result (step S55).

[0096] Then, the control unit 72 provides service SA32 to user U if the data issued (presented) by wallet 10 is legitimate and trustworthy.

[0097] As described above, the configurations in Figures 3 and 4 involve the token provider (Provider IS) issuing VCs (Virtual Capital) along with the tokens at the time of issuance, with the token provider certifying the fact of ownership at the time of token issuance. This configuration has the advantage of high independence because the token provider guarantees the legitimacy of the VCs. On the other hand, there are also disadvantages, such as the possibility that the ownership of the tokens may change depending on circulation (secondary market, tertiary market, etc.), making it unsuitable for situations requiring real-time information, and the need to recall or implement new functions for the token provider's system (Issuer system 50).

[0098] The inventors of this invention also considered a configuration in which a VC is issued in response to a user's generation request, as a way to overcome this disadvantage.

[0099] [5. Timing of VC issuance (2)] <5-1. Overview> Figures 3 and 4 were used to explain the information processing corresponding to the token issuance timing, where VCs are issued in response to token issuance. From here, we will explain the information processing corresponding to the user request timing, where VCs are issued in response to a user's generation request.

[0100] Figure 5 illustrates the overview of information processing in response to user request timing. Figure 5 shows a scenario in which information processing takes place between User U, the customer receiving the service, and Provider VR, which provides the web3 type service SA32 to a person who possesses information that meets predetermined conditions. In the example in Figure 5, Provider IS is omitted, and the DID / VC infrastructure 30 shown in Figure 4 is shown.

[0101] In the example in Figure 5, User U corresponds to the Holder who owns the VC. Provider VR corresponds to the Verifier who verifies whether the VC presented by User U is trustworthy. The DID / VC infrastructure 30 plays the role of Issuer, issuing the VC on behalf of Provider IS.

[0102] First, when the DID / VC infrastructure 30 receives a request to generate a VC from user U, it verifies the tokens issued to user U according to the contract (step S1). The tokens issued to user U are the tokens stored in user U's token wallet.

[0103] For example, if user U holds a token issued by provider IS based on their contributions to service SA31, the DID / VC infrastructure 30 verifies the legitimacy of the token's issuance by provider IS.

[0104] The DID / VC infrastructure 30 issues VC to user U if the token issued to user U is legitimate and trustworthy (step S2). In other words, the DID / VC infrastructure 30 issues VC in response to user U's request for VC generation. The issued VC is stored in user U's VC wallet. In this configuration, where VC is issued in response to a user's generation request, the system on the token provider's side (e.g., provider IS) can be omitted.

[0105] In this situation, user U presents the provider VR with the VC that they have selected from the issued VCs (step S3).

[0106] Provider VR verifies whether the VC presented by user U is trustworthy (step S4). If Provider VR verifies that the VC presented by user U is trustworthy, it provides service SV32 to user U (step S5).

[0107] <5-2. Information Processing Procedures> Next, we will explain the information processing procedure when the overview described in Figure 5 is implemented in the presentation system 1. Figure 6 shows the information processing procedure (2) executed by the presentation system 1. Note that the overview of the processing unit which has the same reference numerals as in the example in Figure 4 will be omitted.

[0108] Furthermore, the information processing procedure shown in Figure 6 represents the information processing procedure at the user request timing, i.e., when user U sends a request to generate a VC. In this information processing, as explained in Figure 5, the DID / VC infrastructure 30 plays the role of issuer, so the token provider's (provider IS) system (Issuer system 50) can be omitted. On the other hand, in the example in Figure 6, similar to Figure 4, it is assumed that user U is issued a token by provider IS according to their contribution performance in service SA31. Also, 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 Figure 6, suppose that the wallet 10 sends a token issuance request to the Issuer system 50 in response to an operation by user U (step S61). In this case, the token issuance unit 51 issues tokens to the wallet 10 in accordance with the contract (step S62). For example, the token issuance unit 51 issues tokens corresponding to user U's contribution performance within service SV31. The issued tokens are stored in the token wallet 11.

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

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

[0112] The VC issuing unit 31 obtains the results of the legitimacy verification, and if the token held by user U is legitimate and trustworthy, it 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 (holding information) has been VCized, based on user U's DID 14, provider IS's DID 53, and the information of the token for which the verification result of legitimacy has been obtained. 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 issuance API is attached, which is an electronic signature generated by the signing unit 36 ​​using the private key of the DID / VC base 30. The issued personal information VC31 is stored in the VC wallet 12.

[0113] Therefore, at step S65, the information that has been converted into a virtual token (VC) is the DID 14 of user U, the DID 53 of provider IS, the token information, and the digital 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 content of the token, and the amount of tokens held by user U.

[0114] In this state, suppose that the Verifier system 70 sends a request to the wallet 10 to present VC (holding information which is VC-converted tokens) in response to an operation by the provider VR (step S71).

[0115] User U, having confirmed the disclosure request, selects from the personal information VC31 only those personal information VC31 that meet the conditions included in the disclosure request. In this case, wallet 10 accepts from the user the selection of information on the VC-enabled tokens included in the personal information VC31 that the user wishes to present to provider VR, and performs selective disclosure by presenting only the information on the selected tokens to provider IS (step S72). For example, wallet 10 presents data (information on the VC-enabled tokens) that has been digitally signed in response to the selection by user U, and to which the digital signature generated by the signing unit 36 ​​using user U's private key has been attached.

[0116] Therefore, at step S72, the information that has been converted into a virtual signature includes, in addition to the user U's DID14, the provider IS's DID53, the token information, and the digital signature generated using the private key of the DID / VC infrastructure 30, the digital signature generated using the private key of user U.

[0117] If the API execution unit 71 receives a selective offer, it executes the VC verification API (step S73). Specifically, the API execution unit 71, through API communication with the DID / VC infrastructure 30, calls the VC verification unit 32 to verify whether the information of the VC-decrypted token is trustworthy. For example, the called VC verification unit 32 accesses the blockchain BC, obtains the public keys of user U and the DID / VC infrastructure 30, and uses those public keys to verify the legitimacy of the data issued (offered) by the wallet 10 (step S74). As a result, the control unit 72 obtains the legitimacy verification result (step S75).

[0118] Then, the control unit 72 provides service SA32 to user U if the data issued (presented) by wallet 10 is legitimate and trustworthy.

[0119] Thus, the configurations in Figures 5 and 6 are designed to convert information about tokens held by user U into a VC at the time of request, with the platform verifying the fact of ownership 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 is possible to verify information about tokens that user U himself definitely owns at the time of the request, and there are advantages such as not needing an organization acting as an issuer (e.g., provider IS) because the VC is automatically generated from on-chain information.

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

[0121] Figure 7 shows a scenario in which user U, who participates in "Community-C1," "Project-C2," and "Community-C3," selectively discloses only the information they possess within each community to the community of their choice.

[0122] According to the example in 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 they also issue and sell tokens.

[0123] On the other hand, "Community-C2" refers to a web2 community. For example, "Community-C2" could be a social networking service or blog where fans who support a specific subject gather.

[0124] In the example shown in Figure 7, user U stores tokens issued by service SA31 (corresponding to service SA31 in Figure 1) in wallet WL31, an application installed on their terminal device 10, based on their contributions to "Community-C1". Specifically, the tokens are linked to wallet address AD1 of wallet WL31. The tokens linked to wallet address AD1 are user U's holding information HL1.

[0125] Furthermore, user U has a web2ID account to access service SA2 so that they can check data showing their contributions to "Community-C2" (which corresponds to service SA2 in Figure 1) from their terminal device 10. For example, in the RDB on the service SA2 side, data showing user U's contributions is managed linked to the web2ID account. The data linked to the web2ID account is user U's personal information HL2.

[0126] Furthermore, user U stores tokens issued from service SA32 (corresponding to service SA32 in Figure 1) based on their contributions to "Community-C3" in wallet WL32, an application installed on their 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 holding information HL3.

[0127] In this situation, for example, if presentation system 1 receives access from wallet VCWL, it converts the held information HL1 into VC. Specifically, presentation system 1 generates verifiable personal information VC_HL1, which serves as proof that user U possesses the held information HL1, and issues the generated personal information VC_HL1 to wallet VCWL.

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

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

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

[0131] Similar to the example in Figure 2, if we define personal information VCn as a single verifiable piece of personal information that combines personal information VC_HL1, personal information VC_HL2, and personal information VC_HL3, using user U's DID as the key, then personal information VCn also includes user U's DID, the digital signature generated using user U's private key, service SV31's DID, service SV31's digital signature generated using service SV31's private key, service SV32's DID, service SV32's digital signature generated using service SV32's private key, and service SV2's DID, service SV2's digital signature generated using service SV2's private key.

[0132] In this situation, the wallet VCWL accepts a selection from user U regarding which of the personal information VC_HL1, personal information VC_HL2, and personal information VC_HL3 to disclose to which other communities, indicating which information the user wishes to disclose.

[0133] Figure 7 shows "Community-C4" and "Community-C5" as services that allow participation or grant benefits only to those who possess information that meets certain conditions, and illustrates examples of requests for the presentation of possessed information from each of these communities.

[0134] Furthermore, Figure 7 shows an example in which user U selects personal information VC_HL1 and personal information VC_HL2 from personal information VCn. In this example, wallet VCWL performs selective presentation, presenting personal information VC_HL1 and personal information VC_HL2 to community-C4, as shown in Figure 7.

[0135] On the other hand, Figure 7 shows an example where user U selects personal information VC_HL3 from personal information VCn. In this example, as shown in Figure 7, wallet VCWL performs selective presentation by presenting only personal information VC_HL3 to community-C5.

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

[0137] The CPU 1100 operates based on programs stored in the ROM 1300 or HDD 1400, controlling various components. The ROM 1300 stores boot programs executed by the CPU 1100 when the computer 1000 starts up, as well as programs that depend on the computer 1000's hardware.

[0138] The HDD1400 stores programs executed by the CPU1100, as well as data used by such programs. The communication interface1500 receives data from other devices via a predetermined communication network and sends it to the CPU1100, and transmits data generated by the CPU1100 to other devices via the predetermined communication network.

[0139] The CPU 1100 controls output devices such as displays and input devices such as keyboards via the input / output interface 1600. The CPU 1100 acquires data from input devices via the input / output interface 1600. The CPU 1100 also outputs the generated data to output devices via the input / output interface 1600.

[0140] The media interface 1700 reads a program or data stored in the recording medium 1800 and provides it to the CPU 1100 via the RAM 1200. The CPU 1100 loads the program from the recording medium 1800 onto the RAM 1200 via the media interface 1700 and executes the loaded program. The recording medium 1800 is, for example, an optical recording medium such as a DVD (Digital Versatile Disc) or PD (Phase Change Rewritable Disk), 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, if computer 1000 functions as a computer of presentation system 1, the CPU 1100 of computer 1000 realizes the functions of each processing unit by executing a program (presentation program) loaded onto RAM 1200. The CPU 1100 of computer 1000 reads and executes these programs from the recording medium 1800, but as another example, these programs may be obtained from other devices 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 by known methods. In addition, the processing procedures, specific names, and information including various data and parameters shown in the above document and drawings can be changed at will unless otherwise specified. For example, the various information shown in each figure is not limited to the information shown.

[0143] Furthermore, the components of each illustrated device are functionally conceptual and do not necessarily need to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions.

[0144] Furthermore, the above embodiments can be combined as appropriate, provided that the processing content is not contradictory.

[0145] Although some embodiments of the present invention have been described in detail above with reference to the drawings, these are illustrative examples, and the present invention can be implemented in various other forms with modifications and improvements based on the knowledge of those skilled in the art, including the embodiments described in the section on the present invention. [Explanation of symbols]

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

Claims

1. An acquisition means for acquiring information held by a user of the service in accordance with the use of the service, An issuing means for issuing verifiable personal information to the user that serves as proof that the user possesses the information, based on the user ID, which is a decentralized identifier linked to the user's wallet, the provider ID, which is a decentralized identifier linked to the provider of the service, and the information held. A presentation means that accepts from the user the selection of the scope of retained information included in the personal information to which disclosure is permitted, and the recipients to whom the information included in that scope will be disclosed, and presents the retained information included in the selected scope only to the selected recipients, A presentation system equipped with the following features.

2. If the scope and recipient are selected, the presentation means presents the verifiable personal information, which has been electronically signed using the user's private key, to the recipient. The presentation system according to claim 1.

3. The acquisition means, if the user is using multiple different services, acquires the information held by the user for each of the multiple different services, according to the usage of each of the multiple different services. The presentation means manages each of the verifiable personal information issued individually for each of the multiple different services in accordance with the information held for each of the multiple different services, by linking each of them to a single user ID, and accepts a selection of which of the multiple different services the information held for should be presented. The presentation system according to claim 1.

4. If the user uses multiple different accounts within a single service, the acquisition means acquires the information held by the user for each of the multiple different accounts. The presentation means includes all of the aforementioned retained information for each of several different accounts, and manages the verifiable personal information issued in accordance with one service by linking it to a single user ID, and accepts a selection of which of the several different accounts the retained information corresponding to should be presented. The presentation system according to claim 1.

5. The aforementioned presentation system is The issuance means is a first issuance means that issues the verifiable personal information when the retained information is generated on the service side. or When an issuance request is received from the aforementioned user, a second issuance means for issuing the aforementioned verifiable personal information, Having one of the following, A provider device belonging to the aforementioned provider and generating the aforementioned owned information includes the first issuing means, A predetermined platform that is externally linked to the aforementioned provider device and receives the aforementioned issuance request comprises the second issuance means. The presentation system according to claim 1.

6. The first issuing means issues to the user the verifiable personal information to which an electronic signature generated using the provider's private key has been attached. The second issuing means issues to the user the verifiable personal information to which an electronic signature generated using the private key of the predetermined platform has been attached. The presentation system according to claim 5.

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

8. The provider of the aforementioned service is the operator of the community service, The acquisition means is, If the service used by the user is a Web2 type community, the information held includes the user's activity data within the Web2 type community, obtained from the database. If the service used by the user is a Web3 community, the information held includes tokens issued from the blockchain according to the user's activity in the Web3 community. The disclosure means, when it receives a disclosure request from a community other than the community used by the user, accepts from the user the selection of the scope of the retained information included in the personal information that may be disclosed to the other community, and accepts from the user the selection of the other community as the recipient to which the information included in the scope will be disclosed. The presentation system according to claim 1.

9. The computer in the presentation system An acquisition means for acquiring information held by a user of the service in accordance with the use of the service, An issuing means for issuing verifiable personal information to the user that serves as proof that the user possesses the information, based on the user ID, which is a decentralized identifier linked to the user's wallet, the provider ID, which is a decentralized identifier linked to the provider of the service, and the information held. A presentation means that accepts from the user the selection of the scope of retained information included in the personal information to which disclosure is permitted, and the recipients to whom the information included in that scope will be disclosed, and presents the retained information included in the selected scope only to the selected recipients, A presentation program designed to function as such.

10. A presentation method performed by a presentation system, An acquisition step of acquiring information held by the user of the service in accordance with the use of the service, An issuance process for issuing verifiable personal information to the user that serves as proof that the user possesses the aforementioned information, based on the user ID, which is a decentralized identifier linked to the user's wallet, the provider ID, which is a decentralized identifier linked to the provider of the service, and the aforementioned possessed information. A presentation step in which the user selects the scope of the retained information included in the personal information to be permitted to be disclosed, and the recipients to whom the information included in that scope will be disclosed, and presents the retained information included in the selected scope only to the selected recipients, A presentation method that includes this.

Images