...
MVCR: Core Consent Receipt Profile
...
(Note this is for inclusion in v0.7)
| Field Name | Data Type | Description | Example Input | |
|---|---|---|---|---|
| Section 1: Header | This is the |
...
(Note: This is essentially the background and strawman document which will require a lot of further definition and consensus. )
Consent Receipt Intro
The consent receipt is a meta format that links policy, purpose, contact and short notice information to a common format so that privacy and associated consent policies can be systematically usable.
Across every jurisdiction there is required a legal notice for consent to be possible. This is the common apex of legal, technical and social obligations salient across jurisdictions. It is this point of obligation that open consent is built upon as a common point of interoperability and scalability..
The aim of the consent receipt specification is to iteratively develop an international framework for consent and legal notice. Open Consent aims to include all the requirements in order to ensure that irrespective of where a data subject is (which cannot be verified at the technological level due to the use of proxy and vpn servers) they are afforded (or have access to) all of their jurisdictional and human rights. This has a further effect of setting the bar to the strongest regulatory levels to enable data control around the individual not the organisation.
Engineered to have a positive impact on global data collection and processing practices, creating equally high protection for all data subjects, irrespective of the geographical location.
With this requirement it is not possible to provide consent if there is no notice and a consent is not usable if it does not have an identity that can be referred to.
(enter consent centered diagram, with Notice, Identity, and consent )
Core Receipt Profile Overview
The common legal obligations to consent are that the purpose for the consent needs to be listed in a notice and that notice has to be in common language which is easily understood by data subjects. This needs to be accompanied by contact information and the name of the data controller.
From a high level these are very ambiguous and when we get into the detail these obligations vary in terms of technical detail from jurisdiction to jurisdiction and vary by consent context.
This is one of the key reasons why consent and its management has been so difficult to evolve. (Beyond the politics, the performative requirements of digital interaction, and political interests of dominant economic stakeholders. )
To address this, the core consent receipt profile, is designed to be a high level meta format which is used to link all the required legal and usability components relevant to a receipt.
The architecture of the receipt is a intended to be broad on the surface and then to drill down into detail according to context, regulation, and technical architecture.
Core Design Scope
- a tool/artifact for people, so they can manage consent independently of organisations
- an independent tool to enable personal data control:
o bootstrap personal data empowerment. A receipt as a tool used independently to access, manage and control data.
o To negotiate and submit terms, around the use of personal data.
to block the use of personal data
to prohibit profiling
to withdraw consent
- Enable a data control around the individual not the organization (A.K.A. - Not User Centric)
o enable fair value exchange
o Used to manage access to personal data, enabling authentication and authorisation gateways for identity and the personal data profiles attached to them
To bind legal obligations to identity protocols
as a switch to negotiate personally controlled profiles
- Trust: transparency over policy and organisations
o trust by seeing if practice and policy meets the transparency in use and practice. AKA (surveillance trust framework)
How is minimum viable defined in the context of the core consent receipt profile?
1. Minimum Viable means, what is minimally required (and achievable in a meta format) by law for a consent legal notice across all jurisdictions
2. Minimum Viable also means a bench mark of usability: at time of writing this means
a. a benchmark of readable at a glance,
b. and systemically usable, which means that a receipt can be aggregated post consent with all consent so that all of the consents can be viewed at a glance . i.e. in a pie chart.
The Detail
Each field in the core receipt profile has a specific purpose to meet either a legal requirement, or a usability requirement. Ideally these will continually be innovated and each requirement will address both.
This document is intended to layout these fields so they can be refined. In the logic field, there is intended to illustrate how the field can be used, with other fields in the specification, to harvest and generated data that can either be aggregated to the receipt payload or be developed with a third party service provider, with the use of the MVCR.
The consent receipt fields are supplemented by tables of definitions and references..
All of these tables and definitions need documentation to explain them and how they are used.
So far, these include: (need to be developed)
- Data Controller contact information, (which IMO needs contextual relevance and proportionality as well)
- The categories of sensitive personal information (SPII)
- what are the purpose specification short descriptions
- what is a short privacy notice field
o need examples and legal references.
- What are operational contexts
o Website based context
o Device Specific Context
§ For mobile /tablet (NTIA)
§ For desktop
§ For watch
o For Physical Space
§ Video surveillance
§ Mobile surveillance
§ IOT
# | Fields | Description | Logic | JWT Claim | |||
1 | Identification: of natural person using any pseudonymous identifiers | Subject Claim, defined/namespaced by the issuer - | This is the identity provided by the data subject to identify the person to the consent and create a profile. | sub / String | 2 ? | Service Title | this is global context for consent: e.g. amazon, amazon express | Identify the scope of purpose and its use. |
3 | Short Notice Field | purpose of the short notice is to provide enhanced transparency about data collection and information sharing practices | This is a short summary that supports the service title and makes transparent the use. | “notice” / String | |||
4 | Date Time Stamp | date and time at the point consent is provided | moment explicit consent is provided the consent transaction is date and time stamped | iat / timestamp | |||
5 | Privacy Policy Link | the internet and immediately accessible privacy policy of the service referred to by the receipt (mydomain.com/privacy) | - if link is not valid receipt is not valid - domain provides an admin registration contact that provides company jurisdiction - IP Address provides GEOlocation - | “policy_uri” / URI (String) | |||
6 | Identity of Data Controller | The identity and company of the data controller and any party nominated to be data controller on behalf of org | “data_controller” / ojbect | ||||
7 | Contact information of Data Controller | Address of Data Controller + at least one other method of contact | ^-- subsumed in the above | ||||
8? | All data collected from the consent session- and/or copy of data collected about the subject of the receiptfirst section of the receipt | ||||||
| svc | array of strings. | this is service and describes in a human understandable fashion global context for consent | ["Company Name" , "Service Name"] | ||||
| jurisdiction | string. ISO two-letter country code if applicable, otherwise free text | this is the jurisidction under which the processing of personal data occurs | US | ||||
| iat | number. Integer number of seconds since 1970-01-01 00:00:00 GMT | Timestamp of when the consent was issued | 1435367226 | ||||
| iss | string. HTTPS URL | this is the URI or Internet location of processing | http://www.consentreceipt.org/ | ||||
| jti | string. | Unique identifier for this consent receipt | 9ef6b81a414b2432ec6e3d384c5a36cea8aa0c30d3dd2b67364126ed80856f9c20654f032eef87ad981187da8c23c1186eefe1503714835c2e952bbb3f22729c | ||||
| sub | string. | Subject provided identifier, usually email addressClaim, defined/namespaced by the issuer | example@example.com | ||||
| Section 2: Data Controller | This section has the data controller, contact and privacy service information | ||||||
| data_controller | object | The identity and company of the data controller and any party nominated to be data controller on behalf of org The object contains information of the data controller in the following fields: Field Name Data Type Description Example Input Required on_behalf boolean. acting on behalf of an organization? true contact string. person to contact Jon Doe company string. company name Data Controller Inc. address string. physical address 123 Main St., Anywhere email string. Email address contact email address jon@datacontroller.com phone string. Phone number contact phone number 00-000-000-0000 | {"on_behalf": true, "contact": "Dave Controller", "company": "Data Controller Inc.", "address": "123 St., Place", "email": "dave@datacontroller.com", "phone": "00-123-341-2351"} | ||||
| policy_uri | string. HTTP URL | the internet and immediately accessible privacy policy of the service referred to by the receipt | http://example.com/privacy | ||||
| Section 3: Purpose Specification | |||||||
| purpose specification | array of strings. | Explicit, Specific and Legitimate: interpreted here as: 'Naming the Service' and 'Stating the Action' and putting it in a receipt, meets these requiremetns, | ? [" CISWG Membership", "Join"] | ||||
| Section 4: Personal Information | |||||||
| pi_collected | object. Keys are the name of the field, value is the information collected. | Personal information collected in relation to, or adjacent of purposes specified | {"name" : "Example Example", "email" : "example@example.com"} | ||||
| sensitive_pi | array of strings. | In many jurisdictions their are additional notice and administrative requirements for the collection, storage and processing of what are called Sensitive Personal Information Categories. These are Sensitive in the business, legal, and technical sense, but not specifically in the personal context. This list of categories are required in some jurisdiction, but, the actual notice and purpose requirements are out the scope of the MVCR. | {"health"} | ||||
| Section 5: Information Sharing | Sharing information with 3rd parties, what categories, with whom, and how informtion is shared | ||||||
| sharing | array of strings. | This refers to the sharing of personal information collected about the individual, with another external party by the data controller (service provider). Should list categories of PII shared, from above list and under what purpose. Sharing is also a container for listing trust marks and trust protocols. | [?] | ||||
| In Review | |||||||
| aud | string. HTTP URL | Audience URI that identifies the target service of this consent | http://engageidentity.com/protected | ||||
| consent_payload | object. Keys are the name of the consent, values are whether or not the user has agreed. | Examples include: Device Identifier, UID, IP Address, Browser Fingerprint, | Email Address, and so onDNT signal client header, .Mobile device id | 9 | Purpose (s) Specification - short purpose description, | - | |
10 | Sensitive Information | What is determined to be personal information can be from a big list of all defined personal information categories from all jurisdictions. ( this indicates that it is possible depending on where parties are that this is sensitive) | if no, then no information is needed, if yes, then more information or assurances are required to show compliance with legal obligations, these can be provided in a number of ways, i.e. third trust marks, protocols, standards, assurances and so on. | “sensitive” / array[strings] -> strings are pointers (URIs?) to details of sensitive information | |||
11 | 3rd party sharing of personal information | This refers to the personal information collected about the individual, | 12 | OC of data collection | {"privacy policy" : "agree","ToS" : "agree"} | ||
| context | array of strings. | Operational Context refers to the conditions that ensure the consent is fair, reasonable and proportional. , e.g. if it is on a website, then there are requirements like; are mandatory fields indicated, is there a separate consent for privacy policy and terms of service? | set of registry values? | This is a self asserted Yes or No that is not mandatory but would be required to demonstrate compliance with legal obligations that are found in various contexts. This provides the contextual framework for context elements in a number of different environments||||
14 | Issuer | URL of the party that generated and signed this consent receipt | self created, third party and service provided created | iss / string [URL] | |||
15 | Receipt Identifier | jti / string |
JWT Claims Model:
{
“iss”: “https://authz.example.com/”
“svc”: [“https://amazon.com/”]
“sub”: “smartopian”
“notice”: “We understand that buying our product is confidential. We are committed to protecting your data and privacy”
“iat”: 23456789876543
“policy_uri”: “https://amazon.com/weownyou”
“data_controller”: {
“email”: “bezos@amazon.com”,
“jurisdiction”: “US”
“domain”: “amazon.com”
}
“purpose”: [“process_your_order”, “deliver_the_goods”, “take_your_money”]
“sensitive”: [“https://amazon.com/receipts/credit_card_info”, “https://amazon.com/receipts/mailing_address”]
“sharing”: [“https://amazon.com/receipts/delivery_company”]
“context”: [“fair_process”, “display_notice”, “stuff”]
“jti”: “56789-oijhgf-3245367kj”
“user_data”: {
“do_not_track”: true
“client_ip_address”: “192.168.128.0”
}
}
alt sharing/sensitive:
{
“sharing”: {
“mothers_maiden_name”: [“https://amazon.com/receipts/internal”]
“address”: [“https://amazon.com/receipts/delivery_company”]
“credit_card”: [“https://amazon.com/receipts/credit_reports”]
}
}
Scenarios
simple Consent Receipt
Jurisdiction scenario
Health Care
...
| ["active privacy policy consent", "passive terms of service consent"] | ||||
| notice | string. HTTP URL | Link to the short notice enables usability and layered policy. to provide enhanced transparency about data collection and information sharing practices | http://example.com/notice | |
| scopes | string. space separated string values | What you’re allowed to do on the service (these can be tied to legal / business / technical layers) | read update |