Versions Compared

Key

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

Meeting Link / Recording

  • Video will be here
  • transcript will be here

Attendees

Attendees

Lance Byrd 

Stephen Curran 

Markus Sabadello 

Samuel Smith 

Daniel Hardman 

Alex Andrei This is a future meeting

Agenda Items and Notes (including all relevant links)

TimeAgenda ItemLeadNotes
5 min
  • Start recording
  • Welcome & antitrust notice
  • Introduction of new members
  • Agenda review
Chairs
5 minsReview of action items from previous meetingChairs
  •  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
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 September 2023
    • Change meeting time to better accomodate west coast (times after 10am ET)?
    • Thoughts on amending the charter https://wiki.trustoverip.org/display/HOME/ZZ+-+Proposal+-+DID%3AWebS+Task+Force regarding where the code lives.

      • For instance, under IPR, ACDC has the following clause “The ACDC TF is not expected to produce source code.”

      • There is no such clause in the did:webs charter.

      • Possibly in WoT repos
        • Possibly start here as a neutral repo
      • Ideal spot in terms of coaliton/PR? As public as possible.
        • Possibly DIF, where the universal resolver lives
          • At least provide some universal resolver contributions
        • Possibly OWF
          • Contributions in support of wallets
  • IIW October 2023
    • Possible milestones?
    5 mins

    Reports

    Open

    Current work

    Spec repo to be donated to ToIP if WG/TF is approved
      • Do we want to define milestones, like IIW, for the spec and reference impl?
        • Arrive with a coherent draft, already registered in DID registry
        • Also arrive with reference impl in DIF Universal Resolver
    • DIF identifiers discovery
      • In next Monday's DIF ID WG meeting, we will talk about "lifecycle of did:web identifiers" which also seems related to this topic:
    dhh1128did-method-webs
  • https://dhh1128.github.io/did-method-webs/index.html
  • Reference impl will be continued hereWebOfTrustdid-keri-resolver

    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
    • Here is some follow-on information from the keri-dev meeting from Samuel Smith :
      • 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 to 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
    • Markus Sabadello , Stephen Curran , and Lance Byrd  diagrams to pompt discussion for the ecosystem/architecture and reference impl
      • Image Removed
      • resolver is the did:webs verification client
      • the did doc service and resolver will BOTH leverage keri libs
      • 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 large, do we need to consider this size?
    • In terms of key rotations and DID doc history Phil Feairheller and Drummond Reed discussed a DID doc URL parameter and registering a DID doc extension for easily referencing the key state used for VP, etc.... and defining how that resulting JSON or array will look. 
    • 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 mins

    Reports

    Open
    • Lots of progress/conversation, issues, PRs in github and slack
    25 minsDiscussionOpen5 minsAny other businessOpen
    • Shall we prioritize the work based on MvP, milestones, etc?
      • IIW Fall 2023
      • There are several potential opportunities, Daniel Hardman will report soon.
    5 minsAny other businessOpen


    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
    • Consider pros/cons and strategy for where reference implementations live
    •  Lance Byrd will provide an outline of how to use a TEL to verify the signature documentstart an ACDC PR to the spec that describes signing