Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Meeting Link / Recording

  • Currently processing will post it ASAP

Attendees

Markus Sabadello 

Stephen Curran 

Daniel Hardman 

Alex Andrei 

Lance Byrd 

Agenda Items and Notes (including all relevant links)

TimeAgenda ItemLeadNotes
5 min
  • Start recording
  • Welcome & antitrust notice
  • Introduction of new members
  • Agenda review
Chairs
  • Antitrust Policy Notice: Attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of ToIP who have signed the necessary agreements are permitted to participate in this activity beyond an observer role.
  • New Members:
5 minsReview of action items from previous meetingChairs
  • This was our first meeting
5 minsAnnouncementsTF Leads

News or events of interest to members:

  • This is a provisional WG/TF and we hope to be officially under ToIP in a month
5 mins

Reports

Open

Artifacts of previous work

25 minsDiscussionOpen
  • Will there be two specs, one for did:webs and did:keri?
    • did:webs will be most convenient and will certainly move ahead
      • depends on the web, so it is a narrower scope
      • perhaps from the 'did method' point-of-view, this is all that is necessary? keri can just be keri without dids
    • keri has no dependency on web tech, could be bluetooth
      • this method would be wider to encompass all that keri can do
      • useful when paired with didcomm, well beyond web tech
  • Markus diagram to pompt discussion for the ecosystem and reference impl
    • resolver is the did:webs verification client
    • the service and resolver will BOTH use keri-diddoc.py
    • we must comply with did:web and did:webs security requirements?
      • maybe did:web can be optional, so you MIGHT be resolvable as did:web IF you comply
    • Should did kel and did json be resolvable on the same path?
      • Github as a did:webs platform
      • Actions that publish the kel and json in the same folder.
    • KEL/TEL service is essentially a witness/watcher service
      • The url where the did:webs is published helps you locate the KEL
        • witness is a primary KEL copy
        • watcher is a secondary KEL copy
        • Given an OOBI (the witness url and AID) you pass the witness an AID and are given the KEL
    • KELs and TELs can grow
  • What is a TEL and how does it fit in a did doc
    • Transaction event log
      • Set of actions taken with your keys, that are anchored to a key state. So you know if something happened before or after a key state
        • For instance issuing a credential. You can prove the key state when you issued the credential
        • Many did docs fail to track the key state when you act (issue a credential)
    • Can be used for publishing service endpoints
    • Will other documents be tied to the did document.... if you only know W3C VCs then how do you 'walk' the history without knowing keri
      • For instance issuing AnonCreds credentials, can we use the verifiability of keri to show the issuance, but all from the did doc (without knowing keri TELs)
        • Everyone will be using keri to produce the did doc, maintain keys, etc.
        • Are there keri operations that non-keri aware users will never use?
5 minsAny other businessOpenHere is some follow-on information from the keri-dev meeting:
  • KEL watcher exists in the KERI ecosystem. TEL watching is still being defined since there are different types of TELs with different security properties.
    • The core concept is duplicity detection. So we need to explore the ways a TEL could be prevent verifiable duplication.
  • In terms of the did doc and did KEL being co-located:
    • If you completely control the AID and ecosystem then no need for a watcher
    • You could even statically generate the KEL and JSON and publish them
    • In a more complex environment you would leverage the entire KERI ecosystem
  • The did:webs resolver could reach out its own watcher
  • For the reference implementation the did:webs document generation service and KEL/TEL service will live together
  • TLS should not be used for authentication, only used for confidentiality
5 mins
  • Review decisions/action items
  • Planning for next meeting 
Chairs
  • Markus Sabadello will move Phil hackmd comments to the Github repo as issues or discussions
  • Daniel Hardman will donate his dh1128 repo if ToIP will allow.... all commits are signed
  • Lance Byrd will provide an outline of how to use a TEL to verify the signature document
  • No labels