LIVE DOCUMENT
Requirements/questions collected for a receipt (making sense) so far, by no particular order and most needing refinement or answers:
- identity of parties
- how does Alice verify the identity of Bob? how does Bob verify the identity of Alice?
- is this a requirement for the receipts or out-of-scope?
synergies between identities and personal data: Are there SP to IdP signaling mechanisms to indicate what types of values are needed by the SP?
- types of receipt
- notice, consent, notification
- types of consent
- notice, implied, as-expected, explicit, agreement (user-initiated) – from git hub doc here, Mark L
- receipt-id
- 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?
- a receipt needs to embed/facilitate traceability + auditability
- support to batched/scheduled consent to the future
- no-consent/refusal
- 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)
- deep sharing of 3rd parties
- is there a receipt to be issued?
- who issues the receipt?
- is consent “cascaded” (first party handles everything) or each a sequence of peer-to-peer Consent cycles?
- 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?
- personal data fields
How to characterize the distinction between the two – what functionalities and attributes in an app are considered optional
How does this relate to data minimization principles
- purpose of use
- Is it specified on a per attribute basis, or just for the overall bundle of attributes requested?
- post-receipt/consent notifications
- means to notify back the recipient post-act (as in a message about changes)