Summary

Recording from the call:

...

 20210302 Indy DID Method Specification Call Recording

Welcome and Introductions

Announcements

Attendees

• Stephen Curran
• Dan Gisolfi
• Paul

Collaboration Channels

• Current hackmd document 
• indy-did-method on RocketChat - https://chat.hyperledger.org/channel/indy-did-method
• indy-did-method repo: ReSpec vs. SpecUp

...

• 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)
      • 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 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.
• Decision on assembly points of concern:
  • The "nymKeyAgreement" flag
  • Remove the "content" item and just inline the rest of the ATTRIB?DIDDoc content
• Other Indy Ledger Objects as DIDs (e.g. schema, etc):
  • Drummonds proposal: https://docs.google.com/document/d/1f99z4Bf8F-DA8EbkNjInVQv2ncJGPwF_Dp7I7Mfyhqs/edit
  • Other options:
    • Use the `@context` to indicate what type of Indy object is being referenced.
    • Use a GET_DID transaction that uses the local identifier for the different objects and the ledger figures out the doc type and returns the appropriate result – e.g. a SCHEMA, CLAIM_DEF, etc.  The existing transactions remain and are used if the client wants.  The GET_DID can also be used to return a NYM.
      • STATE_PROOF comes back in the reply as currently done.
  • Existing transactions

Future Discussions:

...