You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 7
Next »
LIVE DOCUMENT
Requirements/questions collected for a receipt (making sense) so far, by no particular order and most needing refinement or answers.
When you make notes, please add your name after in order to trace and clarify.
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|