| | | |
|---|
4 mins | | @Former user (Deleted) | 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 AOB
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)
|
5 min | | All | 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. Discussed different technologies for managing 'consent' - cookies, OAuth, others Jan - privacy concerns about what is specifically stored on ledger etc
|
10 min | Product roadmap for the demo | All | Here's the project page for the "Demo v2" 2019-03-28 call notes: Ubisecure Oscar sent an email to the ist 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 insted 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 ======= 2019-03-14 notes 2019-03-07 notes 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
Comments: 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?
Decisions needed: Comments (2019-02-14): Comments (2019-02-07): Jim: all should work on the Export function to allow others 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 In digi.me ecosystem there is an app that allows the user to look into their private library 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
Comments (2019-01-31): 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? 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 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
|
10 min | Specification update approach | | See a flowchart version of this here: https://share.mindmanager.com/#publish/b-DWOcuKGnVY1PXBKXTpL0-DQOeqmZMGfGUAPiC5 2019-03-14 notes: |
5 min | AOB | | |
| Next meeting | | *** Next call 2019-04-04 10:30 am Eastern DAYLIGHT Time https://global.gotomeeting.com/join/323930725 |