Privacy-protected cleanroom collaboration

Abstract

In a method for combining data in a cleanroom, a third-party provider encrypts the data using a public key provided by the consumer. The provider passes its data for transcoding, and the identity provider transforms the data into the consumer domain, also encrypting it. The provider passes this data to the cleanroom, where the consumer queries the data to verify for duplicates between datasets. While querying, the consumer provides a key to decrypt the data. Alternatively, both the cleanroom provider and the consumer pass a key to the identity provider, who then double-encrypts the data so that it can only be used by the consumer within the cleanroom.

Description

Technical Field

[0001] A data clean room is a secure and controlled space within a cloud computing environment that enables multiple parties to bring in their data for joint analysis. The data clean room allows parties to collaborate using their separate data without compromising the privacy of the data used in the collaboration. For example, for the purpose of sending a message to a desired target, the party sending the message may be provided with non-personally identifiable information (non-PII) for targeting a specific target.

[0002] Participants in a data clean room may need to use identifiers from third-party providers to find duplicates between the clean room provider's dataset and the consumer's dataset. These identifiers are used, for example, to uniquely identify specific persons and households within a set of such entities in each dataset. However, a clean room consumer may not want the consumer's data to be visible to the clean room provider. Therefore, there is a need for a method to enable the use of third-party identifiers within the clean room environment while protecting the privacy of the data within the clean room.

[0003] The references described in this background art section are not admitted to be prior art with respect to the present invention.

Summary of the Invention

[0004] This invention relates to a privacy-preserving method for a cleanroom provider to use consumer-related data from an app and bring it into the cleanroom, for example, without losing knowledge about its content. A cleanroom provider calling an identity native app for customer-related data can bring the data into the cleanroom in a privacy-preserving manner so that the data content is not exposed.

[0005] To achieve the objectives of some embodiments of the present invention, a third-party provider encrypts data with a public key provided by the cleanroom consumer, and therefore the cleanroom provider can handle the data and bring it into the cleanroom, but cannot actually verify the data. The consumer may provide a key to a third-party provider or a native application. The provider passes the provider's data for transcoding, and the identity provider transforms the data into the cleanroom consumer's domain, also encrypting the data. Therefore, the cleanroom provider can verify the result, but the result is not directly usable by the cleanroom provider. Since the value is encrypted with the cleanroom consumer's key, the result is meaningless to the cleanroom provider, even if it is visible to the provider, because the provider cannot decipher the actual underlying value. The provider simply passes this data into the cleanroom, where the consumer queries the data and checks for duplicates between datasets. While querying, the consumer provides a key to decrypt the data within the cleanroom domain.

[0006] In another embodiment of the present invention, both the cleanroom provider and the consumer provide a key to the identity provider. The identity provider double-encrypts the data, and the cleanroom provider, in addition to putting the data in, also puts in its own key. The consumer can then enter queries similar to those in the previous scenario, but this time both keys are required for the data to be used in the cleanroom. As a result, the data can only be used by the consumer within the cleanroom area.

[0007] In these embodiments, the native app and clean room are software constructs provided by a Software as a Service (SaaS) provider in a cloud computing-based environment. Computational details are hidden from the user by the SaaS service, but these cloud computing systems use compute, storage, and network resources provided by cloud compute and storage providers.

[0008] Existing methods to address this problem utilize a third-party cleanroom rather than operating within the consumer cloud environment. This requires significantly more network traffic between the participating entities. Consequently, this ultimately uses more resources—compute, memory, and storage—due to the overhead associated with coordination between the three entities. In some embodiments, the present invention improves upon this prior art system by reducing the required network traffic and coordination between the cleanroom provider, the consumer, and the provider of the identity resolution solution. By reducing this complexity, it reduces the compute, memory, and storage costs associated with the use of a third-party cleanroom.

[0009] These and other features, purposes, and advantages of the present invention will be better understood in consideration of the following detailed description of preferred embodiments and the appended claims, together with the drawings, as described below. [Brief explanation of the drawing]

