This page contains samples of different consent strings that can be generated as part of the binary Didomi Consent String format under different scenarios.
Example #2: Consent String with only DID and Signature
Given Header, Purpose Consent, Purpose Legitimat Interest, Vendors Consent and Vendors Legitimate Interest sections bit encoded in the first segment:
After the first . there is a Device ID (DID):
and finally, having no OUID, the last segment after the ~ is the signature:
Putting this all together, the final consent string would look like:
Example #3: Consent String with only OUID and Signature
Given Header, Purpose Consent, Purpose Legitimat Interest, Vendors Consent and Vendors Legitimate Interest sections bit encoded in the first segment:
Even though we don’t have a DID, we still store a first . as a placeholder to represent a nullable optional DID here, which will contain no information. We will then add a second . characterm indicating that there is an Organization User ID (OUID):
and finally, the last segment after the ~ is the signature:
Putting this all together, the final consent string would look like:
Example #4: Consent String with no IDs, only Signature
Given Header, Purpose Consent, Purpose Legitimat Interest, Vendors Consent and Vendors Legitimate Interest sections bit encoded in the first segment:
Since we have neither a DID nor an OUID, we will not store any . placeholders. We will directly add the final segment after the ~ which is the signature:
Putting this all together, the final consent string would look like:
Example #5 - Decoded Consent String
Final Encoding Example
When stored or transmitted, the Consent String binary format is encoded as web-safe base64 with the following character set: