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

Compare with Current View Page History

« Previous Version 8 Current »

Meeting Link / Recording

  • did:webs provisional TF
    Friday, September 8 · 10:00 – 11:00am
    Time zone: America/New_York
    Google Meet joining info
    Video call link: https://meet.google.com/rpd-gjgd-nah
    Or dial: ‪(US) +1 563-557-7710‬ PIN: ‪850 219 169‬#
    More phone numbers: https://tel.meet/rpd-gjgd-nah?pin=7665699145995
  • Recording will be posted after the meeting
  • Transcript will be posted after the meeting
  • Chats will be posted after the meeting

Attendees

Markus Sabadello 

Stephen Curran 

Drummond Reed 

John Jordan 

Charles Lanahan 

Nuttawut Kongsuwan 

Lance Byrd 

Wenjing Chu 

Rodolfo Miranda 

Samuel Smith 

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
5 minsAnnouncementsTF Leads

News or events of interest to members:

5 mins

Reports

Open
  • Upcoming milestones
    • IIW Fall 2023
    • There are several potential opportunities, Daniel Hardman will report soon.
  • DIF identifiers discovery "lifecycle of did:web identifiers"
25 minsDiscussionOpen
  • Lance Byrd Security Characteristics PR is simplified w/ did:webs using KEL backing (KERI security guarantees) https://github.com/dhh1128/did-method-webs/pull/26
    • Bright line rule: For features that aren't secure, submit them to did:web?
    • Note: discovery information (less security needed, Best-available-data )... mitigates replay attack, but can be DDOS attacked.
  • Markus Sabadello diagramed the different resolver architectures, pros/cons, support for did:web, etc. https://github.com/peacekeeper/did-keri-resolver/
    • Generate a did doc and oobi file so that you can publish them to any web server
    • Then resolver verifies the did doc using the oobi file
    • Who is the verifier? the resolver
      • Does it need an oobi or does it need all of the events (KEL/TEL) like a Watcher does
        • The verification is verifying that the did document is properly formed.
        • Don't need a pool of watchers, But then availability attacks are potentially a problem.
          • Do we rewrite the watcher to handle a file format that doesn't exist. Currently it is stored as a content addressable database, the database can restream the database in case of loss.
          • Watchers stores KELs/TELs
          • To store the KEL in github, you would need to re-verify it each time.
            • The watcher could bootstrap from this file, but that is very expensive.
            • Watcher code is designed to verify on the fly, making caching very important for scale.
              • Verify only the latest events when a KEL is updated
                • If there is a presentation, etc. you want to asynchronously update. 
        • Use Case. I get a univerisity did
          • I verify the did doc when i get it.
    • Can the resolver cache OOBIs? Yes
5 minsAny other businessOpen


5 mins
  • Review decisions/action items
  • Planning for next meeting 
Chairs
  •  Lance Byrd will write the spec in a way so that it uses a cesr KEL mime type (not files) to support. You are looking for a resource. The resolver gets the URL then queries for the mime type. That could be a local file(s) or an OOBI.

  • No labels