User data exchange system

Abstract

To more securely exchange personal information between a data provider (DP) and a data consumer (DC).SOLUTION: An information processing apparatus transmits a first identifier in response to a user identifier issuance request transmitted from a DC, transmits a second identifier in response to a user identifier issuance request transmitted from a DP, receives, from the DC, a ticket issuance request including information for specifying user data requested by the DC, the first identifier, and the DP of a request destination, issues a data request ticket corresponding to the ticket issuance request, transmits a ticket identifier of the issued data request ticket to the DC, and transmits the data request ticket corresponding to the ticket identifier to the DP when receiving the ticket identifier from the DP. Here, the ticket issuance request includes the first identifier, and the data request ticket transmitted to the DP includes the second identifier corresponding to the first identifier.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates to a user data exchange system. [Background technology]

[0002] Patent Document 1 discloses an electronic commerce system that enables the purchase and sale of goods without the need for the purchaser to transmit personal information to the seller. Specifically, when a proxy server acts as a proxy for a client's access to a product information providing server, it transmits a user ID to the product information providing server. When the product information providing server receives a product purchase instruction, it transmits the product ID and user ID to the proxy server. The proxy server then derives delivery address information based on the user ID and transmits the product ID and delivery address information to a delivery management server. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2003-233729 Summary of the Invention [Problem to be solved by the invention]

[0004] One aspect of the present disclosure aims to provide a technology that enables the exchange of personal information between a data provider and a data consumer to be realized more securely. [Means for solving the problem]

[0005] One aspect of the present disclosure is a user data exchange system including a data consumer, a data provider, and a platform, which mediates exchange of user data between the data consumer and the data provider, the data consumer transmits a first identifier issuance request to the platform to request issuance of a user identifier; the platform generates a first identifier in response to receiving the first identifier issuance request, transmits the first identifier to the data consumer, and stores the first identifier in association with a third identifier that identifies the user; The data consumer stores a first user ID and the first identifier in association with each other; the data provider transmits a second identifier issuance request to the platform provider requesting issuance of a user identifier; the platform generates a second identifier in response to receiving the second identifier issuance request, transmits the second identifier to the data provider, and stores the second identifier and the third identifier in association with each other; The data provider stores the second user ID and the second identifier in association with each other; the data consumer sends a ticket issuance request to the platformer, the ticket issuance request including information identifying the requested user data, the first identifier corresponding to the first user ID, and information identifying the data provider from which the user data is requested; In response to receiving the ticket issuance request, the platform generates a data request ticket including a ticket identifier, the third identifier corresponding to the first identifier, information identifying the user data, and information identifying the data provider to which the request is made, and sends the ticket identifier to the data consumer; the data consumer sends a data retrieval request including the ticket identifier to the data provider; The data provider sends a ticket reference request to the platformer, the ticket reference request including the ticket identifier included in the data acquisition request; the platform identifies a data request ticket corresponding to the ticket identifier included in the ticket reference request, and transmits information identifying the user data and the second identifier corresponding to the third identifier to the data provider; the data provider sends the requested user data for the user of the second user ID corresponding to the second identifier to the data consumer; At least one of the data consumer and the data provider does not hold account information of the user, and uses an identifier issued after the user is authenticated by an ID provider as the first user ID or the second user ID. The user data exchange system is characterized by the above.

[0006] One aspect of the present disclosure is A user data exchange system including a data consumer, a data provider, a platform, a first ID provider, and a second ID provider, the system mediating exchange of user data between the data consumer and the data provider, the first ID provider stores a first user ID of the user; the second ID provider stores a second user ID of the user; the data consumer transmits, via the first ID provider, a first identifier issuance request including the first user ID to the platform, requesting issuance of a user identifier; the platform generates a first identifier in response to receiving the first identifier issuance request, transmits the first identifier to the first ID provider, and stores the first identifier in association with a third identifier that identifies the user; the first ID provider stores the first user ID and the first identifier in association with each other; the data provider transmits, via the second ID provider, a second identifier issuance request including the second user ID to the platform provider, requesting issuance of a user identifier; the platform generates a second identifier in response to receiving the second identifier issuance request, transmits the second identifier to the second ID provider, and stores the second identifier and the third identifier in association with each other; the second ID provider stores the second user ID and the second identifier in association with each other; the data consumer sends a first ticket issuance request to the first ID provider, the first ticket issuance request including information identifying the requested user data, the first user ID, and information identifying a data provider from which the user data is requested; In response to receiving the first ticket issuance request, the first ID provider sends a second ticket issuance request to the platform, the second ticket issuance request including information identifying the requested user data, the first identifier corresponding to the first user ID, and information identifying a data provider from which the user data is requested; In response to receiving the second ticket issuance request, the platform generates a data request ticket including a ticket identifier, the third identifier corresponding to the first identifier, information identifying the user data, and information identifying the data provider to which the request is made, and sends the ticket identifier to the data consumer via the first ID provider; the data consumer sends a data retrieval request including the ticket identifier to the data provider; The data provider sends a ticket reference request including the ticket identifier included in the data acquisition request to the platform via the second ID provider or directly; In response to receiving the ticket reference request, the platform identifying a data request ticket corresponding to the ticket identifier included in the data verification request, and transmitting information identifying the user data and the second identifier corresponding to the third identifier to the data consumer via the second ID provider or directly; the data provider transmitting to the data consumer the requested user data relating to the user of the second user ID corresponding to the second identifier; The user data exchange system is characterized by the above. [Effects of the Invention]

