Consent Notice Receipt Specification

Version : 0.9.2

Date: 2016-10-1 9 7

Editor: Mark Lizar, David Turner

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

Status: XXX WG/DG Kantara Initiative Recommendation

Abstract :

A Consent Receipt is 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. This specification defines the common requirements to create an independent record of consent in the form of a receipt given to the individual. It will include links to existing consent notices and details regarding what information the user is sharing. A Consent Receipt is one element of a framework to bind policy to privacy controls (e.g. Do Not Track).

The Consent Receipt specified in this document is engineered according to modern principles of 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:

1 Introduction

2 Notations and Abreviations

3 Terms and definitions

4 Consent Receipt

4.1 Contents of receipt

4.2 Presentation and Delivery

5 Consent Receipt - JSON

5.1 JSON Fields

5.2 JSON Schema

6 Conformance

7 Considerations

7.1 A Consent Receipt is PII

7.2 Sensitive PII: Liability & Compliance

8 Acknowledgements

9 References

Appendix A: PII Categories of Data

Appendix B: Example consent Receipts

Revision history

1          Introduction

Many legislative jurisdictions require that a user be be provided with a privacy notice in order for their consent for the processing of personal information be valid. However, people today cannot easily track the consent they have given or how information about them is processed .

This Consent Receipt establishes one element of a larger consent framework to help individuals track personal information, how it is shared and under what policies it is governed by connecting consent-specific information to form a record of consent. Much like a purchase receipt maps the price of a product or service to payment, the Consent Receipt effectively maps and links the legal, social and contextual elements of a consent transaction. The use of a standard format promotes consistent consent practices, supports interoperability between systems, and ultimately enables proof of consent.

Editor’s Note: Will insert example of Alice and BobCo with illustration.

This specification defines the required elements of a Consent Receipt, based on the information currently required in consent notices, and a schema for creating a JSON encoded Consent Receipt.

Individuals or organization responsible for implementing this specification will have different security, legal, privacy considerations for the provisioning, control, security and use of a Consent Receipt, which are out-of-scope of this specification. We note as a general rule that this specification is a baseline minimum and that implementers may provide additional information in a receipt in order to meet their own specific regulatory and policy requirements, so long as those additions do not contradict or override the information provided for in this basic consent receipt specification.

Implementers will have   different security, legal, privacy considerations for the provisioning, control, security and use of a C onsent Receipt, which are out-of-scope of this specification.

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

 

CPO Chief Privacy Officer

CR Consent Receipt

DPO Data Protection Officer

GDPR General Data Protection Regulation

PI Personal Information

PII Personally Identifiable Information

 

3          Terms and definitions

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

This specification, where possible, takes terminology and definitions from ISO specifications and other published, recognized efforts to maintain consistency with the terms commonly used in the ecosystem. If other organizations’ terms are not compatible with this 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 data 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 PII. It is a transfer of accountability, not just a transfer of information.

NOTE: When a PII Controller transfers or copies information to another entity it retains accountability for that PII. An example would be an entity using a cloud storage service for backups. We note this here because , for   from a PII subject’s point of view PII Principal , 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: 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 . when consent was obtained from the PII Principal.

3.6         Consent Type

The type of the consent used by the PII Controller as their authority to collect, use or disclose PII.

3.7         Explicit (Expressed) Consent

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

(Of text, data, etc. ) in a form that can be naturally or easily read by a person (frequently in contrast to computer-readable, machine-readable).

[SOURCE: OXFORD]

3.9         Implicit (Implied) Consent

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

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

[SOURCE: ISO 29100]

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

[SOURCE: ISO 29100]

3.12    Privacy Statement

Notice provided by the PII Controller to inform the PII Principal of what will be done with their information.

Note: The contents of this notice may be required by regulation and may include information that is beyond the scope of this specification.

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

