Versions Compared

Old Version 1

changes.mady.by.user Lance Byrd

Saved on

compared with

New Version Current

changes.mady.by.user Lance Byrd

Saved on

Key

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

...

...

Meeting Link / Recording

Attendees

...

Attendees

Markus Sabadello 

Stephen Curran 

Drummond Reed 

John Jordan 

Charles Lanahan 

Nuttawut Kongsuwan 

Lance Byrd 

Wenjing Chu 

Rodolfo Miranda 

Sam 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:

  • ToIP has approved the Open Web Foundation (OWF) IPR license
  • This is a provisional
WG/
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
  • Is a secure did:web spec adoptable, without additional features? Or do we require NEW features like whois, signed files.... if so, can we agree on what else is required?
  • Image Removed
The default should be secure?
  • Verbose solution, Appraisable Security Level API: The spec swells in order to detail multiple 'levels' of security in order to accomodate both familiar and secure mechanisms.
    • Bare JWS provides file integrity, but not authenticity
    • Best-available-data RUN is only acceptable for discovery information, file integrity and monotonically increasing (date)
    • KEL anchors for integrity and authenticity
  • Hybrid solution: You can't publish the JWS without anchoring in a KEL first?
    • Or perhaps, anything not secured by KERI is not did:webs, it is did:web?whois and JWS could be a PR to did:web and the ACDC anchored signature is did:webs
      • Bright line rule: For features that aren't secure, submit them to did:web?
      • Note: discovery information (less security needed, Best-available-data )...
    a level of
      • mitigates replay attack
    informationBright line rule: Should the core of did:webs be the more familiar but less secure options, like JWS? Or should those be extensions to the did:webs spec?
      • , but can be DDOS attacked.
    Daniel Hardman suggested last week that we explore the 'notion that did:web can borrow the view of did:webs" during our discussion about using JWS vs. ACDC.
    • 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 Create a PR for the spec that abstracts the verification information to CESR resources/mime type (not files) to support multiple reference implementations. The resolver can use local file(s), OOBIs, Watcher pools, DB/cache, etc for verification as long as it results in secure KEL/TEL verification.