Consent Notice Receipt Specification

Version : 0.8 (Alpha Draft)

Date: 2016-08-11

Editor: Mark Lizar

Contributors : Iain Henderson, Mary Hodder, Harri Honko, Oliver Maerz, Eve Maler, John Wunderlich

Status: CIS-WG Kantara Initiative Recommendation

Abstract :

In every privacy legislative jurisdiction, there are requirements that a user be provided with a privacy notice in order for their consent in using the site or service to be legitimate. The Consent Receipt specified in this document is engineered according to modern principles for Openness, Consent, and Choice, all of which are critical to privacy. This specification presents to the end-user (or “PII Principle” -- see terms below), a human-readable record that includes links to existing consent notices and details regarding what information the user is sharing with the site or service. This human-readable record format in turn is used to create, with additional JSON schema, a machine-readable record of consent that may be used for auditing, improving customer service, or other records purposes.

 

IPR : Reciprocal Royalty Free with Opt-Out to Reasonable and Non-discriminatory (RAND) HTML version | Copyright ©2016 http://kantarainitiative.org/confluence/x/DYBQAQ ]

Notice:

Copyright (c) 2016 Kantara and the persons identified as the document authors. All rights reserved.

This document is subject to the Kantara IPR Policy - Option Patent & Copyright: Reciprocal Royalty Free with Opt-Out to Reasonable and Non-discriminatory (RAND) HTML version

 


Table of Contents

Abstract:

1 Introduction ................................................................................................................................................................

2 Notational Conventions For Conformance ..................................................................................................

3 Terminology ................................................................................................................................................................

3.1.1 Conformance Modes ...........................................................................................................................................

3.1.2 Required Fields: Mode 1 ....................................................................................................................................

3.1.3 Required Fields: Mode 2 ....................................................................................................................................

3.1.4 Mode 2 Guidance for JSON Implementation .............................................................................................

3.1.5 Header .....................................................................................................................................................................

3.1.6 PII Controller Information ................................................................................................................................

3.1.7 Purpose(s) ..........................................................................................................................................................

3.1.8 Services Array ..................................................................................................................................................

3.1.9 Service Name ...................................................................................................................................................

3.1.10 Purposes Array ..............................................................................................................................................

3.1.11 Purpose of Collection ..................................................................................................................................

3.1.12 Personally Identifiable Information ........................................................................................................

3.1.13 3rd Party Disclosure .........................................................................................................................................

3.1.14 3rd Party Disclosure Y/N ..........................................................................................................................

3.1.15 Third Party .....................................................................................................................................................

4 General JSON Schema ..........................................................................................................................................

5 Considerations ...........................................................................................................................................................

5.1.1 A Consent Receipt is PII ....................................................................................................................................

5.1.2 Sensitive PII: Liability & Compliance ............................................................................................................

6 Acknowledgements ..................................................................................................................................................

7 REFERENCES ........................................................................................................................................................

7.1.1 Normative References ........................................................................................................................................

8 Appendix A: Purpose Categories ......................................................................................................................

9 Appendix B: Personally Identifiable Information (PII) Categories of Data ...................................

10 Appendix C: User Experience Order (put in for reference for now)

11 Appendix D: Example JSON for Consent Receipt (from Kantara Reference Implementation)              

12 Revision history .......................................................................................................................................................

 

1          Introduction

People can not easily track the consents they have given or how information about them is shared. Once used broadly this specification will allow for individuals to track personal information, how it is shared and under what policies it is governed.

The specification documents how conformance is achieved by taking existing consent notices, the kind organizations already are required to have, and links these into the Consent Receipt, in a human readable record format. This is also referred to interchangeably as Conformance Mode 1 - Collection and Display of Notice Requirements in a Human Readable Record Form (ref Mode 1). Mode 1 connects consent-specific information to form a record of consent, increasing both transparency and usability of consent.

Conformance Mode 2, also interchangeably known as the ‘machine-readable’ record of the consent is available combining the basics of Mode 1 with the interoperable format in Mode 2. Each mode has different security, legal, privacy considerations for the provisioning, control, security and use of a consent record. The Consent Receipt is engineered here in reference to all of the privacy instruments researched (ref: ISTPA 1, ISTPA 2 , tables [1] ) as a modern standard for Openness, Consent and Choice which are critical and key to privacy and user experience.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", “NOT RECOMMENDED”, "MAY", and "OPTIONAL" in this document are to be interpreted as described in [ RFC 2119 ].

 

Unless otherwise noted, all JSON [RFC 7159] properties and values are case sensitive. JSON data structures defined by this specification MAY contain extension properties that are not defined in this specification. Any entity receiving or retrieving a JSON data structure SHOULD ignore extension properties it is unable to understand. Extension names that are unprotected from collisions are outside the scope of this specification. https://docs.kantarainitiative.org/uma/rec-uma-core.html - RFC7159

3          Terminology

