Method and system for supporting use of digital wallet

Abstract

Provided, according to one aspect of the present invention, is a method for supporting the use of a digital wallet, the method comprising the steps of: acquiring a first request according to a first protocol from a verifier node; generating a second request according to a second protocol on the basis of the first request, wherein a first digital wallet used by a holder node supports the second protocol rather than the first protocol; acquiring a second response to the second request; generating a first response according to the first protocol on the basis of the second response; and transmitting the generated first response to the verifier node as a response to the first request.

Description

Method and system for supporting the use of a digital wallet

[0001] The present invention relates to a method and system for supporting the use of a digital wallet.

[0002] Recently, as interest in Self-Sovereign Identity (SSI) has increased, there has been active discussion regarding methods to prove the qualifications required to receive desired services using Verifiable Credentials (VC; hereinafter abbreviated as "Credentials"). Basically, this method is carried out by an issuer issuing a credential that digitally expresses that a specific entity, such as an individual or organization, possesses a specific qualification, thereby enabling that specific entity to possess the credential; the holder of the credential then presents it to a verifier in the form of a Verifiable Presentation (VP; hereinafter abbreviated as "Presentation"), and the verifier verifies it.

[0003] As an example of prior art regarding this, the technology disclosed in Korean Patent Publication No. 10-2023-0143410 may be cited. According to this, the method is characterized by comprising: a step of analyzing the ID issuance history recorded in a distributed ID management contract in response to a request for the issuance of a 'distributed ID' from a user to inquire whether there is a distributed ID already issued to the user; a step of issuing a new distributed ID to the user if there is no distributed ID already issued as a result of the inquiry; and a step of updating the ID issuance history by recording the details of the distributed ID issuance in the ID issuance history while registering the issued distributed ID in a distributed ID storage as the new distributed ID delivered to the user is recorded in the user's electronic wallet.

[0004] However, according to the conventional technologies mentioned above and other technologies introduced so far, there was an inconvenience in that when a user (e.g., a holder node) attempts to receive a specific service using credentials via a digital wallet, if the user's digital wallet does not support the specific protocol used by that service, another digital wallet that supports that protocol must be installed separately. Additionally, there was the problem of having to store the same credentials redundantly across multiple digital wallets and requiring management on a per-wallet basis.

[0005] Accordingly, the inventor(s) propose a technology that supports ensuring the interoperability of digital wallets by obtaining a first request according to a first protocol from a validator node and generating a second request according to a second protocol based on the first request, wherein the first digital wallet used by the holder node supports the second protocol rather than the first protocol, obtaining a second response to the second request and generating a first response according to the first protocol based on the second response, and transmitting the first response thus generated to the validator node as a response to the first request.

[0006] <Prior Art Literature>

[0007] <Patent Literature>

[0008] (Patent Document 0001) Korean Published Patent Application No. 10-2023-0143410 (October 12, 2023)

[0009] The present invention aims to solve all the problems of the aforementioned prior art.

[0010] Additionally, the present invention has another objective of obtaining a first request according to a first protocol from a validator node and generating a second request according to a second protocol based on the first request, wherein the first digital wallet used by the holder node supports the second protocol rather than the first protocol, obtaining a second response to the second request, generating a first response according to the first protocol based on the second response, and transmitting the first response thus generated to the validator node as a response to the first request.

[0011] In addition, another objective of the present invention is to support ensuring the interoperability of digital wallets.

[0012] In addition, the present invention has another objective of preventing duplicate storage of credentials.

[0013] In addition, another objective of the present invention is to optimize the user experience by supporting the user to use a digital wallet interface they are familiar with.

[0014] A representative configuration of the present invention for achieving the above objective is as follows.

[0015] According to one aspect of the present invention, a method is provided comprising the steps of: obtaining a first request according to a first protocol from a validator node; generating a second request according to a second protocol based on the first request, wherein a first digital wallet used by a holder node supports the second protocol rather than the first protocol; obtaining a second response to the second request; generating a first response according to the first protocol based on the second response; and transmitting the generated first response to the validator node as a response to the first request.