[0010] [Figure 1] This is an architectural diagram for a cloud computing environment used for an implementation of the present invention. [Figure 2] This is a swim lane diagram illustrating a method according to one embodiment of the present invention, which uses only consumer keys. [Figure 3] This is a swim lane diagram illustrating a method according to one embodiment of the present invention, which uses both a consumer key and a provider key. [Figure 4] Figure 1 is an architectural diagram of computing resources for implementing the cloud computing environment. [Modes for carrying out the invention]

[0011] Before the present invention is described in further detail, it should be understood that the scope of the invention is limited solely by the claims, and that the invention is not limited to the specific embodiments described, nor is it limited to the specific embodiments, and that the terms used in describing those specific embodiments are merely for the purpose of describing those specific embodiments and not to limit them.

[0012] A system providing one embodiment of the present invention leverages the native features of a cloud-based data warehouse environment. An example describes a data warehouse using the Snowflake® SaaS platform from Snowflake Inc. While the Snowflake® environment is used in the following example for clarity, the present invention is not limited thereto. Other SaaS cloud providers have similar features, and the present invention may be implemented on other cloud provider infrastructures in alternative embodiments.

[0013] In one embodiment, the present invention is implemented in a Snowflake® cloud computing environment as shown in Figure 1. Snowflake® is a Software as a Service (SaaS) provider. It abstracts the underlying cloud provider details, layering them and thereby freeing users from concerns about implementation details. Snowflake® layers itself across one of three major cloud providers: Amazon AWS®, Microsoft Azure®, and Google® Cloud. Database storage is supported by individual cloud provider storage; for example, on AWS® it might be an S3 bucket, and on Google® Cloud it might be a GCP bucket. Compute resources in the form of virtual warehouses are supported by compute resources on the individual clouds. On top of these, Snowflake® builds Snowflake's cloud services, which provide services such as security and SQL optimization. Finally, users end up using Snowflake®-managed interfaces to individual cloud provider accounts owned by Snowflake. Users typically interact with this interface using clearly defined SQL commands, and Snowflake® translates those SQL commands to perform individual tasks.

[0014] Snowflake® provides the ability to share data between different accounts through secure sharing. Snowflake® also provides the ability to directly share code / functions between accounts through a database. To enable this functionality, Snowflake® allows references to the database to be passed to the consumer, and therefore certain functions and data are visible to the consumer (as permitted by the data provider). No data is moved; Snowflake® simply grants the consumer account access to data / functions related to the provider account. Compute resources are used on the consumer account.

[0015] The provider has the ability to remove access to the shared database within Snowflake®. Furthermore, while the shared functionality on the shared database is an interface for users, users cannot verify its details.

[0016] Native apps on Snowflake® are a special type of data sharing. Native apps allow for the sharing of stored procedures and the creation of several objects on the consumer side. A Data Clean Room is a special type of native app with more privacy controls.

[0017] The parties in an exemplary data transaction may include, as described below, a “Consumer,” a “Data Provider,” and an “Identification Resolution Provider.” A “Consumer” is a party that owns some data and maintains that data in a cloud environment, such as one facilitated by Snowflake®. This data can be of any type and can be used for any purpose. For example, a consumer could be a retailer that maintains data about its own customers, with each record in the consumer data set relating to a specific customer, and each field containing specific data maintained in relation to that customer.

[0018] A “data provider” is a party that owns additional data that may be useful to consumers in order to extend the usefulness or functionality of its own data. This may be additional or updated data fields relating to the same data records maintained by the consumer in its own data set. In a non-limiting example, a consumer may be a retailer that maintains data about its own consumers, and a data provider may be a party that maintains comprehensive data about consumers across a specific geographical or geopolitical area, such as a particular country or region, and provides a service to extend the retailer data with this additional data. Alternatively, a “data provider” may be another retailer that has its own consumer data, which may be considered extension data from the perspective of the “consumer” in this scenario. Thus, both parties may be retailers, and these retailers may benefit from collaborating with their data, but may be limited in some cases by the need to protect the privacy of this data.