[0007] According to aspects of the present disclosure, the exchange of personal information between data providers and data consumers can be achieved securely. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a diagram showing a schematic configuration of a data exchange system according to an embodiment; [Figure 2] FIG. 4 is a diagram illustrating an example of an ID correspondence table held by each device in an embodiment. [Figure 3] FIG. 4 is a sequence diagram showing a data exchange process in the first embodiment. [Figure 4] FIG. 10 is a sequence diagram showing a dummy ID issuing process in the first embodiment. [Figure 5] FIG. 10 is a sequence diagram showing a dummy ID issuing process in the second embodiment. [Figure 6] FIG. 10 is a sequence diagram showing a data exchange process in the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] As the value of data has become widely known, many services are accumulating user data. It is common for user data holders to provide data APIs as data providers in order to provide user data to data consumers.

[0010] In such a data exchange system, billing arbitration and prevention of name aggregation become issues. In this embodiment, a platform provider mediates data exchange between a data provider and a data consumer, and the above issues are solved by a novel mediation method.

[0011] In this disclosure, platform provider, data provider, and data consumer are all terms that refer to devices, not businesses or individuals. Also, in this disclosure, platform provider may be referred to as PF, data provider as DP, and data consumer as DC.

[0012] Among DPs and DCs, there are some in which the service provider does not hold user account information itself, but relies on an ID provider (IdP) to manage account information and authenticate users. An example of this is a service that requires you to select a Google account when you try to log in to the service. A service that relies on an IdP is called a Relying Party (RP) in the OpenID Connect standard and a Service Provider in the SAML standard. In the following, we will refer to a service that relies on an IdP as an RP, although we do not intend to limit it to a specific standard.

[0013] This disclosure proposes a method for mediating data exchange between a DP and a DC when the DP or DC is an RP.

[0014] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. The configurations of the following embodiments are examples, and the present disclosure is not limited to the configurations of the embodiments.

[0015] First Embodiment (System Configuration) 1 is a diagram showing the configuration of a data exchange system according to one embodiment. The data exchange system has a configuration in which a platform provider (PF) 100, a data consumer (DC) 200, a data provider (DP) 300, and an ID provider (IdP) 400 are connected to each other via a network N so that they can communicate with each other.

[0016] PF100 is a computer (information processing device) having CPU 101, memory 102, and communication device 103. Memory 102 stores programs executable by CPU 101. When CPU 101 executes the programs, PF100 functions as a dummy ID issuing unit 110, an ID correspondence table storage unit 120, a user ID conversion unit 130, a ticket issuance management unit 140, and a ticket DB 150.

[0017] The DC 200 is a computer (information processing device) having a CPU 201, a memory 202, and a communication device 203. The memory 202 stores a program executable by the CPU 201. When the CPU 201 executes the program, the DC 200 functions as an ID federation request unit 210, a ticket request unit 220, a data request unit 230, and an ID correspondence table storage unit 240.

[0018] The DP 300 is a computer (information processing device) having a CPU 301, a memory 302, and a communication device 303. The memory 302 stores a program executable by the CPU 301. When the CPU 301 executes the program, the DP 300 functions as an ID federation request unit 310, a ticket request unit 320, a data providing unit 330, and an ID correspondence table storage unit 340.

[0019] IdP400 is a computer (information processing device) having a CPU 401, a memory 402, and a communication device 403. The memory 402 stores a program that can be executed by the CPU 401. When the CPU 401 executes the program, IdP400 functions as an ID federation request unit 410, a data exchange relay unit 420, and an ID correspondence table storage unit 440.

[0020] The details of each of the above functional units will be explained in detail later with reference to other drawings. Note that some or all of the above functional units may be realized by dedicated circuits or devices.

[0021] The network N is a network configured from a wired communication network and / or a wireless communication network, and the communication device 103, the communication device 203, the communication device 303, and the communication device 403 can communicate with each other via the network N.

