Status: In reviewed by the WG as 1 of x frameworks
This is a framework for person centric use cases, and relies on additional technical use cases and profiles for implementation.
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.
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.
- Anchor Record (the prefix of the receipt)
- Purpose Specification
- Consented Data Control, Protection & Treatment
- Optional Field
- UNCOL - Field Data structure, semantics, sources and descriptions
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.
- Consent Grant Conditions
- Withdraw Permission for a Consent Grant
- Privacy Rights Applicable for this processing context
- Notice of Risk and Liabilities Required in place (or in addition) to contract terms or license agreements
- Notifications : the required notice, notifications, and disclosures for valid processing. This is a new section, which is in early review and development.
- Privacy & Surveillance Change & Notification Log, required for records of processing, for open, operational and responsive Online privacy notification.
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
- A code of conduct, which extends privacy legislation and is approved by a privacy regulator.
- 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;
- 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.
- 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
- 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
Description of data capture element.
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]
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
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
Public Key Used to Sign
The language the notice was presented in
Privacy Rights Regulation for the location the notice was physically read, used for privacy agreement PII Principal expects.
GDPR (privacy agreement)
URI of the Online privacy notice record presented by the PII Principal. Linking to contact and privacy rights access and use information.
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.
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
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.
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
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.
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.
Delegation of Consent
Is the authority to approve the provision of consent or its derogation a delegated authority? y/n
|Delegation of Processing|
For high risk privacy assurance - sub-processors may be required to be listed- and change of sub-processors notified -
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
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.
Section 3 Consented Data Control, Protection & Treatment
Consent Grant Conditions (rules)
|Withdraw (permissions) Consent||Object|
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
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)
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.
|Privacy Change & Notification Log||URI|
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.
Section 4: Optional Consent Receipt Fields
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
|Notification Types||Specifying a list of notification types for a codified conduct, and subsequent practice|
Section 5: Consent Receipt Field Inputs v0.1
Field Input: Source, and list
Accountable Person Role
Defined according to privacy agreement
|Sensitive (or Special) PII Category||Link to the Personal Data Categories|
JSON-LD Example (TBD)
CR V1.2 Specification Document Annex
A: CR v1.2 introduces
- The generation of an anchored record (from the pre-fix of the consent receipt)
- A Notice object for sub-fields to digitally twin the notice using ISO 29100 and to add a log of notifications and disclosures
- Additional sub-fields for PII Controller
B: Generating an ANCR Record and Consent Receipt
- There are multiple ways the ANCR record can be generated, depending on the use case.
- using a third party 'User Agent' or Manually, by any Privacy Stakeholder
- PII Principal (PasE protocol)
- Capture the PII Controller information upon first contact and self asserts this information in a public registry
- PII Controller
- Generates a receipt form the interaction with its own notice - self asserts this information wth a Cyber Notary
- PII Processor
- generates a processor record, generating a receipt by checking validity of processing at time of processing and sharing with a PII Principle
- PII Sub Processor
- PII Notary
- 3rd Party that verifies the claims in a consent receipt
- PII Principal (PasE protocol)
- using a third party 'User Agent' or Manually, by any Privacy Stakeholder
- PII Principal
- 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.
- 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
- 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,
- The ISO/IEC 29100 are overlaid for data processing according to the purpose specification and the PII Principals default privacy agreement)
- an ANCR record is generated by PII Principle for each PII Controller a Principal wishes to track
Generating a Consent Receipt
- A receipt is generated from the information on the ANCR Record, which is also the pre-fix of the consent receipt
- 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
- 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
- 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
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)