Editors:

Action Items

•  Former user (Deleted)  insert walkthrough demo links)
• John Wunderlich edit the outline for draft 5
• Finish Compliance Scale description and compliance audit rules

Related Documents:

• CISWG: Consent Requirements Map: (spreadsheet of laws/principles for receipt and data control R&D)
• Latest Consent Receipt Template
• Hackathon Video and  Convergathon Hack Notes from July 12&13 2014 -->
• Scale of Compliance to measure the legal compliance of a consent receipt

Respect Network (RN) Technical Demo:

• Store a Consent Receipt in your RN personal cloud using XDI: http://amazon-respect-consent.herokuapp.com/
  
• List Consent Receipts in your RN personal cloud: http://open-notice.github.io/respect-network-receipts/

Open Notice  Website - Consent Receipt - Technical Demo

• Provides a simple consent receipt to show compliant policy (in progress) http://on.smartspecies.com/receipt-example/
• Show Directory of Supporters with consent to appear directory managed by supporters personal data store (in progress)

Overview

This is a specification to develop an open consent notice protocol for trusted services.  The specification combines legal, technical and social consent elements and records them in a transparent manner which is called a consent receipt. The consent receipt demonstrates the technical aspects, the fields required for the Minimum Viable Consent Receipt (MVCR) represent the legal aspects, and the trusted services and the compliance scale represent the social aspects of this specifications. 

