Status: In reviewed by the WG.

Summary Overview 

The v1.2 consent receipt is a record of a notice, created when a person interacts with it, reads it online, or uses a QR code sign.   It is used to mirror (twin) privacy and surveillance notices, notifications and disclosures (like cookie pop-ups) so that the user agent (like a browser) can remember the privacy preferences and valid consent state.  This specification illustrates how a person (PII Principle) can generate a consent receipt for any service.  The prefix of the receipt, called an ANCR record, is created first then  used to generate a Consent Receipt.  This helps people capture the state of notice and processing so it can be used by the PII Principal for proof of notice and the PII Controller (Service) as evidence of consent.    Reducing contract  frictions, costs, privacy risks and surveillance. 

This long worked on update to the Consent Receipt information structure aims to address the known challenges for a consented surveillance receipt system.  in this regard, the CR v1.2 specification addresses known surveillance security and digital privacy usability challenges with Consent by Design for a more dynamic data approach.   The consent receipt and anchor record have an ID, used as a key value pair, to assure control over transparency with receipts.  Useful to asses trustworthiness of invisibly embedded online services.

Consent receipt are used for computational privacy, calculating privacy rights, assessing valid consent state, and harvesting  controller + service information by purpose. 


The Consent Receipt v1.2 is specified for devoting scalable and dynamic data processing controls and authorizations with privacy rights.  It is based on the OECD Guidelines on the Protection of Privacy and the Transborder Flows of Personal Data and is apart of a body of work for privacy standards and assurance developed over the 20 + years.  and guided the harmonization of privacy law in the EU and internationally. The OECD Guidelines is closely tied with the Council of Europe's  CoE 108+ (an international privacy agreement), and importantly ISO/IEC 29100, which is interpreted as a security framework extension to encompass the scope of privacy in information technology.  

The OECD guidelines are formalized with  the ISO/IEC 29100:2011 Information technology — Security techniques — Privacy framework, for common terms and definitions, further made accessible as it is released as A Public  ISO Document.   Providing a mature and common semantic framework to refer to the privacy stakeholder relationships in notice and consent records. 

The Consent Receipt v1.2 is the culmination of work over the last 5 years updating the v1.1.  The V1.2 is  better described here as a record of a Privacy Notice and is specified using the OECD Guidelines through the use of ISO/IEC 29100. 

The receipt is generated upon interacting with a Privacy Notice so that a person can capture evidence of reading a notice, and be used to assess conformance to privacy law, or with  ISO/IEC 29184:2020 Online Privacy Notice and Consent standard, which has published the Consent Notice Receipt v1.1 in Appendix B.

Consent by Design 

The Consent Receipt v1.2 is referred to as a Consent by Design specification because a legal state of consent to a purpose is required for the default receipt.  Any additional legal justification is then generated wth the Ancr receipt id'. The default legal justification can be changed to any valid legal justification for processing personal data provided by a notice, notification or disclosure.  The  Consent Receipt is used as a digital twin of the consent notice in which the legal justification (if not consent) is signalled to be presented to the PII Principle to inform of the data processing.  

Note: The consent receipt is used to capture the use of the legal justification for a specified and specific purpose.  One legal justification and one purpose (or purpose bundle) per Consent Receipt. 

V1.2  Overview 

Specification Structure,

The v1.2 is written for a legal Case Study to design  the Consent Receipt to provide proof of notice and evidence of consent for digital identity management systems.  The required fields for this record structure are provided below and referenced to Privacy Notice legal requirements and privacy agreements (which are multi-national privacy laws). Thus defining the core scope of the  Consent Receipt Schema.

 In addition, Technical use cases are defined (WID) to provide Consent receipt extension for specific context and notice requirements. 

In this proposed V1.2 Receipt Structure, the receipt record structure has been broken down into 5 Sections, each section in sequence of generating a consent receipt for any online privacy notice and legal justification,  connecting regulation, with codified practice between privacy jurisdictions. 

  1. Anchor Record (the prefix of the receipt)
  2. Purpose Specification
  3. Consented Data Control, Protection & Treatment  
  4. Optional Field
  5. UNCOL - Field Data structure, semantics, sources and descriptions

Section Summary

Section 1: Anchored Notice Record

The Consent Receipt in v1.1 was first drafted in 2014 to assess the conformance of the consent state for a specified purpose (now called a Consent Grant). Providing a proof of privacy notice.   