[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

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 PII

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]

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 ( http://www.legislation.gov.uk/ukpga/1998/29/section/2 ) as personal data consisting of information relating to the data subject concerning 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

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

NOTE: “collection, use , and disclosure” is a useful articulation of the steps in PII processing.

[SOURCE: PIPEDA]

4          Consent Receipt

4.1         Overview

Editor’s Note: TBD

Contents of receipt

Transaction Details

Field Name

Definition

Guidance

Consent Time Stamp

Date and time of the consent transaction

MUST include a time zone or indicate UTC. Presentation to end users SHOULD consider localization requirements.

Collection Method

A description of the method by which consent was obtained .

Collection M m ethod is a key field for context and determining what fields MUST be used for the Consent Receipt.

Consent Type [DT1]

Indicates whether if the purpose specified is implicit, explicit, or opt-out. It is used when specifying a purpose. N/A in the case where collection is a legal requirement.

Possible consent types:

  • Required or “Allowed by law or regulation”
  • Explicit
  • Opt-in
  • Opt-out
  • Implicit
  • Implementer Defined

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.

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

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.

 

Jurisdiction

Jurisdiction(s) applicable to this transaction.

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

Service

The service or group of services being provided for which PII is collected .

 

Transaction Participants

Field Name

Definition

Guidance

On Behalf

A delegated PII Controller or PII Processor. For example, a third party analytics service would be a PII Processor on behalf of the PII Controller, or a site operator acting on behalf of the PII Controller.

PII Controllers, PII Processors , and other third parties MAY be named. PII Controller(s) MUST be named when Sensitive PII is TRUE.

PII Principal ID

PII Principal provided identifier. E.g. email address, claim, defined/namespace.

Consent is not possible without an identifier.

PII Controller

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

The PII Controller determines the purpose(s) and type(s) of PII processing. There may be more than one PII Controller for the same set(s) of operations performed on the PII. In this case , the different PII Controllers SHOULD be listed , , and it MUST be listed for Sensitive PII with legally required explicit notice to the PII Principal.

PII Controller Address

Physical address of PII controller.

Address for contacting the DPO in writing and verify ID.

PII Controller Contact

Contact name of the PII Controller

 

PII Controller Email

Contact email address of the PII Controller

The direct email to contact the PII Controller regarding the consent. e E .g .   ,   DPO, CPO, privacy contact

PII Controller Phone

Contact phone number of the PII Controller.

The business phone number to contact the PII Controller regarding the consent. e E .g . , DPO, CPO, administrator.

Consented Items

This section specifies personal information categories, attributes, PII confidentiality level, and PII Sensitivity.

NOTE: The Sensitive PII category is used for the Compliance Specification.

 

Field Name

Definition

Guidance

PII Categories

A list of defined PII categories.

PII Category should reflect the category that will be shared as understood by the PII Principal. In Appendix B there is an example of a defined list as supplied by a PII Controller.

PII Confidentiality Level

Used to indicate a level of confidentiality when the PII provided in the context of consent is confidential.

Possible values are low, med, and high.

Privacy Policy

A link to the privacy policy and applicable terms of use in effect when the consent was obtained and the receipt was issued .

 

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.

 

Purpose Category

The reason the PII Controller   is collecting the PII personal information is collected by the PII Controller .

 

Purpose Termination, Duration, Renewal

Conditions for the termination of consent (on a purpose-by-purpose basis), such as length of time, out of the physical area, etc .

Collecting how consent/purpose is terminated . MAY be linked to a consent withdrawal.

Sensitive PII

Indicates whether PII is sensitive or not sensitive.  Possible values are TRUE or FALSE

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 the privacy policy for sensitive data.

Yes and No can be used when presenting the CR in a human-readable format.

Sensitive PII Category

Listing the categories where PII data collected is sensitive.

This field is REQUIRED if Sensitive PII is Yes/TRUE.

Services

The service or group of services being provided for which PII is collected .

 

Third Party Disclosure

Indicates if PII is being disclosed outside the PII Controller Possible values are TRUE or FALSE.

Yes and No can be used when presenting the CR in a human-readable format.

Third Party Name

The name of the third party the PII Processor discloses PII to .

SHOULD be supplied if Third Party Disclosure IS TRUE.

Receipt Metadata

Field Name

Definition

Guidance

Consent Receipt GUID

A unique number for each Consent Receipt.

 

Non-Core Purpose

Indicates if a purpose is not part of the core service of the PII Controller. Possible values are TRUE or FALSE.

Yes and No can be used when presenting the CR in a human-readable format.

Public Key

The PII Controller’s public key used to sign the consent receipt.

 

Version

This indicates   t T he version of this specification a receipt conforms to .

T he value is   This field is REQUIRED in the JSON schema. KI-CR-v1 [DT2] for this version of the specification.

4.2         Presentation and Delivery

Although a CR can be provisioned in any manner that is feasible or expected based on the context, a CR SHOULD MUST be provided to the PII Principal in a human-readable format either on screen, or presented on screen to the PII Principal or delivered to the PII Principal , or both. in a human-readable format. A JSON encoded CR may MAY also be delivered to the PII Principal.

NOTE: Issues such as language translation, localization, human-readable layout and formatting, and delivery mechanisms are out-of-scope for this document.

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 the JSON schema for complete JSON object implementation and general field table .

JSON fields: 

 

CR Field

JSON name

Data Type

Format/Example

Jurisdiction

jurisdiction

string

 

Consent Time-Stamp

iat

integer

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

Collection

 

 

 

Collection Method

moc

string

 

Consent Receipt ID

jti

string

 

Public Key

publicKey

string

 

Version

version

String

 

PII Controller

dataController

object

 

On Behalf

onBehalf

boolean

 

PII Controller Contact Name

contact

string

 

PII Controller Organization

org

string

 

PII Controller address

address

string

https://schema.org/PostalAddress   JSON object recommended.

PII Controller email

email

string

 

PII Controller phone

phone

string

 

Privacy Policy

policyUrl

string

HTTP http URL

Purposes

 

 

 

Purposes Array

purposes

array of objects

 

Purpose of Collection

purpose

 

 

Services

services

array   of objects

 

Services Array

services

array

 

Service Name

serviceName

string

 

Consent Type

consentType

string

 

Purpose Category

purposeCategory

array of strings

 

Non-core Purpose

nonCorePurpose

Boolean

 

Purpose Termination

purposeTermination

string

 

PII Principal ID

sub

string

 

PII Categories

piiCategory

array of strings

 

PII Confidentiality
Level

piiConfidentiality

string

(low, med, high)

Sensitive PII

sensitive

Boolean

 

PII Sensitive
Category

spiCat

array of strings

 

Third Party
Disclosure

thirdPartyDisclosure

boolean

 

Third Party Name

thirdPartyName

string

 

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"

       },

       "org": {

         "type": "string"

       },

       "address": {

         "type": "string"

       },

       "email": {

         "type": "string"

       },

       "phone": {

         "type": "string"

       }

     }

   },

   "policyUrl": {

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

               },

               "thirdPartyName": {

                 "type": "string"

               }

             }

           }

         }

       }

     }

   },

   "sub": {

     "type": "string"

   },

   "sensitive": {

     "type": "boolean"

   },

   "spiCat": {

     "type": "array",

     "items": {}

   }

}

}

