Consent Notice Receipt Specification

Version : 0.9.0

Date: 2016-09-24

Editor: Mark Lizar, David Turner

Contributors : Contributors List URL

Status: XXX WG/DG Kantara Initiative Recommendation

Abstract :

In every privacy M any legislative jurisdiction s , there are require ment s 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 defines a transaction record of a PII Principal’s consent that can be presented and delivered to the PII Principal.   It will include 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 and record of consent that may also be used for auditing, improving customer service, or other records purposes.

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.

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:

Table of Contents

1 INTRODUCTION

2 NOTATIONAL CONVENTIONS FOR CONFORMANCE

3 Terminology

4 Consent Receipt

4.1 Overview

4.2 Contents of receipt

4.2.1 Transaction details

4.2.2 Transaction Participants

4.2.3 Consented items

4.2.4 Receipt metadata

4.3 Presentation and Delivery

5 Consent Receipt - JSON

5.1 Header

6 Conformance

7 Considerations

7.1 A Consent Receipt is PII

7.2 Sensitive PII: Liability & Compliance

8 Acknowledgements

9 References

Appendix A: PURPOSE CATEGORIES

Appendix B: PII CATEGORIES OF DATA

Appendix C: SUGGESTED USER EXPERIENCE ORDER ( PUT IN FOR REFERENCE FOR NOW )

Appendix D: EXAMPLE JSON FOR CONSENT RECEIPT (FROM KANTARA REFERENCE IMPLEMENTATION)

Revision history

1          INTRODUCTION

Editor’s Note: This section has not been reviewed or edited and is unchanged.

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

 

CR Consent Receipt

PI Personal Information

PII Personally Identifiable Information

 

Editor’s Note: Definitions from external sources are unchanged and should be verified.

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

3.1         Collection

The act of receiving or obtaining PII [DT1] from or about a natural person.

3.2         Disclosure

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.

3.3         Consent

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

[ SOURCE [DT2] : ISO 29100]

3.4         Consent Receipt

A record of consent granted by a PII Principal to a PII Controller to collect, use and disclose the PII Principal’s PII in accordance with an agreed set of terms.

3.5         Consent Timestamp

The time and date that the consent receipt is issued.

3.6         Consent Type

The nature of the consent being used by the PII C c ontroller as their authority to collect, use or disclose PII.

3.7         Expressed or Explicit [DT3]

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]

3.8         Human Readable data/ information

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.

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.

[SOURCE: ISO 18001]

3.9         Machine Readable data / information

Machine Readable in the context of this specification refers to the JSON structured data output.

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.

[SOURCE: ISO 18001] [DT4]

3.10    Opt-in [DT5]

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.

[SOURCE: ISO 29100]

3.11    Opt-out [DT6]

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.

[SOURCE: ISO 29100]

3.12    Privacy Statement

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.

3.13    Personally Identifiable Information (PII)

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.

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

[SOURCE: ISO 29100]

3.14    PII Controller

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.

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.

[SOURCE: ISO 29100]

3.15    PII Principal

The natural person to whom the personally identifiable information (PII) relates.

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

[SOURCE: ISO 29100]

3.16    PII Processor

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

[SOURCE: ISO 29100]

3.17    Processing of PII

An operation or set of operations performed upon personally identifiable information (PII).

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.

[SOURCE: ISO 29100]

3.18    Purpose [DT7]

1. The business, operational or regulatory requirement for the collection, use and/or disclosure of a PII Subject's data.

2. The reason personal information is collected by the entity.

[SOURCE: GAPP]

3.19    Purpose Specification

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

3.20    Third Party

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.

[SOURCE: ISO 29100]

3.21    Sensitive PI [DT8]

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.

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.

[SOURCE: ISO 29100]

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]

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.