[0022] (ID correspondence table) 2A to 2D are diagrams showing examples of ID correspondence tables held by the PF100, DC200, DP300, and IdP400, respectively. In these tables, the DC200 and DP300 are RPs, and do not retain user account information themselves. Instead, they use a unique identifier (e.g., a Subject ID) issued by the IdP400 after the user is authenticated by the IdP400 as the user's ID. Here, it is assumed that the user has an account named IdP_A with the IdP400, and the unique identifier issued from the IdP400 to the DC200 is IdP_DC_A, and the unique identifier issued from the IdP400 to the DP300 is IdP_DP_A. The PF100 also assigns and manages a user ID named PF_A1 to this user. Hereinafter, the user IDs used by the PF100, DC200, and DP300 are referred to as the PF user ID, DC user ID, and DP user ID, respectively.

[0023] 2(A), the PF 100 issues a DC dummy ID 122 and a DP dummy ID 123 for one PF user ID 121 and manages them in association with each other. Therefore, the user ID conversion unit 130 can convert a PF user ID (third identifier), a DC dummy ID (first identifier), and a DP dummy ID (second identifier) ​​into one another by referring to the ID correspondence table 120.

[0024] 2(B), the DC 200 manages a DC user ID 241 in association with a DC dummy ID 242 issued to the user by the PF 100. Therefore, the DC 200 can convert a DC user ID and a DC dummy ID (first identifier) ​​to each other. Note that a unique identifier issued by the IdP 400 is used for the DC user ID.

[0025] As shown in Fig. 2(C), the DP 300 manages a DP user ID 341 in association with a DP dummy ID 342 issued to the user by the PF 100. Therefore, the DP 300 can convert between a DP user ID and a DP dummy ID (second identifier). Note that a unique identifier issued by the IdP 400 is used for the DP user ID.

[0026] 2(D), the ID correspondence table 440 of the IdP 400 may include two tables 440A and 440B, but in the first embodiment, only the table 440A is required. The table 440A manages the IdP user ID 441 and the unique identifier (referred to as an assigned ID) 442 assigned to the RP (DC 200 and DP 300) in association with each other.

[0027] In the example shown in Figures 2(A) to 2(D), specifically, PF100 issues a dummy ID called PF_XX for DC200 to a user called PF_A1, and issues a dummy ID called PF_ZZ for DP300, and stores these in association with each other. DC200 associates the user ID called IdP_DC_A with the dummy ID for DC called PF_XX and stores them. DP300 associates the user ID called IdP_DP_A with the dummy ID for DP called PF_ZZ and stores them in association with each other.

[0028] When the PF100 receives a dummy ID for DC from the DC200, it can obtain the dummy ID for DP of the user and notify the DP300. By having such an ID correspondence table in each device, it becomes possible to identify a user between the DC200 and the DP300 via the PF100, without any of the devices knowing the user ID for other services. Note that the PF100 may store only the correspondence relationship between the dummy ID for DC and the dummy ID for DP, without using the PF user ID.

[0029] The dummy ID is issued in cooperation with the dummy ID issuing unit 110, the ID federation request unit 210, and the ID federation request unit 310. Details of this dummy ID issuing process will be described later with reference to FIG.

[0030] (Data exchange process) Figure 3 is a sequence diagram showing the flow of user data exchange processing between DC200 and DP300 via PF100. Here, it is assumed that the dummy ID issuance processing has been completed and that PF100, DC200, and DP300 each hold the ID correspondence tables shown in Figures 2(A) to 2(C). It is also assumed that the user has completed authentication processing in DC200 and that DC200 knows that the user's user ID is DC_A.

[0031] In step S10, the user accesses the DC 200 using a user terminal. The C200 requests to acquire a certain type of user data from the DP 300. Here, the user terminal provides the DC 200 with an identifier (DP_ID) of the DP 300 that provides the data, and an identifier (data ID) that identifies the requested user data.

[0032] In step S11, the ticket request unit 220 of the DC200 requests the PF100 to issue a data request ticket to be used for user data exchange between the DC200 and the DP300. Here, the ticket issuance request includes a DC dummy ID, an identifier (DC_ID) of the DC200, an identifier (DP_ID) of the DP300 that is the data request destination, and a data ID. The DC dummy ID is obtained by the ticket request unit 220 referencing the ID correspondence table storage unit 240 and acquiring a dummy ID that corresponds to the DC user ID. Here, the dummy ID "PF_XX" that corresponds to the DC user ID "IdP_DC_A" is acquired. Furthermore, the IdP_DC_ID is an ID that the DC200 receives from the IdP400 and is therefore known, and the DP_ID and data ID have been notified from the user terminal.

[0033] In step S12, in response to receiving the ticket issuance request, the ticket issuance management unit 140 of the PF 100 issues a data request ticket and stores information about the ticket in the ticket DB 150. The data request ticket includes a ticket ID, a PF user ID, the DC_ID of the data requester, the DP_ID of the data request destination, a data ID that identifies the requested data, and the ticket status. Here, the PF user ID can be obtained by the user ID conversion unit 130 from the DC dummy ID notified by the DC 200 and the ID correspondence table 120. Here, the PF user ID "PF_A1" that corresponds to the DC dummy ID "PF_XX" is obtained.

