Consent Receipt Schema v.1

Status of Document

In progress 19-12-2013

Introduction: 

This is the minimum viable consent  schema (legals.txt) page for the Common Consent Receipt Scenario.  

(draft) A minimum viable consent receipt is comprised of data that is required for explicit consent online across all jurisdictions. This receipt is comprised of a legals.txt file and a stamp produces at the point of consent which creates a consent receipt.  The consent receipt is then delivered to the individual for later use. 

 The Legal.txt contains the fields which are legally required on for use of services (see table below).

  • Privacy Policy
  • Purpose
  • Consent
  • Contact
  • Address
  •  Online terms of service policy for use of services (if there is one)

(Note: `Depending on the jurisdiction, the type of personal data provided, the devices used and the context their may be addition notice requirements and limitations. For example a cookie policy).    

This schema is being developed to evaluate the consent receipt as a transparency and interoperability tool for personalisation and customisation.  A tool that works to extend existing policy frameworks with a common consent receipt.

This Schema is required to  Demonstrate Two basic things: 

  1. The minimum legally required information is published in a legals.txt, in common format, using best practices for the internet. 
  2. Provide consenting individuals with a usable record of a consent at the point of consent.  Exploring the receipts use to manage and standardise consent preferences during and post consent, 

Common Consent Schema

The consent receipt schema below is split into two parts

  • Part 1: Publishing Legals.txt
    • Common Consent Schema for legals.txt

    • Legal Reference Table for Receipt Fields

    • Legal Reference Table

  • Part 2: Generating Receipt
    • Consent Receipt
  • Human Language Common Consent Receipt
  • Annex
    • Proposed/Possible fields

Part 1

Minimum Viable (Common) LEGALS.TXT

Field #Field NamePublishing Format RI RFC 6903
1Privacy Policyprivacy-policy.html
2Terms of Servicetos.html
3Purposelinked to the terms and privacy policy
4Contact - Name ofData Controller, 
5Address of data controller 

 

Legal References For Legals.txt

(Note this document is updated from a google spreadsheet)

Jurisdiction - Consent RequirementsTitle of legislation and prinicplesLink to legislation and prinicplesPrivacy Policy Notice (Act, Limitations)Terms Of Service NoticePurposeContact - Person/office title - Data ControllerAddress of the Data & Data Controller
CanadaPIPEDAhttp://laws-lois.justice.gc.ca/eng/acts/P-8.6/FullText.html4.3.24.3.7 (d)4.2 Principle 2 — Identifying Purposes4.8.24.8.2 - (a)
USA
Fair Information Practice
http://www.ftc.gov/sites/default/files/documents/reports/privacy-online-fair-information-practices-electronic-marketplace-federal-trade-commission-report/privacy2000.pdfPrinciple 1 - Notice & AwarenessPrinciple 2 - Choice & ConsentPrinciple 1: identification of the uses to which the data will be put; Principle 1 - identification of the entity collecting the data;
UK1998 - Data Protection Acthttp://www.legislation.gov.uk/ukpga/1998/29/contents   deceptive acts or practices in or affecting 
EUDirective 95/46/EChttp://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:NOT  Article 10bcommerce.’’Article 10 a
ItalyData Protection Code - Legislative Decree no. 196/2003http://www.garanteprivacy.it/home_en/italian-legislation     
France       
EU- Proposed http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:52012PC0010:en:NOT     
NZNew Zealand Privacy Acthttp://www.legislation.govt.nz/act/public/1993/0028/latest/DLM296639.html     
JapanAct on the Protection of Personal Information Act No. 57 of (2003)http://www.cas.go.jp/jp/seisaku/hourei/data/APPI.pdf     
Sweden3HUVRQDO'DWD$FWhttp://www.government.se/content/1/c6/01/55/42/b451922d.pdf     

Based on the above information there may be more consent or notice specific requirements, but, at this time these are out of scope of the minimum viable consent receipt.  (note: We have started a list of possible fields below to consider adding to future schema's)  

 

Part 2 - Consent Receipt Fields 

This is a list of fields that is stamped on the receipt at the time of providing consent, in addition to the legals.txt data. 

This is the schema for what someone will receive as the consent receipt.  This is generated by combining the legals.txt with information from the website at the point the consent was provisioned. E.g. time/date, web address, ip address, and consent preferences. 

Data FieldFormat  
date & Time   
IP address of WebsiteIP Address  
Do Not Track HeaderY/N  
Digital ID or Email address of person providing consent   

 

Human language Expression 

-------------------------------

Open Notice Consent Receipt,  with ID http://example.com/notice243a34fad

- date/time stamp

written by http://www.example.com ,

which is based somewhere in somewhere in a Country

has 

  a privacy notice at http://www.example.com/privacy.html and 

  a terms of service at http://www.example.com/terms.html

Contact information: Email, Skype, Twitter, FB, Phone, Customer Service,

Address of Data Controller, Address of Data, Nationality of Company

Preferences : 

Authority:

**********

By providing this information this company openly publishes its policy and with the contact information provided is able to answer and deal with minimum obligations for consent across X jurisdictions

Depending on

  • the jurisdiction
  • the type of personal information provided
  • the context
  • the device
  • the preferences selected by the individual

 

x -  jurisidictions

 

-----------

 

Annex A: Proposed Fields: 

 

Proposed-Field #Field NameDescriptionStatusResultNotes
1Consent Tag ID/Or Token- User or Company or Both   
2Time/DateProvide time and date of the consentAddressedIs In the receipt 
3Org/Company Name/IDName of Company   
4JurisdictionLocation of CompanyNAcan be inferred from address 
6Name of Service(s)/Products consenting tooname of product  does this include third parties?
4Consenting Person identifieremail or other identifier used for consent   
5Privacy Policy URL    
6Terms of Service URL    
7cookie policy URL    
8     
9Type Of Consent(default Explicit)   
10Consent Expire    
11Consent Status   

 

 

12Sharing as Field -linking to a list of shared fieldsprivacy  
13Type of Personal informationList of personal attributes collected with sensitivity class (would need to make sensitivity class from legal definitions)privacy  
 Purpose, Number of Purpose,Required in EU law for reason and use of data specification provided at point of collecting consentprivacy  

 

 

 

Comments

CommentsDateInput  
 Nat 19/11/2013 

FYI, OpenID Connect has following client registration parameters: 

 

client_name - Human readable name of the client, e.g., web server

client_uri - uri of the client

policy_uri - privacy policy URI

tos_uri - terms of service URI

 

 

 

Then, each data request is linked with these via client_id which is returned as the response to the registration request. 

The data request is signed, and the user authorization would be signed by the server acting as the proxy to the user. 

That's the very basic scenario. 

In an advanced scenario, the data requests are going to be vetted by a third party (privacy trust framework operator) and signed or registered at the third party and given a reference URI. 

The signed request or the reference URI will be sent from the client to server as the data request then. 

This way, the server can find out if the request is deemed reasonable in the community or not. 

 
Iain1/10/2013generate a unique identifier for each individual consent,  
Iain1/10/2013creating a new field in the MVP that concatenates both giver and receiver identifiers  
Iain1/10/2013recommend a new field for company registration number'not applicable' option 
Lionel7/10/2013explicit consent therefore the value would be 'explicit', but this makes it subsequently extensible to include other values such as 'implicit', 'prior', 'inapplicable', etc  
 7/10/2013Consent Expiry: optionally the time and date when the consent no longer applies  
 7/10/2013(possibly) Duration Type: values could be 'immediate', 'session', 'service usage', 'indefinite'  
 7/10/2013Further consideration is required as to whether a Consent Expiry time/date could be used as an allowable value for Duration Type or whether both fields are necessary.  
 7/10/2013Consent Tag ID can optionally be allowed to be a token representing the User rather than a static unique identifier. For consent use cases such as sharing personal information between two Relying Parties, the use of a token rather than a static ID prevents the Consent Tag ID becoming the means for two organisations to link their respective user accounts and subsequently exchange personal data without the user's consent.In order to allow federated multi-party transactions, we have an IdP that issues pseudonymous identifiers that are unique to a "privacy domain" - i.e. more or less unique to each RP. Our current implementation of consent tokens has a separate opaque pseudonymous user identifier for consents that can be exchanged by a RP for the user identifier that it understands.