• Stephen Curran is pursuing a Hyperledger Labs repo for the resolver reference implementation
  • Proposal accepted https://github.com/hyperledger-labs/hyperledger-labs.github.io/pull/247#pullrequestreview-1611926849
  • Proposal repo created
• Markus Sabadello will make his did:webs and did:keri comparison available so that the sub-community interested in did:keri can collaborate.
• Lance Byrd will start an ACDC PR to the spec that describes signing
  
  • Lance Byrd will provide an outline of how to use a TEL to verify the signature document
• Daniel Hardman will donate his dh1128 repo if ToIP will allow.... all commits are signed

News or events of interest to members:

• ToIP has approved the Open Web Foundation (OWF) IPR license
• This is a provisional TF and we hope to be officially under ToIP in a month, or so
  • From the TSWG:
    • ACTION: Drummond Reed to send an email to the TSWG mailing list notifying all TSWG members of a 7 day review period for the proposed DID WebS Method Task Force, followed by a 7-day email vote seeing if there are any objections.
    • ACTION: did:webs Task Force leads to contact Michelle Janata to add their Friday meeting onto ToIP calendar once the Task Force is officially approved
• IIW October 2023
  • We aim to be registered did method and have an implementation in the Universal resolver
• did:plc and Dimiti's did:web 2.0 (next gen) proposals discussion.
  • https://github.com/decentralized-identity/identifiers-discovery/blob/main/agenda.md#meeting---25-sep-2023---1400-et
• did:webplus
  • https://github.com/LedgerDomain/did-webplus/
  • 

• Upcoming milestones
  • IIW Fall 2023
  • There are several potential opportunities, Daniel Hardman will report soon.
• DIF identifiers discovery "lifecycle of did:web identifiers"

• 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

• https://github.com/dhh1128/did-method-webs/issues
  • Activity this past week
    • Stephen Curran reviewed the newly added did doc section information
    • alsoKnownAs vs equivalentId
    • whois
    • weighted threshold multi-sig
    • SSL/TLS common name
• https://github.com/dhh1128/did-method-webs/pulls
  • Activity this past week
    • Signed Files
    • Whois
      • VCs + JWS vs. Service Endpoint

•  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.