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

Section 1: specify the new terms and the terms they replace in the CR v1.1 spec
Section 2: (table1) specify field names mapped to the CR v1.1
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)
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
Summary: Summarise the additional use and functionality of the extension
Notes
1. Sections 4.2 to 4.5 of CR v1.1 – can be represented by tables instead of paragraphs in draft extension

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 )

HIPPA - Legislation

http://www.hipaasurvivalguide.com/hipaa-regulations/part-164.php

Of note - § 164.414(b) Burden of proof. In the event of a use or disclosure in violation of subpart E, the covered entity or business associate, as applicable, shall have the burden of demonstrating that all notifications were made as required by this subpart or that the use or disclosure did not constitute a breach, as defined at § 164.402.

CFR42 Part2 Regulation Link

https://www.regulations.gov/document?D=HHS-OS-2016-0005-0001

Background Info

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
Unknown macro: {CFR42 Part 2}

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

CR v1.1 Field Name	Equivalent GDPR Term	GDPR CR Field Name	GDPR Field Description (Put in examples)	JSON	Required / Optional	Data Type
Version
Jurisdiction
Consent Timestamp
Collection Method
Consent Receipt ID
Public Key
Language
PII Principal ID
PII Controller
On Behalf
PII Controller Contact
PII Controller Address
PII Controller Email
PII Controller Phone
PII Controller URL
Privacy Policy
Service
Purpose
Purpose Categories
Consent Type
PII Categories
Primary Purpose
Termination
Third Party Disclosure
Third Party Name
Sensitive PII
Sensitive PII Category

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

Table 2:

Field Name

Guidance

Description

Data Types (define field format)

JSON

Required / Optional

Section 4: Schema

Summary

Appendex

The specification.

Once the above is complete, find and replace the terms in the CR, Update the terminology and definitions with the above specified information tor produce a new law specific version of the CR v1.1 specification

Browser not supported