The ADARA Privacy Token Server SDK allows tokenization of Personally Identifiable Information (PII) within an isolated environment. The resulting tokens follow a set of simple standards to allow interactions with other token producers to facilitate meaningful data exchanges without revealing sensitive information about individual users.
The ADARA Privacy Token Server SDK uses a deterministic hash when creating ADARA Privacy Tokens, so the same input to the SDK will always produce the same output and the resulting Privacy Token is transformed to prevent retrieval of the input PII.
With a deterministic result, two tokens created from the same PII match. The ability to match these hashed Privacy Tokens means that tokenized data can be shared or exchanged in a secure, privacy-first manner without revealing PII. Since the values are hashed, the tokens are useless to bad actors.
ADARA wrote the Privacy Token Server SDK to offer out-of-the-box support for engagement with the ADARA Privacy Token API, but does not require usage of this API. |
ADARA Privacy Tokens are unique, irreversibly obfuscated values used to represent more sensitive values, such as PII. Privacy Tokens are durable and platform-agnostic and have no meaning without context, much like asymmetrically encrypted text has no meaning without keys for context. Absent context, the sensitive value within is protected, making tokens useless to bad actors.
Using the open source ADARA Privacy Token Server SDK creates privacy tokens that can be securely and privately shared between ADARA and Data Partners, or even between outside collaborators without involving ADARA. Use ADARA Privacy Tokens to:
Link your customers to the over 1 billion digital identities in ADARA’s Digital Identity Graph
Harmonize and combine all of your customer’s disparate digital identities
Use ADARA's identity solutions to address your fraud detection and Identity Verification (IDV) use cases
Tokenize your data to protect the privacy of your customers
Share tokenized data in a secure, privacy-first manner to participate in:
Avoid breaches of privacy with a decentralized approach to data augmentation
Use ADARA's DRM service to control how, where, and with whom your data is shared and applied. Using this service, we will manage your data to comply with the ADARA Privacy Promise, so data usage will be fully permissioned and privacy compliant.
For more information on ADARA Privacy Tokens, see: |
Beyond basic tokenization, the ADARA Privacy Token Server SDK can use a salt to further transform the hashed value. Here, salt is a unique value used as an additional input in a one-way, irreversible function that hashes data. Salts safeguard this data in storage; the data is irretrievable without that salt yet retrievable with that salt.
There are two types of salt:
Tokenize PII with one salt, then tokenize the same PII with a different salt, and the resulting Privacy Tokens will be entirely different, with no discernable resemblance between them.
When the ADARA Privacy Token Server SDK tokenizes an identifier, it creates a private token and one or more common tokens using the private salt and common salt(s), respectively. Because these tokens are associated within the same identity context, they can be linked together to form a match, as all the individual tokens refer to the same derived identity.
ADARA manages its own identity graph using this same construct: ADARA's tokens are all created using a common salt shared between all data providers who choose to participate in ADARA's data consortium. Extending this concept to the diagram below, if Client A and Client B have an identity with the same PII, they will have different tokens, but they can query ADARA, and ADARA can check the ADARA tokens, made with ADARA's salt, and can identify a match. Client A and Client B would then know that their two different tokens represent the same identity.
Each data provider has a unique and secret salt value and ADARA has its own salt as well, but this is shared.
Clients could even work together in a consortium without ADARA, with their own specific consortium salt. Since they know the consortium salt, they could make tokens that are common to them and compare/share data. Any individual or company without knowledge of the consortium salt wouldn't be able to link Client A and Client B tokens.
Tokens can be produced only for consortiums of interest; an ADARA token is not required. This means that multiple "sub graphs" of identity can be supported based on privacy use cases that may or may not be connected to ADARA's primary identity graph. |
Your private salt is a secret salt unique to you that you do not share. Data hashed with your private salt cannot be retrieved without that private salt, and only you should have that salt. Your private salt allows you to generate tokens for identifiers which are only meaningful to you, even if the tokens themselves become compromised. A private salt is analogous to a private key; treat your private salt as you would treat a private key and:
|
ADARA wrote the Privacy Token Server SDK to offer out-of-the-box support for engagement with ADARA Privacy Token API, but does not require usage of this API. The API provides support for identity graph management, including participation in ADARA's data consortium as well as any other consortiums to which a data provider belongs. Data providers maintain complete control over how identity contexts are managed based on the tokens submitted.
Using the ADARA Privacy Token Server SDK and ADARA Privacy Token API together allows identity expansions and other features related to ID graphing. To use SDK and API together, you will need to share any common salts you use with ADARA. You have two options for managing your salt:
Each approach has its advantages and trade-offs; ADARA can work with you to identify the use case which is most appropriate for your needs.
You may also use this Privacy SDK completely independent of ADARA's Privacy API without even contacting ADARA for provisioning. Create your own salt values and specify them in the appropriate configuration key, then work directly with other SDK users with whom you share a common salt. To generate a salt value, use any string, such as a Universally Unique IDentifier (UUID) or a SHA-256 hash of your favorite disco album.