Requirement (with link to use-case if any) | feature / nice-to-have / required / not-desired | Detail | Comments |
---|
identity of parties |
| how does Company verify the identity of Bob? how does Bob verify the identity of Company? | - a consent receipt captures the identities of the parties in a consent (ML)
- a contact is made for the consent- with the notices in it - so SP and IDP can use the same policies and laws (ML)
- separation (when possible) of Authority and Controller (Tom Jones)
- both should sign the receipt (if possible)
|
types of receipts |
| - notice, notification, consent?
|
|
types of consent |
| - consent not needed, implied consent as you have consent from a previous context, that state of consent as-expected, explicit consent to being consent state, privacy agreement (user-initiated - consent directive with a notification) – from git hub doc here, Mark L
| - Consent Types are the human labels for consent mapped to a legal justification providing the authority for that consent type (ML)
|
receipt uniquess |
| - should enable context over a long period of time (re-consent, changes, revocation, etc.)?
- a previous-receipt-id to enable protocols and establish a notion of session continuity? or a receipt sub-id? or transaction id within a receipt?
| - linking receipts (this should be explored separately in each use case) (ML)
|
traceability and auditability |
| - receipt needs to embed/facilitate traceability + auditability
| - the consent is the permissions record - it should be queried for processing - and this should be logged to provide transparency and queried (in context of service usage) according choice and context by person. (ML)
- I think language matters here: for me, a receipt is the object that links to an internal record (VJ)
|
batched/scheduled consent |
| - support to batched/scheduled consent to the future based on a past consent
| - originally raised by Jim H (VJ)
- is this consent or is this maintenance of consent state? (ML)
|
no-consent/refusal |
| - a receipt to record "no consent"
| - In US - among “merchants” (not consumers), failure to promptly object to a notice of a minor change can be taken as acceptance. And there are numberous other situations, time periods for undoing something, making a claim, etc. (quoting and thanks to Jim Hazard)
- this varies but - in US Healthcare non-consent means that there is no processing - as this requires explicit consent. (ML)
- in the US they have relaxed rules for identity (ML)
|
cascaded consent |
| - further transmission of personal data and consent to 3rd parties (and 3rd parties of 3rd parties)
- who issues the receipt?
- is consent “cascaded” (first party handles everything) or each a sequence of peer-to-peer Consent cycles?
| - is there a receipt to be issued? (ML)
- as a netizen, I really would like that to be the reality (VJ)
- isn't this the same as idp to sp above? (ML)
- I'd say it affects all other components of consent. Imagine that only a subset of data is shared; or that the data gets compounded between different 3rd parties and, together generate, a different kind of PI. (VJ)
|
enumerable fields need external taxonomies |
| - we need taxonomies for certain fields which can be enumerated
- e.g., purposes, legal basis, types of data collected
- the taxonomies in themselves out-of-scope for the spec, i.e., external parties will define them?
| - nope these are what the inputs are. Notice and consent receipts are not useful without standard words for noices for humans to understand; if standardised then people only need to know one set of terms - and its the services that have to adopt to people (not the other way around - thus enabling social physics etc) (ML)
- The problem is race conditions: by the time a taxonomy is finalised by an interest group it is guaranteed to be out of date. So free text fields are an option (just probably worse). (VJ)
|
personal data fields |
| | - raised by Ken K
- in the spec - the subject identifier is personal and the consent record is personal (ML)
|
purpose of use |
| - Is it specified on a per attribute basis, or just for the overall bundle of attributes requested?
| - raised by Ken K
- legally specified to purpose category in the specification, and its the industry, or association, or location, or person who can specify the attributes under that category for that person (ML)
|
post-consent notification |
| - notification in the sense of messaging: means to alert back the individual post-act
|
|
first notice |
| - how is the user exposed to the first notice? whereas in a web scenario this is (sort of) trivial, in other cases (such as medical or CCTV) this may not be straightforward
|
|
|
|
|
|
Notice & Notification Requirements |
|
|
Notification quality capture - |
| measuring - number of eConsent elements achieved in the receipt, with respect to an eConsent quality of knowledge and awareness - | - what are the elements and how are they recorded in a notification - proof ?
- video present and used
- audio present and complete listened too
- speed of completion
|
|
| capacity to respond to an eConsent notice | - physically,
- mentally
- reading level
- device usage
|
|
| A Quizz - to provide proof - and the quilty of a notice and notification proof - testable requirements - | |
|
|
|
|
|
|
|
|
|
|
|
|