[SOURCE: 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.

[SOURCE: 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 implementers of the specification. In the GDPR, this is referred to as special categories of data.

3.22    Use [DT9]

Any processing of PII done by a PII Controller or by a PII processor on behalf of a PII Controller.

The use of collection, use and disclosure is a useful articulation of the steps in PII processing.

[SOURCE: PIPEDA [DT10] ]

4          Consent Receipt

4.1         Overview

Editor’s Note: TBD

4.2         Contents of receipt

Editor’s Note: The field descriptions need to be edited for consistent phrasing and use of terminology.

4.2.1          Transaction details

Editor’s Note: Chose to use my proposed field grouping for now. It will be easy to change this later.

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

Guidance: Date MUST be used for proof of consent, while time MUST be used for logging and auditing consent records chronologically. Should consider localization requirements [DT12] .

Collection Method : A description of the method by which consent was obtained. [DT13]

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.

Jurisdiction : The jurisdiction field MUST contain an ISO [DT14] 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.

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 [DT15] .

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

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.

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:

Opt-out:

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

Implementer Defined: Allow the PII Controller to define the type of consent they are using specifically.

NOTE: This 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.

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.

4.2.2          Transaction Participants

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

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

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

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.

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

Guidance: Data PII C c ontrollers, data p PII P rocessors and other third parties MAY be named.  

(Note: Explicit Sharing use case PI I Controller(s) MUST be name d data c ontroller for when consent marked as S s ensitive PII PII   is TRUE . )

PII Controller Organization [DT16] : [DT17] Name of the data controller organization: the entity accountable for compliance over the management of PII. [DT18]

Guidance: The PII Controller organization MUST be named.

PII Controller Contact Name [DT19] : MUST be supplied in a Consent Notice in a Consent Receipt .

PII Controller Address : Physical address of PII controller.

Guidance: Address for contacting the DPO [DT20] in writing and verify ID) SHOULD be supplied in a Consent Notice and MUST be supplied or linked to in a Consent Receipt .

PII Controller Email : Contact email address of the PII Controller

Guidance: The direct email to contact regarding the consent - DPO, CPO [DT21] , privacy contact, MUST be supplied . for the Consent Notice and Consent Receipt.

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

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

4.2.3          Consented items

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

PI I Categories : A list of defined and posted PI categories ( , defined and posted, s s ee Appendix A for example s) .

Guidance: PII Category MUST be supplied, and should reflect the category that will be shared as understood by the user PII Principal . In Appendix B there is an example of a defined list as suppl ied y by a member PII Controller [DT22] .

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

Sensitive Data PII : Y/N: Indicates whether data is sensitive or not sensitive . Possible values are TRUE or FALSE (Yes and or No can be used w h en presenting the CR in a human-readable format )

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

PII Sensitive PII Category : Listing the categories where PII data collected is sensitive. This field is REQUIRED if Sensitive Data PII   Y/N field is a Yes/TRUE.

PII Confidentiality Level : low, med, high

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.

Purpose Category : The category for the kind of purpose PI [DT23] will be used.

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.

Third Party Disclosure: Y/N

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.

Third Party Name : The name of the 3rd third party the processor discloses PII to or method of disclosure.

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

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

Guidance: A link to the 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.

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. [DT25]

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.

Purposes : A short clear statement of purpose of collection. Organizations MUST provide a clear explanation of why the PII item is necessary when the reason is obscure from the context of the collection.

Note: A list of commonly used purpose categories is provided in Appendix A: .

Services : The service or group of services being provided for which PII is required. Service MUST be identified for consent to be informed.

4.2.4          Receipt metadata

Version : This indicates what version of the Kantara specification this receipt conforms to. [DT26]

Consent Receipt GUID : A unique number [DT27] for the consent and may be used for [DT28] consent login. [DT29]

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

Public Key : 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 [DT30] .

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

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.

4.3         Presentation and Delivery

A CR must be presented on screen to the PII Principal or delivered to the PII Principal in a human readable format . A JSON encoded CR may also be delivered to the PII Principal.

5          Consent Receipt - JSON

5.1         JSON Fields

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

See at JSON schema for complete JSON object implementation and general field table.

This section contains the following JSON fields: 

Editor’s Note: I made changes to three JSON names here and in the schema.

company to org

policyUri to policyUrl

3rdPartyName to thirdPartyName

CR Field

JSON name

Format

Requirement

Jurisdiction

jurisdiction

string

MUST

Consent Time-Stamp

iat

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

MUST

Collection

 

 

 

Collection Method

moc

string

MUST

Consent Receipt ID

jti

string

MUST

Public Key

publicKey

string [DT31]

MAY (SHOULD?)

Version

version

String

 

PII Controller

dataController

object

MUST

On Behalf

onBehalf

boolean

MAY

PII Controller Contact Name

contact

string

MUST

PII Controller Organization

org

string

MUST

PII Controller address

address

string [DT32]

MUST

PII Controller email

email

string [DT33]

MUST

PII Controller phone

phone

string

MUST

Privacy Policy

policyUR I policy Url

string – http URL

MUST

Purposes

 

 

MUST

Purposes Array

purposes

 

MUST

Purpose of Collection

purpose

 

MUST

Services

 

 

MUST

Services Array

services

array

MUST

Service Name

serviceName

string

MUST

Consent Type

consentType

string

MUST

Purpose Category

purposeCategory

array of strings

MUST

Non-core Purpose

nonCorePurpose

Boolean

MAY

Purpose Termination

purposeTermination

string

MUST

PII Principal ID

sub

string

MUST

PII Categories

piiCategory

array of strings

MUST

PII Confidentiality
Level

piiConfidentiality

string (low, med, high)

MAY

Sensitive Data PII

sensitive

Boolean

MUST

PII Sensitive
Category

spiCat

array of strings

MUST if sensitive is TRUE

Third Party
Disclosure

thirdPartyDisclosure

boolean

MUST

Third Party Name

third 3rd PartyName

string

MUST if thirdPartyDisclosure is TRUE

5.2         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 org ": {

         "type": "string"

       },

       "address": {

         "type": "string"

       },

       "email": {

         "type": "string"

       },

       "phone": {

         "type": "string"

       }

     }

   },

   "policyUr l i ": {

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

               },

               " third 3rd PartyName": {

                 "type": "string"

               }

             }

           }

         }

       }

     }

   },

   "sub": {

     "type": "string"

   },

   "sensitive": {

     "type": "boolean"

   },

   "spiCat": {

     "type": "array",

     "items": {}

   }

}

}

