Cross Device and Cross Domain Consent

With OneTrust Cookie Consent, 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 reappear, this will require a complete syncing of the user profile from the server.

An example where the banner would not reappear: the user navigates to a 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 and no banner is shown to the user.

An example where the banner would reappear: the user navigates to a 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 reappearing 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 Global Settings > Consent > Public Keys. Click the Add Public Key button, enter the details, and click Save.
• Create a Consent Group in Cookie Consent.
• 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 website as a way to demonstrate the JWT auth token setup.

1. Go to the JWT.io website.
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.

📘

This value is your public key, which you need to add to your OneTrust tenant via Global 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.

Roku Setup

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

m.global.Addfield("OTsdk", "node", false)
   m.global.OTsdk = CreateObject("roSGNode", "OTinitialize")
// Define OT SDK Params and Profile Sync Params
     sdkParams = m.global.OTsdk.callFunc("OTSdkParams")
     sdkParams.applicationId = "[Insert App Id]" 
   sdkParams.location = "[Insert CDN Location Here]"
   sdkParams.language = "[Insert Language Code Here]"
   sdkParams.version = "[Insert version Here]"
   sdkParams.shouldCreateProfile = true
   sdkParams.syncProfile = true
   sdkParams.syncProfileAuth = "[Insert JWT Token Here]"
   sdkParams.identifier = "[Insert User ID Here]"

 // Initialize the SDK
    m.global.OTsdk.callFunc("startSDK", sdkParams)
// Profile syncing will happen on completion of the initOTSDKData call

The Get Data Subject's Preferences API call can be used to retrieve the user's consent preferences.

API Response codes

FAQs

Do you need to implement a backend component for generating JWTs for OneTrust? Does OneTrust have any recommendations/advice on this 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 website has a lot of great resources if you scroll down the page.

Do you need to implement different 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.

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

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