Specification by example (SBE) is a collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements. It is applied in the context of agile software development methods, in particular behavior-driven development. This approach is particularly successful for managing requirements and functional tests on large-scale projects of significant domain and organisational complexity.^{[1] (https://en.wikipedia.org/wiki/Behavior-driven_development)}

A key aspect of specification by example is creating a single source of truth about required changes from all perspectives. This latest version specification with this document title is the single source of truth. 

Objective

The aim of the specification is to increase usability and the legal compliance of consent.  This means that:

1.  An Organisation can use the MVCR to self assert that they are providing notice and getting implied consent in compliance with their policies and applicable regulations
2. An service user (individual) can save the  MVCR to a personal cloud and self assess if the receipt is compliant with the policies and practices of the organisation

Interoperability & Scalability 

• Interoperable: the common format provide a common structure  for the consent provisioner (the individual) to mange consent globally
• Open Notice is currently working on an open source: Open Consent Registry (OCR), which will be a customisable registry that can be use to automate the functions required to process and use consent receipts at scale.

Background

The Open Notice Initiative is an effort that calls for open consent (http://opennotice.org/callforcollaboration).   This has resulted in the development of this specification for a Minimum Viable Consent Receipt(MVCR).

Glossary 

• Minimum Viable Consent Receipt(MVCR)

• Consent Receipt (CR) 

• Data Subject(DS)

• Data Controller(DC) 

• Trusted Services; A provider of Trust/Privacy Icons, Standard Assurance,  Reputation Services, Trusted Network, Trusted Protocols, 

• Minimum: (in Minimum Viable Consent Receipt) means to only  include only the fundamental links needed to gain transparency and make further usable the consent receipt for consent and identity management. 

• Viable: (in Minimum Viable Consent Receipt) refers to the utility of the receipt being transparent. (Note: wether the receipt is compliant legally is a secondary factor to producing a record of consent)

Minimum Viable Consent Requirements

By its format and structure the MVCR is intended to provide the basic information to review further the compliance of policy for consent. The MVCR is a format for an organisation to link, capture and sign existing (required-to-be open) policy information for consent.  The receipt is intended to provide a structure to capture  all the consent provided (cookie, terms, privacy policy) at the time of consent enabling the data controller to provide a compliance by default receipt.  (as seen in Walkthrough 1) 

A usability of a minimum viable consent receipt can then further be extended with additional notice and consent requirements specific to data subject jurisdiction, data type, location of consent and additional stakeholder contexts. (see extensions) 

MVCR enables organization to self-assert that they are compliant (or compliant by design)

Technically - this means that if a DC that collects personal data provides the fields listed in the MVCR, and does not share personal information or collect sensitive personal information, then the receipts and policies are compliant by default. (see compliance scale and audit f.or MVCR)

A MVCR with a complaint status will assure a basic level of general regulatory compliance with a much higher usability.  It will do this by being digitally represented, digitally accessible, providing at the minimum a clear way to find the Data Controller contact,  required address, and purpose(s) of consent as a standard format.  This format can then be audit for these data points at a glance, with one click access to all consent related policies by default. This can further be enhanced with organisation integrated trusted services (icons and links) to be added to the receipt.  These trusted services, for instance privacy icons or Terms of Service, are then used to further extend the usability and increase the control of consent and trust it provides. 

MVCR: Notice Elements

 Minimum: means to only  include only the fundamental links needed to gain transparency and make further usable the consent receipt for consent and identity management. 

Notice Legal Requirements Included for the MVCR Format (in progress)

Context: Operational Context Legal Requirements for MVCR Context (in progress)

Each jurisdiction has prescriptive text which need to accompany specific types of consent as well as legally written terminology for these requirements.   With notices there are also contextual and prescriptive requirements in legislation, a check list of these elements is being crated in this draft below. (this list is a draft 

Note:  also requires specific text  to accompany a notice at the point of consent, which may vary depending upon legal jurisdiction and context.

Extensions for the MVCR

Open Consent Notice Extensions 

Extension Types

In each jurisdiction there are sensitive types of personal information found in privacy and data protection law.  Each sensitive type corresponds to a jurisdiction an industry of existing assurance and a community of trusted services.   These can be layered on to of the MVCR to meet requirements from multiple jurisdictions and industries and context.

These extensions also enable policy makers to localise the use of consent notices by jurisdiction. 

An extension can be written to strengthen the compliance of a consent receipt, 3rd party trusted services can also be used to extend the compliance or trust inherent to corporate process and these can be added in the form of linked Icons to the consent receipt.

MVCR Proposed Extensions (in progress)

 These are the extensions tables.  This is an active list of extensions being planned and/or developed  need to include the name of the filed, have a description, context, benefit, and examples.

The various table currently include. 

Extension Example: Third Party Sharing Extension V.1

 This incorporates 3rd party sharing and purpose listing format

The first extension for the minimum viable consent receipt is that of linking to the consent receipt of list of third parties personal data is shared with.  In some jurisdictions it is only required that the categories of personal data be provided.

If in the MVCR the "Third Party Sharing" flag is true, this is an extension they can use to make the receipt show this level of compliance.

Enter Table: For Extension structure of 3rd party transparency

(link to Table:  

• Categories of personal data shared & (or)
• Name of third party shared with
• Purpose of sharing
• Link to third party CR & Policies

Trusted Services

Trusted services/networks and frameworks, can be used to meet or exceed notice(and therefore consent) legal requirements. Or to address the need for assurance and trust for people so that consent and its management can be automated and more usable.

• Draft Trust Services Auditing Compliance Scale

  Type of Trust Framework	Consent Policy Format	Personal Policy Preference	Consent Extension Location	Trusted Service Provider Examples
  Tracker: Analytics etc:	Cookie	Do Not Track	browser header	cookiepedia, privacy clearing warehouse, Ghostery
  Terms of Use Policy	Agree to terms			TOS;DR, Citizen Me
  Policy Tracking Services	Policy Comparison	Has terms materially changed ( is consent still compliant? )		TOSBack
  	Consent Type	What kind of consent has been received	To record the type of consent or whether there is an exception to the requirement for consent.
  Reputation	Trust Framework			(all trust services provide reputation)
  Privacy Icons	Pictorial Short Notices			Disconnect Me
  Capture of Personal Preference at Time of Consent	Does the issuing entity acknowledge DNT	If not available, should provide a notice that it is missing		[#receipt]!:uuid:1234<#dnt>&/&/true
  Data Control Protocol				User Managed Access
  Trusted Network Service				Respect Network
  Standards
  Certificates				TrustE
  Levels of Assurance				KI: Identity Assurance Framework

Usability: MVCR Provision Example

The MVCR has a base template that is being updated all the time.

Old Version can be found XXX 

(******Template  HERE***)

We have  a template that we are using for the technical design of the consent receipt, the GUI design is also out of scope.  What is provided by default is a Consent Receipt Template that we are using for technical design. 

Open Notice Consent Receipt Example

(Example (in progress) can be found at http://on.smartspecies.com/support-open-notice/

(******SCREEN SHOT HERE***)

Storing Receipt in Personal Data Store: Technical Walkthrough Example with Respect Network

Amazon Respect Use Case: With the Respect Network and Open Notice
(Note: Amazon Respect is a Fictitious organisation used here only as an example) 

(http://open-notice.github.io/consent-receipt/amazon-mock/signup.html)

Implementation of consent receipt which is signed & created by a DC and stored in a personal Cloud. 

To make the consent receipt usability scalable it needs to be signed and put in a personal data store. 

This specification and demo is created to demonstrate a MVCR being implemented without the need for an Open Notice Registry with the Respect Network (Trusted Network) Trust Framework  which natively has the ability to provision receipts to the highest level of compliance .  This walk through demo is intended to demonstrate how a consent receipt can be stored in a personal cloud from this spec document and demonstrate 'Fast Track' usability. 

1. DS goes to amazonrespect.com website

2. Website presents form and asks for consent:

1. either to sign up initially

2. or  for additional consent and profile management when already logged in

3. DS agrees (clicks on “i agree” button)

4. DC website initiates creating the receipt for the consent that was just given.

5. DC checks for reciept data collection and notice extensions and finishes creating the receipt

6. The receipt is signed by DC.

7. DC website sends an XDI message to DC’s RN cloud to store the signed receipt.

8. DC shows popup window with options (what to do with the receipt). The signed receipt is embedded in the popup window.

1. email to DS using email address in amazon profile

2. store in users personal cloud

3. capture in browser

4. download receipt as pdf

5. opt out of a receipt.  

9. DS clicks on “store receipt in my RN cloud”. (default option)

10. popup window asks DS, what is your cloud name?

11. DS types cloud name =alice

12. popup window runs XDI discovery to find DS’ RN cloud

13. popup window sends an XDI message to DS’ RN cloud to store the signed receipt

The usability of a MVCR can then be made scalable for use in aggregate beyond the point of consent for the data subject with a process in whch the receipt is digitally signed by both parties which identifies the jurisdiction of the Data Controller and of the Data Subject.    (the digital signing of the data subject is currently out of scope of the first draft1)

MVCR Mock Up for Amazon Respect Use Case

MVCR  Compliance Audit