The term Anchored in v 1.2, or ANCR'd, refers to anchoring the PII Principal's Privacy Jurisdiction with a newly added Notice field object to the pre-fix of the Consent Receipt.  In this object the jurisdiction of the PII Principle dictates which versions of privacy rights regulation applies in context.   the PII Principle and the PII Controller is captured and then reused to generate consent receipts. Anchoring the data governance framework with privacy rights.  

In the Consent Receipt v1.2 specification the PII Principal (or agent), creates an anchored notice record from a privacy notice and uses this record to generate a consent receipt.  ANCR notice records and Consent Receipts are generated when a PII Principle interacts with a privacy notice, notification or disclosure in context of data capture and processing

The Consent Receipt v1.2 is predicated on transparency of V1.1, but expands the consent record information structure to include the require fields for evidence of consent for transborder flows of personal information.  The receipt also can include a copy or capture of all the layers of the notice provided.  

Anchoring Privacy Expectations to  PII Principal's context and understanding and capture the notice, permissions and preferences offered to better asses their performance, compliance and privacy risk assurance. 

Section 2: Consent Purpose Specification 

In the Consent Receipt v1.2, the default legal justification is consent and the purpose specification fields are for the most part the same as v1.1.  Except that a legal justification other than consent can be specified to provide the purpose context.   The GDPR, which was published and implemented in 2016 after the consent receipt v1.1 was written,  presented 6 legal justifications for processing which was subsequently adopted in a generic form in ISO/IEC 29184, these 6 legal justifications are used to specify the privacy rights which are applicable to the specific personal data processing or in terms of the ISO 29100 security framework, the surveillance context.    The rights are then listed with the legal justification in the next section of the receipt.  

The GDPR rights specification are used here for example, as a privacy agreement enforced in many countries it provides the current International standard for privacy rights.  

Note:  A consent receipt can be specified for only one legal justification  and one purpose (or purpose bundle). 

Section 3: Consented Data Control, Protection & Treatment

This section is an expansion of the receipt fields to further specify the scope of the legal processing of personal information for a specified purpose.  Assuring a purpose limitation principle. 

 of Provides the fields for the technical capture of personal data processing, separating storage, access and privacy rights that apply for the specified legal justification and context.

This section includes additional fields for specifying privacy rights that are available and the scope of permission that are accessible to the PII Principle. 

Section 4: Description of Code of Conduct or Practice (Optional)

Extending the Privacy Agreement (or legislation) with a technical code of conduct or practice,  notification with additional safeguards and measures that provide additional privacy assurances, in addition to a more streamlined privacy service user experience.

Optional elements specified

  1. A code of conduct, which extends privacy legislation and is approved by a privacy regulator. 
  2. a code of practice, which extends a specified purpose with additional codified practices which are either specified by the Notice Controller, or with a certified and audited/auditable practice. 

These additional options can be used to bundle like purposes together, specify each purpose for a consistent and standard processing, streamline experiencial use by presenting enhanced practices with a valid/authorised badge, icon, or micro-credential. .

Section 5: Field Input Source Data Field Types (UNCOL)

The field data sources for the Consent Receipt are  specified with, OECD Guidelines, Standards, regulatory guidance and legislation.

The long term aim of this section is to Unify the Notice Control   Language (UNCL) iterating towards a notice centric Ontology. Mapping privacy agreement vocabularies with the ISO 29100 terms and definitions and W3C Data Privacy Vocabulary, for machine readable semantics. 

Consent Receipt v1.2x to V 2 (implementation approach) 

Advance the core legal record and receipt field set with implementation specific Use Cases that include providing a notice, notification and disclosure profile for the use case with this specification. 

The consent record structure is further informed by the Privacy as Expected signalling use case in this v1.2 specification.  

Key points of clarity and fields added include;

  1. ANCR Record prefix is created, captured or inferred in order for a PII Principal to create a  record of of a Notice, and with this record be able to generate consent receipts, legally referred to in this specification as a Proof of Notice, which is missing from most identifier management accounts in online services - typified by opt-in checkbox to terms and privacy policies.  In this manner this  v of the Consent Receipt achieves its original objective of addressing the Biggest Lie on the Internet
  2.  A proof of notice can be verified, validated and notarized as a Consent Receipt in order to capturing and assess if the state of consent is valid, and to subsequently measure the  performance of consented Privacy rights for each service, providing identity management system
  3. A Consent Receipt, generated for each session based interaction with a service provider, when compared to its predecessor, automates a Privacy as Expected Signal by displaying if there is a difference or not. 

