Page tree
Skip to end of metadata
Go to start of metadata

Contributed by the Open Consent Group  Advisory; (Mark Lizar, Sal D' Agostino, Paul Knowles) developed through working on the Privacy as Expected Signalling Protocol. 

This is a framework for person centric use cases, and relies on additional technical use cases and profiles for implementation. 

Summary Overview 

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. 

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

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 

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

  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 (UNCL)

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. 

Unified fields data - for purpose specification which harmonizes context - for decentralized governance, 


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 

 

Privacy Controller Extension 

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 

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 

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 

 

Sensitive (or Special) PII Category

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    

Required

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 

PII Principle is a Child or Youth
Yes or No, When this child or youth flag is set, age appropriate privacy is required, with a straightforward procedure to withdraw consent, delete personal information and implement and enforce data retention schedules is required for Privacy AssuranceYes 

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 Relationship to PII Principal 
Relationship to the PII Principal ; Mother

Delegate Name 


First  & Last Name 

Jane Doe

 

Delegate Contact 


 and contact point 


info@myface.com

 

Delegate Address

123 your dr
city, Country

Delegate 

Privacy Jurisdiction 


 If different  

N/A

 

 

Yes  


Delegation of Processing

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



Purpose_of_Disclosure
for policing 

Type of Processing
automatic profiling 

 

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, 

 

 

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

Risks
Privacy risks pertaining 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 Change & Notification LogURI

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




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

 ✓ 

Governing body uriname and URI of the governing body

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

 

 

 

 

 

Notification Types
Specifying a list of notification types for a codified conduct, and subsequent practice



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



Sensitive (or Special) PII Category
Link to the Personal Data Categories



    • 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 

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

Note: For PasE protocol - all Stakeholders generate a consent receipt for each processing activity

  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 

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


Glossary 

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) 




  • No labels

3 Comments

  1. I think this document needs substancial revision and discussion for a number of reasons.

    1. it creates to much new terminology that feels unnecessary. Are neologisms strictly necessary?
    2. I personally do not see the usefulness of a "proof of notice". Maybe there is a legal use-cases but from a end-user standpoint, a receipt, for me, is proof that an event took place (such as collection of personal data after consent or similar basis)
    3. A receipt should not have personal data in it. Not only it feels unnecessary, but doing it brings it a world of pain about security and data governance. The receipt becomes, in itself, a sensitive object.
    4. Overall, this proposal feels complex, relies too much on legal concepts and language and, I suspect, will be difficult to use by our (I expect) target audience which are system designers and implemneters.
    5. For the sake of keeping it simple and compact, I think several fields need justification.
    6. Some fields are difficult to understand which could hinder adoption.
    7. Field names should follow convention and common language (within the target audience) unless necessary.
    8. The receipt, as is, may become a large digital object. It should be very compact (say, <1kB)
    9. there seems to be duplicaiton of information whose authoritive source is external to the receipt. Receipt should link, with protections, and not embed. An example is a privacy policy.
    10. Some fields feel redundant and duplicated.
    11. I think we should make the receipt internationally usable and independent of local jurisdictions. It should, of course, support and align with with major ones (GDPR + ePR at the forefront but not only). This is a technical consideration, however.
    12. I would put more effort on auditability + accoutnability fields.
    13. I'd make the receipt extensible by design.
    14. The withdraw section should be linked to a past receipt instead of trying to capture the context inside the receipt itself.
    15. A receipt should be a standalone document and stand for itself.
    16. I do not see the need to add a different kind of receipt (e.g., ANCR receipt). I do not quite understand what this is.
    17. (other aspects but I think this is enough to get started)


  2. thanks for the input and contributions. 

    Specifically, consent is defined as a legal and social object in privacy law around the world, it is not defined technically.  This is the aim of requesting comments and use cases for Consent signalling, in technical environments.