6          Conformance

Editor’s Note: TBD

7          Considerations

Editor’s Note: This section has not been reviewed or edited and is mostly unchanged.

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.

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

7.2         Sensitive PII: Liability & Compliance

In this document sensitive data collection is indicated with Sensitive Data PII 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 implementer can define what is sensitive in their own privacy policy, even if not classified as sensitive in a particular jurisdiction.

If the implementer 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 implementer:

  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 S s ensitive data PII C c ategories 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 S s ensitive data PII 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.

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

9          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

Appendix A:                    PURPOSE CATEGORIES

Editor’s Note: This section has not been reviewed or edited and is unchanged.

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.

Appendix B:                     PII CATEGORIES OF DATA

Editor’s Note: This section has not been reviewed or edited and is mostly unchanged.

(Explainers/Examples)

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

  • Biographical – (General information like Name, DOB, Family info (mother’s maiden name), marital status. Historical data like educational achievement, general employment history.)
  • Contact – (Address, Email, Telephone Number, etc.)
  • Biometric – (Photos, fingerprints, DNA. General physical characteristics – height, weight, hair color. Racial/ethnic origin or identification - whether self-identified or not)
  • Communications/Social – (Email, message and phone records – both content and metadata. Friends and contacts data. PII about self or others.)
  • Network/Service – (Login ids, usernames, passwords, server log data, IP addresses, cookie-type identifiers)
  • Health – (Ailments, treatments, family doctor info. X-rays and other medical scan data)
  • Financial – (This includes information such as bank account, credit card data. Income and tax records, financial assets/liabilities, purchase/sale of assets history.)
  • 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.)
  • Government Services - I.e. Social Services/Welfare – (Welfare and benefits status and history)
  • Judicial – (Criminal and police records, inc. traffic offenses.)
  • Property/Asset – (Identifiers of property – license plate numbers, broadcasted device identifiers. Not financial assets. Could include digital assets like eBook and digital music data)
  • 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.)
  • 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).
  • 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)
  • 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.)