The Consent Receipt specification, where possible, takes terminology and definitions from other ISO specifications and published, recognized efforts in order to define terms commonly used in the ecosystem. If other organizations terms are not compatible with the Consent Receipt specification, this document will define those terms for clarity and specificity for our purposes.  Terminology specifically leverages where possible, ISO/IEC 29100:2011 "Information Technology -- Security techniques -- Privacy Framework". Terms that originate from other sources are followed with a bracketed citation, for example: “ [ISO 29100] ” and if it is our definition we use: “ [Ours] ” to show we originated it.

Collection

  1. The act of receiving or obtaining PII from or about a natural person.

Disclosure

  1. The transfer or copy, by a PII Controller or a PII Processor acting on their behalf, of PII and accountability for that PII to another entity which will become the PII Controller of that copy of the information. It is a transfer of accountability, not just a transfer of information.

NOTE: A PII Controller is ‘using’ information when it transfers or copies information to another entity but retains accountability for that PII. An example would be an entity using a cloud storage service for backups. We note this here because from a PII subject’s point of view both this ‘use’ and actual ‘disclosure’ may be termed ‘sharing’ information. However these are significant differences from a transparency and regulatory point of view.

Consent

  1. A Personally identifiable information (PII) Principal’s freely given, specific and informed agreement to the processing of their PII. [ISO 29100]

Consent Receipt (CR)

  1. A record of a personal information collection provided to the PII Principle at or shortly after the PII has been collected. [Ours]

Consent Timestamp

  1. The time and date that the consent receipt is issued. [Ours]

Consent Type

  1. The nature of the consent being used by the PII controller as their authority to collect, use or disclose PII.

Human Readable data/ information

  1. Human Readable language means using common and well defined terminology so regular people can understand the meaning. Note: for the purpose of this specification, Human Readable also means the output is displayed in a form that is not the Machine Readable JSON structured data. [Ours]

For example, in ISO 18001, it is defined for driver's licenses as: Data or information that is printed or engraved that is visually present on a driving license and designed to be interpreted by a human. [ISO 18001]

Machine Readable data / information

  1. Machine Readable in the context of this specification refers to the JSON structured data output. [Ours]

For example, in ISO 18001, it is defined for driver's licenses as: Data or information that is encoded into a machine-readable medium, such as a magnetic stripe, bar code, optical memory, or integrated circuit. [ISO 18001]

Privacy Statement

  1. Refers to the notice provided by the PII Controller to inform the PII Principal of what will  be done with their information. Note that the contents of this notice may be required by regulation and/or information that is beyond the scope of the consent receipt..

Personally Identifiable Information (PII)

  1. Any information that (a) can be used to identify the PII Principal to whom such information relates, or (b) is or might be directly or indirectly linked to a PII Principal. [ISO 29100]

NOTE: From [ISO 29100]: 4.4 : To determine whether or not an individual should be considered identifiable, several factors need to be taken into account. In particular, account should be taken of all the means which can reasonably be used by the entity holding the data, or by any other party to identify that individual on the basis of the given information. From [ISO 29100].

PII Controller

  1. A privacy stakeholder (or privacy stakeholders) that determines the purposes and means for processing personally identifiable information (PII) other than natural persons who use data for personal purposes. [ISO 29100]

NOTE: A PII controller sometimes instructs others (e.g., PII processors) to process PII on its behalf while the responsibility for the processing remains with the PII controller. [ISO 29100]

PII Principal

  1. The natural person to whom the personally identifiable information (PII) relates. [ISO 29100]

NOTE: Depending on the jurisdiction and the particular data protection and privacy legislation, the synonym “data subject” can also be used instead of the term “PII principal”." [ISO 29100]

PII Processor

  1. A privacy stakeholder that processes personally identifiable information (PII) on behalf of and in accordance with the instructions of a PII controller. [ISO 29100]

Processing of PII

  1. An operation or set of operations performed upon personally identifiable information (PII) [ISO 29100]

NOTE: Examples of processing operations of PII include, but are not limited to, the collection, storage, alteration, retrieval, consultation, disclosure, anonymization, pseudonymization, dissemination or otherwise making available, deletion or destruction of PII. [ISO 29100]

Purpose

  1. The business, operational or regulatory requirement for the collection, use and/or disclosure of a PII Subject's data. [Ours]
  2. The reason personal information is collected by the entity. [GAPP]

Purpose Specification

  1. A statement or series of statements that defines the purpose(s) for which PII has been collected. [Ours]

Third Party

  1. A privacy stakeholder other than the personally identifiable information (PII) principal, the PII controller and the PII processor, and the natural persons who are authorized to process the data under the direct authority of the PII controller or the PII processor. [ISO 29100]

Sensitive PI

  1. Sensitive Personal Information (SPI) is defined as information that if lost, compromised, or disclosed could result in substantial harm, embarrassment, inconvenience, or unfairness to an individual. [DHS HSSPII]
  2. Sensitive Categories of personal information, either whose nature is sensitive, such as those that relate to the PII principal’s most intimate sphere, or that might have a significant impact on the PII principal. These categories are those related to racial origin, political opinions or religious or other beliefs, personal data on health, sex life or criminal convictions and require opt-in informed consent.[ISO 29100]