Section 1: Anchored Notice Record (Consent Receipt Pre-Fix)

Data Element Label 

Data Type 

Description of data capture element. 

Example Input 


ANCR Record ID 


This the id of the rec ANRC record the receipt is generated from, contains the controller and notice required fields 


A unique no. for each Notice Receipt. Should use UUID-4  [RFC 4122]  

Reg# A23456789  

✓ BT 

Online Privacy Notice  


This object contains information about the privacy notice physical and online location to connect the physical and digital notice in this receipt 

The object contains information of the Notice Location in the following fields: 

Field Name 

Data Type 


Example Input 


Notice response Options 


Ignore is the default, accept, reject, privacy rights info access 





Physical and/or digital address URI- of where notice was read 


✓ BT 



Physical and/or digital address URI- 


✓ BT 

Geo-Location Notice is Read 







Online Privacy Notice Record – log or ledger of  privacy policy changes.   



PrivaNotice HashLink 


Physical and/or digital address URI- 



Notice Container 


Notice Container, in the hashlink/trust notice container .  






Consented Notice Timestamp 

number. Integer number of seconds since 1970-01-01 00:00:00 GMT 

Timestamp of when the consent was issued 



ANCR Schema Version 


The current version of the receipt 

Version 1 


Signing key 


 Public Key Used to Sign





The language the notice was presented in  

English, Spanish  


Privacy   Jurisdiction 


Privacy Rights Regulation for the location the notice was physically read, used for privacy agreement PII Principal expects.  

GDPR (privacy agreement) 


Notice Record 


URI of the Online privacy notice record presented by the PII Principal.  Linking to contact and privacy rights access and use information. 



PII Controller 


PII controller (or data controller:29100)  is a legal entity who through an accountable person (either alone. or jointly or in common with other accountable persons) provides privacy notice and determines the purposes for which and the. manner in which, any personal data are, or are to be, collected, processed and disclosed.  


The object contains information of the PII Controller in the following fields: 

Field Name 

Data Type 


Example Input 


Privacy jurisdiction 


The PII jurisdiction 



Contact name  


Person or representative to contact for privacy rights access  

Jon Doe 




The legally registered company name  

Data Controller Inc. 




Contact email address 

123 Main St., Anywhere 






Contact email address 






Contact phone number 



 Privacy Policy 



Controller Specific URI contact point for identity, address, privacy rights jurisdiction,  access to privacy rights information 





Often website specific is a basic privacy policy 


Accountable Person Role 


e.g., CEO, Data Protection Officer, Data Protection Representative, trader  

Data Protection Representative  


Accountable Person Name 


 First, Last Name

John Controller  


Accountable person 3rd party Org, (y/n) 


If controller is the same employer or not?  Yes/No  
If no – use Privacy Controller Credential Spec  (security for use of rights ) 



Privacy Controller Extension 


Privacy Assurance Requirements

3 tiers of privacy assurance 

  • beneficial owner of process data
    • many parties 




End of ANCR Record 


The ANCR record is used to generate by default a consent receipt v1.1, with the legal justification for an ANCR record being a type of Consent specified by jurisdiction (aka its privacy agreement) and is backward compatible _insert remaining 1.1 fields here. 



Section 2 Consent Receipt – Purpose Specification 

Data Element

Data Type 

Description of Data Capture Element



Consent Receipt ID  


A unique no. for each Consent Receipt generated with an ANCR Record ID. Should use UUID-4 [RFC 4122]. Note, Can have many Consent Receipt ID’s linked to one ANCR Record ID. 


Legal Justification 


This can be further defined by context, for example implied, directed or altruistic.  In addition, the superseded or combined with additional legal justification for processing personal data.  Note can only be one  Purpose and 

The object contains information of the : 

Field Name 

Data Type 


Example Input 


Consent Type 


Implied, explicit,

Implied Consent 


Added Legal Justification for Processing  

The type of consent refers to the consent state of lifecycle of consent, This can be 1 of 5, Contract, legitimate interest, public interest, vital interest, legal obligation 

Legitimate interest 


Sensitive (or Special) PII Category