[0016] According to another aspect of the present invention, a system is provided comprising: a first request acquisition unit for acquiring a first request according to a first protocol from a validator node; a request generation unit for generating a second request according to a second protocol based on the first request, wherein a first digital wallet used by a holder node supports the second protocol rather than the first protocol; a second response acquisition unit for acquiring a second response to the second request; a first response generation unit for generating a first response according to the first protocol based on the second response; and a transmission unit for transmitting the generated first response to the validator node as a response to the first request.

[0017] In addition to this, other methods for implementing the present invention, other systems, and non-transient computer-readable recording media for recording a computer program for executing said methods are further provided.

[0018] According to the present invention, a first request according to a first protocol is obtained from a validator node, and a second request according to a second protocol is generated based on the first request, wherein the first digital wallet used by the holder node supports the second protocol rather than the first protocol, a second response to the second request is obtained, and a first response according to the first protocol is generated based on the second response, and the first response thus generated can be transmitted to the validator node as a response to the first request.

[0019] In addition, according to the present invention, it is possible to support ensuring the interoperability of digital wallets.

[0020] In addition, according to the present invention, duplicate storage of credentials can be prevented.

[0021] In addition, according to the present invention, the user experience can be optimized by supporting the user to use a digital wallet interface that they are familiar with.

[0022] FIG. 1 is a diagram showing the schematic configuration of an overall system for supporting the use of a digital wallet according to one embodiment of the present invention.

[0023] FIG. 2 is a drawing illustrating in detail the internal configuration of a holder-side system according to one embodiment of the present invention.

[0024] <Explanation of Symbols>

[0025] 100: Communication network

[0026] 200: Validator-side system

[0027] 300: Holder-side system

[0028] 400: Issuer-side system

[0029] 310: 1st Request Acquisition Unit

[0030] 320: Request creation section

[0031] 330: Second response acquisition unit

[0032] 340: First response generation unit

[0033] 350: Transmitter

[0034] 360: Communications Department

[0035] 370: Control unit

[0036] 500: Device

[0037] The following detailed description of the invention refers to the accompanying drawings, which illustrate specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It should be understood that various embodiments of the invention are different but need not be mutually exclusive. For example, specific shapes, structures, and characteristics described herein may be modified from one embodiment to another without departing from the spirit and scope of the invention. It should also be understood that the location or arrangement of individual components within each embodiment may be modified without departing from the spirit and scope of the invention. Accordingly, the following detailed description is not meant to be limiting, and the scope of the invention should be understood to encompass the scope claimed by the claims and all equivalents thereof. Similar reference numerals in the drawings indicate identical or similar components across various aspects.

[0038] Hereinafter, in order to enable a person skilled in the art to easily practice the present invention, various preferred embodiments of the present invention will be described in detail with reference to the attached drawings.

[0039] Configuration of the entire system

[0040] FIG. 1 is a diagram showing the schematic configuration of an overall system for supporting the use of a digital wallet according to one embodiment of the present invention.

[0041] As illustrated in FIG. 1, the entire system according to one embodiment of the present invention may include a communication network (100), a verifier-side system (200), a holder-side system (300), an issuer-side system (400), and a device (500).

[0042] First, a communication network (100) according to one embodiment of the present invention can be configured regardless of the mode of communication, such as wired communication or wireless communication, and can be configured as various communication networks such as a Local Area Network (LAN), a Metropolitan Area Network (MAN), or a Wide Area Network (WAN). Preferably, the communication network (100) referred to in this specification may be the known Internet or the World Wide Web (WWW). However, the communication network (100) may include at least a known wired / wireless data communication network, a known telephone network, or a known wired / wireless television communication network, without being limited thereto.

