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>)
      • Do we want to allow the embedded reference to the "owner" of this item to be on another ledger? My guess – no.
      • • How do we get a namespace into
        that
        • 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
      • All objects must be on the same ledger as the controller
      • CLAIM_DEFs may references SCHEMA on the same or another ledger
      • REV_REG_* objects must be on the same ledger as the related CLAIM_DEF
        • 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)
      Only allow cross-ledger references to DIDs and SCHEMA
      • • • • • 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

    • 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

  ...