Information processing device and communication method

Abstract

This information processing device is provided with: a request reception unit that receives a certificate storing personal data, and an information request, from a client terminal; a verification unit that verifies the certificate; a request transmission unit that transmits the information request to an information provision device; a response reception unit that receives information from the information provision device; and a response transmission unit that transmits the information to the client terminal.

Description

Information processing device and communication method

[0001] The present invention relates to content distribution techniques that emphasize SSI.

[0002] In recent years, technology related to self-sovereign identity (SSI) has been attracting attention.

[0003] When realizing a content distribution service or the like that places importance on SSI, users manage their own identity information and selectively disclose only necessary information to the service provider.

[0004] "Decentralized Identifiers (DIDs) v1.0," W3C Recommendation, 19 July 2022 https: / / www.w3.org / TR / did-core / "Verifiable Credentials Data Model v1.1," W3C Recommendation, 03 March 2022 https: / / www.w3.org / TR / vc-data-model /

[0005] SSI is realized by verifiable credentials (VC), which is a collection of personal information and acts as a certificate, and a decentralized identifier (DID). For example, a content provider provides content by verifying the VC presented by a user (client).

[0006] However, there are various VC methods, and it is difficult for content providers to have a verification system that supports all of them. Note that this issue is not limited to content distribution services, and can arise in various information provision services.

[0007] The present invention has been made in consideration of the above points, and aims to provide a technology that enables information providers to provide information based on verified VCs without verifying the VCs.

[0008] According to the disclosed technology, an information processing device is provided that includes a request receiving unit that receives a certificate storing personal data and an information request from a client terminal, a verification unit that verifies the certificate, a request sending unit that sends an information request to an information providing device, a response receiving unit that receives information from the information providing device, and a response sending unit that sends the information to the client terminal.

[0009] According to the disclosed technology, a technology is provided that enables an information provider to provide information based on a verified VC without verifying the VC.

[0010] FIG. 1 is a diagram showing an example of the configuration of a content distribution system. FIG. 2 is a diagram showing an example of the configuration of an SSI-oriented communication system. FIG. 3 is a diagram for explaining the problem. FIG. 4 is a diagram showing an example of the configuration of a communication system in an embodiment of the present invention. FIG. 5 is a sequence diagram showing the operation of the communication system. FIG. 6 is a diagram showing the configuration of a gateway device. FIG. 7 is a diagram showing an example of a content provider registration table. FIG. 8 is a diagram showing an example of a routing table. FIG. 9 is a diagram showing an example of a content transfer table. FIG. 10 is a diagram showing an example of the hardware configuration of a device.

[0011] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applied is not limited to the following embodiment.

[0012] In this embodiment, a content distribution service is described as an example of a service that places importance on SSI, but the technology according to the present invention is applicable to various services other than content distribution services. The content server 300 described below is an example of an information providing device, and the content provided by the content server 300 is an example of information provided by an information providing device. The gateway device 100 described below is an example of an information processing device.

[0013] (Regarding Prior Art) Fig. 1 shows an example of the configuration of a conventional, general communication system for content distribution. As shown in Fig. 1, this communication system includes a client terminal 1 (which may also be called a user terminal), a content server 2, and a content DB 3. The content DB 3 stores various types of content such as video content and 3D content, and the content server 2 can acquire various types of content from the content DB 3.

[0014] The content server 2 manages user identity information (which may also be called attribute information). For example, the content server 2 collects user information based on the user's activity, etc., and manages the identity information obtained by profiling.

[0015] 1 , in S1 (step 1), the client terminal 1 notifies the content server 2 of its identity by transmitting an identifier such as a cookie to the content server 2. The content server 2 acquires content (personalized content) for the user based on the user's identity information, and in S2, distributes the content for the user to the client terminal 1.

[0016] An example of the configuration of an SSI-oriented communication system based on the prior art is shown in Fig. 2. As shown in Fig. 2, this communication system includes a client terminal 1, a content server 2, a content DB 3, and a wallet device 4.

[0017] The wallet device 4 is a device that manages identity information of the user of the client terminal 1. The wallet device 4 may also be called a digital identity wallet.

