From addf5eb695d308e4421a498bd5b661a35b09b406 Mon Sep 17 00:00:00 2001 From: lamrowena <108421200+lamrowena@users.noreply.github.com> Date: Wed, 28 Jun 2023 19:49:50 -0400 Subject: [PATCH 01/12] Naming of fields clarification Additional guidance for regional policy writers on the naming convention for fields in their sections --- Core/Consent String Specification.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Core/Consent String Specification.md b/Core/Consent String Specification.md index 1b0ff6a..b614dbf 100644 --- a/Core/Consent String Specification.md +++ b/Core/Consent String Specification.md @@ -364,7 +364,6 @@ Based on the Section ID table above, the Section ID for Canadian TCF is 5 and t Discrete sections are used to support multiple signals from one architecture while maintaining the ability to modify each section as needed. - Each string section is scoped to the same body that updates the spec. This allows for regional sovereignty policies to make changes that might include more delimited information. For example, if TCF needs a version 3 and eliminates the concept of “out of band” vendors—which would result in the removal of DisclosedVendors and AllowedVendors—that should not require a version bump to the GPP string specification. @@ -528,14 +527,14 @@ Note: items MUST be in sorted order..
  • If the second data type is 1/true, the third data type is an Int Range
  • If the second data type is 0/false, the second data type is a bitfield of length determined by the first data type (see above)
    • - Note: This data type is used for downwards compatibility only. OptimizedRange is the recommended data type to be used moving forward. + Note: This data type is used for downward compatibility only. OptimizedRange is the recommended data type to be used moving forward. -When defining a new Section, regional policy writers should consider the above format to describe their section. +When defining a new section, regional policy writers should consider the above format to describe their section. Policy writers must ensure that each field within the section has a name that is unique for this section. When using multiple sub-sections within the section, field names with similar meanings (such as "type" or "version") shall be prefixed in order to be unique for the section (e.g. "coreVersion" and "publisherVersion"). From 915d1356150c81c7de314fbd409673e0ed56689d Mon Sep 17 00:00:00 2001 From: lamrowena <108421200+lamrowena@users.noreply.github.com> Date: Wed, 28 Jun 2023 21:25:08 -0400 Subject: [PATCH 02/12] Encoding clarifications and example corrections Encoding clarifications, fixed incorrect headers in GPP String Examples 1 and 2 --- Core/Consent String Specification.md | 55 +++++++++++++++++----------- 1 file changed, 34 insertions(+), 21 deletions(-) diff --git a/Core/Consent String Specification.md b/Core/Consent String Specification.md index b614dbf..96edf92 100644 --- a/Core/Consent String Specification.md +++ b/Core/Consent String Specification.md @@ -23,13 +23,13 @@ This document is one of the IAB Tech Lab Global Privacy Platform Specifications. It defines the technical implementation of the structure and encoding for a Global Privacy Platform String (GPP String). -# Additional Reading and Referenced Documents +### Additional Reading and Referenced Documents - [Consent Management Platform JS API](https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/CMP%20API%20Specification.md) - [GPP Sections](https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/tree/main/Sections) -# Updates to Standards Needed to Support GPP +### Updates to Standards Needed to Support GPP Updates were made to existing IAB Tech Lab standards to support the Global Privacy Platform. These updates are based on industry consensus, driven by relevant IAB Tech Lab working groups, including the Global Privacy Working Group and Programmatic Supply Chain Working Group. They include: @@ -40,12 +40,12 @@ GPP assumes the use of OpenRTB 2.x. - Like other existing privacy signals (TCF and USPrivacy), the GPP string is also able to be transported via OpenRTB. This will be included in the Regs object in the November 2022 release. See this [document](https://github.com/InteractiveAdvertisingBureau/openrtb/tree/master/extensions/community_extensions) for approved design prior to release. -## About the Global Privacy Platform +### About the Global Privacy Platform The Global Privacy Platform (GPP) enables advertisers, publishers and technology vendors in the digital advertising industry to adapt to regulatory demands across markets. It is a single protocol designed to streamline transmitting privacy, consent, and consumer choice signals from sites and apps to ad tech providers. IAB Tech Lab stewards the development of these technical specifications. -## About IAB Tech Lab +### About IAB Tech Lab The IAB Technology Laboratory (Tech Lab) is a non-profit consortium that engages a member community globally to develop foundational technology and standards that enable growth and trust in the digital media ecosystem. Comprised of digital publishers, ad technology firms, agencies, marketers, and other member companies, IAB Tech Lab focuses on improving the digital advertising supply chain, measurement, and consumer experiences, while promoting responsible use of data. Its work includes the OpenRTB real-time bidding protocol, ads.txt anti-fraud specification, Open Measurement SDK for viewability and verification, VAST video specification, and DigiTrust identity service. Established in 2014, the IAB Tech Lab is headquartered in New York City with staff in San Francisco, Seattle, and London. @@ -68,11 +68,11 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT In the GPP, a GPP String is used to encapsulate relevant details about transparency and consumer choice and encoded as it applies for each [supported regional or other signal](https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/tree/main/Sections). This document specifies how that string must be formatted and how it must be used. -# What purpose does a GPP String serve? +### What purpose does a GPP String serve? A GPP String’s primary purpose is to encapsulate and encode all the information disclosed to a user and the expression of their choices, for all applicable regions. Using a Consent Management Platform (CMP), the information is captured into an encoded and compact HTTP-transferable string. This string enables communication of the consumer's choices from sites and apps to ad tech providers. Ad tech providers decode a GPP String to determine whether they have the necessary requirements to process a user’s personal data for their purposes. -# What information is stored in a GPP String? +### What information is stored in a GPP String? Version 1 of the GPP String contains the following information: @@ -87,7 +87,7 @@ Section specifications will clearly define which of the above data are represent See [“Discrete Sections”](#discretesections) below for more detail. -# Who should create a GPP String? +### Who should create a GPP String? Digital property owners or CMPs are responsible for generating, persisting, and passing the GPP String. Vendors or any other third-party service providers must neither create nor alter GPP Strings. @@ -173,18 +173,33 @@ To decode a code word, remove the final "1", assign the remaining values 1,2,3,5 The following details provide information on creating, storing, and managing a GPP String. The basic steps for creating a GPP String are as follows: -1. **Create discrete sections.** For each section: - - For sections that use the recommended base64-websafe encoding, create a bit representation of the section’s header (if it exists) and each sub-section adding padding (0) on the right to get to a multiple of 6. Then, convert them to base64-websafe without padding (i.e. removing “=” at the end) and concatenate the header and all sub-sections using the “.” (dot) character. - - For sections that use different encoding, ensure that the data is websafe and does not include the “~” (tilde) character. -2. **Create header section.** Create a bit representation of the GPP header section. Include all IDs for discrete sections in a sorted order. Add padding (0) on the right to get to a multiple of 6. Then, convert it to base64-websafe without padding. -3. **Concatenate all sections.** Concatenate the GPP-header as the first item to the encoded versions of the discrete sections using “~” (tilde) as the delimiter. - - -# How should the GPP String be stored? +
      +
    1. Create discrete sections. + +
      2. +
    2. Create header section. +
        +
      1. Create a bit representation of the GPP header section including all Section IDs for discrete sections in a sorted order.
        2. +
      2. Add padding (0) on the right to get to a multiple of 6.
        3. +
      3. Convert the integer into a character where the integer is the index of the character in the base64-websafe table.
        4. +
      3. +
    3. Concatenate all sections. Concatenate the encoded GPP header as the first item to the encoded versions of the discrete sections using “~” (tilde) as the delimiter.
      4. +
    + + +### How should the GPP String be stored? The storage mechanism used for GPP Strings is up to a CMP, including any non-cookie storage mechanism. -# GPP String Format +### GPP String Format The GPP string is comprised of distinct sections joined together on a “~” (tilde) character. @@ -230,7 +245,7 @@ The Header is always required and always comes first. It consists of the followi - + @@ -277,8 +292,6 @@ Based on the Section ID table above, the Section ID for EU TCF v2 is 2. -**Header Example 2** -
    Sections Range(Fibonacci)List of Section IDs that are contained in the GPP string. Each ID represents a discrete Section that will be concatenated to the Header Section. The IDs must be represented in the order the related Sections appear in the string. This is required to make real time string processing less resource intensive.List of Section IDs that are contained in the GPP string. Each ID represents a discrete section that will be concatenated to the Header Section. The IDs must be represented in the order the related sections appear in the string. This is required to make real-time string processing less resource intensive.
    @@ -599,7 +612,7 @@ Using the same cases as in the [Header Examples](#header) above, the following e - + @@ -623,7 +636,7 @@ Using the same cases as in the [Header Examples](#header) above, the following e - + From ff21f0adc470a9275c5b38312b9e7e8543d5b568 Mon Sep 17 00:00:00 2001 From: lamrowena <108421200+lamrowena@users.noreply.github.com> Date: Wed, 28 Jun 2023 21:44:51 -0400 Subject: [PATCH 03/12] N-bitfield data type clarification Updated name of data type Variable length bitfield to N-Bitfield since that is what is listed in the US state specifications. --- Core/Consent String Specification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Core/Consent String Specification.md b/Core/Consent String Specification.md index 96edf92..76684f2 100644 --- a/Core/Consent String Specification.md +++ b/Core/Consent String Specification.md @@ -458,7 +458,7 @@ The possible data types are: - + From 8adfaafb96fa427bb59ac77ea6c7eaf18320c4e1 Mon Sep 17 00:00:00 2001 From: lamrowena <108421200+lamrowena@users.noreply.github.com> Date: Wed, 28 Jun 2023 21:49:35 -0400 Subject: [PATCH 04/12] Revert "N-bitfield data type clarification" This reverts commit ff21f0adc470a9275c5b38312b9e7e8543d5b568. --- Core/Consent String Specification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Core/Consent String Specification.md b/Core/Consent String Specification.md index 76684f2..96edf92 100644 --- a/Core/Consent String Specification.md +++ b/Core/Consent String Specification.md @@ -458,7 +458,7 @@ The possible data types are: - + From 7ae7853c7577f32db6db5c7fa1c3794eb99c3c4b Mon Sep 17 00:00:00 2001 From: lamrowena <108421200+lamrowena@users.noreply.github.com> Date: Sun, 2 Jul 2023 23:25:55 -0400 Subject: [PATCH 05/12] Further encoding clarifications Updates to address feedback on encoding clarifications --- Core/Consent String Specification.md | 30 +++++++++++++++++----------- 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/Core/Consent String Specification.md b/Core/Consent String Specification.md index 96edf92..81b5c3e 100644 --- a/Core/Consent String Specification.md +++ b/Core/Consent String Specification.md @@ -13,6 +13,11 @@ + + + + +
    Header Example 2
    Encoded header:
    DBABMA    		Encoded header:
    DBABM
    Full GPP String:

    DBABMA~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA
    Encoded header:

    DBACNYA    		Encoded header:

    DBACNY
    Full GPP String:

    DBACNYA~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN
    Variable length BitfieldN-Bitfield (variable length bitfield) variable Array of Number Consists of two datapoints: a fixed length Integer(16) that denotes the length and a bitfield with that specific length.

    Please note: Although the API reads/writes to fields (length + bitfield), it will only output the IDs from the bitfield via JS APIs.
    N-Bitfield (variable length bitfield)Variable length Bitfield variable Array of Number Consists of two datapoints: a fixed length Integer(16) that denotes the length and a bitfield with that specific length.

    Please note: Although the API reads/writes to fields (length + bitfield), it will only output the IDs from the bitfield via JS APIs.    		Sept 28, 2022 1.0 Published final public version
    July 20231.0Added clarifications to encoding mechanism, fixed encoded header examples
    @@ -178,22 +183,23 @@ The following details provide information on creating, storing, and managing a G -
  • Create header section. +
  • Create header section. See examples of the header section below.
    1. Create a bit representation of the GPP header section including all Section IDs for discrete sections in a sorted order.
      2. -
    2. Add padding (0) on the right to get to a multiple of 6.
      3. -
    3. Convert the integer into a character where the integer is the index of the character in the base64-websafe table.
      4. +
    4. Add padding (0) on the right to get to a total bit length that is a multiple of 6.
      5. +
    5. Convert the integer to convert the six bit sequence into a character where the integer is the index of the character in the base64-websafe table.
    • -
  • Concatenate all sections. Concatenate the encoded GPP header as the first item to the encoded versions of the discrete sections using “~” (tilde) as the delimiter.
    • +
  • Concatenate all sections. Concatenate the encoded GPP header as the first item to the encoded versions of the discrete sections using “~” (tilde) as the delimiter. See examples of GPP strings below.
    • +Note that neither the header nor the recommended encoding mechanism for a discrete section utilizes base64 encoding but rather a modified version of it. ### How should the GPP String be stored? @@ -207,20 +213,20 @@ The string must contain a header and applicable discrete section(s): [Header]~[Discrete Section] -**Header** +#### **Header** The header is always required and comes first. The purpose of the Header is to identify which sections are included in a string payload and be a table of contents of where to find each signal in the string payload (broken into discrete sections). It is basically an ordered list of discrete sections that equate to different regions, countries or policies. It lets readers understand what is present in the string and in what order. (See [Discrete Sections](https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/Consent%20String%20Specification.md#discrete-sections-) below) The header contains only a GPP version, the section ID(s) and index of the place of the associated section in the string. The header delegates regional policy versions and technical encoding versions to each substring section so that each may develop independently of each other and the header design. (See [Discrete Sections](https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/Consent%20String%20Specification.md#discrete-sections-) below) -**Section IDs** +#### **Section IDs** For the full list of Section IDs, see [Section information](https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Sections/Section%20Information.md). -**Header Encoding** +#### **Header Encoding** The Header is always required and always comes first. It consists of the following encoded fields and uses Fibonacci encoding. For more information about [Fibonacci Encoding](#fibonacci), see the “About Fibonacci Encoding” section. @@ -252,7 +258,7 @@ The Header is always required and always comes first. It consists of the followi -**Header Examples** +#### **Header Examples** From 5360bab50f213505e60416c1dcfa2a1d37cc4980 Mon Sep 17 00:00:00 2001 From: Jared Moscow <126587246+jaredmoscow@users.noreply.github.com> Date: Mon, 24 Jul 2023 10:26:07 -0400 Subject: [PATCH 06/12] Addition of CMP ID description and examples Added the CMP ID information to explain how CMP IDs should be used based on CMP registration requirements. --- Core/CMP API Specification.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/Core/CMP API Specification.md b/Core/CMP API Specification.md index cf152ee..c6234d7 100644 --- a/Core/CMP API Specification.md +++ b/Core/CMP API Specification.md @@ -113,6 +113,18 @@ Requirements for the interface: All CMPs must support all generic commands. Generic commands are commands that can be used independent of [section specifications](https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Sections/SectionInformation.md). All generic commands must always be executed immediately without any asynchronous logic and call the supplied callback function immediately. The generic commands are: [‘ping’](#ping), [‘addEventListener’](#addeventlistener), [‘removeEventListener’](#removeeventlistener), [‘hasSection’](#hassection), [‘getSection’](#getsection), and [‘getField’](#getfield). + +### What is CMP ID? + + +Regional section policy writers may require CMPs to register to operate within the policies for that section. In these cases, CMP IDs must be used if the CMP has an ID. For CMPs that are not registered, a value of 1 must be used by string creators who do not have a CMP ID and are not using a commercially available CMP. + +**Examples:** + +Publisher A looking to create a GPP string that will contain the section for the US National approach must use 1 as value for CMP ID since the MSPA does not have CMP registration requirements. + +Publisher B looking to create a GPP string that will contain sections for the US National approach or the TCF EU must register themselves or work with a registered CMP and use the assigned CMP ID in accordance with the TCF Policies. + ________ #### `ping` @@ -166,7 +178,7 @@ signalStatus : String, // possible values: not ready, ready supportedAPIs : Array of string, // list of supported APIs (section ids and prefix strings), e.g. used while loading. Example: ["2:tcfeuv2","6:uspv1"] -cmpId : Number, // IAB assigned CMP ID, may be 0 during stub/loading +cmpId : Number, // IAB assigned CMP ID, may be 0 during stub/loading. Reference the above CMP ID section for additional information. sectionList : Array of Number, // may be empty during loading of the CMP From 4824ee4e3c03a1f27a7cd07fb2bc2925b8958a27 Mon Sep 17 00:00:00 2001 From: Jared Moscow <126587246+jaredmoscow@users.noreply.github.com> Date: Mon, 24 Jul 2023 10:44:13 -0400 Subject: [PATCH 07/12] GPP macro substitution clarification Added clarification to the consent string spec on the use of the GPP ID and examples of including vs. excluding the ID. This is related to issue #60 --- Core/Consent String Specification.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Core/Consent String Specification.md b/Core/Consent String Specification.md index 1b0ff6a..c353f9b 100644 --- a/Core/Consent String Specification.md +++ b/Core/Consent String Specification.md @@ -700,14 +700,20 @@ Since the pixel is in an tag without the ability to execute Javascript, th - `${GPP_STRING_XXXXX}` where `XXXXX` is the numeric GPP ID of the vendor receiving the string. - The applicable GPP Section ID must also be inserted, where the ${GPP_SID}macro is present. -For example, for Vendor A with ID 123 to receive a GPP String which includes the EU TCF v2 as applicable section, an image URL must include two key-value pairs with the URL parameters and macros `gpp=${GPP_STRING_123}` and `gpp_sid=${GPP_SID}`. +Vendors not registered to participate in any framework supported by the Global Privacy Platform (e.g. MSPA, TCF CA, TCF EU) may pass ${GPP_STRING} without the GPP ID. Vendors who are registered to participate and have a GPP ID must include it in the macro. When vendors that are callers–who have the option to expand on the macros–are deciding how to proceed with vendor callees not participating in a GPP supported framework (e.g. MSPA, TCF CA, TCF EU), vendors should reference each framework's policy. +**Example when ${GPP_STRING} rather than ${GPP_STRING_XXXXX}may be used:** -The resulting URL is: -`http://vendor-a.com/key1-val1&key2=val2&gpp=${GPP_STRING_123}&gpp_sid=${GPP_SID}` +The GPP String includes one of the US States sections or the US National section, but the string creator has indicated that the transaction is not covered by the MSPA. Vendors who do not participate in the MSPA may request the string, but may not have a GPP ID. In this case, ${GPP_STRING} may be used. + +**Example when ${GPP_STRING_XXXXX}is used:** +Vendor A with ID 123 to receive a GPP String which includes the EU TCF v2 as applicable section, an image URL must include two key-value pairs with the URL parameters and macros `gpp=${GPP_STRING_123}` and `gpp_sid=${GPP_SID}`. + +- The resulting URL is: +`http://vendor-a.com/key1-val1&key2=val2&gpp=${GPP_STRING_123}&gpp_sid=${GPP_SID}` -If the GPP String is: +- If the GPP String is: `DBACNYA~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN` From fb37df960cca523aa2ac15ef15d2e6f98aed433e Mon Sep 17 00:00:00 2001 From: lamrowena <108421200+lamrowena@users.noreply.github.com> Date: Fri, 8 Sep 2023 11:29:49 -0400 Subject: [PATCH 08/12] Added Base64 table --- Core/Consent String Specification.md | 200 ++++++++++++++++++++++++++- 1 file changed, 194 insertions(+), 6 deletions(-) diff --git a/Core/Consent String Specification.md b/Core/Consent String Specification.md index 81b5c3e..969e435 100644 --- a/Core/Consent String Specification.md +++ b/Core/Consent String Specification.md @@ -15,7 +15,7 @@ - + @@ -183,9 +183,9 @@ The following details provide information on creating, storing, and managing a G @@ -193,14 +193,202 @@ The following details provide information on creating, storing, and managing a G
  • Create header section. See examples of the header section below.
    1. Create a bit representation of the GPP header section including all Section IDs for discrete sections in a sorted order.
      2. -
    2. Add padding (0) on the right to get to a total bit length that is a multiple of 6.
      3. -
    3. Convert the integer to convert the six bit sequence into a character where the integer is the index of the character in the base64-websafe table.
      4. +
    4. Add padding (0) on the right to get to a total bit length that is a multiple of 6 bits.
      5. +
    5. Convert the integer to convert the six bit sequence into a character where the integer is the index of the character in the table below.
  • Concatenate all sections. Concatenate the encoded GPP header as the first item to the encoded versions of the discrete sections using “~” (tilde) as the delimiter. See examples of GPP strings below.
    • Note that neither the header nor the recommended encoding mechanism for a discrete section utilizes base64 encoding but rather a modified version of it. +#### Base64 Table from RFC 4648 +
    +
    Published final public version
    July 2023September 15, 2023 1.0 Added clarifications to encoding mechanism, fixed encoded header examples
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ValueEncodingValueEncodingValueEncodingValueEncoding
    0A17R34i51z
    1B18S35j520
    2C19T36k531
    3D20U37l542
    4E21V38m553
    5F22W39n564
    6G23X40o575
    7H24Y41p586
    8I25Z42q597
    9J26a43r608
    10K27b44s619
    11L28c45t62+
    12M29d46u63/
    13N30e47v  
    14O31f48w(pad)=
    15P32g49x  
    16Q33h50y  
    + + ### How should the GPP String be stored? The storage mechanism used for GPP Strings is up to a CMP, including any non-cookie storage mechanism. From 1e92cebd9abf21fb5eec6fcdf55e4f379acd9458 Mon Sep 17 00:00:00 2001 From: lamrowena <108421200+lamrowena@users.noreply.github.com> Date: Fri, 8 Sep 2023 12:35:12 -0400 Subject: [PATCH 09/12] N-bitfield data type clarification Updated name of data type Variable length bitfield to N-Bitfield since that is what is listed in the US state specifications. --- Core/Consent String Specification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Core/Consent String Specification.md b/Core/Consent String Specification.md index 969e435..82b745b 100644 --- a/Core/Consent String Specification.md +++ b/Core/Consent String Specification.md @@ -652,7 +652,7 @@ The possible data types are: - Variable length Bitfield + N-bitfield (Variable length Bitfield) variable Array of Number Consists of two datapoints: a fixed length Integer(16) that denotes the length and a bitfield with that specific length.

    Please note: Although the API reads/writes to fields (length + bitfield), it will only output the IDs from the bitfield via JS APIs. From fe39b955ffaade75810d517240ae619c4df8ba0c Mon Sep 17 00:00:00 2001 From: lamrowena <108421200+lamrowena@users.noreply.github.com> Date: Fri, 8 Sep 2023 16:56:38 -0400 Subject: [PATCH 10/12] Fixed full GPP string example --- Core/Consent String Specification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Core/Consent String Specification.md b/Core/Consent String Specification.md index 82b745b..f605fee 100644 --- a/Core/Consent String Specification.md +++ b/Core/Consent String Specification.md @@ -809,7 +809,7 @@ Using the same cases as in the [Header Examples](#header) above, the following e Encoded header:
    DBABM - Full GPP String:

    DBABMA~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA + Full GPP String:

    DBABM~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA From ebc78d2e6954af40b9a62c34a9c3a9e2d4461647 Mon Sep 17 00:00:00 2001 From: lamrowena <108421200+lamrowena@users.noreply.github.com> Date: Fri, 3 Nov 2023 09:57:13 -0400 Subject: [PATCH 11/12] Fixed string example Fixed conflicting string example --- Core/Consent String Specification.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Core/Consent String Specification.md b/Core/Consent String Specification.md index f605fee..bd4a06b 100644 --- a/Core/Consent String Specification.md +++ b/Core/Consent String Specification.md @@ -15,7 +15,7 @@ Published final public version - September 15, 2023 + Nov 3, 2023 1.0 Added clarifications to encoding mechanism, fixed encoded header examples @@ -833,7 +833,7 @@ Using the same cases as in the [Header Examples](#header) above, the following e Encoded header:

    DBACNY - Full GPP String:

    DBACNYA~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN + Full GPP String:

    DBACNY~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN From 4cfb1eb4dce2d23138b872da523e556f57885f3a Mon Sep 17 00:00:00 2001 From: lamrowena <108421200+lamrowena@users.noreply.github.com> Date: Fri, 3 Nov 2023 10:52:32 -0400 Subject: [PATCH 12/12] Updated Table Name --- Core/Consent String Specification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Core/Consent String Specification.md b/Core/Consent String Specification.md index f47b47c..014ab83 100644 --- a/Core/Consent String Specification.md +++ b/Core/Consent String Specification.md @@ -201,7 +201,7 @@ The following details provide information on creating, storing, and managing a G Note that neither the header nor the recommended encoding mechanism for a discrete section utilizes base64 encoding but rather a modified version of it. -#### Base64 Table from RFC 4648 +#### Table from RFC 4648