Page tree

Versions Compared

Key

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

...

This is a wiki page for discussion. (not official group specification) 

Status of this document

  • Outline Draft

Summary Overview 

The v1V1.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. 

Background 

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  create a record of a privacy notice that is owned by the Individual called the Consent Receipt. 

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 - updates towards dynamic data control record and receipt information structure. 


We are now working on and discussing ANCR v1.2.1 - ANCR record Specification 


Section Summary

Background 

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 Default  (for Dynamic Data Control) 

The ANCR record re-works the flow so as to start with a valid state of Consent, which is then consumed by identity management technologies.  Changing the flow of surveillance and enabling people to human-trust the use of surveillance  and  enable a flow of  consensual data processing to dramatically 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 reasonably expected by the purpose and context of use by the individual as specified in law. 

From this starting point, and legitimate legal justification can then be used to dynamically assert a control over the data that is controlled by the individual.  For example the consent default which intiaites the data flow may be implied consent, and an Contract, or the Vital Interests of the data subject might be used, with a verified PII Controller, or Privacy Controller Credential, (see ToiP - Privacy Controller Credential Specification)_  to dynamically access the personal data.    ANCR Notice record can be generated for proof of notice.  Consent Receipt can be generated for evidence of legitimate processing for another legal justification. 

Consent Types

The ANCR record provides the PII Controller and PII Principle digital identifiers and context along with a consent type, which provides a default scope of permissions in a consent grant to a system.

The consent types here aim to express the full range of consent defaults expected and will evolve. 

Consent Type DescriptionDefaults to ApplyPermission Scope for digital Identity system
Explicit Consent 


Implied Consent 


Expressed Consent


Directed Consent 


Altruistic Consent


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.   An Anchor Record is generated from the PII Controllers credentials as displayed. 

Producing a proof of notice for any additional legal justification can be used to update the default for that context to a new legal justification produced with 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 

...

Specification Draft


Appendix A: Full Specification Overview

The scope and focus of this workgroup is to work on 1 part of the consent record information structure, and contribute this towards a developing global record and receipt specification.

The full record and receipt specification is framed with  5 sections which are being worked on by different groups and efforts and  is the Appendix (below). 

The focus of this workgroup on the first section is aimed at  creating a  Proof of Human Notice for digital Evidence of processing for dynamic data controls for digital identifiers. 

Sections are as follows

  1. Anchored Notice Record 
  2. Purpose Specification 
  3. Data Control, Protection and Treatment
  4. Code of Conduct & Practice
  5. Advanced Notice and Consent Receipt Record 
    1. Consent Receipt Prefix. is being specified with inputs from Verified Credential community of work via ToiP

Specification Roadmap 

Section 2, 3, & 4 -  are being specified by a combination of other efforts including ISO 27560 which are all happening in 2021-23 time frame,. 

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 Summaries

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. 

  1. Dynamic Data Controls
  2. Dynamic Fields:
    1. default consent types for the ANCR Record 
  3. Generating a Receipt for another legal justification
  4. generating a receipt under the authority of a) PII Principal, b) PII Controller, c) Both 
  5. Privacy Rights Agreement - Specifying the legal privacy rules according to the jurisdiction 
  6. Jurisdiction of PII principal for determining  rights access.  (right to complain and be heard) 
  7. Adding a notice payload to a consent receipt 
  8. Rendering a receipt to display the proof of notice 
  9. Rendering the receipt to display notification
  10. Rending a receipt for privacy rights access information. 
    1. Default notice rendering
    2. Verifying rights access and performance
    3.  PII Principle is a verified claim when provided by the individual. 
    4. 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

  1.  purpose specification fields (are for the most part the same as v1.1)
  2.  purpose context - legal justification of processing - instance(s) of processing, purpose categories, 
  3.  purpose specification for 6 legal justifications
  4. specifying rights requests and data processing controls
  5. The rights are then listed with the legal justification in the next

...

  1. sections 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:

...

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 focus discussion on.

  •  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,  notification with  which can be notified with a badge and icon,  provide transparency over 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 

...

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 

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

Field Name 

Data Type 

Description 

Example Input 

Required 

Notice response Options 

 

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

 

 

phy-notice 

String 

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

 

✓ BT 

dig-notice 

String 

Physical and/or digital address URI- 

 

✓ BT 

Geo-Location Notice is Read 

string 

 

 

BT 

OPNR  URI 

String 

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

 

 

PrivaNotice HashLink 

String 

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 

...

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.  

 

...

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

...

Field Name 

...

Data Type 

...

Description 

...

Example Input 

...

Required 

...