[0018] In S1, the client terminal 1 selects only necessary information from the identity information managed by the wallet device 4 and transmits the selected identity information to the content server 2. In S2, the content server 2 acquires content for the user based on the received identity information and distributes the content for the user to the client terminal 1.

[0019] (About VC and DID) In ​​the world of SSI, there are three parties: Holder, Issuer, and Verifier. A Holder is a user who manages / holds their own digital identity. An Issuer certifies attribute information and qualification information for a user and issues a VC (verifiable credentials). A Verifier requests a VC from a Holder that includes the user's identity information required to provide a service, and by receiving it, verifies the Holder's attributes, qualifications, etc. and makes decisions about providing services.

[0020] The VC is signed data that stores a collection of personal information and plays the role of a certificate. The VC may also be called a "certificate that stores personal data" or a "verifiable credential." Note that the "certificate that stores personal data" is not limited to the VC.

[0021] The VC includes the issuer's DID (Decentralized Identifiers) and electronic signature, and by using information registered in a distributed ledger (such as a blockchain), it is possible to verify these without inquiring about the issuer.

[0022] DID is a personal sovereign digital identity. DID is created and managed by the holder himself / herself and registered on a distributed ledger. DID is made public on a distributed ledger, so it is accessible to anyone but difficult to tamper with. The means by which DID is made public (distributed ledger, etc.) is called the DID method.

[0023] (VC use case) In the current SSI world, the service (Verifier) ​​requests a VC containing the identity information it wishes to collect from the user (Holder), and if the user agrees (approves) to the provision, the VC is provided to the service.

[0024] Use cases for VC include vaccination certificates that prove that you have received a COVID-19 vaccine, graduation certificates that show that you have graduated from university, etc. Here, we will explain an example of using VC as a vaccination certificate.

[0025] With the traditional paper method that does not use VC, it is unclear whether the handwritten signature on the vaccination certificate is genuine, and there is a possibility that the vaccination certificate will not be accepted at some service counters (airlines, food and beverage, etc.).

[0026] On the other hand, by using a vaccination certificate standardized by VC, service providers can fairly decide whether to accept vaccination certificates.

[0027] In the above example, there are many issuers (hospitals, etc.) of vaccination certificates, and there are also many verifiers (service providers).

[0028] As mentioned above, when providing a service by verifying VC, the relationship between VC issuers and verifiers is many-to-many. Therefore, interoperability is required for issuing and verifying VC. (Challenges) As with cryptographic algorithms, there are multiple methods (types) of VC, and it is difficult for each service provider to have a verification system that can handle all of them and to build a service.

[0029] Furthermore, there are various DID methods for disclosing DIDs, making it difficult for service providers to determine which DID method to use to verify the DID in a specific user's VC.

[0030] An image of the above problem is shown in Figure 3. In Figure 3, there are client terminals 200-1 to 200-3, a content server 300-1 of content provider 1, and a content server 300-2 of content provider 2. There are also blockchain A and blockchain B as DID methods.

[0031] Client terminals 200-1 to 200-3 present type 1 VC, type 2 VC, and type 3 VC to content server 300-1 and content server 300-2, respectively.

[0032] However, content server 300-1 cannot verify the VC because it does not support type 3 VC, and content server 300-2 cannot verify the VC because it does not support type 1 VC.

[0033] Furthermore, content server 300-1 can resolve DIDs for each VC when it accesses blockchain A, but cannot resolve DIDs when it accesses blockchain B. Furthermore, content server 300-2 can resolve DIDs for each VC when it accesses blockchain B, but cannot resolve DIDs when it accesses blockchain A.

[0034] (Outline of the embodiment) The technology according to the embodiment will be described below. In the embodiment, a gateway device 100 is introduced to solve the above-mentioned problems. The gateway device 100 may be called a VC gateway. The gateway device 100 may also be called an information processing device.

[0035] An example of the configuration of a communication system according to this embodiment is shown in Fig. 4. As shown in Fig. 4, client terminals 200-1 to 200-3 are connected to gateway device 100 via a communication network, and content servers 300-1 and 300-2 are also connected to gateway device 100 via the communication network. Each client terminal 200 has a wallet device.

