- EIC and Identiverse speaker proposals status
- Status: Wiki refresh work
- Status: Distribution-version of slide deck describing the work here (consent receipt today → personal data processing receipt tomorrow - or whatever we decide)
- Discuss EIC demo and scheduling
Please review these blogs offline for current status on Kantara and all the DG/WG:
There is a wiki page that will hold all the known implementations of Consent Receipts - Please update the page or inform Jim, or John, or Andrew of your implementation.
- TIIME, Vienna, February
- EIC, Munich, May
- Identiverse, Washington, June
|40 min||Product roadmap for the demo||All|
Here's the project page for the "Demo v2"
Andrew's personal opinion on what to highlight:
- The fact that giving the person tools necessary for them to keep records (the 'receipts') about their data controller & personal data processing interactions is a new thing in the world
- The ability for the person to take action because they have these records in their possession - the Privacy Control Panel
- The fact that interoperability standards allow many products to work in an 'ecosystem' way
- Even if the audience does not believe that the lawful basis of consent will become a mainstream thing, the person-side record keeping idea is a good one that has broad applicability
- This opens the door to ongoing management of the relationship by the person with the data controller/other
- The consent receipt is also a Notice
- People have an independent record of the interaction in the receipt
- Have hard receipts gone away because they are viewed as 'too much friction'? Is this dangerous?
- The specific set of user stories we want to showcase - what is the "Consent Journey" of the person?
- The roles that each product will cover in the demo
From the project page, the product roles were stated as:
|PCP Dashboard||Dashboard - view and organize receipt from multiple sources|
|Control Panel Function||The part where a person clicks on a button that causes the Receipt Management Platform to take action||digi.me|
|Receipt management platform||Communication substrate - e.g. one possible function: when user clicks on button to exercise a data subject right, this calls the platform which sends instructions to the data controller to take action||digi.me|
|Receipt generator (API?)||Might be part of the receipt management platform?||digi.me?|
|Data controller application||in Demo v1 it was the Bookstore app|
|Data controller registration|
|Receipt Viewer app|
|Receipt language translator||Display the receipt in a different language e.g. French|
|Receipt storage facility|
"wallet" concept; Downloads folder; browser storage; etc
|digi.me (consent manager)|
- The discrete functions need to be identified
- Receipt issuers should be enrolled in advance (data controller should be known)
- Can we show multiple wallets that hold receipts?
- Should build on the flow of the Demo v1 - person does stuff, gets receipts, sees them, acts on them
- Is the 'wallet' (a.k.a. the receipt storage location) singular or multiple?
- Sphere app can display receipts from their own storage locations
- Digi.me only shows receipts within their system
- Jim is pushing engineering towards the idea that the 'control panel' should be able to work on receipts in other app storage locations
- Passing control over a receipt (to act on a receipt and manage it going forward) to a 3rd party breaks the security concept of digi.me and Sphere's apps
- Exporting a receipt is possible, but action on the exported receipt might require a redirect back into the Sphere app
- This is probably the same with all app ecosystems
- Jan - looking at the topic of using the receipt as a data schema but also using the universal namspacenamespace/identifiers (a.k.a. Decentralized Identifiers) to reference the entities and object might allow for broader interoperability
- Peter: we lack the protocols for operations on the receipts themselves - maybe do this in Kantara
- Jan - last week call - Paul and Jan presented on the Hyperledger Indy work for interop
- Remember that we are limited by what exists today - a list of JSON files
- The 'take action' function might be a simple "open URL in the receipt issuer's app"
- Action: Andrew to draw an information flow diagram for discussion for the demo
- Action: ALL - to think about the functionality that your products can do today in light of the "Privacy Control Panel" idea - we will try to do a heat map to try to sort out role assignments and find gaps
|Deferred||Specification update approach|
See a flowchart version of this here:
Mark: Health Use case proposal
*** Next call 2019-02-07 10:30 am Eastern Standard Time / 15:30 GMT