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

• Current work

  • Spec repo is here https://github.com/trustoverip/tswg-did-method-webs-specification
    • Registered in the did registry here https://w3c.github.io/did-spec-registries/#did-methods
  • Reference implementation is here https://github.com/hyperledger-labs/did-webs-resolver

Cole Davis will demo his related work at Switchchord

• Music industry map is huge with many layers of contracts; participants have many different identifiers for purposes of getting paid but no consistent "identity"
• Digital representation of a copyright should flow through supply chain and aggregate transaction data about itself.
• The contracts:
  • Composition copyright (melody and lyrics) usually assigned (sold) by songwriters to music publishers
  • Sound recording copyright (specific recording of a composition) usually assigned (sold) by recording artist to record company
  • "Split sheet" is how songwriters initially divide up copyright ownership for a song written by multiple songwriters
• Copyright management system:
  
  • Songwriter
    • Verified identity with KYC, etc.
  • Publisher
• Currently uses did:web, will transition to something like did:webs
  • Working with industry partner looking at did:ion
• Software-based legal contracts
  • Songwriter agreements
• Web and mobile interactions
  • Name, writer, share, signature, etc.
• Export the credentials in different formats to support the different reqs in the supply chain.
• Avoid music silos, 'bring your own identity'
• Social graphs of cryptographic identifiers via the creative process
  • Organizational identity is just as important for legal, etc.

• KERI Perspective: secure rich discovery
  • authorized identifier list
    • Not did:webs specific
• did:webs perspective
  • generator/resolver use the authorized identifier list
    • EquivId, Redirection, and Authorized Domain is all satisfied by the authorized identifiers that are did:webs
    • AlsoKnownAs is all non-did:webs DID identifiers (Markus can weigh in on non-DID identifiers
  • Questions
    • resolution must fail? or is it just that the metadata isn't there? And thus redirection, etc. is not valid?
    • perhaps only the did:web version is allowed then? can the resolver redirect to did:web, is there a way to notify the user?
    • this brings up the classic issue, that you need to know about weaker security.
• Domain related history, validation, and more
  • EquivalentID
    
    • 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)
    
    • 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 
    • 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)

• 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
  • Related to this CESR spec https://trustoverip.github.io/tswg-cesr-specification/draft-ssmith-cesr.html