[0019] A third-party "identity resolution provider" may be a party that provides services to resolve the identity of records where there is ambiguity as to whether the record relates to the same entity (e.g., consumers) or a different entity. Ambiguity is a common problem, for example, caused by people having the same name, people changing their names, typographical errors or other mistakes in data. An identity resolution provider may maintain a set of identifiers or links that are unambiguously and uniquely associated with a particular entity in a possible data space, such as consumers within a particular jurisdiction. By applying these identifiers to the data of others, the identity resolution provider enables the removal of ambiguity from the data in the other party's data set, because records relating to the same entity will receive a common identifier, while data relating to different entities will receive different identifier values.

[0020] Figure 1 shows an architecture for implementations of the method described herein. Three computing environments are shown: a computing environment for the identity resolution provider 10, a computing environment for the data provider 12, and a computing environment for the cloud environment 20. Each of these computing environments may be implemented as a computer hardware server, a multiprocessor compute cluster, etc. The identity resolution provider 10 provides a native application 16, whose functionality is described below, which may be installed in the cloud environment 20 for execution by the consumer 14. The native application 16 may be implemented as software executable within the computing environment. The data provider warehouse 18 is used by the data provider 12 to retrieve augmented data for use by the consumer 14. The data provider warehouse 18 may be implemented as solid-state computing storage, hard disk storage, or any other physical media storage technology for recording data and / or computing instructions. The consumer 14 itself is the computing and storage resources allocated to the consumer within the cloud environment 20 by the SaaS cloud environment provider.

[0021] To utilize this architecture and data sharing environment in an embodiment of the present invention that uses only consumer public keys, the process proceeds as shown in Figure 2. In step 30, the clean room consumer 14 shares a reference to a table in the database schema containing the public key. The native app 16 uses compute resources in its account to read this key. In step 32, the native app 16 shares a reference to a database containing identity resolution logic with the clean room provider (data provider) 12. Exposure data is passed to these functions, which is calculated by dividing the amount of time a user was shown or "exposed" to a message over a selected date range by the total engagement over the selected date range. Compute resources are used on the clean room provider 12 side to operate the functions shared by the native app 16. In step 34, the resulting dataset contains identifiers in the domain of the clean room consumer 14. The public key provided by the clean room consumer 14 is used to encrypt the dataset. This dataset occupies storage on the clean room provider 12's account. In step 36, the clean room provider 12 shares a reference to its dataset with the clean room consumer 14. In this case, it can be understood that no data is moved, and only access is given for the clean room consumer 14 to use the provider database 18. In step 38, the clean room consumer 14 queries the clean room 22 and provides a secret key in that query to decrypt encrypted identifiers for a data join. Compute resources are used in this case on the consumer side in the clean room 14. In step 40, the clean room returns the duplicate between the dataset provided by the data provider 12 and the dataset provided by the consumer 14. This is stored as a dataset on the consumer side in the clean room consumer 14.In this way, data can be shared within the clean room 22 without compromising privacy.

[0022] Figure 3 shows a variation of this method that uses public keys from both the clean room data provider 12 and the clean room consumer 14. In this case, the identifiers are double-encrypted. Since both keys are used, the data can only be used by the consumer 14 within the domain of the clean room 22 itself. In step 50, the clean room consumer 20 provides its public key to the native app 16, as in the process shown in Figure 2. However, in step 52, the data provider 12 also provides its own public key to the native app 16. In step 54, the native app 16 shares a reference to the database containing the identity resolution logic with the clean room provider (data provider) 12, as described above in Figure 2, and the exposed data is passed to these functions. Compute resources are used on the clean room provider 12 side to operate the functions shared by the native app 16. In step 56, the resulting dataset contains identifiers in the domain of the clean room consumer 14. Both encrypted public keys are provided by the clean room consumer 14 and the clean room provider 12. This dataset occupies storage on the clean room provider 12's account. In step 58, the clean room provider 12 shares a reference to the database with the clean room consumer 14 and also puts in a private key for decryption, which is hidden from the clean room consumer but indirectly available through a shared function / stored procedure. As in the example in Figure 2, it can be understood that in this case no data is moved and only access is given for the clean room consumer 14 to use the provider database 18. In step 60, the clean room consumer 14 queries the clean room 22 and provides its own private key in the response to decrypt the encrypted identifier for data joining. Compute resources are used on the consumer's side in the clean room 14 in this case. In step 62, the clean room returns the duplicate between the dataset provided by the data provider 12 and the dataset provided by the consumer 14.This is stored as a dataset on the cleanroom consumer's side at consumer 14. In this way, the data can be shared within the cleanroom 22 without compromising privacy. It should also be understood that, since both keys are required for decryption, the data can only be used within the area of ​​the cleanroom 22.

