Editors:
| Version | Status | Writer | Editor | reviewer |
|---|---|---|---|---|
v.01 | X | Mark Lizar - ; Summary of Intent | Mary Hodder | |
| v.02 | X | Mark Lizar & Mary Hodder Stakeholder Analysis | John Wunderlich | |
| v.03 | X | John & Mark: Summary of Compliance Contents | Mary Hodder | |
| v.04 | Current | Spec Outline: Mark Lizar PDS Walkthrough: Markus Sabadello Open Notice CR Demo: Mark Lizar | John Wunderlich | |
| v.05 | Next Edit |
StatusThis draft version is currently 95% outlined and 85% drafted
first draft in progress
Action Items
- Former user (Deleted) insert walkthrough demo links)
- John Wunderlich edit the outline for draft 5
- Mark Lizar (Unlicensed) Finish Compliance Scale description and compliance audit rules (needs a table)
- Mark Lizar (Unlicensed) needs a first read through edit after many changes
- Mark Lizar (Unlicensed) needs Open Notice Demo (in progress)
...
Related Documents:
- CISWG: Consent Requirements Map: (spreadsheet of laws/principles for receipt and data control R&D)
- Latest Consent Receipt Template
- Hackathon Video and Convergathon Hack Notes from July 12&13 2014 -->
- Scale of Compliance to measure the legal compliance of a consent receipt
...
Respect Network (RN) Technical Demo:
- Store a Consent Receipt in your RN personal cloud using XDI: http://amazon-respect-consent.herokuapp.com/
- List Consent Receipts in your RN personal cloud: http://open-notice.github.io/respect-network-receipts/
...
This is a specification to develop an open consent notice protocol. The specification combines legal, technical and social consent notice elements and records them in a transparent manner, which is called in this specification a consent receipt. The consent receipt demonstrates the technical aspects, the fields required for the Minimum Viable Consent Receipt (MVCR) represent the legal aspects, and the trusted services and the compliance scale represent the social aspects of this specifications. create a common format for provisioning consent receipts. The specification will provide Organisations the ability to create and provision a record of consent which is linked to the minimum notice requirements.
The MVCR is extensible, by; 1 notice compliance requirements, 2.Context, 3. Trusted Services
- Consent notice requirements can be appended to the MVCR to accommodate different personal data sensitivity, data sharing and additional contextual compliance requirements.
- A context field is a field in the MVCR as there are contextual conditions and exceptions to consent that can be listed and applied by an organisation to the context of receiving consent. In the MVCR the context is a flag with yes or no, if yes, this means the provider has explicitly stated that they implement the check list of contextual consent requirements. Additional contexts can also be added to a consent receipt.
- Organisations can append Trusted Services links/icons to the receipt and further extend the assurance to capture multiple consent notice types e.g. cookie, terms of use. For additional notice delivery context, and, for
This specification provides a simple audit and compliance scale for the consent receipt.
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:
...
to produce a the minimum compliant capable consent receipt that directly links all required policies (open notices) to the consent receipt.
- An Organisation 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
...
The Open Notice Initiative is an effort that calls for open consent (http://opennotice.org/callforcollaboration). This has resulted in the development of this specification for a Minimum Viable Consent Receipt(MVCR).
Glossary
Consent Receipt (CR) A Consent Receipt - denotes a single record of consent and consent context at point of consent provisionConsent Receipt (CR)
Trusted Services; A provider of Trust/Privacy Icons, Standard Assurance, Reputation Services, Trusted Network, Trusted Protocols,
Minimum Viable Consent Receipt(MVCR)
Minimum: (in Minimum Viable Consent Receipt) means to only include only the fundamental include links needed to gain transparency and make further usable the consent receipt for consent and identity management.to all the policies that inform the consent
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)
Data Subject(DS)
Data Controller(DC)
Operational Context of Consent
Minimum Viable Consent Requirements
The MVCR Consists consists of required fields that are used to links consent centric notices to a single record for compliance review. The MVCR consists of linked to the required-to-be open policy information for consent. The receipt is intended to provide a structure that can be extended to capture multiple consent notice types e.g. cookie, terms, privacy policy) at the time of consent enabling the data controller to provide a compliance by default receiptbe open consent policy at the point consent is provided and by so doing provide compliance by default. (as seen in Example1: Personal Cloud Storage of Receipt) A usability of a minimum viable consent receipt can then further be extended with additional notice and consent requirements specific to data subject jurisdiction, data type, location of consent and additional stakeholder contexts. (see extensionsStorage of Receipt)
MVCR enables organization to self-assert that they are compliant (or compliant by design)Technically - this means that if a DC that collects personal data provides the fields listed in the MVCR, and does not share personal information or collect sensitive personal information, then the receipts and policies are compliant by default. (see compliance scale and audit f.or MVCR)and to provide in an open and reviewable manner their policies. To achieve a complaint rating a DC provides an audit able self asserted MVCR and agree's/states that they will implement contextual notice requirements listed for the MVCR. For most online Data Controllers who do not share personal information with 3rd parties and do not collect sensitive personal information compliance will be automatic. If a DC does share personal information and/or collects personal information categories, trust services can automate higher complaince levels and provide a compliant by default status.
A MVCR with a complaint status will assure a basic level of general regulatory compliance with a much higher usability. It will do this by being digitally representedregulatory compliance in a more than compliant manner. The consent receipt should make sense at a glance, be digitally stored, digitally accessible, providing at the minimum a clear way to find the Data Controller contact, required address, and purpose(s) of consent as a standard formatto a consent. This format can then be audit for these data points at a glance, with one click access to all consent related policies by default. This can further be enhanced with organisation integrated trusted services (icons and links) to be added to the receipt. These trusted services, for instance privacy icons or Terms of Service, are then used to further extend the usability and increase the control of consent and trust it provides. click access to all consent related policies by default.
MVCR: Consent Notice Fields
...
| 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) |
| |
| Sensitive Personal Data Flag (Y/N) | Flag to categorise the information collected as sensitive or not (Y/N) | Each jurisdiction has classifications of sensitive personal information: The generally include health, financial, Child Protection, Religious, Union categorisations | If Yes, then additional notice requirements are needed to confirm its compliance status. If No, then the consent is automatically compliant | |
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. | If Yes, then additional notice requirements are needed to confirm its compliance status. If No, then the consent is automatically compliant | |
| 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 | Is the minmum Policy (or short notice) Needed to create a consent receipt. | |
| 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. |
...
Each jurisdiction has prescriptive text which need to accompany specific types of consent as well as legally written terminology for these requirements. With notices there are also contextual and prescriptive requirements in legislation, a .
This table will collect a check list of these elements is being crated in this draft below. (this list is a draft
| Context | Description | UK Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML | EU | USA | Canada | |
|---|---|---|---|---|---|---|
| Online Consent | To provide notice at point of consent the consequences of not provisioning consent | X | X | |||
| Online Consent | To indicate what is required and optional information to provide for consent | X | X | |||
| Physical Consent | Sign posted upon entry to physical space |
...
Extensions for the MVCR
Open Consent Notice Extensions
...
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.
...
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.