- Deferred: Status: Wiki refresh work
- Deferred: Status: Distribution-version of slide deck describing the work here (consent receipt today → personal data processing receipt tomorrow - or whatever we decide)
- ISO 29184 contribution status
- Jan to give an update on the IHAN Consent workshop from last week
- Demo status update
Welcome Pierre Roberge!
- Based in Toronto - 25 years working on financial services, FinTech, working on Digital ID and Fintech, co-founder of SecureKey advisor to Fintech cluster at Mars (innovation hub)
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.
- EIC, Munich, May
- Identiverse, Washington, June
- MyData, Helsinki, September
|10 min||IHAN Consent Workshop update||Jan L|
- SITRA (Finland) - launching the IHAN project
- Workshop on developing consent architecture and specification
- Represented Dativa - presented on Hyperledger consent flow work and data overlays
- Interesting debates - 'what is needed in the future for consent & how does IHAN connect'
- In the audience - there's a split between just the specification and also the consent management practices piece.
- Someone working with DNA - recounted how to 'donate' data for research.
- Andrew described the project at UBC that is doing this
- Discussed different technologies for managing 'consent' - cookies, OAuth, others
- Jan - privacy concerns about what is specifically stored on ledger etc
- Also thinking about how parties can communicate about GDPR Rights and excercising them - anonymously
|10 min||Product roadmap for the demo||All|
Here's the project page for the "Demo v2"
2019-03-28 call notes:
- Oscar sent an email to the list about how to pass the v1.1 receipts to the dashboard/receiver service
- Simple flows - a mechanism - for the end-user
- This would allow direct receipt transfers instead of 'faking it' via the Downloads folder
Go to the demo v2 page for the breakdown of roles and functions for 2019-02-21 call
- Andrew gave a recap of the Demo development status
- Right now we are missing the 'dashboard/control panel' functionality
- A few options to move forward: a) hack a fake dashboard UI, b) create a digi.me '3rd party app' acting as a CR gateway, c) digi.me new feature to allow 'self-certified' receipts. Jim is working with digi.me product engineering on having c) available
- Sneha working on getting Sphere to export JSON consent receipts and also receive control back from the control panel once the user has chosen an action
- More discussion about roles and responsibilities for demo
- 10 weeks to go until EIC
- Discussion around how to build/implement the control panel part of the demo - challenges in getting a team to get resources to build this part
THESE NOTES ARE FROM 2019-01-31 CALL AND ARE DIRECT-EDIT-UPDATED FROM 2019-02-07 CALL
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
- Jim spoke to Gavin (CTO) - apps in the digi.me ecosystem are able to signal to the 'right to erasure' API because the 3rd party app knows the person, digi.me knows no people in the system
- Jim: all should work on the Export function to allow other apps to view
- Andrew: what are we able to show that tells the audience that there is something new coming to the world - where people can see the receipts and take an action that is recognized and acted on at a data controller.
- The Control Panel idea is powerful
- Maybe the user click transfers control over to the receipt issuer's app
- In digi.me ecosystem there is an app that allows the user to look into their private library there
- There are 3rd party apps - these 3rd party apps use the digi.me APIs and issue the Kantara-compliant consent receipts.
- The receipt is shown in the user's digi.me management console
- So, if the user takes an action on that receipt in the digi.me management console, the 3rd party app receives the signal and can act
- digi.me: https://developers.digi.me and https://developers.digi.me/consent-access
- Peter to sketch up a rough sequence
- 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 namespace/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
- (jim) digi.me green light
- (sneha) green light
|10 min||Specification update approach|
See a flowchart version of this here:
- sent the GDPR extension to the W3C "Data Privacy Vocabulary Community Group" for comment
- building a proposal to split the notice from the 'consent' in the structure
- (note that this is similar to the digi.me proposal)
- Andrew urges all participants to post issues into the github repo for proposed spec changes - so that we can discuss and prioritize them for action
- Check the mailing list for a discussion about Consent Objects in FHIR - there's a ballot to expire some material that should be of interest to CIS WG
- Mary: User Submitted Terms work
- The engineering work has shifted to IEEE but there is some discussion about bringing it back to Kantara
*** Next call 2019-04-04 11 10:30 am Eastern DAYLIGHT Time