[0034] In step S13, the ticket issuance management unit 140 of the PF 100 transmits the ticket ID of the issued data request ticket to the DC 200.

[0035] In step S14, the data request unit 230 of the DC 200 transmits a data acquisition request to the DP 300. Specifically, the data request unit 230 transmits to the DP 300 a data acquisition request including the ticket ID transmitted from the PF 100 in step S13.

[0036] In step S15, the ticket request unit 320 of the DP 300 transmits the DP_ID and the ticket ID to the PF 300, requesting details of the data request ticket.

[0037] In step S16, the ticket issuance management unit 140 of the PF 100 obtains detailed information about the data request ticket corresponding to the received ticket ID from the ticket DB 150 and transmits the information to the DP 300. At this time, the ticket issuance management unit 140 replaces the PF user ID included in the data request ticket with a DP dummy ID using the user ID conversion unit 130, and then transmits the detailed information about the data request ticket. Specifically, the PF user ID "PF_A1" is replaced with the DP dummy ID "PF_ZZ". Finally, the ticket issuance management unit 140 transmits to the PF 300 the data ID included in the requested ticket and the DP dummy ID corresponding to the PF user ID. Here, the ticket issuance management unit 140 transitions the state of the ticket as the ticket is referenced by the DP 300.

[0038] In step S17, the data providing unit 330 of the DP 300 refers to the detailed information of the data request ticket and determines whether the requested user data can be provided to the DC 200. The determination result is either whether the data can be provided or not, that is, whether the data request ticket is accepted or rejected. The data providing unit 330 transmits this determination result to the PF 100. The ticket issuance management unit 140 of the PF 100 transitions the state of the ticket depending on whether the DP 300 accepts or rejects the ticket.

[0039] Steps S18 and onward are performed when the DP 300 accepts the ticket. In step S18, the data providing unit 330 of the DP 300 transmits the user data specified in the data request ticket to the DC 200. In the data request ticket, the user is indicated by a DP dummy ID, but the DP 300 can obtain the corresponding DP user ID by referring to the ID correspondence table 340, and can identify which user's user data is being requested. Specifically, it can be identified that the DP dummy ID "PF_ZZ" is the DP user ID "IdP_DP_A".

[0040] In step S19, when the data request unit 230 of the DC 200 receives the user data from the DP 300, it determines whether to accept or reject the user data and transmits the determination result to the PF 100. The ticket issuance management unit 140 of the PF 100 transitions the state of the ticket in response to the DC 200's acceptance or rejection of the user data. If the DC 200 accepts the user data, the DC 200 executes processing using the user data. The type of processing to be executed is not particularly limited in the present disclosure.

[0041] Through the above process, user data can be exchanged without the DC200 knowing the user ID of the DP300, and the DP300 knowing the user ID of the DC200. Furthermore, the PF100 can mediate data exchange without holding the user data itself or the user IDs of the DC200 and DP300. For these reasons, secure data exchange is achieved.

[0042] (Dummy ID issuance process) The process of issuing a dummy ID will be described with reference to Fig. 4. As already mentioned, the DC 200 and the DP 300 do not hold user account information, but use an identifier (issued ID) issued after the user is authenticated by the IdP 400 as the DC user ID and the DP user ID. Note that the process of issuing a dummy ID described below, that is, the process of associating a unique user ID and a dummy ID in the PF 100, the DC 200, and the DP 300, is merely one specific example, and any other method may be used.

[0043] In step S20A, the user is authenticated by the DC200 using a user terminal. As the DC200, as an RP, relies on the IdP400 for user authentication, a user authentication request is forwarded to the IdP400. When the user is authenticated by the IdP400, in step S20B, the IdP400 notifies the DC200 that the authentication was successful and of the assigned ID (IdP_DC_ID). The DC200 uses the ID (IdP_DC_ID) assigned by the IdP400 as the user's DC user ID. When the user terminal requests the DC200 to start data linking processing in step S21, the ID federation request unit 210 of the DC200 requests the PF100 to issue a dummy ID in step S22. Here, the information transmitted from the DC200 to the PF100 is the DC identifier, and not the DC user ID. This dummy ID is a dummy ID for DC (first identifier), and the dummy ID issuance request corresponds to a first identifier issuance request.

[0044] In step S23, in response to the dummy ID issuance request from the DC 200, the dummy ID issuance unit 110 of the PF 100 generates a new PF user ID (third identifier) ​​and a dummy ID for DC (first identifier), associates them, and stores them in the ID correspondence table 120. The dummy ID issuance unit 110 also issues a new ID token, and manages them in association with the PF user ID and the dummy ID for DC. In step S24, the dummy ID issuance unit 110 transmits the issued dummy ID for DC and ID token to the DC 200. In step S25, the ID federation request unit 210 of the DC 200 associates the received dummy ID for DC with the DC user ID and stores it in the ID correspondence table 240. Note that the DC user ID here is D is the ID (IdP_DC_ID) issued by the IdP 400 .

