Summary

Recording from the call: <TO BE ADDED>

Welcome and Introductions

...

• What is in a NYM state proof and if it can be "easily" extended
• Serialization formats

This Week's Discussion:

• 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)
  • 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 transactio
• Serialization formats
• Decision on assembly points of concern:
  • The "nymKeyAgreement" flag
  • Remove the "content" item and just inline the rest of the ATTRIB?
• Other Indy Ledger Objects as DIDs (e.g. schema, etc):
  • Drummonds proposal: https://docs.google.com/document/d/1f99z4Bf8F-DA8EbkNjInVQv2ncJGPwF_Dp7I7Mfyhqs/edit
  • Existing transactions

...