NOTE: In some jurisdictions or in specific contexts, sensitive PII is defined in reference to the nature of the PII and can consist of PII revealing the racial origin, political opinions or religious or other beliefs, personal data on health, sex life or criminal convictions, as well as other PII that might be defined as sensitive. [ISO 29100]

NOTE: For the purposes of this specification, 'Sensitive data' may be considered synonymous with Sensitive PII. Sensitive Data is defined in Section 2 of the Data Protection Act of the UK as personal data consisting of information relating to the data subject with regard to racial or ethnic origin; political opinions; religious beliefs or other beliefs of a similar nature; trade union membership; physical or mental health or other data or as defined by implementors of the specification. In the GDPR, this is referred to as special categories of data.

Use

  1. Any processing of PII done by a PII Controller or by a PII processor on behalf of a PII Controller
  2. The use of collection, use and disclosure is a useful articulation of the steps in PII processing. [PIPEDA]

3.1.1       Conformance Modes

The specification defines and demonstrates the following two modes of requirements to measure the conformance of the Consent Receipt with this specification:  An implementor is in conformance with Mode 1 when they present a human readable consent record that includes the required fields for Mode 1. An implementor is in conformance with Mode 2 when they are in conformance with Mode 1 and, in addition create and make accessible a JSON artifact that meets the schema set out in the section below, delivered to a PII Principal for future reference.

3.1.2       Required Fields: Mode 1

All 18 fields listed below MUST be included in a conforming Consent Receipt made under the terms of Mode 1.

 

  1. Service : The service or group of services being provided for which personally identifiable information is required.

 

  1. PII Principal ID : Subject provided identifier, email address - or Claim, defined/namespace

 

  1. PII Controller : Name of the data controller organization: the entity accountable for compliance over the management of PI(I).

 

  1. On Behalf : Delegated data controller and or data processor, for example, a third party analytics service would be a processor on behalf of the controller. Can also be the site operator is acting on behalf of the Data Controller.

 

  1. Contact Address : Physical address of PI controller

 

  1. Contact Email : Contact email address of the PI Controller

 

  1. Contact Phone : Contact phone number of the PI Controller

 

  1. PI Categories : A list of PI categories, defined and posted, see Appendix A for example

 

  1. Sensitive Data Y/N : Indicates whether data is sensitive or not sensitive (Yes or No)

 

  1. Purpose Category : The category for the kind of purpose PI will be used.

 

  1. 3rd Party : The name of the 3rd party the processor discloses PII too or method of disclosure,

 

  1. Consent Type : Model possible consent types:

A minimum list:

  • Explicit (or Expressed)
  • Implicit (or Implied)
  • N/A - collection required for purposes specified in law

 

Types of consent and their definitions follow in a ranked list.

NOTE: origin of explanation follows in brackets and corresponds to references.

Required or allowed by law or regulation: The PII controller collects the PII for purposes that are specified in law or regulation and may use it solely for the purposes set out in the law or regulation. [Ours]

Expressed or Explicit: The user has an opportunity to provide a specific indication that they consent to the collection of their PII for purposes that have been specified in a prior notice or are provided at the time of collection. [Europe 5.4.4]

  • Opt-in: a process or type of policy whereby the personally identifiable information (PII) principal is required to take an action to express explicit, prior consent for their PII to be processed for a particular purpose. [ISO 29100]
  • Opt-out: a process or type of policy whereby the PII principal is required to take a separate action in order to withhold or withdraw consent, or oppose a specific type of processing. [ISO 29100]

Implied or Implicit: The PII Controller has a reasonable expectation to believe that authority or consent already exists for the collection of the PII. [Ours]

Implementor Defined: Allow the PII Controller to define the type of consent they are using specifically. [Ours]

NOTE : THIS is a suggested ordered list, ranked by priority in legal regimes. This is using the format from the standard, where the types of consent are identified PLUS the "Required or allowed by law or regulation." This one may supersede or make consent superfluous but where an entity still wants or should provide a receipt. Opt-in is clearly a form of Expressed or Explicit consent. The question is less clear with respect to Opt-out. If we look at the ISO definition it could be read as a form of explicit consent.

 

  1. Collection Method : A description of the method by which consent was obtained.

 

  1. Jurisdiction : The jurisdiction field MUST contain an ISO two-letter country code if the applicable jurisdiction is in one of the countries for which there is such a code. Otherwise, the field MUST contain a non-empty string describing the jurisdiction.

 

  1. Privacy Policy : A link to the privacy policy that is valid when the consent was obtained and the receipt was issued.

 

  1. Receipt ID :  A unique number for the consent and may be used for consent login.

 

  1. Consent Time Stamp : Date and time MUST include time zone, or use UTC where consent was granted for operational use.

 

  1. Purpose Termination/Duration/Renewal :  Conditions for the termination of consent (on a purpose-by-purpose basis), such as length of time, out of physical area, etc .

3.1.3       Required Fields: Mode 2

Mode 2 has these additional fields

-           Version

-           GUUID

-           Public Key

-           Non Core Purpose

-           Data Controller Contact Name

 

