OpenConsent : Consent Receipt Extension Draft 1- v0.1
Kantara CR v1.1. (RAND license) 

OpenConsent – (last update) Nov 5^th, 2018, 

Ext. Title: Explicit Consent Record & Receipt Extension for extending the Kantara CISWG: Consent Receipt with privacy laws that require explicit consent. 

Status:(in draft for WG)  

Methodology (Project Kit) for creating this consent receipt extension

• the CR v1.1 - is the Minimum Viable Consent Receipt Specification 
• It is useful for mapping existing laws and consent requirements to the international framework for creating an international privacy notice & consent record that is based on ISO SC 27 29100 Privacy Framework body of work 

1. Section 1: specify the new terms and the terms they replace in the CR v1.1 spec
2. Section 2: (table1) specify field names mapped to the CR v1.1 
3. Section 3: (table 2) specify new field terms and map changes only to fields that are replaced (– do not repeat what is already in the CR v1.1) 
4. Section 4: specify a schema section for additional terms that are created for the for the extension, which are not referecnces in the CR v1.1
5. Summary: Summarise the additional use and functionality of the extension 
6. Notes
   1. Sections 4.2 to 4.5 of CR v1.1 – can be represented by tables instead of paragraphs in draft extension

1. Generate new Law specific CR - based on Ext Specification by finding and replacing the terms in the spec.  (have tested this and it works nicely)  

Creating a template: using the template and providing instructions on using the template as notes, (in line ) 

Objective of this CR Extension

The Consent Record & Receipt [Enter LAW] Extension for extending the Kantara CISWG:(MVCR) Consent Receipt v1.1for the EEA.  Utilising the Kantara MVCR to map the [Law] lexicon and semantics to the international ISO 29100 lexicon. 

Intended use:  Used as a core interoperable format for a record and receipt of explicit consent for special categories of data, and children’s data as required in privacy law.  (used in prototyping this extension kit process for extending the Kantara CR to full Consent Record and Receipt Specifications)

This Extension is used to map the [HIPPA & CFR42a] terms for explicit consent compliance requirements to the Kantara Initiative Consent Receipt (CR) v1.1.

In this extension document, only those elements that have been mapped or added to the Consent Receipt Specification, are specified in this extension document. 

This document defines the field mappings to replace terms and glossary items in the CR v1.1. specification, with the specific terms of this specification also adds additional fields and terms, that are required by the [insert law] as an extension to the CR v1.1,

Extension Scope

This extension to the Kantara CR V1.1 map's the [Law ]  lexicon to the international ISO lexicon for explicit consent, while also adding extension fields to meet [Law e.g.  CFR42 Part 2] requirements.

This extension provides an example of how to generate an extension for the Kantara (Minimum Viable International) Consent Receipt v1.1 that maps a national legislation to and international standard, to enable cross domain interoperability in consent transparency internationally.

This extension interprets the Kantara Consent Receipt v1.1 specification as an explicit consent record and receipt specification that is used by the Identity Management industry to specify a high assurance explicit consent token or certificate.

This extension interprets the {LAW name} justification for consent as 'explicit' for specified [ 'special categories]' of personal data, including the recording of delegated explicit parental consent for the processing of children's data, services which process special or sensitive categories of personal data, employ automatic identification, decision making and profiling. 

For fields for an explicit consent receipt the 'Equivalent' {HIPPA or CFR42a} field name replaces the CR field name and are used to replace the terms and fields in the CR. 

Scope Limitation:  The notice and policies required for this explicit consent and their conformance should be linked via the required PII Controller URL and are not in scope of this extension template. 

An Explicit Consent & Notice Record for Producing a Receipt

This specification extension acknowledges that an explicit consent receipt is made with a subset of fields in a consent record.   This extension provides some guidance for keeping records of processing by defining the fields and format for creating a consent record that demonstrates compliance with

 records of processing and proof of notice for an explicit consent receipt to meet the requirements as set out in (list the reference) Regulation.   

Creating a record of consent for an explicit consent receipt. The explicit consent record focuses on identifying the privacy identity to include, the processors, sub-processors, delegated consenting parties contact name and address, and fields with the required linked contracts, model clauses and agreements, linked to the record of consent, which are not represented in the receipt fields provided to the { PII or Data]} Subject.   In addition, onward transfers (or information sharing), in a record of consent that produces a receipt, the onward transfer should include the country personal data is being transferred to, list the type of adequacy safeguard and provide a link to a url with a description of the transfer scope.

Records are required for explicit consent on behalf of the processor, this will be required if the Controller is audited, or if the controller is seeking accreditation for high assurance for explicit consent.  In such context, these records should include the categories of recipients the nature and purpose of the processing, the type of PI and PI categories of PI Principles are required in the processor record for consent as defined in (list legal reference from law e.g. CFR42 Part2)  

For regulator and bodies providing codes of practices or accreditation, an explicit consent record requires the categories of recipients to whom the PI have been or will be disclosed, including recipients in third countries or international organisations; Including, the category of PI Principle – is required in a consent record along with the PI category, as required in records of processing that are used to produce a privacy notice or consent receipt.

Section 1: New and replacement terms in the extension 

Section 2:  fields mapped to the CR v1.1

Table 1 

Section 3: Additional CR v1.1 Field Extensions for CFR42 Part2

Table 2: 

Section 4: Schema 

Summary

Notes & Discussion:

1. Once the above is complete, find and replace the terms in the CR, Update the terminology and definitions with the above specified information to produce a sub-specification - for the new law.  
   1. On interoperability 
      1. Former user (Deleted) raises potential issue that might break spec if fields are changed -so want to be careful and think through first before deciding on what to actually call the out put .. - aka avoid in appropriate. fragmentation  
      B. Requirements 
      1. additional or derivatives specification must add to, not fragment specification work
         1. contributing extra fields and their definition to the CR spec  should increase specification scope.