[0023] The methods described herein can be implemented in various embodiments by any combination of hardware and software. For example, in one embodiment, the method may be implemented by a computer system (for example, a computer system as in Figure 4) or a collection of computer systems, each of which includes one or more hardware processors that execute program instructions stored in a computer-readable physical storage medium coupled to a hardware processor, within the provider environment 12 and the customer environment 14. The program instructions may implement the functions described herein (for example, the functions of various hardware servers and other components that implement the network-based cloud computing resources described herein). The various methods shown in the figures and described herein represent exemplary implementations. The order of any method may be changed, and various elements may be added, modified, or omitted.

[0024] Figure 4 is a block diagram illustrating exemplary computer hardware systems in various embodiments. Computer system 140 may implement the hardware portion of a cloud computing system as forming part of various implementations of the present invention. Computer system 140 may be any of various types of hardware devices, including, but not limited to, commodity servers, mainframe computer systems, workstations, network computers, application servers, physical storage devices, or generally any type of computing node, compute node, compute device, and / or hardware computing device.

[0025] The computer system 140 includes one or more hardware processors 140a, 141b...141n (any of which may include multiple processing cores, some of which may be single-threaded or multi-threaded) coupled to physical system memory 142 via an input / output (I / O) interface 144. The computer system 140 may further include a network interface 146 coupled to the I / O interface 144. In various embodiments, the computer system 140 may be a single-processor system including one hardware processor 141a, or a multi-processor system including multiple hardware processors 141a, 141b...141n, as shown in Figure 4. Processor 141a, etc., may be any suitable processor capable of executing computing instructions. For example, in various embodiments, processor 141a, etc., may be a general-purpose processor or embedded processor implementing one of various instruction set architectures. In a multi-processor system, each of processors 141a, etc., may, but usually, implement the same instruction set. Computer system 140 also includes one or more hardware network communication devices (e.g., network interface 146) for communicating with other systems and / or components across communication networks, such as a local area network, a wide area network, or the Internet. For example, a client application running on system 140 may use network interface 146 to communicate with a server application running on a single hardware server or a cluster of hardware servers that implement one or more of the components of the system described herein in a cloud computing environment, which are implemented in various subsystems. In another example, an instance of a server application running on computer system 140 may use network interface 146 to communicate with other instances of the application that may be implemented on other computer systems.

[0026] In the illustrated embodiment, the computer system 140 also includes one or more physical persistent storage devices 148 and / or one or more I / O devices 150. In various embodiments, the persistent storage device 148 may correspond to a disk drive, tape drive, solid memory or drive, other mass storage device, or any other persistent storage device. The computer system 140 (or a distributed application or operating system running on it) may, as needed, store instructions and / or data in the persistent storage device 148 and retrieve the stored instructions and / or data as needed. For example, in some embodiments, the computer system 140 may implement one or more nodes of a control plane or control system, and the persistent storage 148 may include a solid-state drive (SSD) mounted on its server node. Multiple computer systems 140 may share the same persistent storage device 148, or they may share a pool of persistent storage devices, where the devices in the pool represent the same or different storage technologies, including the technologies described above.

