Abstract

This document is a product of the ISWG Work Group. It records the scenarios and use cases governing the development of consent receipt and guiding associated implementations and deployments.

A Scenario specifying a receipt data schema

Status

This document is currently under active development. Its latest version can always be found here. See the Change History at the end of this document for its revision number.

Editors

Mark Lizar

Intellectual Property Notice

The ISWG Work Group operates under Option ABC and the publication of this document is governed by the policies outlined in this option.

Table of Contents

Introduction and Instructions

This document is a product of the ISWG Work Group. It records the scenarios and use cases governing the development of the Consent Receipt Schema (CRS) and guiding associated implementations and deployments.

Please use the scenario template near the end of this document in adding new scenarios and subordinate use cases. Change the status keyword in each scenario and use case title as appropriate, linking to the meeting minutes page explaining the status change:

• Pending: Initial status when first submitted
• Accepted: Needs to be accounted for in Consent Receipt Schema V1 and/or its associated compliant implementations
• Deferred: Relevant to the problem space; may be considered in future versions
• Rejected: Out of scope

Edit the descriptions of technical issues and scope questions to reflect (or point to) group decisions about how to handle them.

Scenario: Minimum Viable Consent Receipt (In Progress)

Submitted by: Mark Lizar

The goal of this scenario is to create a specification for a receipt schema and a demonstrator; creating, providing and using a minimum viable consent receipt. 

Initial Audience

1. Open Notice & Kantara Community
2. The Usable Privacy Project
3. Mozilla
4. Internet Society

Background

Economic Performance of Consent:

A commercial receipt you received at point of purchase has many uses, it can be submitted to a third party, either to show a budget and costs, or to report on what was purchased and for how much.  It is a great tool for reducing friction, saves time, money.  Like a commercial receipt, consents can also be submitted to a third party, it can be compared, counted, and like purchasing preferences, consent preferences can also be collected.   In this way a receipt and preferences can be used with third parties like a token to access other services.

Experience of Consent

Hypothesis: Better managed consent preferences and policy will result in better user experience, transparency, privacy and security. 

Governance of Consent:

A receipt can also be used as a tool for governance, for instance, the Tax authorities can use a commercial receipt to check and see if the sales are hidden, the purchaser can use a receipt to be sure of the cost of goods and compare the change provided against the price advertised or currency provided to make sure of compliance.  

Objective

 Specify the existing fields for a consent transaction receipt and list them as a basic template for consent receipts. (Note: This entails formally defined attributes, published and open for comment.)

Develop scenario covering the life cycle (Pre-consent, Consent, Post-Consent) of a minimum viable consent receipt for building a demonstrator.  This would involve

1. Part 1: Pre-Consent - Create a consent receipt generator, embed code and publish legal.txt  --> Involves Common Terms and Legal.TXT
2. Part 2: Create a consent receipt button and provision a consent to a service user
3. Part 3: Service user, uses the receipt post consent  to improve user experience and compare policies.

The demonstrator includes 3 parts (or a stages of the lifecyle), 1. Pre-Consent, 2. Consent 3. Post-Consent

1. Pre-Consent
   1. a website form for a company to generate a legal.txt file
   2. Publishing legal.txt
   3. An embed code is created for company to put behind their consent buttons on the website
2. Consent
   1. A service user selects the consent '+ receipt' option to collect a receipt
      1. The id used by the service user to provision consent is used to send the receipt. 
         1. With no pre arranged application, a modal box will appear  asking for selection of identifier to use with the receipt
            1. this could be social login, email, etc
         2. the receipt is then accepted and stored by the digital identity being used for the consent
3. Post - Consent
   1. TOSSOS - Receipts are used to compare policy changes using TOSSOS
   2. TOS;Dr - Receipts are used to look up TOS;Dr rating
   3. Out of Scope
      1. Browser Plugin - Receipts are captured and used automatically  to make policy responsive and to customise experience, reduces steps in stage 2. streamlining user experience. 
         1. Would require a receipt viewing capability, preferably on aggregate and current view as well. (by identity would be useful too)

