Didomi Consent String

The Didomi Consent String (DCS) is a new binary format that replaces the traditional didomi_token, typically stored in cookies or local storage. Once enabled, the DCS will be stored in the didomi_dcs cookie and/or local storage, replacing the older didomi_token across your organization’s implementation.

The DCS format is inspired by the IAB TCF and GPP strings and is designed to offer a smaller, more compact representation of user consent data. It is generated and consumed by the Didomi SDK and is designed to optimize performance and improve storage efficiency.

Use our DCS decoder to easily decode Didomi consent strings.

📘 Enable Didomi Consent String

What purpose does a Consent String serve?

A Consent String’s primary purpose is to encapsulate the expression of a user's choices for their personal data processing under any regulation. The Consent String is used as Didomi's storage format (in cookies or similar local storage) and can be consumed by Didomi's clients and partners to determine whether they have the necessary legal permissions to process a user's personal data for their purposes.

The Didomi Consent String stores user choices for custom vendors and purposes in all cases. Within the context of a GDPR regulation, the IAB TCF String remains the source of truth and the Didomi Web SDK works with both strings to create a unified view of consent choices that are reflected in the public API functions on the SDK. Custom vendors and purposes are assigned numerical IDs that are encoded in the Didomi Consent String and can be accessed by the following API functions:

• Didomi.getVendorNumericId

• Didomi.getVendorByNumericId

• Didomi.getPurposeByNumericId

• Didomi.getPurposeNumericId

What information is stored in a Consent String?

In general, a Consent String contains the following information:

1. General Metadata: version of the Consent String, when it was last updated, when it was initially created, user ID, etc.

2. Purposes Status: user’s choices for processing their personal data for specific purposes.

3. Vendors Status: a user's choices for third-party vendors to access and process their personal data.

The Didomi Consent String is divided into several sections:

🔒 Encoded Sections

• Header Section: contains general metadata;

• Purposes Consent Section: a user’s choice for processing their personal data for specific purposes based on consent legal basis;

• Purposes Legitimate Interest Section: a user’s choice for processing their personal data for specific purposes based on legitimate interest legal basis;

• Vendors Consent Section: a user's choices for third-party vendors to access and process their personal data for consent legal basis;

• Vendors Legitimate Interest Section: a user's choices for third-party vendors to access and process their personal data based on legitimate interest legal basis;

📝 Non-encoded Sections

• Device ID (DID): a device ID where Didomi Consent String is stored. The DID is appended to the previous Consent String Sections with the . character as a separator. The DID is always the first ID appended to the last of the Consent String Sections. This field is optional, but we still append the . as a placeholder to separate it from the OUID.

• Organization User ID (OUID): a user’s id assigned to this user by the organization (client). It is used to synchronize the user choices between different sessions. The OUID is appended to the string after the DID with the . character as a separator. This field is optional and is only appended to the consent string when the cross device feature is enabled.
• Signature: A cryptographic signature (not bit-encoded) used to verify the integrity of the consent string. Appended to the full string using a ~ (tilde). Only present when the signature feature is enabled.