3.1.4       Mode 2 Guidance for JSON Implementation

The Machine Readable mode contains five functional sections. Each section contains fields from the JSON format and are grouped by section category.

The five sections include:

1.       Consent Receipt Header

2.       PII Controller Information

3.       Purpose Specification

4.       Personally Identifiable Information

5.       Information Sharing

 

3.1.5       Header

The purpose of the Header structure sets out administrative fields for the consent transaction and is the metadata for the overall Consent Receipt. This section contains the following fields: 

3.1.5.1       Jurisdiction

           JSON Format:

Data field name:  jurisdiction

Description: ISO two-letter country code if applicable, otherwise free text

Format : string

 

Field Guidance

Jurisdiction MUST be specified for digital Consent Receipt. ISO country codes linked to a country ICON are recommended. In-person jurisdiction is implied, online it is inferred.

3.1.5.2       Consent Time-Stamp

JSON Format

Data field name: iat

Description: Date and time MUST include time zone, or use UTC where consent was granted for operational use.

Format: integer - number of seconds since 1970-01-01 00:00:00 GMT


Field Guidance
Date MUST be used for proof of consent, while time MUST be used for logging and auditing consent records chronologically.

3.1.5.3       Collection

JSON Format

Data field name:

Description:

Format:

 

Field Guidance

 

3.1.5.4       Collection Method

JSON Format

Data field name: moc

Description: A description of the method by which consent was obtained.

Format: string

 

Field Guidance

Collection method is a key field for context and determining what fields MAY be used for the Consent Notice and MUST be used for the Consent Receipt.

3.1.5.5       Receipt ID

JSON Format

Data field name: jti

Description: A unique number for the consent and may be used for consent login.

Format: string

 

Field Guidance

A globally unique ID (GUID) MUST be assigned to the Consent Notice or Consent Receipt.

3.1.5.6       Public Key

JSON Format

Data field name: publicKey

Description: Public Key of the authorizing Data Controller

Format: string

 

Field Guidance
This is the public key used to sign the consent receipt, which is needed to validate the Consent Receipt was provided by the Data Controller .

 

3.1.5.7       Version

JSON Format

Data field name: version

Description: Version of the Consent Receipt specification

Format: string

 

Field Guidance

This indicates what version of the Kantara specification this receipt conforms to.

 

3.1.6       PII Controller Information

This section identifies the individual and company that is accountable for data protection and the privacy policy to which the consent is bound.

See at JSON schema for complete JSON object implementation and general field table. This section contains the following fields:

3.1.6.1         PII Controller

JSON Format

Data field name: dataController

Description:

Format: object

 

Field Guidance
The controller determines why (purpose) and how (means) the processing of PII takes place. There may be more than one PII Controller for the same PII set(s) of operations performed upon. In this case the different PII Controllers SHOULD be listed in the Consent Receipt, and MUST be listed for sensitive consent with legally required  Explicit Notice to the PII subject.

 

3.1.6.2       On Behalf

JSON Format

Data field name: onBehalf

Description: Delegated data controller and or data processor, for example, a third party analytics service would be a processor on behalf of the controller. Can also be the site operator is acting on behalf of the PII Controller.

Format: Boolean

 

Field Guidance

Data controllers, data processors and other third parties MAY be named.

(Note: Explicit Sharing use case MUST name data controller for consent marked as sensitive PII.)

3.1.6.3       Contact Name

JSON Format

Data field name: contact

Description: Contact name for the PII Controller.

Format: string

 

Field Guidance
Contact Name - MUST be supplied in a Consent Notice in a Consent Receipt.

3.1.6.4       Company

JSON Format

Data field name: company

Description: Name of the data controller organization: the entity accountable for compliance over the management of PII.

Format: string

 

Field Guidance
The PII Controller organization MUST be named.

3.1.6.5       Contact Address

JSON Format

Data field name: address

Description: Physical address of PII Controller

Format: string

 

Field Guidance

Contact Address - (of processor(s) address for contacting the DPO in writing and verify ID) SHOULD be supplied in a Consent Notice and MUST be supplied or linked to in a Consent Receipt.

3.1.6.6       Contact Email

JSON Format

Data field name: email

Description: Contact email address of the PII Controller

Format: string

 

Field Guidance
Contact Email - the direct email to contact regarding the consent - DPO, CPO, privacy contact, MUST be supplied for the Consent Notice and Consent Receipt.

3.1.6.7       Contact Phone

JSON Format

Data field name: phone

Description: Contact phone number of the PII Controller

Format: string

 

Field Guidance
Contact Phone - the business phone to contact regarding the consent - DPO, CPO, administrator SHOULD be supplied for the Consent Notice and MUST be supplied for the Consent Receipt.

 

3.1.6.8       Privacy Policy

JSON Format

Data field name: policyUri

Description: A link to the privacy policy that is valid when the consent was obtained and the receipt was issued.

Format: string - HTTP URL

 

Field Guidance

A link the to privacy policy and applicable terms of use if including data and privacy concerns MUST be included in the Consent Notice and Consent Receipt at the time of Consent recording.