Use Case: Demonstrator Scenario 1, Part 1: Pre-Consent (In Progress)

Submitted by: Mark Lizar

The primary focus is to create the first legal.txt (which I think at the time of this writing is already done) and develop a process for an organisation to distribute a consent receipt. 

Scope of Work for Stage 1

• Focus first on creating a minimum viable consent receipt schema and using this as the schema for the legal.txt file
• Create webpage with Minimum Viable Consent Form  

1. Create Legal.txt
2. Publish Legal.TXT
3. Generate Embed Code for Consent to be used by other organisations

• Optional
  • Create a Common Terms option to layer policies for different consent context. e.g. mobile phone, physical location, online service 
  • Option would be on first page for use in creating legal.txt file and would demonstrate the ability to create certified data sets
    • link existing policies to layered notice

   Wireframe illustration

Scenario 1 Part 1 - Site Map

• Scenario 1 Part 1 A - Create Legal.txt

• 

  - Scenario 1 Part 1: B - Publish Legal.TX

• Optional - look into publishing with multiple methods

• Scenario 1 Part 1: C --> Create Embed Code for Consent to be used by other organisations

The Embed Code is the consent receipt schema.  At the point of consent a snap shot of the consent is captured and sent to the consent provisioner. 

• Notes: 
  • Exploring a Common Terms approach and layering policies for different consent context. e.g. mobile phone, physical location, online service 
    • use existing standards and best practices
  • Option would be on first page for use in creating legal.txt file and would demonstrate the ability to create context specific consent receipts. 
    • link existing policies to layered notice
• Discussion Needed:
  • Publishing, 
    • where should legal.txt be published? (multiple places?)
    • What ID should be used,how will people receive/store and use their receipts? 

Use Case: Demonstrator Scenario 1, Part 2: Consent (Pending)

When a consent is provisioned using the consent option/button 

- a receipt is generated  at the point of consent, the identity used to provision the consent is used to deliver the consent receipt

1. Consent
   1. The org, who has generated a LEGALS.TXT and embed code, cuts and pastes the code, which links to the LEGALS.TXT, file and adds it to the code in the current consent option that exists on the website. 
      1. We can generate three different types of buttons. (I agree button, Check box opt-in, I have read and understand terms and service - but with the receipt option) 
   2. A service user selects the consent '+ receipt' option to collect a receipt
      1. The id used by the service user to provision consent is used to send the receipt. 
         1. With no pre arranged application, a modal box will appear  asking for selection of identifier to use with the receipt
            1. this could be social login, email, etc
         2. the receipt is then accepted and stored by the digital identity of choice
   3. Including Data in the Receipt for the recipient
      1. This should include all reasonable elements that can be captured at that point and provided in a receipt format. 
         • DNT Header, URI links for privacy or terms, IP Addresses,  (full list is pending).  As well as a counter. 

Scenario 1: Part 2

Scenario 1: Part 2: A

Scenario 1: Part 2 : B -Digital Identity

Scenario 1 Part 2: C

Scenario 1 Part 2:: D - Consent Receipt View

Scenario 1 Part 2:  Consent Summary (on Aggregate) View : (Note this is currently out of scope of this Scenario)

Use Case: Demonstrator Scenario 1, Part 3: Post-Consent (Pending)

1. Post - Consent
   1. TOSSOS - Receipts are used to compare policy changes using TOSSOS
   2. TOS;Dr - Receipts are used to look up TOS;Dr rating
   3. Out of Scope
      1. Browser Plugin - Receipts are captured and used automatically  to make policy responsive and to customise experience, reduces steps in stage 2. streamlining user experience. 
         1. Would require a receipt viewing capability, preferably on aggregate and current view as well. (by identity would be useful too)

Scenario 1; Part 3 Wire Frames - (in Progress Through Stage 1 & 2)

Issue: unique-title

(Provide technical commentary on the issues brought up by this use case.)

Change History