[0043] For example, the communication network (100) may be a wireless data communication network and may implement conventional communication methods such as WiFi communication, WiFi-Direct communication, Long Term Evolution (LTE) communication, 5G communication, Bluetooth communication (including Bluetooth Low Energy (BLE) communication), infrared communication, ultrasonic communication, etc., in at least a part thereof. As another example, the communication network (100) may be an optical communication network and may implement conventional communication methods such as Light Fidelity (LiFi), etc., in at least a part thereof.

[0044] Next, a node (not shown) according to one embodiment of the present invention, for example, an issuer node, a holder node, a verifier node, etc., is a contact point or connection point capable of communicating with other nodes through a communication network (100), and may be a concept including a physical node of a server, computer, laptop, smartphone, tablet PC, etc. (i.e., a digital device equipped with memory means and equipped with a microprocessor to have computational capabilities) or a logical node of an application, program module, virtual machine, etc. (i.e., a virtual node).

[0045] Specifically, according to one embodiment of the present invention, a node may be a digital wallet itself or a concept that includes a digital wallet. A digital wallet refers to a software or hardware device that allows a user to securely store and manage digital assets, authentication information, identity information, etc., and means of storing various data and enabling the use of the stored data as needed. For example, an issuer node, a holder node, and a validator node may each refer to a digital wallet owned by the issuer, holder, and validator, or a digital wallet running on the devices of the issuer, holder, and validator.

[0046] According to one embodiment of the present invention, these nodes may refer to each node that is associated with one another to form a distributed ledger network. According to one embodiment of the present invention, in order to support the use of credentials based on Distributed Ledger Technology (DLT), these nodes may include a validator-side system (200), a holder-side system (300), and / or an issuer-side system (400), which will be described later, in the form of program modules such as applications or widgets. Additionally, such program modules may be downloaded from an external application distribution server (not shown) or an external system (not shown), etc.

[0047] Here, according to one embodiment of the present invention, a distributed ledger may refer to a method of storing and managing data in a distributed manner across multiple nodes without centralized authority while maintaining data integrity and security. Specifically, the distributed ledger described above includes, but is not limited to, a blockchain, a tangle, a hashgraph, a directed acyclic graph (DAG), etc.

[0048] Specifically, a distributed ledger according to one embodiment of the present invention may be a blockchain (or a blockchain network). The aforementioned blockchain network may be a network capable of ensuring the integrity and reliability of the recorded information without relying on an authorized third party by jointly verifying information to be stored on the network by a plurality of nodes participating in the network, and recording and sharing the verified information on the network. For example, according to one embodiment of the present invention, such a blockchain network may be a network that is similar in at least some of its characteristics to those of conventional blockchain networks such as Bitcoin, Ethereum, and Quantum. Furthermore, according to one embodiment of the present invention, such a blockchain network may be a concept that includes various types of blockchain networks, such as a private blockchain network, a public blockchain network, or a hybrid network of a private blockchain and a public blockchain.

[0049] Meanwhile, according to one embodiment of the present invention, the fact that each node may be associated with the aforementioned nodes to form a distributed ledger network is merely an example and is not limited thereto. That is, a node according to one embodiment of the present invention may refer to any kind of reliable storage means that acts as a participant in verifying and storing data and exchanging information with other nodes to maintain the integrity and consistency of the entire system.

[0050] Next, a verifier-side system (200) according to one embodiment of the present invention can perform a function of verifying the credentials based on information regarding credentials provided by a holder node.

[0051] According to one embodiment of the present invention, the validator-side system (200) may mean a system that includes a validator node or is included in a validator node, and may mean the validator node itself.

[0052] Next, a holder-side system (300) according to one embodiment of the present invention can perform the function of proving its own qualifications by receiving credentials from an issuer node (400) and presenting information regarding them to a verifier node.