List of Personal Data Categories and Sub Categories is Maintained in the W3C DPV.  The contributed Personal Data Categories list to DPV was curated by this Work Group

  • Financial
  • Health
  • Religious
  • Criminal Record



Purpose Context 


Purpose context, (also known as purpose category), can also be the name of a service name, or brand name, or context generically. To assist PII Processor  and PII Principal in identifying the purpose of use. 

Context Website  

Purpose Type  


Type of purpose refers to the purpose category, for example: marketing  





The purpose description further defines /describes the purpose category. Also referred to as a purpose sub-category. 

Behavioral advertising    


Delegation of Consent 


Is the authority to approve the provision of consent or its derogation a delegated authority?  y/n 


The object contains information of the : 

Field Name 

Data Type 


Example Input 


PII Principle is a Child or Youth
Yes or No, When this child or youth flag is set, age appropriate privacy is required, with a straightforward procedure to withdraw consent, delete personal information and implement and enforce data retention schedules is required for Privacy AssuranceYes 

Delegated Authority Type,  

This is the authorized party title,  Parent, guardian, state authority   



Delegation Purpose  

 Age of PII Principal, Competence of PII Principal, Legal Status of PII Principal  

Parental Consent


Delegate Relationship to PII Principal 
Relationship to the PII Principal ; Mother

Delegate Name 

First  & Last Name 

Jane Doe


Delegate Contact 

 and contact point


Delegate Address

123 your dr
city, Country


Privacy Jurisdiction 

 If different  





Delegation of Processing

For high risk privacy assurance - sub-processors may be required to be listed- and change of sub-processors notified - 

Field Name 

Data Type 


Example Input 



To fill in, - the Sub-Processor service name or category,  privacy jurisdiction, contract type,  and authentication identifier type 

Payment service provider, USA, credit card 


PII/Data Category 


Also known as Personal Data Category.  The category, or categories of PII being processed and whether this is determined as special or sensitive PII category, according to the legal jurisdiction of the controller.  Link to Table


Field Name 

Data Type 


Example Input 


PII Category  

Name of PII Category, and if it is sensitive or special  

Children’s Data, Special 


PII sub-category   

Children's Health Data

Health Data, Sensitive   



PII Disclosures  


For processing PII for a purpose (what disclosures are required), disclosure categories of sub-processors and 3rd parties.   To supply or authorize the service, e.g.  a sub-processor is a relying party service and is contracted for the specified purpose as a sub-processor.  A 3rd Party disclosure, is not under contract for the purpose and is required or justified to authorize the processing.    

The object contains information of the : 

Field Name 

Data Type 


Example Input 


3rd Party Category

provide the purpose, the category of the 3rd party, the processing derogation, the privacy agreement(s) the disclosures are governed by

for policing 

Type of Processing
automatic profiling 



Data Type 

Section 3 Consented Data Control, Protection & Treatment  



Consent Grant Conditions (rules)



The object contains information Specifying Scope of Permission: Defined by purpose 

Field Name 

Data Type 


Example Input 


Frequency of Processing  


Every time service is used with implied consent 



Frequency of Access to Data Store 


Once per explicit consent 



Processor receipt required 


y/n, supply chain transparency required, means a receipt is generated every time PII is processed for any legal justification 







Sensitive PII Category 


to add primary context of use, this indicates the legal notice, notification, and disclosure requirements applicable to the consent purpose 



PII Categories 


PII Categories of Data Processing  



Collection Method 


 what methods are being used to collect PII, 



Collection from 3rd party sources?  

list 3rd party, or non-direct sources of PII  Collection, profiling and personal data aggregations 

(Note: could add list of source of data collection) 




Withdraw (permissions) ConsentObject

Withdraw consent - means withdraw all permission for processing personal data - using privacy rights that are applicable. This process specifies the termination of processing personal data, The mechanism for the PII Principle to Delete or have anonymized personal data

Field Name 

Data Type 


Example Input 


Consent Grant Purpose Expiry
description of when purpose is complete

Withdraw Consent URIa link to (restrict or object to processing)  withdraw consent, which can be automated with a 2 factor notification.

description of what data treatment constitutes withdrawal of consent, MUST include; wether personal data is deleted, or anonymized, and if a PII Principal preference for data or deletion is respecteddeleted, anonymized, Con_Pref,Y

PII Anonymized
if PII Anonymized what PII data and Identifier Attributes are anonymized, with what method,  and for what purpose 

Privacy Rights Enumerated for this legal justification  


