Summary

Recording from the call: 

...

	Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct.

Welcome and Introductions

...

• Start the SpecUp document for the DID:Indy specification method
• From last week's discussion – confirmation of approach:
  • Update the NYM to add a "diddocContent" item that is the equivalent of what we proposed would go in the DIDDoc ATTRIB, with assembly left to the client 
    • Include support for the version_id and version_time resolution parameters.
    • Confirm error checking done on the NYM write.  See proposal in the hackmd document (valid JSON, no NYM fields, valid DIDDoc)
      • What are the security implications of running this code on a node – vulnerability possibility.
  • Other options rejected
    • Have a single call that gets the NYM and ATTRIB and state proofs for both with same multi-signed merkle root, and leave the assembly to the client.
      • Likely choice if extending the NYM is impractical
    • Do nothing
    • Single call with both state proofs and ledger does assembly
    • Write DIDDoc on ledger writes and have state proof for DIDDoc
    • Add WRITE_DIDDOC transaction
• Serialization formats
  • Include in document that DIDDocs are JSON-LD
    • Three serialization formats in the DID Core spec – let's go with 1 to reduce interop and implementation effort.
    • Daniel Hardmanwants to discuss this further, so that we consider JSON.
• Decision on assembly points of concern:
  • The "nymKeyAgreement" flag
  • Process: Remove the "content" item and just inline the rest of the DIDDoc content

...