[0053] According to one embodiment of the present invention, the holder-side system (300) may refer to a system that includes a holder node or is included in a holder node, or it may refer to the holder node itself. In particular, the holder-side system (300) according to one embodiment of the present invention may be a system that includes a digital wallet or includes a digital wallet, or it may be a separate system capable of linking with the digital wallet of a holder node. According to one embodiment of the present invention, such a holder-side system (300) may be a system managed by the operator of the digital wallet or a system managed by a third party different from the operator of the digital wallet.

[0054] Additionally, a holder-side system (300) according to one embodiment of the present invention may perform the function of obtaining a first request according to a first protocol from a validator node and generating a second request according to a second protocol based on the first request, wherein the first digital wallet used by the holder node supports the second protocol rather than the first protocol, obtaining a second response to the second request, generating a first response according to the first protocol based on the second response, and transmitting the first response thus generated to the validator node as a response to the first request.

[0055] The configuration and function of the holder-side system (300) according to the present invention will be examined in detail through the following detailed description.

[0056] Next, the issuer-side system (400) according to one embodiment of the present invention can perform the function of generating credentials and issuing them to a holder node. Generally, the issuer is a trusted institution or organization that has the authority to verify information about an individual or organization and issue credentials that prove it. For example, various institutions such as universities, government agencies, financial institutions, and employers may be such issuers, but are not limited thereto.

[0057] According to one embodiment of the present invention, the issuer-side system (400) may mean a system that includes an issuer node or is included in an issuer node, and may mean the issuer node itself.

[0058] Next, the device (500) according to one embodiment of the present invention is a digital device that includes a function to communicate after connecting to a verifier-side system (200), a holder-side system (300) and / or an issuer-side system (400). Any digital device equipped with memory means and equipped with a microprocessor to have computational capabilities, such as a smartphone, tablet, smart watch, smart band, smart glasses, desktop computer, laptop computer, workstation, PDA, web pad, mobile phone, etc., can be adopted as the device (500) according to the present invention.

[0059] In particular, the device (500) may include an application (not shown) that enables a user to receive services according to the present invention from a validator-side system (200), a holder-side system (300), and / or an issuer-side system (400). Such an application may be downloaded from a validator-side system (200), a holder-side system (300), an issuer-side system (400), and / or an external application distribution server (not shown). Meanwhile, the nature of such an application may generally be similar to the first request acquisition unit (310), request generation unit (320), second response acquisition unit (330), first response generation unit (340), transmission unit (350), communication unit (360), and control unit (370) of the holder-side system (300) as described below. Here, at least a part of the application may be replaced with a hardware device or firmware device capable of performing substantially the same or equivalent functions as needed.

[0060] According to one embodiment of the present invention, such a device (500) may mean one of a plurality of nodes (e.g., issuer node, holder node, validator node, etc.) that are associated with each other to form a distributed ledger network.

[0061] Configuration of the holder-side system

[0062] Below, we will examine the internal configuration of the holder-side system (300) that performs important functions for the implementation of the present invention and the functions of each component.

[0063] FIG. 2 is a drawing illustrating in detail the internal configuration of a holder-side system (300) according to one embodiment of the present invention.

[0064] As illustrated in FIG. 2, a holder-side system (300) according to one embodiment of the present invention may be configured to include a first request acquisition unit (310), a request generation unit (320), a second response acquisition unit (330), a first response generation unit (340), a transmission unit (350), a communication unit (360), and a control unit (370) of the holder-side system (300). According to one embodiment of the present invention, the first request acquisition unit (310), the request generation unit (320), the second response acquisition unit (330), the first response generation unit (340), the transmission unit (350), the communication unit (360), and the control unit (370) may be program modules in which at least some of them communicate with an external system (not shown). Such program modules may be included in the holder-side system (300) in the form of an operating system, an application program module, or other program modules, and may be physically stored in various known storage devices. Additionally, these program modules may be stored in a remote storage device capable of communicating with the holder-side system (300). Meanwhile, these program modules include, but are not limited to, routines, subroutines, programs, objects, components, data structures, etc., that perform specific tasks or execute specific abstract data types as described below according to the present invention.

