Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Summary

...

Overview 

The v1.2 consent receipt is used to capture any privacy notice or surveillance sign, specifically referencing OECD Guidelines on the Protection of Privacy and the Transborder Flows of Personal Data and the shared principles which have guided the harmonization of privacy law closely tied with the Council of Europe.  Setting the standard in and amongst countries.   Referenced by many national privacy and international privacy agreements, and the basis for the (Free) ISO/IEC 29100:2011 Information technology — Security techniques — Privacy framework.

The Consent Receipt Specifications rely on these principles and frameworks v1.1 is published in the ISO/IEC 29184:2020 Online Privacy Notice and Consent standard in the appendix. 

The consent receipt v1.1 has been adopted as a starting point  a privacy rights conformance tool that can capture a notice that can be assessed for Conformance with privacy regulation, or with the controls in ISO 29184.

The v1.1 Consent Receipt (published in 2017) aimed for the minimum viable consent receipt (MVCR) and to work on the semantics of specifying a purpose and its contextual integrity.  

The v1.2 consent receipt is used to mirror privacy and surveillance notice, notifications and disclosures for the purpose of empowering the PII Principal with this information in a manner that is proportionate to the context and privacy risks inherent to processing PII. Any Notice can be capture by a PII Principal by generating it with an anchored consent receipt generated by the PII Principals User Agent (person software and device).

V1.2 Receipt Structure Update

Organizing the Consent Receipt into 5 sections, breaking data capture elements down into more granular data objects,  clarifying  obligations for processing and the rules for processing.

  1. Anchor Record (the prefix of the receipt)
  2. Purpose Specification
  3. Data Treatment
  4. Optional
  5. Field Data

Section 1: Anchored Notice Record

The term Anchored in v 1.2, refers to anchoring the PII Principal's Privacy Jurisdiction with a new Notice field object added to the pre-fix of the consent receipts, (referred to here also as the anchor record).  

In this Consent Receipt framework the PII Principal creates an anchored record of an online privacy notice and uses this record to generate consent receipts when interacting with a notice or form for data capture.   Producing an audit trail that can be used to assess the valid state of the consent grant provided to digital identity systems, the  legal identity of the service provider, and the providers accountable person.  The receipt is designed to capture session information, preferences and permissions for a specified purpose. 

The added notice object fields are used to capture the location the notice was read both online and off.  Anchoring Privacy Expectations to  PII Principal's context and understanding 

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 as the purpose context.   The GDPR, which was published and implemented in 2016 after the consent receipt v1.1 was written, in the GDPR, and in ISO/IEC 29184, their are 6 legal justifications which can be used to derrogate the consent receipt, in which different privacy rights and obligations apply for processing personal data. 

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

Section 3: Consented Data Control, Protection & Treatment

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 Optional Elements

The optional elements are designed for adding additional tiers of Privacy Assurance to the receipt and record specifying in  addition to privacy law, a Code of Conduct and Practice provider. 

A code of conduct is approved by a Privacy Regulator, while a code of practice is implemented by the PII Controller which can also be  certified by a third party Privacy Assurance program provider. mirror (twin) privacy and surveillance notice, notifications and disclosures for the purpose of empowering the PII Principal with this information so that people can access and use privacy rights independently of a service provider.   This is made possible because PII Principles keep their own Consent Receipts that contain the privacy preferences and a record of permissions for  processing PII.

In this long update to the Consent Receipt information structure, the specification address the outstanding issues, (encompassing many when know global privacy challenges),  Privacy Notice (Online or Physical surveillance signs for in person interaction) can be captured with a Consent Receipt to record any legal justification for processing PII.       

CR 1.2 Overview 

The Consent Receipt v1.2 is specified for scalable and dynamic data processing controls and authorizations.  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 for 20 + years.  These guidelines adopted an international version of Fair Information  Practices, which many privacy legislation is based upon. It has guided the harmonization of privacy law internationally, is closely tied with the Council of Europe and CoE 108+, and importantly it provides the framework for 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  create a record of a privacy notice that is owned by the Individual called the Consent Receipt. 