[0036] Note that content server 300-1 and content server 300-2 are provided by content providers, and content server 300-1 and content server 300-2 may each be referred to as a "content provider." Furthermore, when "content provider 400" is mentioned separately from content server 300, "content provider 400" specifically refers to a terminal or the like at the content provider.

[0037] As shown in FIG. 4, the gateway device 100 is located between the client terminal 200 and the content server 300 .

[0038] The gateway device 100 verifies the VC sent from the client terminal 200, selects a content server 300 (content provider) to connect to based on the verification result of the VC, obtains content from the content server 300, and transmits the content to the client terminal 200.

[0039] That is, the gateway device 100 is a device that performs routing by VC verification, and performs access control between the client terminal 200 and the content server 300 .

[0040] (Processing Sequence) An example of a processing sequence of the communication system according to this embodiment will be described with reference to FIG.

[0041] The processing sequence can be roughly divided into the following three stages.

[0042] (1) Content distribution by a content provider and gateway device configuration. (2) Access to content by a client terminal. (3) Collection of statistical information by a content provider. The processing sequence will be explained below based on the above classification.

[0043] <(1) S1 to S2> In S1, the content provider 400 deploys content on the content server 300.

[0044] In S2, the content provider 400 configures the gateway device 100. Specifically, the content provider 400 configures and registers the profile of the content provider 400, the conditions for providing the content, and the like in the gateway device 100. Specific examples of the configuration information will be described later.

[0045] <(2) S3 to S8> In S3, the client terminal 200 transmits a content request with a VC to the waitlist device 100.

[0046] In S4, the gateway device 100 verifies the VC. If the gateway device 100 successfully verifies the VC, it selects the content server 300 to which the content request is to be sent based on the VC verification result. Specifically, as will be described later, it selects the content server 300 to which the content request is to be sent based on the attribute value in the verified VC. Here, it is assumed that the content server 300 shown in FIG. 5 is selected.

[0047] In S5, the gateway device 100 transmits (routes) the content request to the content server 300.

[0048] In S6, the content server 300 transmits the content requested by the content request to the gateway device 100.

[0049] When the gateway device 100 receives the content from the content server 300, it assigns a VC to the content in S7, and in S8 transmits the content with the VC assigned to the client terminal 200. Note that it is also possible not to assign a VC.

[0050] <(3) S9 to S10> In S9, the content provider 400 requests statistical information from the gateway device 100. In S10, the gateway device 100 transmits the statistical information to the content provider.

[0051] The statistical information is, for example, statistical information about the contents of the VC, such as statistical information about age, nationality, or sex.

[0052] Although the statistical information providing function is an additional function rather than a basic function of the gateway device 100, the collection of information such as statistical information on age is considered to be valuable for the content provider 400.

[0053] (Configuration example and functional overview of gateway device 100) Fig. 6 shows a functional configuration example of the gateway device 100. As shown in Fig. 6, the gateway device 100 includes a VC verification unit 110, a routing table 120, a content provider registration unit 130, a content request reception unit 140, a content response transmission unit 150, a content request transmission unit 160, a content response reception unit 170, and a content transfer unit 180.

[0054] The VC verification unit 110, the content request transmission unit 160, the content request reception unit 140, the content response reception unit 170, and the content response transmission unit 150 may also be referred to as the verification unit, the request transmission unit, the request reception unit, the response reception unit, and the response transmission unit, respectively.

[0055] The functions of the components shown in FIG. 6 are as follows:

[0056] The content provider registration unit 130 holds a table, receives the profile of the content provider 400, the conditions for providing content, etc. from the content provider 400, and registers them in the table. The content provider registration unit 130 also sets up the routing table 120 using the information received from the content provider 400.

[0057] The content request receiving unit 140 receives a content request with a VC from the client terminal 200. The VC verifying unit 110 verifies the VC received from the client terminal 200.

[0058] The routing table 120 stores information necessary for routing. The content request sending unit 160 sends a content request to the content server 300 based on the information in the routing table 120.

[0059] The content response receiving unit 170 receives content from the content server 300. The content transferring unit 180 determines a transfer destination of the content and passes the content together with client information (such as an IP address) to the content response transmitting unit 150. The content response transmitting unit 150 transmits the content to the client terminal 200.

[0060] The content provider registration unit 130 may receive a statistical information request and transmit the statistical information.