3.1.7          Purpose(s)

This section specifies the service(s) and purpose(s) for which the PII Controller is collecting PII. Services are listed as array of service objects (for object structure see the JSON schema). Note: A list of commonly used purpose categories is provided in Appendix B.

3.1.8          Services Array

JSON Format

Data field name: services

Description: Array that groups the fields related to service

Format: array

 

Field Guidance
See schema for more info

3.1.9          Service Name

JSON Format

Data field name: serviceName

Description: The service or group of services being provided for which PII is required.

Format: string

 

Field Guidance
Service MUST be identified for consent to be informed.

3.1.10      Purposes Array

JSON Format

Data field name: purposes

Description: Array that groups the fields related to purpose

Format: array


Field Guidance
See schema for more info

3.1.11      Purpose of Collection

JSON Format

Data field name: purpose

Description: A short clear statement of purpose of collection.

Format: string

 

Field Guidance
Organizations MUST provide a clear explanation of why the PII item is necessary when the reason is obscure from the context of the collection.

 

3.1.11.1   Consent Type

JSON Format

Data field name: consentType

Description: Explicit (or Expressed), Implicit (or Implied) or N/A - collection required for purposes specified in law.

Format: string

 

Field Guidance
Consent Type MUST be recorded at the time consent recorded. Indicates whether the purpose specified is implied, explicit, opt-out. It is used when specifying a purpose. N/A in the case where collection is a legal requirement.

3.1.11.2   Purpose Category

JSON Format

Data field name: purposeCategory

Description: The category for the kind of purpose PII will be used

Format: array of strings

 

Field Guidance

Purpose of use explains why the PII is required and what the PII is being processed for. MUST be supplied in both Consent Notice and Consent Receipt.

3.1.11.3   Non Core Purpose (Y/N)

JSON Format

Data field name: nonCorePurpose

Description: Indicates if a purpose is not part of the core service of the PII Controller (Yes or No).

Format: Boolean

 

Field Guidance
This indicates if a purpose is not required for the primary core service or is a consent preference. MAY be present in Consent Receipts, IS NOT used in Consent Notices.

3.1.11.4   Purpose Termination/Duration/Renewal

JSON Format

Data field name: purposeTermination

Description:  Defines the duration of consent and/or its condition of termination.

Format: string

 

Field Guidance
Collecting how consent/purpose is terminated. MAY be displayed for Consent Notices and MUST be for Consent Receipts. MAY be linked to consent withdrawal.

3.1.12      Personally Identifiable Information

This section specifies personal information categories, attributes, PII confidentiality level, PII Sensitivity for the purpose of explicit personal data tracking. Note: Sensitive Information Category is used for Compliance Specification.

3.1.12.1   PII Principal ID

JSON Format

Data field name: sub

Description: Subject provided identifier, email address - or Claim, defined/namespace.

Format: string

 

Field Guidance
A PI Principal ID (identifier) MUST be included for a Consent Receipt to be valid. Consent is not possible without an identifier.

3.1.12.2   PII Categories

JSON Format

Data field name: piiCategory

Description: A list of PII categories, defined and posted, see Appendix B for example.

Format: array of strings

 

Field Guidance

PII Category MUST be supplied, and should reflect the category that will be shared as understood by the user. In Appendix B there is an example of a defined list as supply by a member.

(and note for spec editor: not one promoted by the CIS-WG)

 

3.1.12.3   PII Confidentiality Level

JSON Format

Data field name: piiConfidentiality

Description: low, med, high

Format: string

 

Field Guidance
This is a field that MAY be used to indicate a level of confidentiality when the PII provided in the context of consent is confidential.

3.1.12.4   Sensitive Data Y/N

JSON Format

Data field name: sensitive

Description: Indicates whether data is sensitive or not sensitive (Yes or No).

Format: Boolean

 

Field Guidance
MUST be supplied. If data covered by the Consent Receipt is sensitive, or could be interpreted as sensitive, this can be Yes, which indicates that there is policy information out of band of the Consent Receipt. This field should be linkable to privacy policy for sensitive data.

(Note: There is no requirement to say why this is sensitive in version 0.8.)

3.1.12.5   PII Sensitive Category

JSON Format

Data field name: spiCat

Description: Listing the categories where PII data collected is sensitive.

Format: array of strings

 

Field Guidance
This field is REQUIRED if Sensitive Data Y/N field is a Yes/TRUE.

3.1.13 3rd Party Disclosure

The purpose of this section is to provide the PII Subject with information about how their information is shared with third parties. This is a Yes/No (binary On and Off) flag, and if On, then the 3rd parties can be specified, using purpose and at the minimum the purpose categories for the sharing of PII.

3.1.14      3rd Party Disclosure Y/N

JSON Format

Data field name: thirdPartyDisclosure

Description: Indicates whether disclosure is occurring for the purposes specified in the receipt.

Format: Boolean

 

Field Guidance
a Yes/No flag that indicates if PII is being disclosed outside the PII Controller organization . MUST be supplied for both Consent Notice and Consent Receipt.

3.1.15      Third Party

