Status of this document
- Outline Draft
V1.2 - updates towards dynamic data control record and receipt information structure.
We are now working on and discussing ANCR v1.2.1 - ANCR record Specification
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 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 Default
The concept of specify a set of default authorizations for consensual data processing to decrease and minimize the requirements for privacy notice and notifications.
The user experience and Receipt v1.2 is referred to as a Consent by Default because the initial relationship state for any interaction is provided by default in relation to what is reasonable expected by the purpose and context of use by the individual.
Specifying Notice Record and Receipts for Additional Legal Justifications
Any additional legal justification can be Notified from this default context and instance to generate and link a consent receipt.
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 scope and focus of this workgroup is to work on 1 part of the consent record information structure, and contribute this towards a future v2 record and receipt specification.
Section 5 - Is the specification of field for the record and receipt specification, which we aim to contribute towards a global privacy rights access standard in the future.
Section 1: Anchored Notice Record
A key element missing in online only interactions is proof of informed or knowledgeable consent and the risks associated with this notice. The aim is to work through the fields in sections and to specify a way to generate consent receipts by both PII Principal and PII Controller.
By working through the first section and complete the first deliverable a report will be made and the next section can be reviewed.
In this section we aim to review these topics.
- Dynamic Data Controls
- Dynamic Fields:
- default consent types for the ANCR Record
- Generating a Receipt for another legal justification
- generating a receipt under the authority of a) PII Principal, b) PII Controller, c) Both
- Privacy Rights Agreement - Specifying the legal privacy rules according to the jurisdiction
- Jurisdiction of PII principal for determining rights access. (right to complain and be heard)
- Adding a notice payload to a consent receipt
- Rendering a receipt to display the proof of notice
- Rendering the receipt to display notification
- Rending a receipt for privacy rights access information.
- Default notice rendering
- Verifying rights access and performance
- PII Principle is a verified claim when provided by the individual.
- How can this claim be verified
Section 2: Purpose Specification
In the Consent Receipt v1.2.2 section focus and discussion on the consent record information structure, utilizing the GDPR an Internationally adopted (ISO 29184) legal processing justification categories
Note: A consent receipt can be specified for only one legal justification and one purpose (or purpose bundle).
Section 3: 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.
- 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: Code of Conduct & Practice (Optional)
Extending the Privacy Agreement (or legislation) with a technical code of conduct or practice, which can be notified with a badge and icon, provide transparency over additional safeguards and measures (aka privacy preserving technology) that provide additional privacy assurances, in addition to a more streamlined privacy service user experience.
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 Data Field Sources (UNCL)
The specification of the field data for each section will be collated and combined, including the data sources and specified and referenced according to the OECD Guidelines, Standards, regulatory guidance and legislation.
Unified fields data - for purpose specification which harmonizes context - for decentralized governance referring to a consent by default status.
Section 5: Consent Receipt Field Inputs v0.1
record spec - with specified field data - which then harmonizes what is specified as a consent for a purpose - ./
Field Input: Source, and list
Accountable Person Role
Defined according to privacy agreement
There are a number of legal consent types which are required for active state consent transparency and compliance
|Sensitive (or Special) PII Category||Sensitive Personal Data Categories |
|Personal Data Categories||Personal Data Categories - these have been contributed to the W3C Data Privacy Vocabulary Controls where they are synced and maintained|
Note: add delegated authority types
JSON-LD Example (TBD)
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
- 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
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.
Definition of terms and their references from ISO, W3C etc