[0061] (VC and VC Verification) The VC used in this embodiment is, for example, the VC specified in "https: / / www.w3.org / TR / vc-data-model-2.0 / ".

[0062] Furthermore, there are various methods based on the proof of the VC (such as a digital signature by the issuer) for the VC verification performed by the VC verification unit 110. Examples of VC verification methods are listed below.

[0063] ・JSON Web Tokens with JSON Web Signatures (https: / / datatracker.ietf.org / doc / html / rfc7515) ・JSON-LD proofs (https: / / www.w3.org / TR / json-ld / ) ・AnonCreds (https: / / hyperledger.github.io / anoncreds-spec / ) Many JWT (JSON Web Token) format VCs have also been proposed. Therefore, it is expected that VCs can be presented by adding them to the value of a Custom Header or the query string of a URL.

[0064] An example of a VC verification method will now be described. For example, the verification method assuming verification of a VC in the W3C DID / VC / VP format is outlined below.

[0065] The VC verification unit 110 uses the DID Method to obtain the DID Document (public key) corresponding to the issuer's DID and the DID Document (public key) corresponding to the client's DID from the DID of the issuer and the DID of the client (Holder) included in the VP / VC. The VC verification unit 110 verifies that the VP Holder signature and the VC Issuer signature are signatures made with private keys linked to those public keys (validity of the signatures, no tampering with the messages). The VC verification unit 110 also obtains validity information / revocation information for the VC and verifies that the VC is valid.

[0066] (Details of Routing Process and Table) The gateway device 100 acts as a proxy between the client terminal 200 and the content server 300. The routing of messages / contents by the gateway device 100 is routing on L7.

[0067] Based on the verified content of the VC, the gateway device 100 issues a request to the content server 300. The request may vary depending on the content of the VC.

[0068] In response to this request, the content server 300 returns the content, and the gateway device 100, acting as a proxy, transfers the content to the client terminal 200.

[0069] Fig. 7 shows an example of a table held by the content provider registration unit 130. As shown in Fig. 7, the table of the content provider registration unit 130 has a content provider ID, a content provider URL, a content server URL, and a VC attribute value condition expression.

[0070] The content provider registration unit 130 of the gateway device 100 receives gateway setting information (information constituting the above table) from the content provider 400 and registers the information in the table. The content provider registration unit 130 also registers information in the routing table 120 described below.

[0071] An example of the routing table 120 is shown in Fig. 8. As shown in Fig. 8, the routing table 120 has a VC attribute value condition expression and a content server URL. The content request sending unit 160 refers to the routing table 120 to send a content request to the content server 300 having a URL that corresponds to the attribute value described in the VC verified by the VC verification unit 110. The VC attribute value condition expression will be described below.

[0072] When a certain attribute value in a VC presented by a client terminal 200 satisfies a condition set by a content provider, the gateway device 100 accesses a content server URL that corresponds to the condition and acquires the content. For example, if there is a VC with an attribute indicating age, the gateway device 100 performs an operation such that if the attribute value is "20 years old or older," it acquires content A, and if the attribute value is "under 20 years old," it acquires content B.

[0073] The VC attribute value condition expression is an expression that indicates the above condition. For example, suppose the part related to the attribute value of the VC contains the content ".... credentialSubject: {age: 35,nationality: Japan,....},...". In this case, an example of the VC attribute value condition expression is "$.credentialSubject.age >= 20". This condition indicates that "age must be 20 years or older", and if the attribute value indicated in the above VC = 35 years old, this condition is met.

[0074] The VC attribute value condition expression may be a combination of multiple conditions, such as "$.credentialSubject.age >= 20 && $.credentialSubject.nationality == Japan".

[0075] The content transfer unit 180 may hold a table for managing sessions. An example of this table is shown in FIG. 9. The table shown in FIG. 9 is a table that is referenced to transfer content from the content server 300, and includes a session ID, a corresponding VC, and client information (such as an IP address). The content transfer unit 180 references this table and instructs the content response transmission unit 150 to transmit content to a destination indicated by the client information (such as an IP address) corresponding to the VC that was added to the content request received from the client terminal 200.