Privacy jurisdiction 

...

String 

...

The PII jurisdiction 

...

UK 

...

 

...

Contact name  

...

String 

...

Person or representative to contact for privacy rights access  

...

Jon Doe 

...

 

...

company 

...

String 

...

The legally registered company name  

...

Data Controller Inc. 

...

 

...

address 

...

String 

...

Contact email address 

...

123 Main St., Anywhere 

...

 

...

 

email 

 

...

String 

...

Contact email address 

...

dave@datacontroller.com 

...

 

...

 

phone 

 

...

 

...

Contact phone number 

...

00-000-000-0000 

...

 

...

 Privacy Policy 

 

...

String 

...

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

...

https://www.domain.org/privacy 

...

 

...

 

...

String 

...

 

...

Often website specific is a basic privacy policy 

...

 

...

Accountable Person Role 

...

String 

...

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

...

Data Protection Representative  

...

 

...

Accountable Person Name 

...

String 

...

 First, Last Name

...

John Controller  

...

BT 

...

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 ) 

...

No 

...

 

...

ToiP

...

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

...

Example 

...

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 

...

The object contains information of the : 

...

Field Name 

...

Data Type 

...

Description 

...

Example Input 

...

Required 

...

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 

...

 

...

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

 

...

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    

...

Delegation of Consent 

...

Object 

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 

...

Description 

...

Example Input 

...

Required 

...

Delegated Authority Type,  

...

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

...

Parent

...

 

...

Delegation Purpose  

...

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

...

Parental Consent

...

 

...

Delegate Name 

...

First  & Last Name 

...

Jane Doe

...

 

...

Delegate Contact 

...

 and contact point 

...

 

...

Delegate 

Privacy Jurisdiction 

...

 If different  

...

N/A

...

 

 

...

Yes  

...

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

...

Field Name 

...

Data Type 

...

Description 

...

Example Input 

...

Required 

...

Sub-processor_Service-Name

...

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 

...

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

 

...

Field Name 

...

Data Type 

...

Description 

...

Example Input 

...

Required 

...

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   

...

 

...

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.    

...

The object contains information of the : 

...

Field Name 

...

Data Type 

...

Description 

...

Example Input 

...

Required 

...

3rd Party Category

...

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

...

 

...

Yes  

...

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, 

...

 

...

 

...

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

...

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

...

List of obligation categories 

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

...

 

...

 

...

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. 

...

3 types of change state notifications 

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

...

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

 

...

 

...

 

...

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  

...

The object contains information of the : 

...

Field Name 

...

Data Type 

...

Description 

...

Example Input 

...

Required 

...

Legal Justification  

...

 string

...

 legal justification for processing personal data

...

 contract

...

 ✓ 

...

Code of Practice Code of Conduct URI 

...

URI 

...

 link to code of practice for this processing. 

...

 

...

Certification Valid to Date 

...

 

...

 date code of practice is valid for

...

 

...

 

...

Assessor 

...

 

...

 

...

 

...

 

...

Bundled purpose notice and notifications 

...

 

...

 number of consented purposes that are bundled in one consent

...

 

...

 

...

Industry sector 

...

 SIC Code

...

 industry SIC Code

...

 

...

 

 

...

 

...

 

...

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 
GDPR: Data Protection Officer, Data Protection Representative, and translated to ISO. As role – Chief Privacy Officer, with comparable responsibilities 

...

 

...

 

...

    • 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 (aka privacy preserving technology)  that provide additional privacy assurances, in addition to a more streamlined privacy service user experience.

Discussion includes: 

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

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. 

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 Label 

Reference

Field Input: Source, and list 

Example 

Required 

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

There are a number of legal consent types which are required for active state consent transparency and compliance

  1. implied consent - e.g. going to a website 
  2. implicit consent - e.g. through actions that are implicit and indicative of consent expectations
  3. explicit consent - e.g. providing personal information for a legal specified purpose and privacy rights notice 
  4. expressed (or directed) consent - e.g. an explicit consent that is specified by the PII Principal 
  5. altruistic consent - e.g. a consent specified with a code of practice rather that to a specific legal entity (name of controller not necessarily provided) 


Sensitive (or Special) PII Category
Sensitive Personal Data Categories 
  • personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs;
  • trade-union membership;
  • genetic data, biometric data processed solely to identify a human being;
  • health-related data;
  • data concerning a person’s sex life or sexual orientation.

References



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

    • 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



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

...

  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 

...

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

...


Acronyms

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. 

Glossary 

Definition of terms and their references from ISO, W3C etc


Evidence of Consent

Privacy Agreement 

...