Cross Domain and Cross Device Consent

With OneTrust Cookie Compliance, you now have the ability to share and link consent given by a user on one Website or Mobile App across your other managed Websites and Mobile Apps. This is achieved through a user profile that contains the consent given by the user from the first property interaction. The user profile is shared across the protected OneTrust cloud to additional devices or browsers where the user chooses to roam, safely creating a seamless user experience.

How does it work?

Once a known user is identified, via logging in for example (though we do not require this method), their unique user identifier is passed to OneTrust. Using this unique identifier we create a consent profile on our cloud. This profile now holds all the choices they made on the banner or preference center.

The next time the user logs in or goes to another property and logs in, OneTrust will first look for that user ID in our cloud and return with the previously gather consent configuration. Using the consent configuration from our cloud, we will then update their consent on their device or browser so that it can be read by your integrations. Additionally, the banner will not appear.

For the banner not to re-appear, this will require a complete syncing of the user profile from the server.

An example where the banner would not re-appear, user navigates to website that requires consent for A and B. User consents to A and B on the website. After this, the user logs into the Mobile App that requires consent for A and B. Consent for both A and B are synced, no banner is shown the the user.

An example where the banner would re-appear, user navigates to website that requires consent for A and B. User consents to A and B on the website. After this, the user logs into the Mobile App that requires consent for A, B and Z. Consent for both A and B are synced, but the banner could be shown here depending on how the geolocation rules are configured.

The reason the banner would be shown in the later example is because the user has never consented to Z before. Therefore the banner would still be shown as it is still a choice not yet made by the user.

Key Points

• The user must be a known user and have previously consented meaning they have a data subject identifier profile in OneTrust.
• Purposes must be shared across Web and Mobile properties
• Currently only fully synced profiles will result in the banner not re-appearing to the user.
• User identifier should be passed before OneTrust script is loaded or the OneTrust SDK is initialized.
• User identifier can be any unique identifier of your choosing, e.g. email, phone number, unique user ID
• Consent is shared within a consent group. - Consent groups have not yet been implemented.
• Consent is stored on the OneTrust cloud. This allows us to share consent not only across domains, but across different devices and applications as well.

How to Pass User Identifiers to OneTrust

Prerequisites

• A reliable way to identify a user.
• The ability to create a JSON Web Token (JWT) authorization token. This will be passed to OneTrust servers to ensure authenticated access to users' consent profile. For more information, see jwt.io.
• Enable the Cross Device Consent feature toggle on your OneTrust tenant
• Upload the Public Key for the generated JWT in your OneTrust tenant.
  Navigate to Settings
  Under the Consent sub-section, click Public Keys
  * Add the Public Key and click Save
• Create a Consent Group in Cookie Compliance
• Enable Consent Logging on the Geolocation Rule in scope

Creating JWT Auth Tokens

OneTrust does not create the JWT Auth token, this needs to be created by your team.

As a security best practice, we recommend using a backend for generating these unique JWTs for each user that you plan to sync consent profiles for. In this section, we will use the JWT.io site as a way to demonstrate the JWT auth token setup.

1. Go to JWT.io site
2. In the Decoded > PAYLOAD: DATA section, add the unique user identifier as the value for "sub"
3. In the Decoded > VERIFY SIGNATURE section, add a value for your-256-bit-secret.
   1. This value is your Public Key, which you need to add to your OneTrust tenant via Settings > Consent > Public Keys
4. In the Encoded section, copy the value. This will be your Auth Token in the Cookies and Mobile SDK Cross Device Consent configurations.

Website Setup

1. Identify the User. This can be done using your existing authentication methods.
2. Configure the OneTrust JavaScript variable:
   • id: Add the unique User Identifier value
   • isAnonymous: set as false to create/update User Profiles with OneTrust
   • token: The JWT authorization token that you produce with the unique User Identifier.

<script>
	var OneTrust = {
		dataSubjectParams: {
			id: "[Insert User ID Here]",
			isAnonymous: false,
			token : '[Insert JWT Token Here]'
		}
	};
</script>

Notes

• Make sure dataSubjectParams is injected before the main OneTrust Script.
• Use new script tag for cross device.
• Once you turn on Cross Device via creating a Consent Group, the Script Tag in the Integration > Scripts page of OneTrust tenant will be updated to reflect the required script tag for Cross-Device.