[0065] Meanwhile, although the holder-side system (300) has been described as above, this description is exemplary, and it is obvious to those skilled in the art that at least some of the components or functions of the holder-side system (300) may be realized within a device (500) or server (not shown) or included within an external system (not shown) as needed.

[0066] First, a first request acquisition unit (310) according to one embodiment of the present invention can perform the function of acquiring a first request according to a first protocol from a validator node.

[0067] Specifically, according to one embodiment of the present invention, a validator node may request specific information (e.g., identity information, qualification information, income information, etc.) from a holder node to achieve a specific purpose, for example, to provide a specific service to a holder node. Such a request by the validator node, i.e., the first request, may be generated according to a first protocol (e.g., OpenID4VP protocol). According to one embodiment of the present invention, the first request by the validator node may be a request to the holder node to generate a VP containing the above specific information using the VC held by the holder node and then submit the VP.

[0068] Next, a request generation unit (320) according to one embodiment of the present invention may perform the function of generating a second request according to a second protocol based on a first request according to a first protocol obtained from a validator node. At this time, according to one embodiment of the present invention, the first digital wallet used by the holder node may support a second protocol rather than the first protocol.

[0069] Specifically, according to one embodiment of the present invention, the first digital wallet used by the holder node may be a wallet that does not support the first protocol but supports the second protocol. Since the first request is generated according to the first protocol, the first digital wallet that does not support the first protocol may not be able to respond immediately to the first request. Accordingly, the request generation unit (320) according to one embodiment of the present invention may generate a second request by converting the first request into a request according to the second protocol supported by the first digital wallet so that the first digital wallet can respond to the first request. If necessary, the request generation unit (320) may prevent the content from being tampered with during the conversion process by verifying the integrity of the hash value regarding the first request and the hash value regarding the second request by comparing them.

[0070] For example, the first protocol may be the OpenID4VP protocol, and the second protocol may be the DIDComm protocol. As another example, the first protocol and the second protocol may be different versions of protocols of the same type but not compatible with each other. However, the first protocol and the second protocol according to one embodiment of the present invention are not limited to the examples described above and may be modified in various ways within the scope of achieving the purpose of the present invention.

[0071] According to one embodiment of the present invention, the request generation unit (320) can generate a second request according to the second protocol according to a predefined protocol-to-protocol conversion rule.

[0072] Specifically, according to one embodiment of the present invention, the request generation unit (320) may define a protocol-to-protocol conversion rule before obtaining the first request from the validator node in order to generate a second request according to the second protocol based on a first request according to the first protocol.

[0073] For example, the request generation unit (320) may search for a digital wallet installed on the device (500) of the holder node, identify that the protocol supported by the digital wallet is the second protocol, and investigate the characteristics of the second protocol. Then, the request generation unit (320) may define or update protocol-to-protocol conversion rules in a manner such as mapping message formats based on protocol(s) other than the second protocol, for example, based on the relationship between the first protocol and the second protocol. Then, when the first request is obtained from the validator node, the request generation unit (320) may convert the first request into the second request by appropriately selecting a predefined protocol-to-protocol conversion rule. If necessary, this process may be performed periodically.

[0074] In addition, according to one embodiment of the present invention, such protocol-to-protocol conversion rules can be managed dynamically. For example, the request generation unit (320) can learn about new types and / or new versions of protocols on its own and update protocol-to-protocol conversion rules based on what it has learned.

[0075] Next, the second response acquisition unit (330) according to one embodiment of the present invention can perform the function of acquiring a second response to a second request.

[0076] Specifically, according to one embodiment of the present invention, since the second request follows the second protocol, the holder node can generate a response to the second request using a first digital wallet that supports the second protocol. According to one embodiment of the present invention, the response of the holder node (i.e., the second response) may be to select a VC containing specific information requested by the validator node through the first request, or to generate a VP using such a VC. The second response thus generated may also follow the second protocol. Furthermore, the second response acquisition unit (330) according to one embodiment of the present invention can acquire the second response through the first digital wallet.