[0045] In step S26, the user terminal transmits a data link request to the DC200, including the identifier of the DP300 that is the data link destination. In step S27, the DC200 redirects to the DP300, passing the ID token received in step S24. In step S28A, the user is authenticated by the DP300 using the user terminal. As the DP300, as an RP, relies on the IdP400 for user authentication, the user authentication request is forwarded to the IdP400. When the user is authenticated by the IdP400, in step S28B, the IdP400 notifies the DP300 that the authentication was successful and of the issued ID (IdP_DP_ID). The DP300 uses the ID (IdP_DP_ID) issued by the IdP400 as the user's DP user ID.

[0046] In step S29, the ID federation request unit 310 of the DP 300 requests the issuance of a dummy ID to the PF 100. Here, the DP 300 transmits the DP identifier and ID token to the PD 100, but does not transmit the DP user ID.

[0047] In step S30, in response to the dummy ID issuance request from the DC200, the dummy ID issuance unit 110 of the PF100 issues a new dummy ID for the DP, associates it with the PF user ID and the DC dummy ID, and stores it in the ID correspondence table 120. Note that the dummy ID issuance unit 110 can determine from the received ID token which PF user ID and DC dummy ID the issuance request for the DP is for. In step S31, the dummy ID issuance unit 110 transmits the issued dummy ID for the DP to the DP300. In step S32, the ID federation request unit 310 of the DP300 associates the received dummy ID for the DP with the DP user ID and stores it in the ID correspondence table 340. In step S33, the DP300 calls back to the DC200, and control of the user terminal returns to the DC200.

[0048] In this way, the issuance and sharing of dummy IDs for each user ID of PF 100, DC 200, and DP 300 is completed, as shown in Figures 2(A) to 2(C). At this time, the PF user ID, DC user ID, and DP user ID are not notified to other devices, so name identification that associates accounts can be prevented.

[0049] In the above explanation, both the DC 200 and the DP 300 act as RPs and rely on the IdP 400 for user authentication, but either the DC 200 or the DP 300 may hold user account information itself. In this case, the DC 200 or DP 300 that does not function as an RP uses a user ID that it manages instead of the ID (IdP_DC_ID or IdP_DP_ID) issued by the IdP 400.

[0050] In another embodiment, the PF 100 may generate the DC dummy ID and the DP dummy ID as ciphertexts obtained by encrypting the PF user ID using the encryption keys for the DC 200 and the DP 300. For example, the dummy ID issuance unit 110 may generate a new PF user ID in response to a new dummy ID issuance request from the DC, and generate a DC dummy ID (first identifier) ​​by encrypting the PF user ID using the DC encryption key (conversion process). Furthermore, the dummy ID issuance unit 110 may generate a DP user ID (second identifier) ​​in response to a dummy ID issuance request from the DP by encrypting the PF user ID identified by the ID token using the DP encryption key (conversion process). Furthermore, the user ID conversion unit 130 may obtain a DP user ID corresponding to the DC user ID by performing a decryption process (inverse conversion process) on the DC user ID using the DC encryption key, and then encrypting the DC user ID using the DP encryption key (conversion process). The same applies to conversion from a DP user ID to a DC user ID. In this way, the PF100 is a DC dummy It is possible to mutually convert between DC dummy IDs, DP dummy IDs, and PF user IDs without storing the IDs and DP dummy IDs. In this embodiment, on the premise that the secrecy of the encryption key is maintained, it is also possible to prevent leakage of the correspondence table between PF user IDs, DC user IDs, and DP user IDs.

[0051] Furthermore, the dummy ID issuing unit 110 may use the PF user ID (third identifier) ​​itself as the dummy ID for the DC (first identifier) ​​and the dummy ID for the DP (second identifier). In this example, although there is a disadvantage that direct data exchange without the mediation of the PF becomes possible when the DC and the DP collude, it is possible to exchange data securely between the DC and the DP.

[0052] (Advantageous Effects of the Present Embodiment) User data can be exchanged between the DC200 and the DP300 without knowing the user ID of the DC200. PF100 can also mediate data exchange without storing the user data itself or the user IDs of the DC200 and the DP300. For these reasons, secure data exchange is achieved. Furthermore, accounting and error handling processes can be performed based on the state management of the data request ticket.

[0053] <Modification of the first embodiment> A spoofing attack is possible where a malicious attacker provides a fake data provider and provides data from the fake data provider to a data consumer. Similarly, a spoofing attack is possible where a malicious attacker provides a fake data consumer and steals data from a data provider.