JSON Format

Data field name: 3rdPartyName

Description: The name of the 3rd party the PII Controller discloses PII to.

Format: string

 

Field Guidance

Third party name SHOULD be supplied if 3rd Party Disclosure Y/N field is a Yes.

4          General JSON Schema

{

  "$schema": "http://json-schema.org/draft-04/schema#",

  "type": "object",

  "properties": {

      "version": {

          "type": "string"

      },

      "jurisdiction": {

          "type": "string"

      },

      "iat": {

          "type": "integer"

      },

      "moc": {

          "type": "string"

      },

      "jti": {

          "type": "string"

      },

      "publicKey": {

          "type": "string"

      },

      "dataController": {

          "type": "object",

          "properties": {

              "onBehalf": {

                  "type": "boolean"

              },

              "contact": {

                  "type": "string"

              },

              "company": {

                  "type": "string"

              },

              "address": {

                  "type": "string"

              },

              "email": {

                  "type": "string"

              },

              "phone": {

                  "type": "string"

              }

          }

      },

      "policyUri": {

          "type": "string"

      },

      "services": {

          "type": "array",

          "items": {

              "type": "object",

              "properties": {

                  "serviceName": {

                      "type": "string"

                  },

                  "purposes": {

                      "type": "array",

                      "items": {

                          "type": "object",

                          "properties": {

                              "purpose": {

                                  "type": "string"

                              },

                              "consentType": {

                                  "type": "string"

                              },

                              "purposeCategory": {

                                  "type": "array",

                                  "items": {

                                      "type": "string"

                                  }

                              },

                              "piiCategory": {

                                  "type": "array",

                                  "items": {

                                      "type": "string"

                                  }

                              },

                              "nonCorePurpose": {

                                  "type": "boolean"

                              },

                              "purposeTermination": {

                                  "type": "string"

                              },

                              "thirdPartyDisclosure": {

                                  "type": "boolean"

                              },

                              "3rdPartyName": {

                                  "type": "string"

                              }

                          }

                      }

                  }

              }

          }

      },

      "sub": {

          "type": "string"

      },

      "sensitive": {

          "type": "boolean"

      },

      "spiCat": {

          "type": "array",

          "items": {}

      }

  }

}

 

5          Considerations

 

Consent is how people regulate privacy.  As a social control, consent is the signal people provide when they share personal information that is specific to a particular context. When broken down, the nature of consent for human communication and signaling can be observed in different ways: as implied consent, opt-out consent, and explicit consent.

 

With each consent policy notice and a Consent Receipt implementation there are different UX, legal, privacy, and security related considerations for the collection disclosure and use of PII consent by the organizations.

5.1.1       A Consent Receipt is PII

A Consent Receipt combines personal information with the agreement for its used to provide services. A Consent Receipt links multiple data sources with an identifier, which when identified in a Consent Receipt constitutes PII. In all jurisdictions consent for Sensitive Personal Information requires explicit consent, and is prescribed and regulated by privacy law.

 

5.1.2       Sensitive PII: Liability & Compliance

In this document sensitive data collection is indicated with Sensitive Data Y/N flag and is REQUIRED.  If ‘No’, then the Consent Receipt has limited liability for the provider as different jurisdictions have legal requirements for what is classified as sensitive . In addition, the implementor can define what is sensitive in their own privacy policy , even if not classified as sensitive in a particular jurisdiction .

 

If the implementor selects ‘Yes’ because sensitive data is collected , but, does not provide the categories of sensitive personal information with PII Sensitive Category field then it is assumed that what is sensitive and how it is managed will be found in the privacy policy linked to the Consent Receipt.

 

The provision of a Consent Receipt with the Yes field selected indicates the provider of the receipt is liable for providing the correct collection, use and disclosure policies as required by law in the provisioning jurisdiction. As a result, there are three levels of liability to consider for Consent Receipts by the implementor:

  1. Provision of the Consent Receipt for non sensitive PII (‘sensitiveData=NO’)
  2. Provision of a sensitive Consent Receipt with compliance claims out of scope of the receipt (SPI=YES but no SPI categories are listed)
  3. Provision of a sensitive Consent Receipt with the ‘sensitiveData=YES’ and sensitive categories are listed. These sensitive data categories MUST be linked to the consent notices specific to that sensitive PII use for the Consent Receipt to be used for a compliance claim so that the receipt can inherently demonstrate compliance with the consent notice requirements for the particular type of consent.
    1. If the sensitive data category is not linked to the specific notice for the compliance claim, the Consent Receipt  MUST NOT be considered transparent enough itself to be a compliance claim.

 

NOTE: In multiple jurisdictions there are categories listed as sensitive personal information. If you use, collect or disclose any of these categories or type of personal information these have legal meaning and can infer PII revealing the racial origin, political opinions or religious or other beliefs, personal data on health, sex life or criminal convictions, as well as other PII that might be defined as sensitive.

6          Acknowledgements