<script src="https://[CDN LOCATION]/consent/[YOUR DOMAIN ID]/otSDKStub.js"  type="text/javascript" charset="UTF-8" data-domain-script="[YOUR DOMAIN ID]" ></script>
<script type="text/javascript">
function OptanonWrapper() { }
</script>

• While implementing on the browser, you can inspect the Network tab and verify the configuration is setup correctly when you start to see the Request URL https://consent-api.onetrust.com/v1/preferences?syncgroup= in the list.

• The following API can be used to get user consent preferences Get Preferences

API Response codes

Mobile App Setup

1. Identify the user. This can be done using your existing authentication methods.
2. Pass the OneTrust SDK the params.

Android

// Define the Profile Sync Params
OTProfileSyncParams otProfileSyncParams = OTProfileSyncParams.OTProfileSyncParamsBuilder.newInstance()
  .setSyncProfile("true")
  .setSyncProfileAuth("[Insert JWT Token Here]")
  .setIdentifier("[Insert User ID Here]")
  .build();

// Define OT SDK Params and pass the Profile Sync Params reference
OTSdkParams sdkParams = OTSdkParams.SdkParamsBuilder.newInstance()
  .setProfileSyncParams(otProfileSyncParams)
  .shouldCreateProfile("true")
  .build();

// Initialize the SDK
otPublishersHeadlessSDK.startSDK(
  "[Insert CDN Location Here]",
  "[Insert App Id]",
  "[Insert Language Code Here]",
  sdkParams
)

// Profile syncing will happen on completion of the startSDK call

iOS

// Define the Profile Sync Params
let profileSyncParams = OTProfileSyncParams()
profileSyncParams.setSyncProfile("true")
profileSyncParams.setSyncProfileAuth("[Insert JWT Token Here]")
profileSyncParams.setIdentifier("[Insert User ID Here]")


// Define OT SDK Params and pass the Profile Sync Params reference
let sdkParams = OTSdkParams()
sdkParams.setProfileSyncParams(profileSyncParams)
sdkParams.setShouldCreateProfile("true")

// Initialize the SDK
OTPublishersHeadlessSDK.shared.startSDK(
  "[Insert CDN Location Here]",
  "[Insert App Id]",
  "[Insert Language Code Here]",
  sdkParams
)

// Profile syncing will happen on completion of the startSDK call

• The following API can be used to get user consent preferences Get Preferences

API Response codes

FAQs

Does the client need to implement a backend component for generating JWTs for OneTrust? Does OneTrust have any recommendations/advice on that matter?

As a security best practice, yes, we recommend using a backend for generating JWTs as OneTrust does not support this functionality today. The JWT.io site has a lot of great resources if you scroll down the page.

Does the client need to implement differentiate JWTs generated for different types of users? (i.e. web vs. mobile)

No, a JWT auth token is user-specific and tied to their unique identifier. Since you are likely using the same identifier to sync a user's consent between web to mobile or web to web, there is no need to change the JWT auth token in this scenario.

How would the client go on about supporting the following scenario: 1) User starts using the site/app anonymously 2) User saves their cookie/SDK preferences anonymously 3) User decides to register/login?

For Mobile SDK implementations, the overrideDataSubjectIdentifier() method should be used for this situation. Please refer to iOS or Android documentation for more information.

What's the relation of the identifier passed to the SDK via the setIdentifier() method to the unique user identifier specified as sub in the JWT payload?

They need to be the same for both Cookies and Mobile SDK implementations.

• Cookies: OneTrust.dataSubjectParams.id JS needs to equal sub value
• Mobile: OTProfileSyncParams.setIdentifier("id") needs to equal sub value

If not configured this way, it will result in a 401 Unauthorized error when the profile syncing request is made for both situations.

Apart from the sub, is there anything else the client would need to provide to OneTrust as part of the JWT payload?

Not at this time, sub is the only required field in JWT payload.

Does the Mobile SDK fire events when consent preferences change in another device/platform?

No, not at this time. You will need to call startSDK() again to pull down the latest changes to a user's consent on another platform.

Will Cross Domain/Device Consent feature work with IAB2 templates?

Yes, the Cookies SDK supports this today. The Mobile SDK supports this as of the 6.15 release.