End-user Identity Verification

Before accepting a privacy request, it is important that you first verify that the end-user is who they claim they are.

The following identity verification methods are available:

  1. Email verification (magic link)
  2. Phone number verification via SMS (magic link)
  3. Account login via JSON Web Tokens (JWT)
  4. Account login via OAuth 2

All identity verification logic can be configured on the "Request Settings" page.

Transcend comes pre-configured with email verification. Before a user can submit a request, they must input their email address.

The data subject is sent an email where they are asked to click a magic link to verify their identity.

The magic link sends the data subject back into the Privacy Center where they then must confirm the request.

You can disable this email verification step by switching to a different authentication method. You can also enable email verification in addition to JWT Account Login or OAuth verification.

If your data subjects are identified and authenticated by their phone numbers, SMS verification may be the right choice for you.

How it works: Transcend connects to Twilio via a standard OAuth integration. The data subject enters their phone number in the Privacy Center after verifying their account. To support this form of verification, you will need to add an enricher. The enricher will send a verification link to the data subject's phone number. When the data subject clicks on the link, their phone number is verified.

To set it up, first set up a new integration with Twilio.

Connecting a Twilio integration inside our platform

After that, create a new template inside Email Templates with the Internal Title equal to 'Phone number verification' if there is no template with that name. Add a 'Message Subject' and a 'Message Template'. The 'Message Template' can include {{{ verifyUrl }}}, that will be filled with the verification URL that the user will click to verify their phone number, and {{{ noVerifyUrl }}} to reject the verification request. {{{ verifyUrl }}} is a variable that will be filled by our platform with the verification URL that the user will click to verify their phone number. {{{ noVerifyUrl }}} is a variable that will be filled by our platform with the URL that the user will click to reject the verification request. One example of a message that you can use is:

Hi there! You recently made a request of type {{type}}. Please verify your phone number by clicking this link: {{{ verifyUrl }}}. Not you? Click this link to block this request: {{{ noVerifyUrl }}}.

Creating new phone template

Then, set up a new identifier. If that is not set up yet, go to the Identifiers and create a new one. This should be a phone identifier.

Creating a new phone identifier

Then, go ahead and create a new enricher with type "Twilio Phone Number Verification".

Creating a phone enricher

Connect to the Twilio integration. And for each region that data subjects may be, add a phone number for that region. You can find these numbers on Twilio's console. The number should have the ability of sending SMS messages. For each region that you want to support, add a phone number with the specified region. For example, if you want to add support for the US, add a phone number with the number +1XXXXXXXXXX. If you want to add support for the UK, add a phone number with the number +44XXXXXXXXXX, and so on.

Checking the Twilio number for one region

For the template, please select the created template: 'Twilio Phone Number Verification'. You can also set the expiration time for the verification link (in hours). The default is 24 hours. After that, the link will expire. You will set it when creating the enricher setting the property Expiration Duration. After that, you will have the proper setup for running new requests with phone number verification.

On the customer side, after the user confirms their email and verifies it, the user will be prompted to enter their phone number for verification.

Modal for the customer to verify the phone number

The enricher will be run on the platform. You will see the enricher running on the request that is sent to the user. The status of the request will look like the following:

The enrichment phase inside the admin dashboard

The enricher will run and send a verification link to the user's phone number. The user will click on the link and the phone number will be verified, completing the phone number verification.

Modal showing that the customer verified their phone

If you have end-users with accounts, it's best to have them prove they can sign into their account. Transcend supports asymmetrically-signed JSON Web Tokens as a form of authentication to the Privacy Center. To support this form of authentication, you will need to host an endpoint on your authentication service that can check a user's session and redirect back to your Privacy Center.

  • Data subject is redirected from your Privacy Center to your backend server
  • If the data subject has an active valid session, your server redirects the user back to the Privacy Center with a JSON Web Token containing the core identifier for that user
  • If the data subject has no active session, redirect them through their account login and then back to the JSON Web Token endpoint.
  • Sombra will validate the JSON Web Token using whatever public key you've set.

To setup JWT account login, visit the "Request Settings" page. There should be a section for "Authentication Methods > JWT" where you can set the public key that Sombra can use to validate the session JWT.

Read more on how to write the endpoint on your backend here.

If your website has the ability to create OAuth 2 applications, you can create an application for your Privacy Center to allow data subjects to log in with their account. The application will only need permission to receive the email address associated with the user.

OAuth 2 verification is performed with Sombra (End-to-End Encryption) meaning you don't have to trust Transcend to authenticate the user.

If you already have OAuth 2, just register a new application on your side (you can call it "Privacy Center"), and then input the needed Client ID, scopes, etc. in the "Request Settings" settings page, under "Authentication Methods > OAuth".

If you have several classes of end-users (such as account-holders and newsletter-subscribers), you can use different authentication methods for each class. Please refer to the "Data Subjects" guide to set this up.