Consent String Schema

• Consent String Schema
  • Schema format
    • Type
    • Field
    • Consent String Type
    • Specification Version
    • Test
    • Types
    • Fields and segments
  • Schema Validation
    • Structure validation
    • Type validation
    • Key validation

Consent strings store user consent status as binary data, encoded in base64. Encoding user consent status into a binary string, or decoding it from an existing one, requires an encoder/decoder library. The schema defines the consent string format in a human-readable way. This allows new formats to be defined, or existing ones updated, without modifying the encoder/decoder library.

Schema format

The schema has the following structure:

• consent_string_type
• specification_version
• tests
• types
• fields or segments

Type

Encoders and decoders need to know the type of data they're working with. The schema defines fields with specific types, much like variables in programming. The following types must be supported by the encoder/decoder library:

Field

The main building block of the schema is a field. The field is analog of variable in a programming language and each filed must have a type. There is a field definition example:

{
  "type": "version",
  "description": "The Didomi Consent String version 6bits number",
  "key": "dcs_version",
  "value": 2  
}

Here we are defining the field with type "version" and key equal to "dcs_version". The encoder will use the key property to access the field value provided in the user status object. We could also define the field value property to instruct the encoder to read the value not from the user status object but from the schema.

Another example of the field property is optional. Each field could be an optional and this will instruct encoder to place 1 bit flag in encoded string before the field value. If the flag is 1, the value is present and decoded. If it's 0, the value is absent and skipped during decoding. There is example of the optional field definition

{
  "type": "date",
  "key": "sync",
  "optional": true
}

There are fields that could be encoded using different encoding algorithms for optimization purposes. To specify what algorithms (types) could be used by encoder for value encoder we use variants field attribute:

{

  "type": "enabled_disabled_ids",
  "description": "User Status for purposes opt-out",
  "key": "purposes_li",
  "variants": [
    "bit_field_2_bits",
    "ranges_u16",
    "ranges_fibonacci"
  ]
}

This example shows how to encode user status for purposes using three methods: bit_field_2_bits, ranges_u16, and ranges_fibonacci. The encoder chooses the method producing the shortest result and includes the chosen method's code before the encoded value, allowing the decoder to correctly decode the string.

Some types need to have size information to encode / decode correctly.

{
  "type": "string",
  "description": "Two-letter ISO 639-1 language code in which the CMP UI was presented",
  "key": "consent_language",
  "size": 12
}

Here we are defining a 12 bits string type field.

There is the summary for all field attributes:

Consent String Type

The consent string schema supports the following types:

Specification Version

For each string type several specification versions could be defined, for example, for Didomi Consent String we have specification_version 1 and 2, where version 1 has some restrictions for the encoder.

Test

The consent string schema defines tests for an encoder and decoder in tests array. The encoder/decoder library should run these tests to make sure the library produces expected results based on the schema.

Types

The types array defines a subset of types supported by the consent string schema (Type). Each type from types must appear at least ones in field definition and all types from fields definition should be listed in types array.

Fields and segments

The consent string schema could have fields array on the top level or segments array. The fields array contains field definition (Field) and segments could be used to define a segmented string structure, where each segment encoded separately and then connected to each other using . character.

For example:

{
  "tests": {
    "encoded": "CQH-gkAQH-gkAAHABBENBOFgAPAAAELAAAAAF5wAQF5gXnABAXmAAAAA.YAAAAAAAAAAA"
  }
}

Here we have an IAB TCF string as encoded value with two segments : core and publisher.

In the schema segments defined as the following object:

 {
    "name": "Disclosed Vendors",
    "key": "disclosed_vendors",
    "optional": true,
    "fields": [
      {
        "type": "segment_type",
        "description": "DisclosedVendors segment is 1 which is 001 in binary.",
        "key": "disclosed_vendors_segment_type",
        "value": 1
      },
      {
        "type": "optimized_array_of_u16_ranges",
        "description": "Vendors Disclosure",
        "key": "disclosed_vendors"
      }
    ]
  }

Each segment has name, key, optional and fields properties, where the all property except optional mandatory ones.

Schema Validation

The consent string schema library provides validator function that validates schemas using 3 steps:

• validate schema structure using zod library
• validate schema types
• validate schema keys

Structure validation

We use zod to define the consent string schema structure and also control types. For example, there is field definition using zod:

import { z } from 'zod';

export const availableTypesSchema = z.nativeEnum(SchemaTypes);

export const typesSchema = uniqueNotEmptyArray(availableTypesSchema);

export const consentStringTypeSchema = z.enum([
  'didomi_consent_string',
  'iab_tcf_string',
  'gpp_string',
]);

export const variantsTypes = z.enum([SchemaTypes.bit_field_2_bits, SchemaTypes.ranges_fibonacci, SchemaTypes.ranges_u16]);

export const variantsSchema = uniqueNotEmptyArray(variantsTypes);

export const fieldSchema = z.object({
  type: availableTypesSchema,
  description: z.string(),
  key: z.string(),
  optional: z.boolean().optional(),
  size: z.number().or(z.string()).optional(),
  value: z.number().optional(),
  variants: variantsSchema.optional()
});

This schema ensures the type property contains only permitted types, and the variants property contains exactly three allowed types.

Type validation

While zod validates types, the schema must also ensure all types in its types array are used in field definitions, and that all field types are listed in the types array. This mirrors programming languages, where types are defined before use and unused definitions may trigger warnings or errors. The library's typeValidator enforces this constraint after zod validation.

Key validation

The last validation step need to ensure that all keys in the fields definition unique. The library's keyValidator runs after the typeValidator to enforces this constraint.