6          Conformance

Editor’s Note: TBD A Consent Receipt MUST include the fields as defined in the table bel ow. When using JSON, the Consent Receipt MUST also be valid according to the Consent Receipt schema.

CR Field

H h uman-readable

JSON encoding

Collection Method

MUST

MUST

Consent Receipt ID

MUST

MUST

Consent Time-Stamp

MUST

MUST

Consent Type

MUST

MUST

Jurisdiction

MUST

MUST

Non-core Purpose

MAY

MAY

On Behalf

MAY

MAY

PII Categories

MUST

MUST

PII Confidentiality
Level

MAY

MAY

PII Controller

MUST

MUST

PII Controller address

MUST

MUST

PII Controller Contact Name

MUST

MUST

PII Controller email

MUST

MUST

PII Controller Organization

MUST

MUST

PII Controller phone

MUST

MUST

PII Principal ID

MUST

MUST

PII Sensitive
Category

MUST if Sensitive PII is TRUE

MUST if Sensitive PII is TRUE

Privacy Policy

MUST

MUST

Public Key

MAY

MAY

Purpose Category

MUST

MUST

Purpose of Collection

MUST

MUST

Purpose Termination

MUST

MUST

Sensitive PII

MUST

MUST

Services

MUST

MUST

Third Party Name

MUST if thirdPartyDisclosure is TRUE

MUST if thirdPartyDisclosure is TRUE

Third Party
Disclosure

MUST

MUST

Version

MUST

MUST

 

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 implicit 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 use d   in order for the service provider 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 which is prescribed and regulated by privacy law.

7.2         Sensitive PII: Liability & Compliance

In this document , sensitive data collection is indicated with Sensitive PII 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 , or confidential, 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 to in 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 notice 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 Sensitive PII Categories MUST be linked listed to in the consent notices Consent Receipt specific to that sensitive PII use for the Consent Receipt to be used for a compliance claim . so that In this manner, the receipt can inherently demonstrate compliance with the consent notice requirements for the particular type of consent.
    1. If the Sensitive PII category is not linked listed   to in the specific notice for the compliance claim Consent Receipt , 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 sensitive personal information these have legal requirements, require explicit consent and can have jurisdiction-specific legal notice requirements to be informed For example, 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

Eve Maler

The Consent Receipt standardization effort has been developed with the support of many communities, as noted in our acknowledg e ments 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/

[GDPR] General Data Protection   Regulation , http://www.eugdpr.org/article-summaries.html

[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

[PIPEDA] Personal Information Protection and Electronic Documents Act , http://laws-lois.justice.gc.ca/eng/acts/P-8.6/index.html

[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

[OXFORD] Oxford University Press - Definition of human-readable in English, https://en.oxforddictionaries.com/definition/us/human-readable

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 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 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 s, 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 S s ecurity , passport and driving license numbers, NHS number (UK). Just the numbers rather than data associated with them.)
  • Government Services - i I .e . Social Services/Welfare – (Welfare and benefits status and history)
  • Judicial – (Criminal and police records, inc luding . 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 luding . 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 the employer when not held by the 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. )

The following examples ar e based on data from the Kantara reference implementation [DT3] .  

Human-readable Consent Receipt

Editor’s note: Need image of human-readable example based on the same data in the JSON example below EXAMPLE JSON FOR CONSENT RECEIPT

A.1         (FROM KANTARA REFERENCE IMPLEMENTATION) JSON Consent Receipt

{

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

0.9.1

2016-10-02

New Abstract and Introduction, editorial review and update of most sections, and updates based on WG feedback.

0.9.2

2016-10-19  

Further editorial updates.

Created tables for CR field definition, JSON field descriptions, and CR conformance.

 


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


[DT1] Input required from the WG.

[DT2] This should be defined within the spec for each version of the spec. The string I proposed is completely arbitrary. Alternatives are welcome. However, please note that this string does NOT have to be human-readable. It is better to keep the string simple and let the implementers replace it with text that is appropriate to their audience. (e.g. in other languages).

[DT3] Need a URL reference.