Appendix C:                    SUGGESTED USER EXPERIENCE ORDER ( PUT IN FOR REFERENCE FOR NOW )

Editor’s Note: This section has not been reviewed or edited and is mostly unchanged.

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 PII 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": []

}

Revision history

Version

Date

Summary of Substantive Changes

0.8 (Alpha)

2016-08-06

 

0.9

2016-09-21

Significant restructuring of document and updates based on comments received.

 

 

 

 

 

 

 


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


[DT1] Shouldn’t this be “data” or “information” because it’s not all PII.

[DT2] Added to all definitions from another source.

[DT3] Which term?

[DT4] These definitions may no longer be required.

[DT5] Moved here from body of the document

[DT6] Moved here from body of the document

[DT7] How can you have two definitions for the same term? You need to pick one definition or create a second term.

[DT8] Multiple definitions and the ISO 29100 is not listed 1 st . Could add note indicating how this varies between jurisdictions and provide the other definitions as examples.

[DT9] Two definitions again?

[DT10] I assume this is http://laws-lois.justice.gc.ca/eng/acts/P-8.6/index.html . I couldn’t find its formal definition of “use”.

 

[DT11] From MyData - Description requires that time zone must be included. Still, Format –section below defines timestamp as an epoch which cannot contain time zone information.

[DT12] From MyData - This must be clarified. What does this mean?

[DT13] From: MyData - Free text or predefined options?

[DT14] From MyData - ISO 3166-1, alpha-2 or ??

[DT15] Based on what?

[DT16] Is this different from “PII Controller Name”?

[DT17] I changed this from “Company”

[DT18] From MyData - Any requirements? VAT-number? Business ID?

[DT19] From MyData - Name of a real person? Any requirements?

[DT20] What is a DPO

[DT21] Does this mean chief privacy officer?

[DT22] Is this what “member” meant?

[DT23] PI or PII?

[DT24] From MyData - Does this mean that privacy policy must have a version number? What happens when privacy policy is updated to new version? Is the old privacy policy still valid? If not, must all consents be regenerated?

[DT25]

From MyData

Any rules for this? Timestamps?

 

Harri: The field structure MyData specification team chose to describe the consent duration was two define two timestamps: ‘not-valid-before’ and ‘not-valid-after’. Not-valid-before can be the time of signing the consent, but it could also be a time frame reaching to a past time setting. This allows technically e.g. consenting to move one’s data from source A to data using service B, including the data history at source side. These two timestamps could be appended with string field (as in CR v0.8) to document the potential termination condition in words (-> string).

[DT26] From MyData - Compatibility between other versions?

Backwards…forwards compatibility – what is going to be the policy?

[DT27] From MyData - Unique number? Can this be UUID4? Is it unique enough?

[DT28] From MyData - Meaning? How?

[DT29] This seems like an implementation detail.

[DT30] From MyData - Is this only public key needed? During Hackathon we were instructed use URL that points to public key. Is this still the way to go?

[DT31] From MyData - Is there need for more detailed specification of key format?
- JWK?
- X.509 cert?
- something else?

[DT32] From MyData - How address is expressed as a string? This needs clear format.

How address formats of different countries are taken into account?

As a result - is string correct format or should this be described as a JSON-object?

[DT33] From MyData - Are validation rules needed for implementations?