[0076] (Hardware Configuration Example) Any of the devices described in this embodiment (gateway device, information processing device, client terminal, content server, content provider terminal, etc.) can be realized by, for example, running a program on a computer. This computer may be a physical computer or a virtual machine on the cloud.

[0077] That is, the device can be realized by executing a program corresponding to the processing performed by the device using hardware resources such as a CPU and memory built into a computer. The program can be recorded on a computer-readable recording medium (such as a portable memory) and stored or distributed. The program can also be provided via a network such as the Internet or email.

[0078] Fig. 10 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 10 includes a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, and the like, all of which are interconnected via a bus B. The computer may further include a GPU.

[0079] The program that realizes the processing on the computer is provided by a recording medium 1001, such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

[0080] The memory device 1003 reads and stores a program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes functions related to the device in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network, etc. The display device 1006 displays a GUI (Graphical User Interface) or the like according to the program. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, etc., and is used to input various operation instructions. The output device 1008 outputs the results of calculations.

[0081] (Effects of the embodiment, etc.) As explained above, the technology explained in this embodiment provides a gateway device between the client terminal and the content server / content provider, eliminating the need for content providers to build VC verification mechanisms that accommodate various projects. This increases the range of content providers that can be accessed by client terminals. Furthermore, the technology according to this embodiment has the following significance.

[0082] In the early days of services using verifiable credentials (VC), many content providers lacked the know-how and skills to verify VC. For this reason, for example, equipping a content distribution platform (such as a cloud) with a gateway device and having a mechanism for verifying VC would be an added value to the platform. In many clouds, Application Load Balancers perform routing based on HTTP request headers and URLs, and it is conceivable that similar services for VC will become widespread.

[0083] The following additional notes are provided regarding the above-described embodiments.

[0084] <Additional Notes> (Additional Item 1) An information processing device comprising: a request receiving unit that receives a certificate storing personal data and an information request from a client terminal, a verification unit that verifies the certificate, a request sending unit that sends the information request to an information providing device, a response receiving unit that receives information from the information providing device, and a response sending unit that sends the information to the client terminal. (Additional Item 2) The information processing device according to Additional Item 1, wherein the request sending unit determines the information providing device to which the information request is to be sent based on content of the certificate verified by the verification unit. (Additional Item 3) The information processing device according to Additional Item 1 or 2, wherein the request sending unit determines the information providing device to which the information request is to be sent based on setting information set by a business operator that provides the information. (Addendum 4) A communication method executed by an information processing device, comprising: a request receiving step of receiving a certificate storing personal data and an information request from a client terminal; a verification step of verifying the certificate; a request sending step of sending an information request to an information providing device; a response receiving step of receiving information from the information providing device; and a response sending step of sending the information to the client terminal.

[0085] Although the present embodiment has been described above, the present invention is not limited to such a specific embodiment, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims.

[0086] REFERENCE SIGNS LIST 100 Gateway device 110 VC verification unit 120 Routing table 130 Content business registration unit 140 Content request reception unit 150 Content response transmission unit 160 Content request transmission unit 170 Content response reception unit 180 Content transfer unit 200 Client terminal 300 Content server 400 Content business 1000 Drive device 1001 Recording medium 1002 Auxiliary storage device 1003 Memory device 1004 CPU 1005 Interface device 1006 Display device 1007 Input device 1008 Output device

Claims

1. An information processing device comprising: a request receiving unit that receives a certificate storing personal data and an information request from a client terminal; a verification unit that verifies the certificate; a request sending unit that sends an information request to an information providing device; a response receiving unit that receives information from the information providing device; and a response sending unit that sends the information to the client terminal.

2. The information processing device according to claim 1, wherein said request transmission unit determines said information providing device to which an information request is to be sent based on the contents of said certificate verified by said verification unit.

3. The information processing device according to claim 1 or 2, wherein the request sending unit determines the information providing device to which the information request is to be sent based on setting information set by a business providing the information.

4. A communication method executed by an information processing device, comprising: a request receiving step of receiving a certificate storing personal data and an information request from a client terminal; a verification step of verifying the certificate; a request sending step of sending an information request to an information providing device; a response receiving step of receiving information from the information providing device; and a response sending step of sending the information to the client terminal.

Images