[0027] Computer system 140 includes one or more physical system memories 142 that can store code / instructions 143 and data 145 accessible by (one or more) processors 141a, etc. System memory 142 can include, for example, multiple levels of memory and memory cache in a system designed to swap information in memory based on access speed. Interleaving and swapping can extend to persistent storage device 148 in a virtual memory implementation form where the memory space is mapped onto the persistent storage device 148. The technologies used to implement system memory 142 can include, by way of example, static random access memory (RAM), dynamic RAM, read-only memory (ROM), non-volatile memory, solid-state memory, or flash-type memory. Similar to the case of persistent storage device 148, multiple computer systems 140 can share the same system memory 142 or share a pool of system memories 142. One or more memories 142 may contain program instructions 143 executable by (one or more) processors 141a, etc. to implement the routines described herein.

[0028] In various embodiments, program instructions 143 can be encoded in binary, assembly language, any interpreter-type language such as Java (registered trademark), compiled languages such as C / C++, or any combination thereof, where the particular languages given are merely examples. In some embodiments, program instructions 143 can implement multiple distinct clients, server nodes, and / or other components.

[0029] In some implementations, program instructions 143 may include instructions executable to implement an operating system (not shown) which may be any of the various operating systems, such as UNIX®, LINUX, Solaris®, MacOS®, or Microsoft Windows®. Any or all of program instructions 143 may be provided as a computer program product or software which may include a non-temporary computer-readable storage medium storing the instructions, which may be used to program a computer system (or other electronic device) to perform a process according to various implementations. The non-temporary computer-readable storage medium may include any mechanism for storing information in a form readable by a machine (e.g., a physical computer) (e.g., software or processing application). Generally, the non-temporary computer-accessible medium may include computer-readable storage media or memory media, such as magnetic or optical media, for example, a disk or DVD / CD-ROM coupled to or communicating with the computer system 140 via the I / O interface 144. Non-temporary computer-readable storage media may also include any volatile or non-volatile media, such as RAM or ROM, which may be included as system memory 142 or another type of memory in some embodiments of the computer system 140. In other implementations, program instructions may be communicated using optical, acoustic, or other forms (e.g., carrier waves, infrared signals, digital signals, etc.) of propagated signals transmitted over a communication medium, such as a network and / or wired or wireless link, such as a network interface 606. The network interface 146 may be used to interface with other devices 142, which may include other computer systems or any type of external electronic device.

[0030] In some embodiments, the system memory 142 may include a data store 145 as described herein. Generally, the system memory 142 and persistent storage 148 may be accessible on other devices 142 over a network and may store data blocks, replicas of data blocks, metadata associated with the data blocks and / or their states, database configuration information, and / or any other information that can be used when implementing routines described herein.

[0031] In one embodiment, the I / O interface 144 may coordinate I / O traffic between a processor 141a, etc., in the system, and between the system memory 142 and any peripheral devices, including through a network interface 146 or other peripheral interfaces. In some embodiments, the I / O interface 144 may perform any necessary protocols, timing, or other data conversions to convert data signals from one component (e.g., system memory 142) into a format suitable for use by another component (e.g., a processor 141a, etc.). In some embodiments, the I / O interface 144 may include support for devices attached through various types of peripheral buses, such as a Peripheral Component Interconnect (PCI) bus standard or a variation of the Universal Serial Bus (USB) standard. Also, in some embodiments, some or all of the functions of the I / O interface 144, such as an interface to the system memory 142, may be directly incorporated into one or more processors 141a, etc.

[0032] The network interface 146 may, for example, allow data to be exchanged between the computer system 140 and other devices attached to the network, such as other computer systems (which may implement one or more storage system server nodes, primary nodes, read-only node nodes, and / or database system clients as described herein). Furthermore, the I / O interface 144 may allow communication between the computer system 140 and various I / O devices 150 and / or remote storage 148. The input / output devices 150 may, in some embodiments, include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice or optical recognition devices, or any other devices suitable for inputting or retrieving data by one or more computer systems 140. These may connect directly to a specific computer system 140 or, generally speaking, to multiple computer systems 140 in a cloud computing environment, a grid computing environment, or other systems involving multiple computer systems 140. Multiple input / output devices 150 may exist communicating with the computer system 140, or they may be distributed across various nodes of a distributed system including the computer system 140. In some embodiments, similar input / output devices may be separate from the computer system 140 and may interact with one or more nodes of the distributed system including the computer system 140 via wired or wireless connections, such as over a network interface 146. The network interface 146 may typically support one or more wireless networking protocols (e.g., Wi-Fi / IEEE 802.11, or another wireless networking standard). The network interface 146 may support communication over any suitable wired or wireless general data network, such as other types of Ethernet® networks.Furthermore, the network interface 146 may support communication over telecommunications / telephony networks such as analog voice networks or digital fiber optic networks, communication over storage area networks such as Fibre Channel SANs, or communication over any other suitable type of network and / or protocol. In various embodiments, the computer system 140 may include more components than those shown in Figure 4, fewer components than those shown in Figure 4, or components different from those shown in Figure 4 (e.g., displays, video cards, audio cards, peripheral devices, or Ethernet® interfaces).

