Editors:Editors:
v.01 Mark Lizar
v.02 Mary Hodder
...
v.04 Mark Lizar & Markus Sabadello
Related Documents:
• CISWG: Consent Requirements Map: (spreadsheet of laws/principles for receipt and data control R&D)
...
- Scale of Compliance to measure the legal compliance of a consent receipt
Overview
This is a specification to develop an open consent notice protocol for trusted services use. It has 3 sections: a technical, . The specification combines legal, social element technical and social consent elements and records them in a transparent manner.
Specification Design Notes
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:
- An An organization can use the MVCR to self assert that they are providing notice and getting implied consent in compliance with their policies and applicable regulations
- 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
...
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
...
| Field Name | Description | Purpose/Explanation | Reason Why This Field is Required | Cloud Receipt Capture & Sign: Format example in (XDI) Note: following lines all prepended with ([=]!:uuid:1111/[+]!:uuid:9999) |
|---|---|---|---|---|
| Data Subject | Name or pseudonym of the user at minimum, | Data Subject is primary party to consent | Is the consent contributor and primary party of the consent, (which is why this is the first field of the MVCR) if not signed by Data Subject then its use post consent may be limited. | Data Subject: Alice [=]!:uuid:1111 |
| Address (and jurisdiction) of Data Controller | Name of the entity issuing the receipt | Should be the entity/organization that is in control of the personal data and is responsible for consent compliance. | Is the Data Controller and is the primary party responsible for administration of the consent | Data Controller: Amazon [+]!:uuid:9999 |
| Purpose | The purposes for which the personal information is being collected. | this is a single purpose at minimum linked to the short purpose notice, or policy of purpose. | A purpose notice is a basic and common legal requirement and functionally a requirement of consent. | [#receipt]!:uuid:1234[<#purpose>]<@0>&/&/"We need to process your payment." [#receipt]!:uuid:1234[<#purpose>]<@1>&/&/"We need your data to prevent fraud." [#receipt]!:uuid:1234[<#purpose>]<@2>&/&/"We will advertise to you." |
| Location of Consent | The location of the consent provision. from which the consent receipt originates.(For example the web page with the consent button. ) | This indicates the 'point of consent' - hopefully a button where the user clicked "I agree" or "I consent" (i.e. the biggest lie) Can be a URI, URL, URN, This can also be a physical space where surveillance legal notice requirements exist (EU) - Global Positioning System (GPS) |
| |
| 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. | ||
Third Party Sharing | Flag whether data is shared with third parties. (Y/N) | If true, then compliance is dependent upon additional notice requirements not present in a MVCR. This can be addressed with the "Third Party Sharing" extension. | For example: Third Party Sharing (N) - Unless purpose is explicitly stated on the receipt. (in demo purpose is shared | |
| Timestamp | When consent was obtained | To record when the user, either by implication or explicity, granted consent for the purposes described. | ||
| Privacy Policy | The issuing entity's privacy policy (either inline copy, or reference to URI) | If not available, should provide a notice that it is missing | ||
| Cookie Policy | The issuing entity's cookie policy (either inline copy, or reference to URI) | If not available, should provide a notice that it is missing | ||
| Terms of Service | The issuing entity's terms of service (either inline copy, or reference to URI) | If not available, should provide a notice that it is missing | ||
| 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 | ||
| Sensitive | Flag to categorise the information collected as sensitive or not (Y/N) | Medical, financial information for example | ||
| Jurisdiction | The jurisdictions of the data protection authority for the data controller and data subject | this is taken from the data controller address and the location of the consent. | ||
| Context | Flag wether the Operational Requirements are present or not. (Y/N/Unknown) | For the presentation of consent there are contextual and prescriptive requirements in legislation, a check list of these elements is being crated in this draft below. (this list is living draft ) | Consent has contextual compliance requirements for the notice to be sufficent. These depend on the location of the consent and data subject. An organisation can agree to add address this list when implementing the consent receipt. |
...
Note: also requires specific text to accompany a notice at the point of consent, which may vary depending upon legal jurisdiction and context.
Extending the MVCR
These These is the extensions table. 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
| Field Name | Description | Instructions | Legal Requirement (this item must be listed on LR table) | Context (this item must be listed in the Operational Requirements table) | (usability/Interoperability Benefit) | XDI Example |
|---|---|---|---|---|---|---|
| Jurisdiction | The jurisdictions of the parties: the data protection authority is mandatory. |
| Usability: enables receipt to be used as evidence or for the purpose of legal data controls out of context of the consent event. | |||
| 3rd Party | ||||||
| Sensitive Data | ||||||
| Trusted Services Extension | ability to add trusted services to the minimum viable consent receipt | |||||
| Consent Receipt Request Extension | This is a button a user can press to request a consent receipt from a business |
|
| This is for all contexts of the MVCR | Usability |
...
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 has required notice and personal information management processes for that consent to be legally compliant. These can be layered on to of the MVCR to meet requirements from multiple jurisdictions and industries and context.
There are multiple categories These extensions also enable policy makers to localise the use of consent notices by jurisdiction.
Categories of extensions:
Core Extensions: update the MVCR and can be used across jurisdiction or globally to increase the compliance and utility of CR
Sectoral Extensions: Jurisdictional or industry specific that are layered onto the consent receipt for specific data types
Personal Extensions: To signal (advertise) consent preference or data stores by an individual agent, for instance capturing the DNT preference in a browser session
Organisational Extensions: To signal (advertise) consent options and contextual data uses
Compliance: The need for an extension for compliance
Trusted Services; Frameworks, Networks, Service Extensions : These would be in the form ofExtensions
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.
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
...
- Consent Policy Format
...
...
Consent Extension Location
...
Tracker: Analytics etc:
...
Terms of Use Policy
...
Reputation
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
- Categories of personal data shared & (or)
- Name of third party shared with
- Purpose of sharing
- Link to third party CR & Policies
Type of Trust Framework - Consent Policy Format
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 TOSBack Reputation
Trust Framework (all trust services provide reputation) Privacy Icons
Pictorial Short Notices Disconnect Me Data Control Protocol
User Managed Access Trusted Network Service
Respect Network Standards
Certificates
TrustE Levels of Assurance KI: Identity Assurance Framework
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:
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.
...
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.
...
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
Legal: Compliance Audit & Scale
MVCR Compliance Audit
Each field on the MVCR contains legal notice requirements, each of these components are listed in and the presence of these are counted and a flag is added to record if any of these self asserted claims have been disputed and not resolved.
The MVCR has a maximum rating of compliant. Additional Ratings are possible with extensions.
Notice Compliance Checklist | Non Compliant | Partially Compliant | Compliant | Above Compliant | Trusted | User Managed |
|---|---|---|---|---|---|---|
Contact of DC |
|
| X |
| ||
Address of DC |
| X |
|
| ||
Purpose(s) |
| X |
|
| ||
Sensitive Data (If NO) |
|
| X |
| ||
Share with 3rd Party (If No) |
|
| X |
| ||
| Any of the above self asserted is Disputed or un verifiable (Y/N Flag) (If No) ( if Yes and unresolved = Non-Compliant) | X |
MVCR Compliance Scale
The compliance scale is the social aspect of the MVCR Specification. The scale provides a simple icon for a universal measure of MVCR compliance.
Summary of Benefits to MVCR
- Transparency: The MVCR receipt is a common format for the legally required policies which provide notice. links to all notices and demonstrate a much higher level of minimum viable notice (for consent) legal compliance. This standard is intended to augment the existing legal notice and consent infrastructures that is already in place and reward greater transparency of consent. .
- Extensible: The MVCR Spec is intended to be easily extensible and auditable, with a jurisdicitional legal compliance audit built in for making transparent legal context and controls of a consent transaction. Meaning that consent legal notice requirements are different by jurisdictions, industry, for various sensitive data types, for sharing to 3rd parties, tracking (cookie consents), in additional to personal and contextual consent preferences of the individual. Extensions are notice requirements layered onto this MVCR format to meet and match legal requirements and trust frameworks to address cross jurisdictional management of consent.
- Trusted Services Vehicle: A receipt passed to the service user at time of consent provides a legal trust framework to build upon. As a result it is the MVCR is intended as a vehicle for delivering trusted services to the individual. A stakeholder can utilise trust services, which are then linked to the receipt, which further extend the compliance and "fast track" usability of consent and identity management by using a spec compliant receipt. Eg.privacy icons, TOS reputation, certifications, trusted networks, and protocols
- MVC is intended to be an all purpose consent process enhancement.
- This MVCR specification is intended to be used so any organisation can implement the spec and provide a MVCR.