[0054] To prevent such attacks, when PF100 is requested to perform an ID federation operation by an RP (DC200 and DP300), client authentication, that is, verification that the RP is a client trusted by PF100, may be performed. To achieve client authentication, the RP needs to register information with PF100 to authenticate itself. However, if the RP has already registered authentication information with the IdP, registering separate authentication information can be a hassle for both the RP and the PF.

[0055] To eliminate this hassle, the IdP registers its own authentication information with the PF 100, and when the RP (DC and / or DP) performs an ID federation operation (sends a dummy ID issuance request) to the PF 100, the dummy ID issuance request includes the authentication information registered with the IdP and is sent to the PF 100. The PF 100 can verify the reliability of the RP by requesting an authenticated IdP to query the RP authentication information, and if authentication is successful, it sends dummy IDs (dummy ID for the DC and dummy ID for the DP) to the RP. In this way, a chain of trust can be constructed in which the PF trusts the RP, the IdP trusts the RP, and therefore the PF trusts the RP.

[0056] The authentication information registered in the IdP can be a signature with a client certificate, a client secret, or the like.

[0057] Second Embodiment In the first embodiment, the DC 200 and the DP 300 perform the ID federation process (a dummy ID issuance request to the PF 100 and conversion between the dummy ID and the user ID), but in this embodiment, the ID federation process is performed by the IdP 400. In the following, it is assumed that the IdP used by the DC 200 and the IdP used by the DP 300 are different entities, and the former will be referred to as IdP-A and the latter as IdP-B. IdP-A corresponds to the first ID provider, and IdP-B corresponds to the second ID provider.

[0058] In this embodiment, since IdP400 performs ID federation processing, ID correspondence table 440 of IdP400 includes table 440B that associates and manages assigned IDs 443 and dummy IDs 444. Note that in the example of Fig. 3(D) , both assigned IDs for DC and assigned IDs for DP are associated with dummy IDs in table 440B, but in reality, IdP-A and IdP-B each have one record of each of these.

[0059] The dummy ID issuing sequence in this embodiment will be described with reference to Fig. 5. The same processes as those in the first embodiment (Fig. 4) are given the same numbers and the description thereof will be omitted.

[0060] The processing in steps S20A and S20B is the same as in the first embodiment.

[0061] When the data linking process is started in step S21, the DC 200 requests the PF 100 via the IdP-A to issue a dummy ID for the DC. Specifically, in step S22A, the ID federation request unit 210 of the DC 200 requests the IdP-A to issue a dummy ID, and in step S22B, the ID federation request unit 410 of the IdP-A sends a dummy ID issuance request to the PF 100.

[0062] In step S23, in response to receiving the dummy ID issuance request, the dummy ID issuance unit 110 of the PF 100 generates a new PF user ID and a dummy ID for DC, associates them, and stores them in the ID correspondence table 120. The dummy ID issuance unit 110 also issues a new ID token and manages it in association with the PF user ID and the dummy ID for DC. In step S24, the dummy ID issuance unit 110 transmits the issued dummy ID for DC and ID token to IdP-A. In step S25, the ID federation request unit 410 of IdP-A associates the received dummy ID for DC with the DC user ID and stores it in the ID correspondence table 440B.

[0063] The processing in steps S26 to S28B is the same as in the first embodiment.

[0064] When authentication in the DP300 is successful and data linking processing is initiated, the DP300 requests the PF100 via the IdP-B to issue a dummy ID for the DP. Specifically, in step S29A, the ID federation request unit 310 of the DP300 requests the IdP400 to issue a dummy ID, and in step S29B, the ID federation request unit 410 of the IdP400 sends a dummy ID issuance request to the PF100. The dummy ID issuance request includes an ID token and a DP identifier.

[0065] In step S30, in response to the dummy ID issuance request from IdP-B, the dummy ID issuance unit 110 of the PF 100 issues a new dummy ID for the DP, associates it with the PF user ID and the dummy ID for the DP, and stores it in the ID correspondence table 120. Note that the dummy ID issuance unit 110 can determine from the received ID token which PF user ID and DC dummy ID the issuance request for the dummy ID for the DP is for.

[0066] In step S31, the dummy ID issuance unit 110 transmits the issued dummy ID for DP to IdP-B. In step S32, the ID federation request unit 410 of IdP-B associates the received dummy ID for DP with the DP user ID and stores it in the ID correspondence table 440B. In step S33, the DP300 calls back to the DC200, and control of the user terminal returns to the DC200.

[0067] In this example, both the DC 200 and the DP 300 entrust the ID federation process to the IdP 400, but either the DC 200 or the DP 300 may independently create an ID, as in the first embodiment. A linking process may be performed and the correspondence between the dummy ID and the DC user ID or the DP user ID may be stored in the ID correspondence table.

[0068] According to this embodiment, there is no need for the DC 200 or the DP 300 to implement an ID federation function, and it is sufficient for only the IdP 400 to implement the ID federation function. Therefore, it is easy to provide a new DC 200 or DP 300.

