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 Respect Network Save Receipt to Cloud: Technical Walkthrough: Markus Sabadello Open Notice Website CR Demo: Mark Lizar | John Wunderlich Mary Hodder | |
v.05 | Next Edit |
...
Table of Contents outline true indent 10px
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/
...
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 produce a the minimum compliant capable consent receipt that directly links all required policies (open notices) to the consent receipt.
...
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. | |
Operational Context Flag | 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. | Consent has contextual compliance requirements for the notice to be sufficent. These depend on the location and format of the consent notices An organisation displays agreement (or not) to implement these OC requirements and this is reflected on the consent receipt. |
MVCR Format Notice
...
Requirements (in progress)
Full reference table can be found here:
...
Notice Requirements Receipt Meets | Description | UK UK DPA 1998 | EU 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 | USA For Sharing Personal Sensitive Information with 3rd Parties | Canada | APEC | P3P | FTC FIPPS | OECD FIPPS |
---|---|---|---|---|---|---|---|---|---|
Contact of Data Controller (DC) | Legally required to provide contact details of the DC | X | X | ||||||
Address of Data Controller (DC) | Legally required to provide contact details of the DC | X | X | ||||||
Purpose(s) | Legally required to provide purpose for data control | X | X | ||||||
Third Party Legal Requirements Transparency | This is a flag to see if additional notice extensions are requirements to assess compliance | X | X | ||||||
Sensitive Personal Information Collection Transparency | This is a flag to see if additional notice extensions are requirements to assess compliance | X | X |
...
List of current or planned extensions
Priority | Extension Type | Field Name | Description | Instructions | Legal Requirement Jurisdiction (this item must be listed on LR table) | Context (this item must be listed in the Operational Requirements table) | (usability/Interoperability Benefit) | XDI Example |
---|---|---|---|---|---|---|---|---|
1 | Core Extension | Jurisdiction | The jurisdictions of the parties: the data protection authority is mandatory. |
| All | Usability: enables receipt to be used as evidence or for the purpose of legal data controls out of context of the consent event. | ||
2 | Core Extension | Collect Sensitive Personal Data |
| |||||
3 | Core Extension | 3rd Party Trusted Services Extension (this is the functionality for Registry) | ability to add trusted services to the minimum viable consent receipt | This incorporates 3rd party sharing and purpose listing format | ||||
4 | Usability Extension | 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 | |
5 | Operational Context Extension | Policy Extension for Consent Cookie Policy Link | The issuing entity's cookie policy Link (either inline copy, or reference to URI) | If not available, should provide a notice that it is missing or self assert an icon | Legally in the EU a cookie requires explicit assent |
| ||
6 | OperationalContext Extension | Policy Extension for Terms of Service Link | 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 | Legally Terms need to be open and accessible in order to be fair and reasonable. |
| ||
7 | keep copy of all notices with receipt | Store all notice data option as a part of signed receipt |
Trusted Services Appendix
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. It is for seen that a notice registry is the natural place for trust services to register their services.
A process for auditing and verifying all trust services needs to be in place for trust services to be trusted. Then when an organisation enrols into the registry they can also add (or manage) trust services that has been added to the receipt.
This is a table to map the list and categories of assurance framework with examples and notes on interoperability with this category of service.
Type of Trust Framework
Consent Policy Format
Personal 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
Has terms materially changed ( is consent still compliant? )
TOSBack
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.
Reputation
Trust Framework
(all trust services provide reputation)
Privacy Icons
Pictorial Short Notices
Disconnect Me
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
Data Control Protocol
User Managed Access
Trusted Network Service
Respect Network
Standards
Certificates
TrustE
Levels of Assurance
KI: Identity Assurance Framework
Examples:
This is a specification by example, all examples need to be listed and demoed in this section.
MVCR Consent Receipt Template
The MVCR has a base template v.1 that we have using to wireframe consent receipts: V.1
Latest Template Version
(******Template HERE***)
We have a template that we are using for the technical design of the consent receipt, the GUI design is also out of scope. What is provided by default is a Consent Receipt Template that we are using for technical design.
Example 1: Open Notice Consent Receipt
(Example (in progress) can be found at http://on.smartspecies.com/support-open-notice/
Example 2: Storing Receipt in Personal Data Store: Technical Walkthrough Example with Respect Network
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.
To make the consent receipt usability scalable it needs to be signed and put in a personal data store.
This specification and demo is created to demonstrate a MVCR being implemented without the need for an Open Notice Registry with the Respect Network (Trusted Network) Trust Framework which natively has the ability to provision receipts to the highest level of compliance . This walk through demo is intended to demonstrate how a consent receipt can be stored in a personal cloud from this spec document and demonstrate 'Fast Track' usability.
DS goes to amazonrespect.com website
Website presents form and asks for consent:
either to sign up initially
or for additional consent and profile management when already logged in
DS agrees (clicks on “i agree” button)
DC website initiates creating the receipt for the consent that was just given.
DC checks for reciept data collection and notice extensions and finishes creating the receipt
The receipt is signed by DC.
DC website sends an XDI message to DC’s RN cloud to store the signed receipt.
DC shows popup window with options (what to do with the receipt). The signed receipt is embedded in the popup window.
email to DS using email address in amazon profile
store in users personal cloud
capture in browser
download receipt as pdf
opt out of a receipt.
DS clicks on “store receipt in my RN cloud”. (default option)
popup window asks DS, what is your cloud name?
DS types cloud name =alice
popup window runs XDI discovery to find DS’ RN cloud
popup window sends an XDI message to DS’ RN cloud to store the signed receipt
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. This process identifies the jurisdiction of the Data Controller and of the Data Subject. This example also includes signing of the receipt by the DC. (the digital signing of the DS (data subject) is currently out of scope of the first draft1)
MVCR Mock Up for Amazon Respect Use Case
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
Each item in the MVCR will be rated with this scale presented below
The compliance scale is based on the ICO table of compliance http://ico.org.uk/for_organisations/data_protection/working_with_the_ico/~/media/documents/library/Data_Protection/Detailed_specialist_guides/auditing_data_protection.pdf
...
Examples:
This is a specification by example, all examples need to be listed and demoed in this section.
MVCR Consent Receipt Template
The MVCR has a base template v.1 that we have using to wireframe consent receipts: V.1
Latest Template Version
(******Template HERE***)
We have a template that we are using for the technical design of the consent receipt, the GUI design is also out of scope. What is provided by default is a Consent Receipt Template that we are using for technical design.
Example 1: Open Notice Consent Receipt
(Example (in progress) can be found at http://on.smartspecies.com/support-open-notice/
Example 2: Storing Receipt in Personal Data Store: Technical Walkthrough Example with Respect Network
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.
To make the consent receipt usability scalable it needs to be signed and put in a personal data store.
This specification and demo is created to demonstrate a MVCR being implemented without the need for an Open Notice Registry with the Respect Network (Trusted Network) Trust Framework which natively has the ability to provision receipts to the highest level of compliance . This walk through demo is intended to demonstrate how a consent receipt can be stored in a personal cloud from this spec document and demonstrate 'Fast Track' usability.
DS goes to amazonrespect.com website
Website presents form and asks for consent:
either to sign up initially
or for additional consent and profile management when already logged in
DS agrees (clicks on “i agree” button)
DC website initiates creating the receipt for the consent that was just given.
DC checks for reciept data collection and notice extensions and finishes creating the receipt
The receipt is signed by DC.
DC website sends an XDI message to DC’s RN cloud to store the signed receipt.
DC shows popup window with options (what to do with the receipt). The signed receipt is embedded in the popup window.
email to DS using email address in amazon profile
store in users personal cloud
capture in browser
download receipt as pdf
opt out of a receipt.
DS clicks on “store receipt in my RN cloud”. (default option)
popup window asks DS, what is your cloud name?
DS types cloud name =alice
popup window runs XDI discovery to find DS’ RN cloud
popup window sends an XDI message to DS’ RN cloud to store the signed receipt
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. This process identifies the jurisdiction of the Data Controller and of the Data Subject. This example also includes signing of the receipt by the DC. (the digital signing of the DS (data subject) is currently out of scope of the first draft1)
MVCR Mock Up for Amazon Respect Use Case
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
Each item in the MVCR will be rated with this scale presented below
The compliance scale is based on the ICO table of compliance http://ico.org.uk/for_organisations/data_protection/working_with_the_ico/~/media/documents/library/Data_Protection/Detailed_specialist_guides/auditing_data_protection.pdf
Trusted Services Appendix
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. It is for seen that a notice registry is the natural place for trust services to register their services.
A process for auditing and verifying all trust services needs to be in place for trust services to be trusted. Then when an organisation enrols into the registry they can also add (or manage) trust services that has been added to the receipt.
This is a table to map the list and categories of assurance framework with examples and notes on interoperability with this category of service.
Type of Trust Framework
Consent Policy Format
Personal 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
Has terms materially changed ( is consent still compliant? )
TOSBack
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.
Reputation
Trust Framework
(all trust services provide reputation)
Privacy Icons
Pictorial Short Notices
Disconnect Me
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
Data Control Protocol
User Managed Access
Trusted Network Service
Respect Network
Standards
Certificates
TrustE
Levels of Assurance
KI: Identity Assurance Framework
Design Appendix:
Summary Design Goals to Assess: 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 with higher default usability. .
- 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.
...