List of privacy rights currently listed are those legally specified to be enforceable in the EEA General Data Protection Regulation. Refer to Privacy Rights for Identity Management Protocol Receipt Types Specification v0.1  

An (enforceable Multi-National Privacy Agreement Framework) Specified for the Consent Receipt here.  The privacy rights presented in the receipt are dependent on 3 factors, a) the legal justification b)  Obligations  c) Derogation's (and exemptions)

  • 6 legal justifications; 
    • consent

    • contractual necessity,

    • compliance with legal obligations,

    • vital interest, 

    • public interest, and 

    • legitimate interest

  •  6 Privacy Rights
    • Subject Access,
    • Rectification,
    • Erasure,
    • Restrict Processing,
    • Object to Processing,
    • Automated Individual Decision Making
Data LabelData TypeDescriptionExampleRequired
Legal Justification
The legal justification is above the 

Privacy Rights
Capture of the Legal justification is what informs what rights are available 

Privacy risks pertaining to the nature, purpose and consequences of the collection, use or disclosure to which they are consenting.  Including privacy rights limitations for Transborder data transfers.,


List of obligation categories 

  1. surveillance practices, security practices, data protection practices specific to context 
  2. rights access, privacy risks, rights performance requirements

List of laws, regulations or policies that supersede the justification and rights specified. Required to determine the scope and sequence of rights application for a specific processing context to be informed 

Request Response Time
the min and maximum amount of time a request can be responded to. 

Request Resolution or Escalation Time
the length of time expected for a fair and reasonable resolution or escalation. 





Notifications are required in certain context, Notifications can also be Optional, but are restricted to privacy agreement framework and can be specified by a legal justifications.  PII Controller Services that are Certified with a Code of Conduct and/or Practice can use icons and bundle the notification specification in the certified code. 

Data LabelData TypeDescriptionExampleRequired
Notification for Change of Privacy Statestring

3 types of change state notifications 

  1. minor change of state
  2. non-material change of state
  3. material change of state

Notification Requesting Renewal or Reuse of Legal Justification  for the Same Purpose
Notification requires summary of purpose specification, indicating they are the same as expected, including risks, obligations and derogations.

Notification Requesting a New Consent for a new purpose
Indicating reason for purpose change + specifying new purpose

Notification of Consent Termination

Consent Termination Notification Must Include

  • Consent Purpose
    • date and time
    • deleted data y/n
    • deleted identifiers
    • record kept (if any)
    • anyonymised your data with x process




Privacy Change & Notification LogURI

For a privacy policy to be operational a log of changes to the state of the controller, the justifications/purpose for processing, the security, risks, or any of the above specified conditions requires an accessible record of change and notification.  Required to demonstrate a valid state of consent.   For example: a Change of state include, 

a change in LEI, in ownership, in the active/legal status of the organization, or more specifically, in terms of conditions of processing like a change in purpose, a data breach etc.  

Data LabelData TypeDescriptionExampleRequired
Privacy LogURILink to a publicly available log or third party ledger

Section 4: Optional Consent Receipt Fields

Section 4 

Data Type 

Description of Optional Element 



Codified Conduct Provider 


By default the code of conduct is privacy regulation that is anchored in a receipt.

  A code of conduct MUST be approved by a data protection regulator and is valid for the specified jurisdictions, and does not extend without an adequacy assessment, mapping and approval for use with another Privacy Agreement



Codified Practice Provider 


For processing PII for a purpose, the required disclosure categories of sub-processors and 3rd parties.   To supply or authorize the service, e.g.  a sub-processor is a relying party service and is contracted for the specified purpose as a sub-processor.  A 3rd Party disclosure, is not under contract for the purpose and is required or justified to authorize the processing  

The object contains information of the : 

Field Name 

Data Type 


Example Input 


Legal Justification  


 legal justification for processing personal data



Governing body uriname and URI of the governing body

Code of Practice Code of Conduct URI 


 link to code of practice for this processing. 


Certification Valid to Date 


 date code of practice is valid for








Bundled purpose notice and notifications 


 number of consented purposes that are bundled in one consent



Industry sector 

 SIC Code

 industry SIC Code






Notification Types
Specifying a list of notification types for a codified conduct, and subsequent practice

Section 5: Consent Receipt Field Inputs v0.1  

Field Label 


Field Input: Source, and list 



Accountable Person Role 