[0069] The data exchange process in this embodiment will be described with reference to Fig. 6. The same processes as those in the first embodiment (Fig. 3) are given the same numbers and the description thereof will be omitted.

[0070] When the user's consent to data linkage is obtained in step S10, in step S11A, the ticket request unit 220 of the DC 200 requests IdP-A to issue a data request ticket to be used for user data exchange between the DC 200 and the DP 300. The ticket issuance request includes the identifier (DC_ID) of the DC 200, the identifier (DP_ID) of the DP 300 to which the data is requested, and the data ID. In step S11B, the data exchange relay unit 420 of IdP-A requests the PF 100 to issue a data request ticket. At this time, IdP-A includes a DC dummy ID in the ticket issuance request. Since IdP-A knows which user the ticket issuance request is from, it can determine the DC dummy ID of that user by referring to the ID correspondence table 440B. The DC dummy ID is obtained by referring to the ID correspondence table storage unit 440 and acquiring the dummy ID corresponding to the DC user ID. Here, the dummy ID "PF_XX" corresponding to the DC user ID "IdP_DC_A" is acquired.

[0071] The process of issuing a data request ticket by the PF100 in step S12 is the same as in the first embodiment, but the PF100 transmits the ticket ID to the DC200 via the IdP-A (steps S13A and S13B). Note that the PF100 may transmit the ticket ID directly to the DC200 without going through the IdP-A.

[0072] In step S14, the data request unit 230 of the DC 200 transmits a data acquisition request to the DP 300. Specifically, the data request unit 230 transmits to the DP 300 a data acquisition request including the ticket ID transmitted from the PF 100 in step S13.

[0073] The ticket request unit 320 of the DP300 sends a ticket reference request including the ticket ID included in the data acquisition request to the PF100. Specifically, in step S15A, the ticket request unit 320 of the DP300 sends the DP_ID and ticket ID to the IdP-B to request details of the data request ticket. In step S15B, the IdP-B sends the DP_ID and ticket ID to the PF100 to request details of the data request ticket. Here, the DP300 sends the ticket reference request to the PF100 via the IdP-B, but it may also be sent directly to the PF100 without going through the IdP-B.

[0074] In step S16, the ticket issuance management unit 140 of the PF 100 acquires detailed information of the data request ticket corresponding to the received ticket ID from the ticket DB 150, and transmits it to the DP 300 via the IdP-B (steps S16A and S16B). At this time, the ticket issuance management unit 140 replaces the PF user ID included in the data request ticket with a dummy ID for DP using the user ID conversion unit 130, and then transmits the detailed information of the data request ticket. Specifically, the PF user ID "PF_A1" is replaced with a dummy ID for DP "PF_ZZ". Here, the ticket issuance management unit 140 transitions the state of the ticket as the ticket is referenced by the DP 300. Note that the PF 100 The detailed information of the ticket may be sent to the DP 300 without going through the IdP-B.

[0075] The processing from step 17 onwards is the same as in the first embodiment.

[0076] <Modification of the second embodiment> It is assumed that the DC200 and DP300 attempting to perform ID federation are RPs of the same IdP. In such a case, it is not possible to prevent name matching. This is because both the DC200 and the DP300 entrust the ID federation operation of a specific user to the same IdP, and this IdP can determine that the specific user is using both the DC and the DP.

[0077] In order to prevent such name matching, the following measures will be taken. In step S23, when PF100 issues a dummy ID for DC to a certain user in response to a request from an IdP, if a dummy ID for DP has already been issued for the same user to the same IdP, the dummy ID for DC is not issued. Also, in step S29, when PF100 issues a dummy ID for DP to a certain user in response to a request from an IdP, if a dummy ID for DC has already been issued for the same user to the same IdP, the dummy ID for DP is not issued. In other words, when IdP-A and IdP-B are the same entity, PF100 does not issue a dummy ID for DC or a dummy ID for DP even if it receives a dummy ID for DC or a dummy ID for DP.

[0078] In this way, by not issuing a dummy ID for DC and a dummy ID for DP to the same IdP for a certain user, it is possible to prevent name matching.

[0079] (Other embodiments) The above-described embodiment is merely an example, and the present disclosure can be modified and implemented as appropriate within the scope that does not deviate from the gist of the disclosure.

[0080] The present disclosure can also be realized by providing a computer program implementing the functions described in the above embodiments to a computer, and having one or more processors in the computer read and execute the program. Such a computer program may be provided to the computer via a non-transitory computer-readable storage medium connectable to the computer's system bus or via a network. Non-transitory computer-readable storage media include, for example, any type of disk, such as a magnetic disk (e.g., a floppy disk, a hard disk drive (HDD), etc.), an optical disk (e.g., a CD-ROM, a DVD disk, a Blu-ray disk), a read-only memory (ROM), a random-access memory (RAM), an EPROM, an EEPROM, a magnetic card, a flash memory, an optical card, or any type of medium suitable for storing electronic instructions. [Explanation of symbols]

