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.
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.
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.
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).
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.
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
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. .
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.
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;
Section 1: Anchored Notice Record (Consent Receipt Pre-Fix) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Element Label | Data Type | Description of data capture element. | Example Input | Required | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ANCR Record ID | string | 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 | Object | 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 | 1435367226 | ✓ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ANCR Schema Version | String | The current version of the receipt | Version 1 | ✓ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Signing key | String | Public Key Used to Sign |
| ✓ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Language | String | The language the notice was presented in | English, Spanish | ✓ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Privacy Jurisdiction | String | Privacy Rights Regulation for the location the notice was physically read, used for privacy agreement PII Principal expects. | GDPR (privacy agreement) | ✓ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Notice Record | String | URI of the Online privacy notice record presented by the PII Principal. Linking to contact and privacy rights access and use information. |
| ✓ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
PII Controller | Object | 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Element | Data Type | Description of Data Capture Element | Example | Required | ||||||||||||||||||||||||||||||||||||||||||||||||||
Consent Receipt ID | String | 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. | 54nMMj7eq | |||||||||||||||||||||||||||||||||||||||||||||||||||
Legal Justification | Object | 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
| Consent | |||||||||||||||||||||||||||||||||||||||||||||||||||
Purpose Context | String | 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 | Marketing | |||||||||||||||||||||||||||||||||||||||||||||||||||
Purpose
|
| The purpose description further defines /describes the purpose category. Also referred to as a purpose sub-category. | Behavioral advertising | Required | ||||||||||||||||||||||||||||||||||||||||||||||||||
Delegation of Consent | Object | Is the authority to approve the provision of consent or its derogation a delegated authority? y/n
| Yes | |||||||||||||||||||||||||||||||||||||||||||||||||||
| Delegation of Processing | For high risk privacy assurance - sub-processors may be required to be listed- and change of sub-processors notified -
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
PII/Data Category | Object | 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
| Yes | |||||||||||||||||||||||||||||||||||||||||||||||||||
PII Disclosures | Object | 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.
| Yes | |||||||||||||||||||||||||||||||||||||||||||||||||||
Data Type | Section 3 Consented Data Control, Protection & Treatment | Example | Required | |||||||||||||||||||||||||||||||||||||||||||||||||||
Consent Grant Conditions (rules) | Object |
| Yes | ✓ | ||||||||||||||||||||||||||||||||||||||||||||||||||
| 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 | Object | 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 |
| 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 | 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.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Section 4: Optional Consent Receipt Fields | |||||||||||||||||||||||||||||||||||||||||||||||||
Section 4 | Data Type | Description of Optional Element | Example | Required | |||||||||||||||||||||||||||||||||||||||||||||
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 | Object | 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 Label | Reference | Field Input: Source, and list | Example | Required |
Accountable Person Role |
| Defined according to privacy agreement |
|
|
| Consent Type | ||||
| Sensitive (or Special) PII Category | Link to the Personal Data Categories | |||
| ||||
In Progress
Generating a
Note: For PasE protocol - all Stakeholders generate a consent receipt for each processing activity
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)