[0077] Next, the first response generating unit (340) according to one embodiment of the present invention can perform the function of generating a first response according to the first protocol based on the second response obtained as above.

[0078] Specifically, according to one embodiment of the present invention, since the second response is generated according to the second protocol, it may be data in a format unsuitable for processing by a validator node using the first protocol. Accordingly, the first response generation unit (340) according to one embodiment of the present invention may generate a first response by converting the second response into a response according to the first protocol so that data in a format that can be processed by the validator node is transmitted to the validator node. If necessary, the first response generation unit (340) may prevent the content from being tampered with during the conversion process by verifying the integrity of the second response by comparing the hash value of the second response with the hash value of the first response.

[0079] Meanwhile, according to one embodiment of the present invention, the second response to the second request described above may be generated according to the encryption method of the second protocol, for example, the ECDH-ES (Elliptic Curve Diffie-Hellman Ephemeral-Static) method of the DIDComm protocol. In addition, the first response generation unit (340) according to one embodiment of the present invention may generate the first response according to the encryption method of the first protocol corresponding to the encryption method of the second protocol, for example, the JWE (JSON Web Encryption) method of the OpenID4VP protocol. By doing so, it is possible to maintain the encryption level and comply with the necessary security policy.

[0080] Next, a transmitting unit (350) according to one embodiment of the present invention can perform the function of transmitting the first response generated as above to a validator node as a response to a first request according to a first protocol obtained from a validator node.

[0081] Specifically, according to one embodiment of the present invention, since the first response is generated according to the first protocol used by the validator node, the validator node can receive the first response from the transmitting unit (350) and process it appropriately to perform a necessary operation (e.g., providing a specific service to the holder node).

[0082] Meanwhile, according to one embodiment of the present invention, a situation can be assumed in which a holder node uses a plurality of digital wallets, for example, a first digital wallet and a second digital wallet, and all of the plurality of digital wallets support a second protocol rather than a first protocol, and a validator node requests information regarding a first VC stored by the first digital wallet and a second VC stored by the second digital wallet.

[0083] In such cases, a first request according to a first protocol obtained from a validator node may include a request for information regarding a first VC stored by a first digital wallet used by a holder node and a second VC stored by a second digital wallet used by a holder node. And, a second response acquisition unit (330) according to an embodiment of the present invention may obtain a second response to a second request according to a second protocol based on information regarding a first VC obtained from a first digital wallet and information regarding a second VC obtained from a second digital wallet.

[0084] Specifically, a request generation unit (320) according to one embodiment of the present invention can generate a second request by decomposing a first request according to a first protocol obtained from a validator node into a request for information regarding a first VC and a request for information regarding a second VC. The request generation unit (320) can send the request for information regarding a first VC to a first digital wallet and the request for information regarding a second VC to a second digital wallet. Furthermore, a second response acquisition unit (330) according to one embodiment of the present invention can obtain a second response to a second request according to a second protocol by integrating information regarding a first VC obtained from a first digital wallet and information regarding a second VC obtained from a second digital wallet.

[0085] On the other hand, according to one embodiment of the present invention, a situation can be assumed in which a holder node uses a plurality of digital wallets, for example, a first digital wallet and a second digital wallet, and among the plurality of digital wallets, the first digital wallet supports a second protocol other than the first protocol, and the second digital wallet supports the first protocol, and a validator node requests information regarding a first VC stored by the first digital wallet and a second VC stored by the second digital wallet.

[0086] Even in such cases, the first request according to the first protocol obtained from the validator node may include a request for information regarding the first VC stored by the first digital wallet used by the holder node and the second VC stored by the second digital wallet used by the holder node. Furthermore, the request generation unit (320) according to one embodiment of the present invention may decompose the first request according to the first protocol obtained from the validator node into a request for information regarding the first VC and a request for information regarding the second VC, generate a second request according to the second protocol based on the request for information regarding the first VC, and generate a third request according to the first protocol based on the request for information regarding the second VC. The request generation unit (320) may send the second request to the first digital wallet and send the third request to the second digital wallet.