[0033] Any of the embodiments of the distributed systems described herein, or any of their components, may be implemented as one or more network-based services in a cloud computing environment. For example, read-write nodes and / or read-only nodes in the database tier of a hardware database system may present database services and / or other types of physical data storage services employing the distributed storage systems described herein to clients as network-based services. In some embodiments, network-based services may be implemented by software and / or hardware systems designed to support interoperable machine-to-machine interaction over a network. Web services may have interfaces written in a machine-readable format. Other systems may interact with network-based services in a manner defined by the description of the network-based service's interface. For example, a network-based service may define various actions that other systems may invoke and define specific application programming interfaces (APIs) that other systems are expected to follow when requesting these actions.

[0034] In various embodiments, network-based services may be requested or invoked through the use of a message containing parameters and / or data associated with the network-based service request. Such messages may be formatted according to a specific markup language, such as XML, and / or encapsulated using a protocol. To fulfill a network-based service request, a network-based service client may assemble a message containing the request and transmit that message to an addressable endpoint corresponding to the web service (e.g., a Uniform Resource Locator (URL)) using an Internet-based application layer transport protocol, such as the Hypertext Transfer Protocol (HTTP).

[0035] Unless otherwise specified, all technical and scientific terms used herein have the same meaning as those generally understood by those skilled in the art to the extent of this invention. Similar or equivalent methods and materials as those described herein may also be used in the practice or testing of this invention, but only a limited number of exemplary methods and materials are described herein. It will be apparent to those skilled in the art that many more modifications are possible without departing from the inventive concept herein.

[0036] All terms used herein should be interpreted in the broadest possible form that is consistent with the context. When grouping is used herein, all individual members of the group, as well as all possible combinations and subcombinations of the group, are included individually. When a scope is specified herein, the scope includes all subscopes within the scope, as well as all individual points within the scope. When terms such as “about” and “approximately” are used herein, the terms include quantities, measurements, etc. that do not deviate significantly from the explicitly stated quantities, measurements, etc., so as not to impair the stated purpose of the apparatus or process. All references cited herein are incorporated herein by reference to the extent that they do not conflict with this disclosure.

[0037] The present invention has been described in relation to several preferred and alternative embodiments, which are intended to be illustrative and not to be limited to the full scope of the invention as described in the appended claims.

Claims

1. A method for data collaboration, Steps to share a consumer public key with a native application across a network from a consumer computing environment, The steps include: sharing a reference to an identification information resolution logical database from the native application to the data provider computing environment in order to provide an identifier function; The steps include: allocating computing resources within the data provider computing environment and operating the identifier function to generate an identifier dataset within the data provider computing environment; The steps include: in the native application, encrypting the identifier dataset with the consumer public key, and storing the resulting encrypted identifier dataset in a clean room, wherein the clean room comprises a secure and controlled space that allows multiple parties to bring data to each other for collaborative analysis; A step of sharing a reference to the encrypted identifier dataset with the consumer computing environment, A step of sending a query from the consumer computing environment to the clean room, wherein the query comprises a consumer secret key, Using the consumer secret key, the steps include decrypting the encrypted identifier dataset in the clean room to facilitate data joining, A method that includes [a certain feature].

2. The method according to claim 1, further comprising the step of reading the consumer public key in the native application.

