Overview

Due to the nature of our product, Trinsic is charged with the protection of highly-sensitive data. Security is baked deep into Trinsic's platform as a top-level concern. Our security philosophy can be described by a few core tenets:

1. If it's software, it can be hacked ("Assume Breach")

This is an obvious -- if unfortunate -- observation, from which the rest of our philosophy naturally flows. Modern software is incredibly complex, and is written primarily by fallible humans (that's us). While it is theoretically possible to create software with no security vulnerabilities, the unfortunate reality is that every real-life system can likely be hacked with a certain amount of resources, effort, skill, and luck.

This is also known as an "Assume Breach" paradigm: assume that your system will be breached, such that you can minimize the damage when one occurs.

Of course, it is always best to never have a security breach in the first place. This is our top priority; one we pour considerable effort into.

2. Data we don't have access to is data that cannot be stolen

In the event a breach does occur, Trinsic's approach to data security (including novel mechanisms described below) serves to significantly minimize the volume of data that is vulnerable.

We don't store data unless we truly need to for a legitimate product function that benefits you or your users. We do not sell user data to anyone, so we have no interest in hoarding it.

For the data we do have to store, we take care to store it for the least amount of time necessary. Of course, we employ industry-standard at-rest data encryption for our database and cache.

However, while at-rest data encryption is useful, it still encrypts data in such a way that we have access to it at rest, because we have access to the key (or HSM) necessary to decrypt the data. Any data that an organization has access to is data that a successful attacker also has access to.

Therefore, for as much data as possible, we store it in such a way that we cannot access it ourselves. This is explained in further detail below.

3. Build on best practices

Trinsic's data security solution involves some proprietary approaches which we believe significantly elevate our level of security compared to the industry at large. However, we recognize that industry best practices are designated as such for a reason, and it would be irresponsible not to make use of them.

The total security of any software system is composed of a number of layers. Each layer has different strengths and weaknesses, and no layer is ever invulnerable. By incorporating many layers of security -- and ensuring each of those layers is based on solid security foundations and is strong -- systems can be built to be highly secure, if not entirely invulnerable. Most of these layers are formed by properly implementing best practices.

Trinsic's "assume breach" philosophy places a special focus on minimizing the damage of a hypothetical catastrophic breach, and employs a number of novel techniques to do so. However, we also put great care into ensuring our system is as resilient to breach as possible by making use of industry best practices.

Basic

This section covers industry-standard ways in which we protect user data.

At-rest encryption

Per industry standards, all sensitive data is encrypted at rest using AES-256 with integrity checks provided by our Cloud infrastructure provider.

Application-Level Encryption

All sensitive data is encrypted at the application layer using AES-256 with integrity and context checks.

It should be noted that little data is protected solely by application-level encryption. Identity data is protected by the approach described in Advanced .

Data Scope & Lifetime

As mentioned above, we store as little data as possible, for as little time as possible.

Once identity data ceases to be of use to you or your user, it ceases to be of use to us -- so we delete it.

Redaction

We employ a mandatory data redaction policy with a maximum lifetime of 1 month, which is the longest amount of time a session's data will be stored in our systems.

Sessions can be redacted at any time prior to their scheduled redaction via the API, potentially reducing the total time data is present on Trinsic's servers to seconds.

Monitoring and Alerting

We employ industry standard monitoring and alerting to aid with detection of a breach or other security concerns.

Advanced

This section covers enhanced techniques that Trinsic employs to protect user data.

Passkey-based Reusable Identity Encryption

As part of our Remember Me feature (if enabled), users are given the opportunity to save a verification performed with a supported provider, allowing them to reuse it in the future with minimal friction. The saved identity credential is protected with a passkey.

This feature is built on WebAuthn ("passkeys"), using the PRF and Large Blob extensions to enable key derivation.

When a user saves a credential, we prompt them to register a passkey on their device. This passkey (using the aforementioned extensions), once created, contains key material that is only revealed to the user's browser, and is never sent to us. This key material is used to derive an encryption key, which is then used to encrypt the identity credential. When the user later re-uses the credential, they are prompted to authenticate the previously-created passkey, which will release the key material to the browser once again, allowing it to decrypt the user's identity credential.

Because the encryption key material never leaves the user's device, Trinsic is able to store the user's encrypted credential without having access to it at rest.

End to End encryption

Session Data Vault

When a user begins a session, we create a secure data vault specific to that session. This data vault can only be accessed with a key that is stored securely in the user's cookies, and which we do not save or log anywhere in our backend (we do not retain it).

Whenever the user is interacting with our product (that is, sending an HTTP request to our backend), we have access to the vault's key in-memory, allowing us to store and retrieve data to or from it. However, at rest (that is, outside the context of an HTTP request from said user), we have no access to the key necessary to access the data, meaning an attacker also would not be able to access it.

This approach allows us to store sensitive data in our backend during the context of a user session, while allowing the user's browser to manage the actual encryption key to access the vault. Our backend has access to the vault only when the user is "on the line".

Results Access Key

When your user completes a session, Trinsic needs to save the resultant identity data in such a way that it can be delivered to you when you call the Get Session Results API.

To ensure that Trinsic cannot access this data at rest, we store the identity results in the aforementioned session data vault, and embed the decryption key in the resultsAccessKey that is delivered to you via our clientside SDKs or redirect URL.

We do not save or log the decryption key for the identity data, and so can only access the data during the course of the Get Session Results API call.

Dashboard Data Visibility

When customers have end-to-end encryption turned on, the results of their verifications are not accessible by Trinsic; this also means Trinsic can't display the results in the dashboard. Therefore, we give customers the option to turn end-to-end encryption mode off in cases where customers need to view the results of their verifications in the Dashboard. To accomplish this, Trinsic retains a read-only copy of the resultsAccessKey for any given session.

This feature provides a compromise between functionality and security for scenarios where it's important to view verification results in the dashboard. For production apps, we recommend you only disable end-to-end encryption if viewing verification data in the dashboard is an absolute necessity.

Conclusion

End-to-end encryption allows Trinsic to store data for a legitimate user-focused purpose without having access to it at rest. This approach allows us to drastically reduce the data that is accessible by our systems (and therefore by a hypothetical attacker), which ultimately helps ensure the safety of your and your users' data. Automatic and manual data redaction significantly reduces the lifetime of user data on the platform.