The Consent Receipt effort has been developed in the Kantara Community, supported by people who have invested in making this specification open and free to use. It is free so that people can have a common way to see their own data control and sharing. If you wish to provide feedback, you may join the Kantara Working Group, and then email us on our list at wg-infosharing@kantarainitiative.org or send feedback to: info@consentreceipt.org.

 

In addition to Kantara, we wish to thank the following contributors to the Consent Receipt effort:

Customer Commons

Colin Willis

Sal D’Agostino

Andrew Hughes

Justin Richer

Sarah Squire

 

The Consent Receipt standardization effort has been developed with support of many communities, as noted in our acknowledgements section, and leverages best of breed standards, legal regulation and technical practices in its design and development, as noted in the references section.

 

 

7          REFERENCES

7.1.1       Normative References

 

[DHS HSSPII] DHS Handbook for Safeguarding Sensitive PII. (Ed. 2012). https://www.dhs.gov/sites/default/files/publications/privacy/Guidance/handbookforsafeguardingsensitivePII_march_2012_webversion.pdf

[ Europe 5.4.4] Kosta, E., Consent in European Data Protection Law. Section 5.4: “Consent in the Context of Sensitive Data.” (Ed: 2013) p. 98-100.  https://goo.gl/JGPX2Y

[GAPP] - Generally Accepted Privacy Principles, developed through joint consultation with the Canadian Institute of Chartered Accountants (CICA) and the American Institute of Certified Public Accountants (AICPA) through the AICPA/CICA Privacy Task Force . https://www.cippguide.org/2010/07/01/generally-accepted-privacy-principles-gapp/

[ISO 18001-1:2005]    Information technology — Personal identification — ISO-compliant driving license — Part 1: Physical characteristics and basic data set. < https://www.iso.org/obp/ui/#iso:std:iso-iec:18013:-1:ed-1:v1:en >

 

[ISO 29100:2011]    Information technology -- Security techniques -- Privacy framework.

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45123

 

[RFC2119]    Bradner, S., “ Key words for use in RFCs to Indicate Requirement Levels ”, BCP 14, RFC 2119, DOI 10.17487/RFC2119 , March 1997, < http://www.rfc-editor.org/info/rfc2119 >.

 

[RFC7159]     Bray, T., Ed., “ The JavaScript Object Notation (JSON) Data Interchange Format ”, RFC 7159, DOI 10.17487/RFC7159 , March 2014, < http://www.rfc-editor.org/info/rfc7159 >.Normal Text

The list below contains a list of purposes for which Personally Identifiable Information (PII) has been collected, based on input from subject matter experts. This list is neither normative, in that none of these are required purposes in any given context, nor complete, in that each purpose for each collection by each entity is contextually specific. This list is provided for convenience and demonstration purposes. It is the case that in many jurisdictions, the entity collecting PII for identified primary purposes may not use that same information without the consent of the PII Subject for secondary purposes, unless required to do so by law, and it is the case that the PII Subject should be able to deny consent for secondary purposes while still receiving core functions from the site, application or service.

 

#

Description

Short Code

Notes

1.

To enable the entity to carry out the core functions of its site/app/services.

Core Function

Default Purpose

2.

To provide contracted or requested services to the PII Subject.

Contracted Service

 

3.

To deliver contracted or requested services to the PII Subject.

Delivery

 

4.

Communicating with you about information or services you specifically request.

Contact Requested

 

5.

Providing you with a personalized experience of our site/app/service.

Personalized Experience

 

6.

Communicating with you about our other services you may be interested in.

Marketing

 

7.

Communicating with you about the services of third parties you may be interested in.

Marketing Third Parties

 

8.

Providing the information to third parties to deliver our services on our behalf.

Use for Delivery

 

9.

Providing the information to third parties to enable them to communicate with you about their own services you may be interested in.

Disclosure for Marketing

 

10.

Providing the information to third parties to enable them to deliver or improve their own services to you.

3rd Party Disclosure for Core Function

 

12.

Complying with our legal obligations for record keeping.

Legally Required Data Retention

 

13.

Complying with our legal obligations to provide the information to law enforcement or other regulatory/government bodies.

Required by Law Enforcement or Government

 

14.

Protecting your vital and health interests.

Protecting Your Health

 

15.

Protecting our legitimate interests, yours or those of a third party.

Protecting Our Interests

 

16.

Measure or improve our performance or the delivery of our services.

Improve Performance

 

17.

Membership

 

 

 

NOTE: Other purposes may be uses as appropriate for the specific context of each jurisdiction and the site, application or service.

(Explainers/Examples)

