(all in one file)
=== 30 Mar 2022===
- calls will take a break until (expected) mid/end of May to progress offline work
- core spec
- software proof of concept
=== 17 Mar 2022===
- architecture of the proof-of-concept as a web3 application
=== 10 Mar 2022===
meeting postponed, due to lack of availability of members.
===3 Mar 2022===
===24 Feb 2022===
===17 Feb 2022===
- welcoming Jeff Corrigan and pointing out formalities
- there's now a working json of the receipt structure
- current list of fields (xls)
- notion that a next gen receipt needs two components:
- bidirectionality, so a protocol user/controller can be devleoped (e.g., signing)
- hooks to external services (e.g., obtaining keys, identities, risk rating)
- open sourcing code is supported by all
- Jeff suggests posting code + docs under AWS but not locked to AWS (as a reference implementation and forkable) - similar to this.
- forward: procude some text in the spec --> code --> finish spec
- dev team will do code outside the regular calls and report back
Actions:
- create spec structure in gdocs
- setup meeting with devs
===10 Feb 2022===
Agenda
1) intros
2) review active deliverables
AP: create a document that can be used for a hackathon for the next meeting
https://www.wearemillions.online
4. Receipt format (Vitor)
5. Event handling (Tadej)
6. Security (Tadej)
- Use Case (Črt)
3) demo preparation
4) other topics of interest
Notes ahead of the meeting
- a new file with fields with an added column about
- where each field is sourced from
- whether it is independently obtained by the user (or browser user-agent) such as "on Behalf of PII Principal", "keys")
- whether it comes directly from the Controller via JSON in the HTNL (that the add-on detects)
- whether it is mutually agreed using a protocol (complexity of it to be discussed) - e.g., the Privacy Notice hash needs to be sent by the Controller bu verified by the User - both do hashes and confirm they match)
- whether the information could/must come from a third-party (a directory, registry, blockchain, etc)
===3 Feb 2022===
- The call was moved to a different time (2pm/GMT, 9am/ET) which caused agenda conflicts
- Brief catch-up on the work
===27 Jan2022===
call did not happen due to agenda conflicts
===20 Jan2022===
- continue the overview of 1st draft receipts field (link TBA)
- reviewed and scoped with group comments CRWeb receipt format (13jan22 version - crweb-receipt-format-20220113.xlsx)
- Tadej Fius (Unlicensed) to create a first iteration of the data model → the data model will raise missing details and specifics (e.g., what is excatly a "key")
- IIW will be the end of April (show whatever we'd like) This session will be in-person what to present?
- How does the lifecycle get addressed (Vitor will elaborate in the roadmap) Lifecycle manager not part of the receipt
- the record or receipt should only include key information per the kind of consent as an extension of CR 1.1
- @Črt There will also be work done on registries as part of Fair Data Protocol; juyst FYI at this point, but at one stage I see the structure of the receipt "registered" in this way: https://github.com/fairDataSociety/FIPs/blob/master/text/0001-fdp-roadmap.md
- rough roadmap for the essentials of the spec:
- Working prototype (in the sense of "Minimum Viable Concept/Product") by mid Feb. This is a website, add-on, html semantics, receipt record
- This work to feed ideas (by end of Feb) and a potential participation in https://www.wearemillions.online (1-21 March)
- from here we develop the more advanced concepts such as lifecycle etc
===13 Jan2022===
===06Jan2022===
===23 & 30Dec2021===
No meetings over the Christmas New Year Holiday
===16dec2021===
===9dec2021===
Review CR 1.1
https://github.com/KantaraInitiative/consent-receipt-v-next/issues/13
Consent lifecycle What and How (open item to be fleshed out)
ISO 27560
Datafund work (Jan L.)
https://github.com/decentralised-dataexchange/automated-data-agreements/blob/main/interface-specs/data-agreement-schema/v1/data-agreement-schema.json
https://w3c-ccg.github.io/ld-proofs/
Data Agreement demos from NGI ESSIF-LAB sub-grantees iGrant.io, Gattaca, and the Human Colossus Foundation. These three demos implementations demonstrate how a consent notice (or "data agreement" as it was called in the ESSIF-LAB context) gets signed as a shared record between issuers/verifiers (data controllers) and holders (data subjects). The data agreement sets a clear purpose of usage, what personal data is collected, how long data can be retained, and on what lawful basis it can be processed; both parties keep a record, allowing precise GDPR enforcement and transparency on all sides. The data agreement was originally based on the Kantara Initiative's Consent Notice, which is now being standardized as a new ISO standard 27560. All DIF members are welcome to the demo to better understand what data agreements are and how it has been implemented using VC technology by the NGI essif-lab participants. The meeting will be recorded and archived as a meeting of the Claims & Credentials WG.
https://us02web.zoom.us/j/87498640502?pwd=WTN0SVJHSzZtdVFYd3JYT3JadjB1UT09
Friday, 10 December - 4:00 - 4:50pm CET
Tadej Fius speaking of schemas
something like https://docs.microsoft.com/et-ee/uwp/schemas/mobilebroadbandschema/carriercontrolsignatureschema/element-signature
Črt: link to the sample
https://github.com/datafund/dr-editor-sample/tree/master/example_files
Črt: note that there are 3 parts in the https://github.com/datafund/dr-editor-sample/blob/master/example_files/CR_project_config_demo_w_formdata_larger_w_timestamp.json: - schema (from Kantara, basically) - uiSchema: (what is shown on screen, also with Enum options for some fields) - formData: the actual data
further notes:
- attendees - VJ, JL, CA, JP, RG, TF
- consent lifecycle - consensual that it is of interest
- CRWeb should support DiDs/VCs (as in ADA), even if not required
- the technical impact of this is that the receipt should be extensible
Actions:
Consent lifecycle What and How (open item to be fleshed out)
===2dec2021===
- attendees - VJ, TF, SA, CA
- discussion around security and authenticity in receipts
===25nov2021===
- CRWeb’s specification and companion docs – CRWeb-ToC-20211125.pdf shows an outline
- CRWeb will also deliver a proof-of-concept to demonstrate the concepts. A kick-off proposal for the architecture is in the attachment as well
- Browser add-on listens to events
- HTML contains metadata (e.g., Controller info) in JSON-LD
- JSON-LD contains the name of the html artifact associated with the receipt event
- A discussion on the protocol itself, considering authenticity and accountability: how to authoritatively architect the transactions?
- Event id, with provable order, will need nonces, timestamps, UUIDs, versioning, etc.
- This will further support the notion of a Consent Lifecycle
- Decentralised approaches of high interest to the group – they should be seamlessly supported as a use-case (including to facilitate auditability)
- Receipts should be aligned with what is expected from ISO 27560 (and ideally feed into it)
- VJ to send an early schema of a receipt to get started. CR1.1+datafund extension should be a starting point.
Actions
- VJ to kick-off the schema
- AH to share doc on 5 (?) ways to keep accountable (?) data controllers
- TF to send schema used by DF