The Consent Receipt Specifications relies on International interpretation of Privacy Principles that are widely adopted as a foundation for National privacy legislation in the International OECD Guidelines, to which the conformance record, that is the Consent Receipt (a Privacy Notice Record) can be assessed by applying both the standardized controls and structures specified in the ISO/IEC 29184:2020 Online Privacy Notice and Consent standard, or in context (by context) with legislated privacy law like the EU (GDPR)  General Data Protection Regulation.  Or conversely with a legal standard, for example Canada's Meaningful Consent standard. 

Consent by Design 

The Consent Receipt v1.2 is referred to as a Consent by Design specification as the default receipt legal justification is consent. 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 a digital twin or capture of the notice of processing in which the legal justification (if not consent) must be presented for the notice to comply with this specification.  ]

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 Receipt Update

The Kantara published, Consent Receipt v1.1(2017)  can be found in the Appendix of ISO 29184 (called more accurately Consent Notice Receipt) has been successfully adopted by ISO SC 27 WG, (to begin specifying an ISO Standard) called  ISO 27560, Consent record information structure.   Which is now in working draft 3 with the next meeting in late October. 

The V1.2 Receipt Structure has been updated and further specified by organizing the Consent Receipt into 5 sections, breaking data capture elements down into more granular data objects,  clarifying  rights access obligations for processing and the application of codes of conduct and practice to provide additional rules for personal data processing.

The Sections: 

  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 term Anchored in v 1.2, refers to anchoring the PII Principal's Privacy Jurisdiction with a new Notice field object added to the pre-fix of the consent receipts, (referred to here also as the anchor record).  

In this Consent Receipt framework the PII Principal creates an anchored record of an online privacy notice and uses this record to generate consent receipts when interacting with a notice or form for data capture.   Producing an audit trail that can be used to assess the valid state of the consent grant provided to digital identity systems, the  legal identity of the service provider, and the providers accountable person.  The receipt is designed to capture session information, preferences and permissions for a specified purpose. 

The added notice object fields are used to capture the location the notice was read both online and off.  Anchoring Privacy Expectations to  PII Principal's context and understanding 

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 as the default privacy rights for this consent receipt, which would be superseded by the privacy agreement (legislation) which the PII Principal expects. 

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 consent receipt fields that specify the scope of the legal processing of personal information for a specified purpose.  (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 Optional Elements

The optional elements for the Consent Receipt 1.2 are for the extension of processing 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. 

ISO/IEC 29184 specifies that the need to provide exhaustive notice can be replaced with a certified code of practice  reducing notice fatigue, in which the codified provider/assessor, or intermediary directly provides additional privacy assurance monitoring.

Section 5: Field Input Source Data (UNCOL)

...


Data Type 

Section 3 Consented Data Control, Protection & Treatment  

Example 

Required 

Consent Grant Conditions (rules)

Object 

 

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

Field Name 

Data Type 

Description 

Example Input 

Required 

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) 



 

Yes  

 

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 

Description 

Example Input 

Required 

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.

Withdrawal-process
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  

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)

  • 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
Notification Types
TBD To disclose to the nature, purpose and consequences of the collection, use or disclosure to which they are consenting
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 Obligations

Risks
Privacy risks pertaining Derogation'sList of laws, regulations or policies that supersede these privacy rights, are required part of the notice or notification sequence  for rights to informed and privacy assured 

 

 

 Notice of Risk

 

Notification -  

  • Privacy Risks – listed – 
  • Controller Obligation - security elements, for data protection,
  • Risk Mitigations -
  • certified code of practice,  – bundles these elements into a badge/icon - and the badge links to them all . 

 

  •   there is no agreement for data protection complaints  

 

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.,

Obligations

List of obligation categories 

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


Derogation's
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

 

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 State LogURI

a log of changes to the state of privacy, required for independently ascertaining if the State of consent is valid,

changes of state include, change in LEI ownership, change in active status the organization, change in purposeChange & 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.  

Data LabelData TypeDescriptionExampleRequired
Privacy LogURILink to a publicly available log or third party ledger http://domain.com/privacylog


...

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

...