[0087] Furthermore, a second response acquisition unit (330) according to one embodiment of the present invention may acquire a second response to a second request and a third response to a third request, and generate a first response according to a first protocol based on the second response and the third response. Here, the third response may be according to the first protocol. Since the process of converting the second response into a format according to the first protocol has been described above, a redundant explanation will be omitted.

[0088] Next, a communication unit (360) according to one embodiment of the present invention can perform the function of enabling data transmission and reception from / to a first request acquisition unit (310), a request generation unit (320), a second response acquisition unit (330), a first response generation unit (340), and a transmission unit (350).

[0089] Finally, a control unit (370) according to one embodiment of the present invention can perform the function of controlling the flow of data between a first request acquisition unit (310), a request generation unit (320), a second response acquisition unit (330), a first response generation unit (340), a transmission unit (350), and a communication unit (360). That is, by controlling the flow of data from / to / from the outside of the holder-side system (300) or the flow of data between each component of the holder-side system (300), the control unit (370) according to one embodiment of the present invention can control the first request acquisition unit (310), the request generation unit (320), the second response acquisition unit (330), the first response generation unit (340), the transmission unit (350), and the communication unit (360) to perform their respective unique functions.

[0090] By using the holder-side system (300) described above, the following embodiments can be realized:

[0091] (Example)

[0092] We can assume a situation where a user (holder node) intends to apply for a loan service from Bank A (validator node), and while Bank A uses the OpenID4VP protocol (first protocol), the user's smartphone has a digital wallet from Company B installed that supports only the DIDComm protocol (second protocol).

[0093] In this case, the request generation unit (320) can detect Company B's digital wallet by searching for applications installed on the user's smartphone and identify that the protocol supported by Company B's digital wallet is the DIDComm v2.0 protocol (second protocol). Then, the request generation unit (320) can determine that the message format is JSON-LD, the encryption method is ECDH-ES+A256KW, and the signature algorithm is EdDSA (Edwards-curve Digital Signature Algorithm) by analyzing the characteristics of the protocol. Then, the request generation unit (320) can define conversion rules between the OpenID4VP protocol (first protocol) and the DIDComm protocol (second protocol) based on the determined information.

[0094] Next, the first request acquisition unit (310) can acquire a first request according to the OpenID4VP protocol (first protocol) from Bank A (validator node). The first request may be in the following format:

[0095] - presentation_definition_uri: "https: / a-bank.com / pd / loan-kyc"

[0096] - response_uri: "https: / a-bank.com / vp / response"

[0097] - nonce: "n-0S6_WzA2Mj"

[0098] - state: "af0ifjsldkj"

[0099] Next, the request generation unit (320) can generate a second request according to the DIDComm protocol based on a first request according to the OpenID4VP protocol, according to the conversion rules between the OpenID4VP protocol and the DIDComm protocol. Specifically, the request generation unit (320) can interpret the Presentation Definition of the first request to determine that the credentials required by Bank A (validator node) are an identity certificate and an income certificate issued within 30 days, and then convert the first request into a request according to the DIDComm protocol, i.e., a second request. The second request (DIDComm message) may be in the following format:

[0100] {

[0101] "@type": "https: / didcomm.org / present-proof / 2.0 / request-presentation",

[0102] "@id": "12345678-1234-5678-1234-567812345678",

[0103] "comment": "Identity verification for Bank A loan application",

[0104] "formats": [{

[0105] "attach_id": "dif-presentation-exchange",

[0106] "format": "dif / presentation-exchange / definitions@v1.0"

[0107] }],

[0108] "request_presentations~attach": [{

[0109] "@id": "dif-presentation-exchange",

[0110] "mime-type": "application / json",

[0111] "data": {

[0112] "json": {

[0113] "presentation_definition": {

[0114] "id": "a-bank-loan-kyc",

[0115] "input_descriptors": [

[0116] {

[0117] "id": "identity_credential",

[0118] "name": "Identity Certificate",

[0119] "purpose": "Identity verification",

[0120] "constraints": {

[0121] "fields": [{

[0122] "path": ["$.credentialSubject.name"],

[0123] "filter": {"type": "string"}

[0124] }]

[0125] }

[0126] },

[0127] {

[0128] "id": "income_credential",

[0129] "name": "Income Certificate",

[0130] "purpose": "Income verification",

[0131] "constraints": {

[0132] "fields": [{

[0133] "path": ["$.issuanceDate"],

[0134] "filter": {

[0135] "type": "string",

[0136] "pattern": "^(202[4-5])-.*"

[0137] }

[0138] }]

[0139] }

[0140] }

[0141] ]

[0142] }

[0143] }

[0144] }

[0145] }]

[0146] }

[0147] Next, the second response acquisition unit (330) can send a second request (DIDComm message) to Company B's digital wallet to display a user authentication request popup. At this time, the user can check the request from Bank A through Company B's wallet, select an identity certificate and an income certificate among the credentials they possess, and then approve the submission of the selected credentials using methods such as biometric authentication (fingerprint). By doing so, the second response acquisition unit (330) can acquire a DIDComm Presentation (second response) from Company B's digital wallet.

[0148] Next, the first response generation unit (340) can generate a first response according to the OpenID4VP protocol based on a second response according to the DIDComm protocol according to the conversion rules between the OpenID4VP protocol and the DIDComm protocol. Specifically, the first response generation unit (340) can generate the first response by extracting a Verifiable Presentation, reconstructing the DIDComm Presentation (second response) into an OpenID4VP response format, and then encoding it into a JWT format. The first response may be in the following format:

[0149] OpenID4VP Response:

[0150] {

[0151] "vp_token": "eyJhbGciOiJFUzI1NiIs...",

[0152] "presentation_submission": {

[0153] "id": "a-bank-submission-001",

[0154] "definition_id": "a-bank-loan-kyc",

[0155] "descriptor_map": [

[0156] {

[0157] "id": "identity_credential",

[0158] "format": "jwt_vp",

[0159] "path": "$"

[0160] },

[0161] {

[0162] "id": "income_credential",

[0163] "format": "jwt_vp",

[0164] "path": "$"

[0165] }

[0166] ]

[0167] },

[0168] "state": "af0ifjsldkj"

[0169] }

[0170] Next, the transmitting unit (350) can transmit the first response to Bank A as a response to Bank A's first request. Bank A can verify the VP TOKEN (first response), and if the verification is passed, proceed with the loan application process so that an approval notification is sent to the user. By doing so, the user can use Bank A's services using the digital wallet of Company B that they previously used.

[0171] The embodiments according to the present invention described above may be implemented in the form of program instructions that can be executed through various computer components and recorded on a computer-readable recording medium. The computer-readable recording medium may include program instructions, data files, data structures, etc., either individually or in combination. The program instructions recorded on the computer-readable recording medium may be those specifically designed and configured for the present invention or those known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Examples of program instructions include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. Hardware devices may be modified into one or more software modules to perform processing according to the present invention, and vice versa.

[0172] Although the present invention has been described above with reference to specific details such as specific components, limited embodiments, and drawings, this is provided only to aid in a more comprehensive understanding of the invention, and the invention is not limited to the above embodiments, and a person skilled in the art to which the invention belongs can make various modifications and changes from this description.

[0173] Accordingly, the scope of the present invention should not be limited to the embodiments described above, and all scopes equivalent to or equivalently modified from the claims set forth below, as well as the claims set forth below, shall be considered to fall within the scope of the concept of the present invention.

Images