Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

(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
    • list of fields
  • 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)

  1. 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)
  • vitor jesus Tadej Fius (Unlicensed) to create a template JSON first iteration of the current iteration of the receipt spec (still working on itWorking on a demo, and a external potential hackathon for early Marchdata 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===

...