3. The method according to claim 2, further comprising the step of sharing a set of exposure data from the data provider computing environment to the native application.

4. The method according to claim 3, further comprising the step of storing duplicates in the consumer computing environment.

5. The method according to claim 4, further comprising the step of returning the duplicates between the data provider dataset and the consumer dataset from the clean room to the consumer computing environment.

6. The method according to claim 1, further comprising the step of sending a provider public key from the provider computing environment to the native application.

7. The method according to claim 6, further comprising the step of encrypting the identifier dataset with the provider's public key.

8. The method according to claim 7, further comprising the step of sharing the provider's private key from the provider computing environment to the clean room.

9. The method of claim 8, wherein the step of decrypting the encrypted identifier dataset in the clean room to facilitate data joining utilizes both the consumer private key and the provider private key to decrypt the encrypted identifier dataset.

10. One or more computer processors, The memory space that stores the instructions and A machine comprising, where, when the instruction is executed by the one or more computer processors, the one or more computer processors, Sharing consumer public keys from a consumer computing environment with native applications, To provide identifier functionality, a reference to the identification information resolution logical database is shared from the native application to the data provider computing environment, The data provider computing environment is used to allocate computing resources and operate the identifier function to generate an identifier dataset. In the aforementioned native application, the identifier dataset is encrypted with the consumer public key, and the resulting encrypted identifier dataset is stored in a clean room. Sharing a reference to the encrypted identifier dataset with the consumer computing environment, Sending a query from the consumer computing environment to the clean room, wherein the query includes a consumer secret key, Using the aforementioned secret key, the encrypted identifier dataset in the clean room is decrypted to facilitate data joining, A machine that performs a task.

11. The machine according to claim 10, further comprising, when executed by the one or more computer processors, an instruction causing the one or more computer processors to share a set of exposure data from the data provider computing environment to the native application.

12. The machine according to claim 11, further comprising, when executed by the one or more computer processors, instructions causing the one or more computer processors to store the redundancies in the consumer computing environment.

13. The machine according to claim 10, further comprising, when executed by the one or more computer processors, an instruction causing the one or more computer processors to send a provider public key from the provider computing environment to the native application.

14. The machine according to claim 13, wherein when the instruction is executed by the one or more computer processors, the machine further encrypts the identifier dataset with the provider's public key.

15. The machine according to claim 14, further comprising, when executed by the one or more computer processors, an instruction causing the one or more computer processors to share a provider's private key from the provider computing environment to the clean room.

16. The machine according to claim 15, further comprising, when executed by the one or more computer processors, an instruction causing the one or more computer processors to decrypt the encrypted identifier dataset in the clean room in order to facilitate data joining, using both the consumer secret key and the provider secret key.

17. A computerized system for data collaboration, wherein the system is An identity resolution computing environment comprising a native application, wherein the native application is configured to receive a consumer public key, share a reference to an identity resolution logical database to provide identifier functionality, and encrypt an identifier dataset with the consumer public key to create an encrypted identifier dataset. A data provider computing environment, wherein the data provider computing environment is configured to receive the reference to the identification information resolution logical database and to operate an identifier function to generate the identifier dataset, A consumer computing environment, wherein the consumer computing environment is configured to generate a consumer public key and generate a query comprising a consumer secret key, A clean room configured to receive the encrypted identifier dataset and to receive the query containing the consumer secret key for decrypting the encrypted identifier dataset in the clean room, A computerized system equipped with these features.

18. The computerized system according to claim 17, wherein the data provider computing environment is further configured to share a set of exposure data with the native application.

19. The computerized system according to claim 18, wherein the data provider computing environment is further configured to send a provider public key to the native application, and the native application is further configured to encrypt the identifier dataset with the provider public key to create a double-encrypted identifier dataset.

20. The computerized system according to claim 19, wherein the data provider computing environment is further configured to share a provider private key with the clean room, and the native application is further configured to decrypt the double-encrypted identifier dataset using both the consumer private key and the provider private key, so that the double-encrypted identifier dataset can be decrypted only from within the clean room.

Images