[0081] 100: Platformer (PF) 200: Data Consumer (DC) 300: Data Provider (DP)

Claims

1. A user data exchange system including a data consumer, a data provider, and a platformer, which mediates exchange of user data between the data consumer and the data provider, The data consumer transmits a first identifier issuance request to the platform to request issuance of a user identifier; the platform generates a first identifier in response to receiving the first identifier issuance request, transmits the first identifier to the data consumer, and stores the first identifier in association with a third identifier that identifies the user; The data consumer stores a first user ID and the first identifier in association with each other; the data provider transmits a second identifier issuance request to the platform to request issuance of a user identifier; the platform generates a second identifier in response to receiving the second identifier issuance request, transmits the second identifier to the data provider, and stores the second identifier and the third identifier in association with each other; The data provider stores the second user ID and the second identifier in association with each other; the data consumer transmits to the platform a ticket issuance request including information specifying the requested user data, the first identifier corresponding to the first user ID, and information specifying the data provider from which the user data is requested; In response to receiving the ticket issuance request, the platform generates a data request ticket including a ticket identifier, the third identifier corresponding to the first identifier, information identifying the user data, and information identifying the data provider to which the request is made, and sends the ticket identifier to the data consumer; the data consumer sends a data retrieval request including the ticket identifier to the data provider; The data provider sends a ticket reference request to the platformer, the ticket reference request including the ticket identifier included in the data acquisition request; the platform identifies a data request ticket corresponding to the ticket identifier included in the ticket reference request, and transmits information identifying the user data and the second identifier corresponding to the third identifier to the data provider; the data provider sends the requested user data for the user of the second user ID corresponding to the second identifier to the data consumer; At least one of the data consumer and the data provider does not hold account information of the user, and uses an identifier issued after the user is authenticated by an ID provider as the first user ID or the second user ID. A user data exchange system comprising:

2. The ID provider registers authentication information with the platform provider, When the data consumer sends the first identifier issuance request, the data consumer includes authentication information registered with the ID provider and sends the request to the platform; the platform transmits the first identifier to the data consumer when authentication of the authentication information included in the first identifier issuance request is successful; When the data provider sends the second identifier issuance request, the data provider includes authentication information registered with the ID provider and sends the request to the platform; the platform transmits the second identifier to the data provider when authentication of the authentication information included in the second identifier issuance request is successful; 2. A user data exchange system according to claim 1.

3. Data Consumer, Data Provider, Platformer, and First ID Provider and a second identity provider, the user data exchange system mediating exchange of user data between the data consumer and the data provider, the first ID provider stores a first user ID of the user; the second ID provider stores a second user ID of the user; the data consumer transmits a first identifier issuance request to the platform via the first ID provider, requesting issuance of a user identifier; the platform generates a first identifier in response to receiving the first identifier issuance request, transmits the first identifier to the first ID provider, and stores the first identifier in association with a third identifier that identifies the user; the first ID provider stores the first user ID and the first identifier in association with each other; the data provider transmits a second identifier issuance request to the platform via the second ID provider, requesting issuance of a user identifier; the platform generates a second identifier in response to receiving the second identifier issuance request, transmits the second identifier to the second ID provider, and stores the second identifier and the third identifier in association with each other; the second ID provider stores the second user ID and the second identifier in association with each other; the data consumer sends a first ticket issuance request to the first identity provider, the first ticket issuance request including information identifying the requested user data and information identifying a data provider from which the user data is requested; In response to receiving the first ticket issuance request, the first ID provider sends a second ticket issuance request to the platformer, the second ticket issuance request including information identifying the requested user data, the first identifier, and information identifying a data provider from which the user data is requested; In response to receiving the second ticket issuance request, the platform generates a data request ticket including a ticket identifier, the third identifier corresponding to the first identifier, information identifying the user data, and information identifying the data provider to which the request is made, and transmits the ticket identifier to the data consumer via the first ID provider; the data consumer sends a data retrieval request including the ticket identifier to the data provider; The data provider sends a ticket reference request including the ticket identifier included in the data acquisition request to the platform via the second ID provider or directly; In response to receiving the ticket reference request, the platform identifies a data request ticket corresponding to the ticket identifier included in the ticket reference request, and transmits information identifying the user data and the second identifier corresponding to the third identifier to the data provider via the second ID provider or directly; the data provider transmitting the requested user data relating to the user of the second user ID corresponding to the second identifier to the data consumer; A user data exchange system comprising:

4. When the first ID provider and the second ID provider are the same entity, the platform does not issue the first identifier or the second identifier even if it receives the first identifier issuance request or the second identifier issuance request.

4. A user data exchange system according to claim 3.

Images