The present invention relates generally the exchange of electronic data in the marketplace, and in particular to a system and method that creates a strong identity for Consumers/Users that is pre-authenticated at creation and is allowed to interface with Service Providers in a trusted relationship. This allows creation of an identity marketplace and direct Consumer controlled data within a Service Provider environment. At no point does the Control System have the ability to identify the Consumer/Users, and the Control System holds no Consumer identifiable data.
Service Providers, individual consumers and government agencies may be thought of as physical end-points to any interaction that occurs among them. For example, a consumer may need to physically interface with the department of motor vehicles DMV (a government agency) to acquire a driver's license, and then the consumer may take this driver's license to a bank (a Service Provider) to open a bank account. These physical activities are usually necessary to establish a consumer's identity pursuant to certain legal and regulatory obligations, such as Anti-Money Laundering (AML) or Know Your Customer (KYC). In some cases, physical interaction may not be necessary for a Consumer/User to establish an account with a Service Provider such as opening an Internet account. However, Service Providers will usually require some authentication to prove that a Consumer/User is who they claim they are and capture other information that helps the Service Provider authenticate a Consumer/User. Electronic and digital interactions between participants usually require authentication through an identity provider (IDP) based on username/password combinations or multi-factor authentication. These systems usually require an IDP to have direct knowledge of an end-point identity. Direct knowledge is gained by capturing, storing and using Personally Identifiable Information (PII) regarding a Consumer/User, which is information that identifies, relates to, describes, is capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular Consumer/User or device. Examples of PII data may include name, signature, social security number, gender, physical and genetic characteristics, address, telephone number, passport number, employment history, bank account number, credit card number, driver's license number, or any other financial information, medical information, or health insurance information. Most electronic systems require that consumers directly provide their PII information either to a Service Provider, the IDP directly or to another party, consequently resulting in the consumer losing control over this sensitive data. These systems are inherently susceptible to data breaches and information leakage.
It would be highly desirable to create systems and protocols that limit the sharing of PII with Control Systems (such as an IDP) and Service Providers (such as phone companies, banks, and the like). It would also be highly desirable to create a system, or a web of trust, where Service Providers and others can be assured that a Consumer/User is who they claim to be and that no one else can imitate the Consumer/User identity. If a trusted web of identity could be created in a system where there exist pre-validated Consumer/User data attributes, a system could be created for direct control of these data attributes by the Consumer
The present invention relates to a system and method for direct Consumer-controlled data that stores encrypted hashes representing the data within the Control System, and only the Consumer has control of when a Service Provider can actually see the unencrypted data. In the system of the present invention, the Control System acts as the custodian of these encrypted data hashes, and helps establish a trusted relationship between the Service Provider and the Consumer/User. The trust relationship (or the web of trust) is created in a way whereby the Control System does not store consumer PII—just the encrypted hashes that are used to establish relationships between the Service Providers and the Consumers/Users. Further, this web of trust allows for the creation of a verified marketplace where Consumers/Users have control over what attributes are visible to which Service Providers, and at what time (for example, online advertisers being able to see certain data attributes such as a Consumer's FICO score, and for how long).
Accordingly, a system that generates the above defined web of trust can be leveraged to allow for direct controls by Consumers/Users over sensitive data and relationships. Emerging regulations such as General Data Privacy Regulation (GDPR) and California Consumer Protection Act (CCPA) demand that consumers have the right to their data and enterprises must prove compliance, however the mechanisms currently adopted to comply with these emerging regulations often leverage archaic mechanisms of data controls, such as SQL programming, to purge data bases of sensitive information. This is both time consuming and manual, resulting in expensive implementations that often cannot prove compliance. An object of the present invention is to create a web of trusted end-points where control can be given directly to the Consumer/User, and Service Providers do not need to burden themselves with maintaining the Consumer's/User's sensitive information; instead the Consumer/User is given direct control over their sensitive information.
Attention is now directed to several Figures. The implementations described within these illustrations are examples of the systems, and the scope of the present invention is not limited to only such interactions. The numerals and alphabetics correspond to the parts of the drawings in each illustration.
Several figures have been presented to illustrate features of the present invention. The scope of the present invention is not limited to what is shown in the figures.
The present invention relates to a system for direct Consumer controlled data that stores encrypted hashes representing the data in the Control System, where only the Consumer has control of when a particular Service Provider can actually see the unencrypted data, and for how long.
The system/protocol of the present invention requires that a Service Provider must first establish a relationship with the Control System (this process is called on-boarding of a Service Provider). The Service Provider communicates with the Control System via a “Secure Enclave (SM)”, this is a piece of software sometimes known as a “driver” that establishes the unique identity for the Service Provider (including a hardware tie-in to the service provider's computer systems via hardware security modules—one example of this hardware security module is Intel's SGX platform). The Control System requires that the Service Provider have a highly verified identity through trusted third parties (such as SSL Extended Validation). Once the Control System receives the unique Service Provider attributes, the Control System creates an encrypted cryptographic hash for the Service Provider which is unique to this Service Provider; this is called a Service Provider Identifier or SID. As part of establishing the SID, the Control System also requires that the Service Provider inform the Control System which Consumer data attributes (i.e. names of fields) the Service Provider requires for establishment of a trusted connection with the Consumer/User account (such as Consumer's name, address, gender, social security number, and the like).
Next the System or Protocol requires that all Consumers/Users doing business with the particular Service Provider (that has already been on-boarded onto the Control System as described above) also be on-boarded to the Control System. The Consumer/User device must have an application that establishes secure connections between the Consumer device, the Control System and Service Providers—this application is known as the Client Secure Enclave Application. The Client Secure Enclave Application runs on the Consumer's system (such as a mobile device, laptop, server or other consumer interface device). The Client Secure Enclave Application establishes a unique identity for the Consumer/User. The unique identity associated with the Consumer may be thought of as a Digital Wallet that is created using one or a combination of biometric inputs, post quantum key distribution and other unique cryptographic key generation techniques. The Consumer's/User's unique identity along with required encrypted hash fields are passed from the Client Secure Enclave Application to the Control System. The Control System passes the above Consumer's identity and required encrypted hash fields to the Service Provider. The Secure Enclave Driver in the Service Provider environment matches the received Consumer identity attributes to verify the Consumer exists inside the Service Provider's environment. Once the Service Provider confirms the identity of the Consumer with the Control System, the Control System establishes a unique Identifier for the Consumer (this unique Consumer/User identity is called a MID). The Control System saves the Consumer's/User's required encrypted hashes (for all agreed upon data attributes between the Service Provider and Consumer/User) on the Control System in a table associated with this Consumer's/User's MID called a MID Attribute Table. Note that the Control System never stores the actual Consumer data attributes; only an encrypted hash of these data attributes is stored in the Control System, making the Consumer/User anonymous to the Control System. The Control System also creates a MID to SID hash relationship identifier, known as a Bridge identifier (BID) that can only be generated given the particular MID and SID combination.
The above described on-boarding protocol for the Service Provider and Consumer/User on the Control System establishes a highly correlated and encrypted relationship between the Service Provider and the Consumer/User. The protocol flow in this invention allows the Service Provider to access Consumer/User's sensitive information through the Control System's Secure Enclave (SM) driver that is installed on the Service Provider's system, and the Service Provider can purge the Consumer sensitive information from other areas, also called Target Systems, (such as databases and persistent stores within the Service Provider's infrastructure). A Target System is the original source of data within an enterprise. For example, an enterprise may store Consumer/User information within a SalesForce data base (or other Customer Relationship Management systems or data bases). The Service Provider may choose to retain original Consumer/User data within the existing Target Systems and simply use the Control System as an aggregation point. Meaning the Control System can act as a Master Data Repository (where data attributes are aggregated) or an Identity Master (where identity characteristics are aggregated). The Service Provider may also choose to not retain original information within existing Target Systems and only use the Control System for storage of this information.
If the Service Provider only accesses the Consumer/User sensitive information (such as PI I data) through the Secure Enclave (SM) Driver, the Service Provider unburdens itself from regulatory compliance obligations and allows the Control System to take over these regulatory obligations. The Consumer/User can interface with the Control System to instruct it to update BID Attribute Table on the Service Provider's Secure Enclave in ways such that the associated data attribute in the Service Provider's environment can be controlled per the Consumer/User's desire.
The Control System has built in Connector that allows the Control System to connect and access data from a given Target System. A Connector is a piece of software that uses different APIs to connect to different Target Systems and access data from these Target Systems. The Connectors are responsible for discovering certain types of sensitive data within a given Target System (such as PII data). The Connector may use manual processes to identify the sensitive data within a Target System, such as a User Interface to allow the Service Provider to choose what data should be identified as sensitive information (such as PII data). The Connector may also use Machine Learning and Artificial Intelligence functionality to automatically identify sensitive data within a Target System. Each different type of Target System (such as Oracle, SalesForce, MySQL, etc.) may have a different Connector that has the ability to gather data from that particular Target System.
The Connectors have the ability to recognize changes made to data attributes within the Target System or the Control System and map those changes back to the original source. The process is known as a Change Data Capture (CDC) event. For example, if a data attribute such as a phone number is updated with a certain Target System, like SalesForce, the Connector has the ability to recognize this update and it can automatically update that phone number within the Control System. Similarly, if a Consumer were to update his or her personal information within the Control System (such as a phone number or address) the Connector remembers which Target System that particular attribute came from and it can automatically update the original source of that attribute (that is, the Target System). By keeping track of the original source of data for every data attribute and identity, the Control System (via the Connector mechanism) acts as a Master Data repository (or a single source of truth). Similarly, because the Control System can keep track of identities across multiple Target Systems for a Service Provider, the Control System can also act as an Identity Master. For example, a Service Provider may have a particular Consumer identity in one Target System (SalesForce) as Mike M. Jones and the same Consumer identity in a different Target System (Oracle) as Mike Moses Jones—the Control System acting as a Identity Master can reconcile the two slightly different names to be the same identity and help the Service Provider manage the data in one place.
The Control System only identifies Consumers/Users as encrypted identities and does not have knowledge of any specific Consumer/User identity. The Consumer, at this point, has total control of their sensitive data and can enable Service Providers to view any sensitive data by unlocking the data in the Service Provider's systems through the Consumer encryption keys. The Consumer can revoke access to all or certain attributes of the Consumer's sensitive data directly by manipulating the encrypted hash keys within the Control System that in-turn prohibit the Service Provider's ability to see this data.
The Control System also has a Policy Engine component as part of the described system. The Policy Engine is responsible for controlling what data attributes are treated in what manner. For example, a Service Provider may want to allow Consumers to update their phone numbers at any time; however, if the Consumers wants to update their addresses, then they must submit utility bills with the new addresses. The Policy Engine can help the Service Provider define a policy that allows for the phone number to get updated directly. The Policy Engine will also automatically challenge the Consumer to upload a utility bill as evidence of an address change and alert the administrator at the Service Provider that they must manually accept the address change after a review of the utility bill. The Policy Engine is a programmatic interface that allows for highly sophisticated interactions to take place between the Consumer and the Service Provider, and control how data attributes are allowed to be updated or accessed.
Turning to
In order to revoke access to a particular attribute the protocol execution flow is as follows:
In summary, the present invention defines a system and method for a Consumer/User to interface with one or more Service Providers in a fashion that is pre-authenticated directly by the Service Provider to allow Consumer/User to set up an authentication/verification system that uses pre-assigned Consumer/User data attributes that are agreed upon between the Service Provider and the Consumer. A Control System controls and orchestrates these relationships by storing encrypted hashes of sensitive data. At no time does the Control System store or have access to the Consumer/User's personal sensitive data itself. At any time, the Consumer/User can add or revoke a particular Service Provider's ability to access all or portions of the Consumer/User's information.
Several descriptions and illustrations have been presented to aid in understanding the present invention. One with skill in the art will realize that numerous changes and variations are possible while still keeping the spirit of the invention. Each of these changes and variations is within the scope of the present invention.
1) Attribute Table
Attribute Tables are data storage tables where data such as Social Security Numbers, Names, Address, and other attributes are stored in an encrypted format where encryption is done using public/private key combinations for either Consumers or Service Providers.
2) Authenticated Relationship
A relationship between a Consumer/User and a Service Provider where the Service Provider has received information to verify the identity of the Consumer/User, and where the Consumer/User controls the Service Provider's access to Personally Identifiable Information of the Consumer/User.
3) Authorization Token
Data transmitted from the Control System to a particular Consumer/User that allows only that Consumer/User to log on to a particular Service Provider and no other Service Provider.
4) Bridge
A data record that links a particular Consumer/User to a particular Service Provider.
5) Bridge Identifier (BID)
A unique encrypted identifier (also known as a private key) established by the Control System that identifies the relationship between a particular Consumer/User and a particular Service Provider.
6) Consumer Identifier (MID)
A unique encrypted identifier established by the Control System for the Consume/User
7) Consumer or Consumer/User
A person or entity that has interacted or may interact with one or more Service Providers by means of one or more computing devices.
8) Control System
A third party computing device or devices, which may include one or more servers, that at least in part establishes, and at least in part controls, one or more Authenticated Relationships between one or more Consumer/Users and one or more Service Providers.
9) Digital Wallet
A Digital Wallet is software storage capability on a Consumer device or computer where that Consumer's private information is stored in an encrypted form, such as name, social security number, crypto currency keys, medical records, etc.
10) Encryption Keys
Encryption keys are combination of public/private keys (usually digital number and/or dynamic combination of numbers generated through biometrics and post quantum key distribution concepts).
11) Hash
A string of data that is unique to a larger data set, wherein any change in the larger data set causes a change in the hash, and it is impossible to create any portion of the larger data set from the hash.
12) Identity Provider (IDP)
An entity that authenticates the identity of a participant in a transaction based on username/password combinations or multi-factor authentication.
13) Onboard
The process by which a participant registers with the Control System, wherein the Control System identifies the participant and generates secure hashes of particular data related to that participant.
14) Personally Identifiable Information (PII)
Information regarding a Consumer/User, which comprises information that identifies, relates to, describes, is capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular Consumer/User or device. Examples of PII include name, signature, social security number, physical and genetic characteristics, address, telephone number, passport number, employment history, bank account number, credit card number, or any other financial information, medical information, health insurance information or any other personal or sensitive information relating to the Consumer/User.
15) Secure Enclave
A piece of software sometimes known as a “driver” that establishes the unique identity for the participant. A Service Provider Secure Enclave may include hardware tie-in to the Service Provider's computer systems via hardware security modules—such as with Intel's SGX platform. A Client Secure Enclave is an Application (App) running on a user device. The Client Secure Enclave Application establishes a unique identity for the Consumer/User. The unique identity associated with the Consumer may be created using one or a combination of biometric inputs, post quantum key distribution and other unique cryptographic key generation techniques.
16) Service Provider
An entity or individual that provides or proposes to provide services to an authorized Consumer/User.
17) Service Provider Identifier (SID)
A unique encrypted identifier for the Service Provider established by the Control System.
18) Verified Consumer Identity
A set of data that authenticates the identity of a Consumer/User
This application is related to, and claims priority from, U.S. Provisional Patent Application No. 62/869,520 filed Jul. 1,2019. Application 62/869,520 is hereby incorporated by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
62869520 | Jul 2019 | US |