Defined according to privacy agreement 
GDPR: Data Protection Officer, Data Protection Representative, and translated to ISO. As role – Chief Privacy Officer, with comparable responsibilities 



Consent Type

Sensitive (or Special) PII Category
Link to the Personal Data Categories

    • Note: Adding consent types 
    • Note: add list of sensitive data categories to spec - with definitions
    • Note: add delegated authority types
    • Note- add data category table (from DPV) 
    • Note - add notification types
    • Note - list of things that go into privacy log - to maintain a valid state of processing / consent
    • Note- Add what collections methods are usable for receipt

JSON-LD Example (TBD)

In Progress

CR V1.2 Specification Document Annex

A: CR v1.2 introduces

  1. The generation of an anchored record (from the pre-fix of the consent receipt)
  2.  A Notice object for sub-fields to digitally twin the notice using ISO 29100 and to add a log of notifications and disclosures
  3. Additional sub-fields for PII Controller

B: Generating an ANCR Record and Consent Receipt 

  1. There are multiple ways the ANCR record can be generated, depending on the use case. 
    1. using a third party 'User Agent' or Manually, by any Privacy Stakeholder
      1. PII Principal (PasE protocol) 
        1. Capture the PII Controller information upon first contact and self asserts this information in a public registry 
      2. PII Controller
        1. Generates a receipt form the interaction with its own notice - self asserts this information wth a Cyber Notary 
      3. PII Processor
        1. generates a processor record, generating a receipt by checking validity of processing at time of processing and sharing with a PII Principle 
        2. PII Sub Processor
      4. PII Notary 
        1. 3rd Party that verifies the claims in a consent receipt 
  2. PII Principal
    1. an ANCR record was conceived as a consent receipt generated by the PII Principle, or Individual (PIPEDA) is used to generate a proof of privacy or surveillance with a verifiable notice record and with a signed  consent notice receipt.     
    2. ISO/IEC 29100 - Stakeholder roles and definitions are overlaid/mapped to the notice from a specific context and used to capture a record of the notice and generate a  consent receipt
    3. the consent receipt can then be used as a verified rights claim, which can then be presented to the PII Controller, it can also be used by PII Controllers to standardize the use of Access Controls with a code of practice, and, to receive proof of notice from Individuals that use their service for evidence in the future,
    4. The ISO/IEC 29100 are overlaid for data processing according to the purpose specification and the PII Principals default privacy agreement) 
  3. an ANCR record is generated by PII Principle for each PII Controller a Principal wishes to track

Generating a 

Generating a Consent Receipt

  1. A receipt is generated from the information on the ANCR Record, which is also the pre-fix of the consent receipt 
    1. There are multiple ways to source and verify the information is valid and active in an ANCR record, before it is used to generate a consent receipt
  2. The default state of a notice record is consent, it is further specified with additional legal justifications, which are overlaid upon the default state, or specified as an explicit consent to  a specified purpose, which is captured by the notification provided by the PII Controller

Note: For PasE protocol - all Stakeholders generate a consent receipt for each processing activity

  1. in the processing a Consent  Receipt is  created for each PII Processing activity for a PII Controller by each Process and Sub-Processor using a 2 Factor Notice protocol in which a notice is generated first time a purpose or processing is authorized, approved by the accountable person, to generate a derogated consent receipt for that specific stakeholder, retrievable by a PII Principle with the consent receipt id, (only when) the ANCR id is generated from a consent receipt id provided by the PII Controller

ANCR Record & Blinding Identity Taxonomy for Consent Receipt Identifier Management 

Their are 2 identifiers used in the receipts 

1. is the ANCR Record iD which is anchored to the PII Controller Notice and the PII Principal's capture of the notice (or equivalent) 

2. The Consent receipt iD that is generated when a PII Principle interacts with the notice, context of a sign or notification


BT = Blinding Taxonomy  is a field that is encrypted, and blinded, so as not be available at rest without a key, in this specification, these fields are blinded by the PII Principal’s User Agent. (BUAT)  If these fields are generated by a 3rd party or controller, then this data is not ‘required’ in this is specification. 

Evidence of Consent

Privacy Agreement 

Proof of Notice  

Consent Grant for a Purpose 

Purpose Limitation (and Scope)

Permissions for a Purpose 

Purpose (or Permission) Management  - Not Consent Management  Platforms - (there is no such thing as consent management platform - this is permission management at best)