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:
- The minimum legally required information is published in a legals.txt, in common format, using best practices for the internet.
- 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
- Proposed/Possible fields
Part 1
Minimum Viable (Common) LEGALS.TXT
Field # | Field Name | Publishing Format RI RFC 6903 |
---|---|---|
1 | Privacy Policy | privacy-policy.html |
2 | Terms of Service | tos.html |
3 | Purpose | linked to the terms and privacy policy |
4 | Contact - Name ofData Controller, | |
5 | Address of data controller |
Legal References For Legals.txt
(Note this document is updated from a google spreadsheet)
Jurisdiction - Consent Requirements | Title of legislation and prinicples | Link to legislation and prinicples | Privacy Policy Notice (Act, Limitations) | Terms Of Service Notice | Purpose | Contact - Person/office title - Data Controller | Address of the Data & Data Controller |
---|---|---|---|---|---|---|---|
Canada | PIPEDA | http://laws-lois.justice.gc.ca/eng/acts/P-8.6/FullText.html | 4.3.2 | 4.3.7 (d) | 4.2 Principle 2 — Identifying Purposes | 4.8.2 | 4.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.pdf | Principle 1 - Notice & Awareness | Principle 2 - Choice & Consent | Principle 1: identification of the uses to which the data will be put; | Principle 1 - identification of the entity collecting the data; | |
UK | 1998 - Data Protection Act | http://www.legislation.gov.uk/ukpga/1998/29/contents | deceptive acts or practices in or affecting | ||||
EU | Directive 95/46/EC | http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:NOT | Article 10b | commerce.’’ | Article 10 a | ||
Italy | Data Protection Code - Legislative Decree no. 196/2003 | http://www.garanteprivacy.it/home_en/italian-legislation | |||||
France | |||||||
EU- Proposed | http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:52012PC0010:en:NOT | ||||||
NZ | New Zealand Privacy Act | http://www.legislation.govt.nz/act/public/1993/0028/latest/DLM296639.html | |||||
Japan | Act on the Protection of Personal Information Act No. 57 of (2003) | http://www.cas.go.jp/jp/seisaku/hourei/data/APPI.pdf | |||||
Sweden | 3HUVRQDO'DWD$FW | http://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 Field | Format | ||
---|---|---|---|
date & Time | |||
IP address of Website | IP Address | ||
Do Not Track Header | Y/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 Name | Description | Status | Result | Notes |
---|---|---|---|---|---|
1 | Consent Tag ID/Or Token | - User or Company or Both | |||
2 | Time/Date | Provide time and date of the consent | Addressed | Is In the receipt | |
3 | Org/Company Name/ID | Name of Company | |||
4 | Jurisdiction | Location of Company | NA | can be inferred from address | |
6 | Name of Service(s)/Products consenting too | name of product | does this include third parties? | ||
4 | Consenting Person identifier | email or other identifier used for consent | |||
5 | Privacy Policy URL | ||||
6 | Terms of Service URL | ||||
7 | cookie policy URL | ||||
8 | |||||
9 | Type Of Consent | (default Explicit) | |||
10 | Consent Expire | ||||
11 | Consent Status |
| |||
12 | Sharing as Field - | linking to a list of shared fields | privacy | ||
13 | Type of Personal information | List 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 consent | privacy |
Comments
Comments | Date | Input | ||
---|---|---|---|---|
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. | |
Iain | 1/10/2013 | generate a unique identifier for each individual consent, | ||
Iain | 1/10/2013 | creating a new field in the MVP that concatenates both giver and receiver identifiers | ||
Iain | 1/10/2013 | recommend a new field for company registration number | 'not applicable' option | |
Lionel | 7/10/2013 | explicit 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/2013 | Consent 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/2013 | Further 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/2013 | Consent 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. |