Consent string clarifications

[lamrowena]

• Additional guidance for regional policy writers on the naming convention for fields in their sections (Addresses #5)
• Encoding clarifications, fixed incorrect headers in GPP String Examples 1 and 2 (Addresses #6, #44, #61)
• Formatting updates

[janwinkler]

This sounds not good (2x in the text): "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." sugestion: "Convert the bit sequence into strings by taking each 6 bits, convert the 6 bits into an integer and use this integer as the index of the character in the base64-websafe table."

And if possible, I'd (visually) highlight this much more: "Note that neither the header nor the recommended encodin ..."

[janwinkler]

@lamrowena The description for N-Bitfield is missing in the field definitions table. Since we are already using it in all US states/nation, we should add it (i was under the impression it was already in there!?)

[jaredmoscow]

@janwinkler thanks for both comments, rowena is still on holiday until july 17th. we should be able to make the final tweaks and merge the PR when she's back.

1. To convert the bit sequence into strings, start by taking each 6 bits, convert the 6 bits into an integer, and use this integer as the index of the character in the base64-websafe table
2. Looks like there is already a verified change for the N-Bitfield item that is part of this PR. N-bitfield data type clarification

[janwinkler]

Hmm, yes, in the version that you linked there is this change with the n-bitfield, but if i look at the "final" version (https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/pull/83/files) the change is not in there

[kasmith-roku]

I'd like to point out that this policy for adding padding only exists for the purposes of encoding, and there is no explicit policy around how to handle incomplete/truncated GPP Strings when decoding.

I don't believe the onus should be on the receiver of GPP Strings to introduce padding to allow for proper decoding as this has the potential to introduce consent signals that were not originally passed and introduces liability/risk to the decoder by manipulating/assuming consent status.

Making an explicit policy that GPP Strings should not be truncated once properly encoded would address some edge cases from handling malformed strings.

[janwinkler]

@kasmith-roku actually there is never any padding. the problem here is that we do not use base64 (which would have padding) but instead use a way that is veeeeerrrrry similar to base64. the challange is to tell people explicitly that they should NOT use base64 (or if they do, they must check that padding is added/removed in a correct way)

[janwinkler]

my preference would be to remove all wording of "base64" from the spec. this way nobody gets confused

[janwinkler]

You have updated the examples but missed out the "Full GPP String" example ;-)

E.g. it says "Encoded header: DBABM" but then "Full GPP String: DBABMA~...."

[lamrowena]

@janwinkler fixed that last example, thanks for catching that

[jaredmoscow]

@janwinkler can you confirm all examples are now correct and this is ready to merge?

[janwinkler]

go go go :-)