• Antitrust Policy Notice: Attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of ToIP who have signed the necessary agreements are permitted to participate in this activity beyond an observer role.
• New Members: 
  • Ed Eykholt 
  • Bjorn (Blocktrust)

• Current work

  • Spec repo is here https://github.com/trustoverip/tswg-did-method-webs-specification
  • Reference implementation is here https://github.com/hyperledger-labs/did-webs-resolver

News or events of interest to members:

• ToIP has approved the Open Web Foundation (OWF) IPR license
  • 60 day period is complete
• Welcome to the did-spec-registry did:webs!!! https://w3c.github.io/did-spec-registries/#did-methods

• 1.0 spec completed by December 15?
  • November to iron major/minor issues
  • First-half of December to tighten wording, etc.
• Domain related history, validation, and more
  • Lets assume needed information (verifiable attestation) will be anchored to the KEL
  • Do a read through before discussing, to get the whole picture
  • EquivalentID
    •  even stronger semantics than AlsoKnownas
    • Set of identifiers with the same did method (did:webs) and same AID
    • Currently says anything with the same AID is equivalent identifier
      • We need to use a different phrase than 'equivalent identifier', 'canonical' (does that just mean the AID)?
    • Equivalency includes subsets = stale info okay
      • duplicity detection of bad actor (fork)
    • EquivalentID use in did doc metadata
      • only other did:webs
        • did:web on the same domain, but different security characteristics
        • did:keri has same security characteristics but not web specific
    • for reference:
      • did:indy automatically carries two equivalentIds
      • did:ion has long-form and short-form
  • AlsoKnownAs (AKA)
    • We need to state how accepting this is
    • Automatic transformations of AlsoKnownAs
      • did:web on the same server, but different security characteristics
      • did:keri has same security characteristics but not web specific
    • Redirection says Authorized domains anchored to KEL
      • Mastadon community uses AKA as redirection
  • Handling Web Redirection
    • Stabilizing did:webs on an unstable web
    • Redirection is equivalency?
      • Only if you declare in the event log (KEL)?
        • Intentionally stated by the controller
        • Undefined redirection can happen, but not authorized (intentional?)
    • Cache or offline storage 
    • Should there only be one, all others being redirects?
      • Easier publish management
      • Multiple domains supported could be useful
      • Hard to tell the difference between 'moving away' and 'alsoKnownAs'
    • Redirection says Authorized domains anchored to KEL
      • Mastadon community uses AKA as redirection
  • Recent discussion in Spoofing issue
  • Domain authority issue
    • each attestation is not chained
    • rules section states no control (does not require control) of the domain (per our conv. last week)
      • Is there something special about domain control?
      • should we also link to the spec, where it acknowledges that web infrastructure is dynamic and how the process works to keep the identifier stable over time.
    • Any considerations with path?

  • Matrix to facilitate the search for the simplest schema(s)

    anchored to KEL	stable/hist did:webs	Equiv/AKA/redirect	authorized domain
    whole did
    domain
    port
    path
    date time
    restrict

• Open PRs and Issues
  • https://github.com/trustoverip/tswg-did-method-webs-specification/issues
  • https://github.com/trustoverip/tswg-did-method-webs-specification/pulls

• • Markus Sabadello will do a read through the spec and report additional changes needed
  • Samuel Smith will pursue the IANA CESR MIME type registration within the ACDC TF
    • Provisional registration is short-term
    • Then work towards official registration
    • Lance Byrd will follow up
  • Cole Davis  will show a demo