•  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/
  • Image Added

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

• 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

• 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
• 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?
• • 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
information
• • , 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
Bright 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?
• 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.