Cross Device and Domain Consent - Roku

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.

Roku Setup

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

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("initOTSDKData", sdkParams)
// Profile syncing will happen on completion of the initOTSDKData 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.

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.