Summary

Recording from the call: 

Welcome and Introductions

...

• Note: Work from Gimly (Jack Tanner) on "DID verifiable conditions" – e.g. "N of M signatures to update a DID" – https://github.com/Gimly-Blockchain/verifiable-conditions
• Other Indy Ledger Objects as DIDs (e.g. schema, etc):
  • Code and documentation:
    • https://github.com/hyperledger/indy-node/blob/master/indy_node/server/request_handlers/read_req_handlers/get_claim_def_handler.py
    • https://github.com/hyperledger/indy-node/blob/master/docs/source/requests.md
       
  • Rule: Only allow cross-ledger references for DIDs and SCHEMA – all other ledger references are assumed to be on the same ledger
    • All objects must be on the same ledger as their creating controller
    • CLAIM_DEFs may reference SCHEMA on the same or another ledger
    • REV_REG_* objects must be on the same ledger as the related CLAIM_DEF
  • Identifier adjustments:

    • NYM: did:indy:sovrin:staging:F72i3Y3Q4i466efjYJYCHM

    • Schema: "F72i3Y3Q4i466efjYJYCHM:2:npdb:4.3.4" (<nym_id>:<object type>:<name>:<tag>)
      • How do we get a namespace into the identifier?
        • I think changing the <nym_id> to a <did> would resolve it.
          • did:indy:sovrin:staging:F72i3Y3Q4i466efjYJYCHM:2:npdb:4.3.4
            • Alternative: did:indy:sovrin:staging:SCHEMA:F72i3Y3Q4i466efjYJYCHM:2:npdb:4.3.4
          • did:indy:sovrin:staging:56495   Resolver: did:indy:sovrin:staging:56495?resource=true
        • That would make it look like a DID, even though the DID is just a component.
          • Do we auto-detect the "type of DID"?
          • Presumably if "?resource=true" returns the ledger object, but what if that query parameter is left off?  Do we just return the DIDDoc of the DID?
    • CLAIM_DEF: "5nDyJVP1NrcPAttP3xwMB9:3:CL:56495:npdb" (<nym_id>:<object type>:<signature_scheme>:<schema_txn>:<tag>) 
      • Note how the SCHEMA is referenced in the CLAIM_DEF identifier – as a transaction ID.
      • Changes:
        • Change <nym_id> to <did>
          • did:indy:sovrin:5nDyJVP1NrcPAttP3xwMB9:3:CL:56495:npdb
          • Alternate: did:indy:sovrin:CLAIM_DEF:5nDyJVP1NrcPAttP3xwMB9:3:CL:56495:npdb
        • Change <schema_txn> to either
          • <schema_txn> (no change when on same ledger)
          • did:indy:<namespace>:<schema_txn> (different ledger)
          • • did:indy:sovrin:5nDyJVP1NrcPAttP3xwMB9:3:CL:did:indy:idunion:56495:npdb
            • <DID of controller>:<object type>:<signature_scheme>:<ledger of schema_txn>:<tag>
            • Alternate: did:indy:sovrin:CLAIM_DEF:5nDyJVP1NrcPAttP3xwMB9:3:CL:did:indy:idunion:SCHEMA:56495:npdb
        • Add Sequence Number DID version:
          • did:indy:<namespace>:<seqno>?resource=true
          • Do we need to also provide a DIDDoc version of the objects?  What would that look like – especially if we have to provide it as JSON-LD
  • No Changes:
    • REVOC_REG_DEF: "5nDyJVP1NrcPAttP3xwMB9:4:5nDyJVP1NrcPAttP3xwMB9:3:CL:56495:npdb:CL_ACCUM:TAG1" (<nym_id>:<ver>:<cd_nym_id>:<ver>:<sig>:<seqno>:<?>:<?>:<tag>)
    • REVOC_REG_ENTRY: "5:5nDyJVP1NrcPAttP3xwMB9:4:5nDyJVP1NrcPAttP3xwMB9:3:CL:56495:npdb:CL_ACCUM:TAG1" (<?>:<nym_id>:<ver>:<cd_nym_id>:<ver>:<sig>:<seqno>:<?>:<?>:<tag>)
       

• JSON vs. JSON-LD
  • Here's a google doc that captures my thinking. I am not so emotionally or intellectually caught up in my own perspective here that I will balk if I am out-voted, but I would appreciate knowing that a thoughtful discussion about it occurred before a decision was made. .
• The "close-to-finished" DID Method Spec – please review
  • Perhaps not close to finished – doesn't talk about other objects yet – the conversation above 
  • At risk – DNR/DND

...