Note: Some of these categories are also considered Sensitive Data;

        1. Biographical – (General information like Name, DOB, Family info (mother’s maiden name), marital status. Historical data like educational achievement, general employment history.)

        2. Contact – (Address, Email, Telephone Number, etc.)

        3. Biometric – (Photos, fingerprints, DNA. General physical characteristics – height, weight, hair color. Racial/ethnic origin or identification - whether self-identified or not)

        4. Communications/Social – (Email, message and phone records – both content and metadata. Friends and contacts data. PII about self or others.)

        5. Network/Service – (Login ids, usernames, passwords, server log data, IP addresses, cookie-type identifiers)

        6. Health – (Ailments, treatments, family doctor info. X-rays and other medical scan data)

        7. Financial – (This includes information such as bank account, credit card data. Income and tax records, financial assets/liabilities, purchase/sale of assets history.)

        8. Official/Government Identifiers – (This includes any widely recognized identifiers that link to individual people. Examples include National Insurance, ID card, Social security, passport and driving license numbers, NHS number (UK). Just the numbers rather than data associated with them.)

        9. Government Services - I.e. Social Services/Welfare – (Welfare and benefits status and history)

        10. Judicial – (Criminal and police records, inc. traffic offenses.)

        11. Property/Asset – (Identifiers of property – license plate numbers, broadcasted device identifiers. Not financial assets. Could include digital assets like eBook and digital music data)

        12. Employee Personal Information – (Records held about employees/ members/ students) not elsewhere defined. Incl. HR records such as job title, attendance/disciplinary records. Salary - as opposed to income.)

        13. Psychological/Attitudinal – (Inc. religious, political beliefs, sexual orientation and gender identity – though not genetic gender which is Biometric. Traits and personality measures or assessments, but not psychological health - which is health data).

        14. Membership – (Political, trade union affiliations, any other opt-in organizational/group membership data - third party organizations only. Includes name of employer when not held by employer. Could extend to online platform membership. Some might be more sensitive than others – may want a separate category)

        15. Behavioral – (Any data about the behavior, habits or movements of an individual - electronic or physical. Location, browser/search history, web page usage (analytics), energy usage (smart meters), login history, calendar data, etc.)16

CX Order

Field Name on Receipt

Field Type

1

Service

String

2

PII Principal ID

String

3

PII Controller

String

4

On Behalf

String

5

Contact Address

String

6

Contact Email

Email

7

Contact Phone

Number

8

PII Category

List

9

Sensitive Data Y/N

Yes/ No

10

Purpose Category

List

11

3rd Party Disclosure Y/N

Yes/ No

12

Consent Type

List

13

Collection Method

List

14

Jurisdiction

String

15

Privacy Policy

URL

16

Consent ID

String

17

Consent Time-Stamp

Military time

18

Purpose Termination/ Duration/ Renewal

List

 

 

{

  "version": "0.8",

  "jurisdiction": "US",

  "iat": 1470790094,

  "moc": "web form",

  "jti": "56eca54b-46f2-4825-b325-35c7451b59a4",

  "publicKey": "http://wordpress.dev/?cr_public_key=true",

  "dataController": {

      "onBehalf": false,

      "contact": "Colin Wallis",

      "company": "Kantara Initiative, Inc.",

      "address": "401 Edgewater Place, Suite 600, Wakefield, MA, 01880 USA",

      "email": "privacy-controller@kantarainitiative.org",

      "phone": "+1 781-623-3094"

  },

  "policyUri": "http://kantarainitiative.org/confluence/display/GI/Option+Patent+and+Copyright+(RAND)",

  "services": [

      {

          "serviceName": "Kantara Initiative WG - Information Sharing",

          "purposes": [

              {

                  "purpose": "Authority to sign Participation Agreement",

                  "consentType": "Explicit",

                  "purpose_category": [

                      "Affiliation"

                  ],

                  "piiCategory": [

                      "Membership"

                  ],

                  "nonCorePurpose": false,

                  "purposeTermination": "http://kantarainitiative.org/confluence/display/GI/Option+Patent+and+Copyright+(RAND)",

                  "thirdPartyDisclosure": false

              },

              {

                  "purpose": "Voting Status",

                  "consentType": "Explicit",

                  "purposeCategory": [

                      "Core Function"

                  ],

                  "piiCategory": [

                      "Membership"

                  ],

                  "nonCorePurpose": true,

                  "purpose_termination": "(when no activity)",

                  "thirdPartyDisclosure": false

              },

              {

                  "purpose": "Agree to IPR Policy",

                  "consentType": "Explicit",

                  "purposeCategory": [

                      "Core Function"

                  ],

                  "piiCategory": [

                      "Membership"

                  ],

                  "nonCorePurpose": false,

                  "purposeTermination": "staff@kantarainitiative.org",

                  "thirdPartyDisclosure": false

              },

              {

                  "purpose": "Web statistics",

                  "consentType": "Explicit",

                  "purposeCategory": [

                      "Improve Performance"

                  ],

                  "piiCategory": [

                      "Network/Service"

                  ],

                  "nonCorePurpose": false,

                  "purposeTermination": "staff@kantarainitiative.org",

                  "thirdPartyDisclosure": true,

                  "3rdPartyName": "Google"

              }

          ]

      }

  ],

  "sub": "cr-testing@berlinco.com",

  "sensitive": false,

  "spiCat": []

}

 

 

 

 

Version

Date

Summary of Substantive Changes

0.8 (Alpha)

2016-08-06

 

 

 

 

 

 

 

 

 

 

 

 


[1] ISTPA, (2007)   Analysis of Privacy Principals , pg. 64, [Online] http://www.istpa.org/ [Accessed Nov, 4 2010]