...
...
...
...
...
Date
2018-08-0209
Status of Minutes
DRAFTApproved
Approved at: <<Insert link to minutes showing approval>> 2019-12-12 Meeting notes (CR) DRAFT
Attendees
Voting
...
- Andrew Hughes
- Richard Gomer
Non-Voting
- Marvin van Wingerde (iQuality)
- Claire Denton
- Tom Jones
- Sylvester
Temp list of names
- Mark LizarChris Cooper
- Oscar SantolallaKartik Venkatesh
- Jim PasqualeJoss Langford
Non-Voting
- Sylvester
- Colin Wallis
- Sal D'Agostino
Regrets
Quorum Status
Meeting was <<>> quorate
Voting participants
Participant Roster (2016) - Quorum is 5 of 9 as of 2018-07-12
Iain Henderson, Mary Hodder, Harri Honko, Mark Lizar, Jim Pasquale, John Wunderlich, Andrew Hughes, Oscar Santolalla, Richard Gomer
Discussion Items
Time | Item | Who | Notes |
---|---|---|---|
4 mins |
|
| |
5 min |
| All | Please review these blogs offline for current status on Kantara and all the DG/WG:
There is a new wiki page that will hold all the known implementations of Consent Receipts - Please update the page or inform Andrew of your implementation. Planning a Member Plenary meeting October 26-ish San Francisco (Friday after IIW)
|
40 min | Interoperable Consent Receipt demo at MyData Conference | All | 1) Dev team status Google drive folder for export/import of consent receipts
|
2) Sequence diagram and roles status
| |||
3) Storyboard status | |||
4) Stage narrative status
| |||
5) Team Issues and showstoppers discussion No issues reportedOpenConsent raised an issue: The result is that there is no PII. Controller name in a receipt produced spec an viewed in the viewer. From OC -viewer conformance input - The spec does not clearly differentiate between child objects (or values) and their parents. Thus the spec defines piiController as an array. What it then does is list a number of other fields WITHOUT indicating that they are a grouped object that is what is in the array. Solution piiController should not be a string, neither should service or purpose - these fields should also be reviewed to be an object .. Might also have a name field (or description field in the object that is a string.
| |||
AOB |
| ||
Next meeting | 2018-08-02 16 same time, same number GOAL IS TO HAVE ALL DEMO PARTICIPANTS JOIN THE CALL TO WORK OUT ANY MAJOR ISSUES |
From 2018-08-02 call:
- digi.me
- Consentua
- Still on track - deciding on timing of code change deployment on Monday - some front end work to go after that
- Ubisecure
- Still on track
- OpenConsent
- Viewer exists, able to read consent receipts, working on the UI
- Can consume api.consentreceipt.org and v1.1 CR
- Trunomi
- Still on track - JSON examples early next week
- clym
From 2018-07-26 call:
- digi.me
- n/a
- Consentua
- Developers have promised CR output Week of August 6-10 - we will be looking for the output in the shared google folder
- Developers have promised CR output Week of August 6-10 - we will be looking for the output in the shared google folder
- Ubisecure
- n/a
- OpenConsent
- Viewer has been started - looking to get receipts from others
- Target is August 15 to be able to display CRs
- Open call to suggest features for OC to include - provide them this week if possible
- Trunomi
- currently in their 2-week dev sprint - target completion week of August 6-10
- clym
- n/a
- Telus
- Resource and scheduling estimates for creating an external CR for an existing app
...
- digi.me
- new internal release v2.2 is available this week
- some enhancements to Consent Access functions - some export functions
- created field mapping versus specification - spreadsheet has been available for a few weeks
- has new spreadsheet with updated JSON file info - has sent to David and Andrew for pre-review
- digi.me has drafted a 'vendor extension' - proposal for new objects to be added to the spec
- digi.me is done
- Consentua
- Service is ready to go - just need to create a format for the CR spec - a configuration change, not a code change
- work planned to start next week - planning session - will have more status on Monday
- Ubisecure
- Minimal prototype - no CR in product
- They will use the CR generator to create a sample app - a bookshop
- CR will be downloadable
- OpenConsent
- underway to create a Viewer plus Viewer API
- scheduling estimates underway - target is to demo this at the interop demo
- Trunomi (via Andrew)
- currently in their 2-week dev sprint - will have code after next week
- Telus
- Resource and scheduling estimates for creating an external CR for an existing app
From 2018-07-12 call:
1) Story board discussion - Richard
https://gist.github.com/RichardGomer/14fccfb4c590d6b1285422215cd6e3b5
- Diagram A: "Get consent receipt"
- This is the crux of the demo
- How does the user know they have a CR?
- What will a user experience when this happens?
- Option: make CRs optional to the user (ask them if they want a CR at all)
- How do they know what to do with at CR?
- How does the user know they have a CR?
- Diagram B: "List Consent Receipts"
- The location of this diagram is not specific (on purpose)
- Two parts here:
- 1) for any given Data Controller, how will they show a list of CR for the user, to that user?
- 2) open question about consolidate repos for CRs from many data controllers, for the user
- FOR THE DEMO:
- Use files to store the CRs
- Use a filename convention (including extension)
- Use a dedicated folder to hold the downloaded CR files
- Use a File Manager to get a list of CRs
- ACTION: Mark: to ask Joss if the receipt storage application is available (from the COEL work)
- Diagram C: "View a Consent Receipt"
- Consentua does not currently do this - who does?
- digi.me has a viewer in the product today
- He will have a sample JSON receipt export available this week
- At this time, digi.me does not want to be a wallet - so no function planned to import general purpose CRs
- There are too many wallets on the market already
- OpenConsent is in planning stages of creating a general purpose viewer
- Current implementation is for 'privacy receipt' which is a subset of a 'consent receipt'
- Ubisecure
- Viewer is not planned for this timeframe - they plan to generate CRs for download through the browser
- Tom Jones has an XSL for diplaying CRs
- Diagram D: "Move a Consent Receipt"
- Open question about how to move the receipt from one system to another
- Export/download/import (browser)
- Share action (on mobile)
- Drag-drop (desktop)
- Email - do we have a MIME-type for Consent Receipts? (Nope, not yet)
- Q: What about using an API? A: The diagrams are about user interaction patterns, not infrastructure.
3) Timing for initial testing & location of repo
- ACTION: Andrew to publish the WG's github repo location
- ACTION: Andrew to create an publish a Google Drive folder for file exchanges (e.g. Exported CR files)
- digi.me is almost ready to start exporting CRs
From 2018-07-12 call:
Andrew walked through the sequence diagram.
- Richard - the 'Export' consent receipt might be too disruptive to the user - maybe
- John Krogulski - what data formats? A: It's set out in the specification
- Mark - should we be using JWT for transfers?
- A: This might be a complexity that we should incorporate in later interops
- A: This is a complexity versus future-proofing question... ANDREW to ask the list/implementers
- ACTION: All to post comments to the wiki page about the sequence diagram, questions, clarifications etc.
- Storyboard
- Ready to draft a user story - aiming for delivery on next call
- Tom - there are prior activities that are not showing on the sequence - the Data Subject has to be identified to the Controller and Platform including any consents
- Mark - the "initial consent flow" - the sequence is not showing the bootstrapping sequence - the sequence is showing the ongoing interactions
- ACTION: Andrew to annotate with prerequistes and assumptions of user already being set up
- Richard
- ACTION: to document the technical flows of Consentua in the context of the interop demo sequence
- Sylvester's Action item:
A receipt reader is an application that parses (reads) consent receipts automatically. A reader only handles consent receipts in it's machine readable format and is a component of some automatic process.
A receipt viewer is an application that a human uses to interpret the contents of a consent receipt. An application can only be considered a receipt viewer if it presents receipt data in a human readable form.
A receipt dashboard is an app used by humans to store and manage consent receipts. A user can use their dashboard to perform batch operations on multiple receipts at a time.
ACTION: All to comment on these starter definitions, on list (note that the text above has already been edited)
From 2018-06-28
- Discussed Kartik's v1 of the sequence diagram
- Park: the discussion about 'viewer/reader/dashboard' and the differences in functionality that those terms encompass
- Has anyone played with the 'sand' demo app? URLs to follow by email
- First part of the demo:
- Data Subject interacts with Organization A and as a result, a consent receipt is created and shown to the Data Subject. The consent receipt is stored in a place that is known to the Data Subject.
- Second part of the demo:
- Data Subject starts their preferred app which they normally use to view and manage their consent receipts and sees a list of consent receipts that are in the place referenced from the first part of the demo. Data Subject clicks the new consent receipt and the contents are displayed.
- ACTION: Mark/Sylvester to write functional descriptions of the 'viewer/reader/dashboard' concepts
From 2018-06-21 call:
- John walked through the draft scenario
- Mircea: why would the receiving org need to generate a new CR?
- A: Depends on the interpretation of Article 20 implementation
- Jim: digi.me's consent feature requires that the data processor notifies the user on downstream sharing
- Karik: Trunomi allows counterparties to be defined and data sharing rules defined up front. PSD2 scenarios - has 2 consents that are tracked - 3rd party doing payments on behalf and the financial institution
- ACH: Would it make sense to just do the simplest thing: one data controller mints a CR and a different org displays it.
- Richard: important to do display and that the back end system is following the CR instructions
- Jim: digi.me has started work to 'export' a CR artifact. The user might be notified of sharing event.
- John: starting to think that we should disconnect the demo scenario from any specific regulatory requirement - this should stay a technical demo
- Robert: agrees - show what you received is what was sent - and show multiple receipts that display in the same way
- ACH: related that people in unconference sessions are capable of imagining potential uses of CRs - we need to show the simplest functions
- Kartik: conceptually makes sense - questions on the details about how multiple platforms will play
- Mircea - need to decide on which systems take on what roles in the demo - which ones create CR, which ones consume & display
- Richard: in principle it is OK - what does it actually look like to a User - the UX and concept of a CR moving from one place to another - there is no metaphor for this yet
- Oscar: does not have viewer yet - so this would help to have some else's viewer to use
- Mark: is the CR moved directly by the back end or are the actions done by the User.
- ACH: has lined up a mobile operator as a issuer of CRs - but they have no viewer - they need the user to use someone else's viewer
- ACH: need to do a storyboard
- Robert: the metaphor should probably be the same as physical receipt management - one place to view them
- ACTION: Richard to sketch a story board for this
- ACTION: Kartik to ask questions around how consent management platforms - send to email - includes sequence diagram
- Mircea - is each consent receipt unique? and should it stay at the originator org? then the only thing transfered would be the CR id?
- ACTION: Jim - to list some of the high level activities that digi.me is undertaking
- Mark: OpenConsent is planning to have a Viewer by August
- Possible distinction: A Viewer - look at CRs one at a time. Dashboard - look at multiple CRs and act on them.
From 2018-06-14 call:
- Jim: any project wanting to participate in the MyData consent receipt interop demo - we need you do do a mapping against the CR fields - there is a spreadsheet!
- Need to ensure that the Use Case spotlights the user-centric approach. A motivator to show vendor-vendor interop is to demonstrate industry resilience.
- Since the CR will contain personal data (and probably sensitive data) we must avoid giving the impression that we are unware of risks and anti-patterns.
- There are 10 weeks remaining until presentation day!
- Next week's call:
- Confirm the high-level scenario for the demo
- Should this be limited to exchange of CRs? or showing data transfer that involves CRs
- Discuss and finalize a sequence/interaction diagram
- Confirm the CR-related roles required for the demo (Display-ers/dashboards, the Person, CR Issuers)
- Richard Gomer is committed to the project (per Chris
) - will have input into the UX issues
- The Consentua WebSDK demonstrator has embodied some of these concepts
- Pre-work assignments (due for distribution to the WG by Tuesday):John - will develop a draft sequence diagram
- Confirm the high-level scenario for the demo