Summary

Recording from the call: dummyfile.txt

Welcome and Introductions

...

• Serialization formats

This Week's Discussion:

• DIDDoc Construction:
  • Generate template and merge in diddocContent if present, or
  • If diddocContent is present, it is the DIDDoc – check to be sure that the NYM key is in the DIDDoc
  • Good idea? At minimum, we need to be able to add elements of diddocContent to all of the NYM-based DIDDoc
• 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 require namespaced ledger references for DIDs, CLAIM_DEFs, and SCHEMA. Implications:
    • 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
  • Add resource resolution via Sequence Number: did:indy:sovrin:56495?resource=true, which returns the ledger object at that location
    • A resolver would call the existing GET_TXN Indy call.
  • Change identifiers outside of the ledger to the following:
    
    • Schema: did:indy:sovrin:F72i3Y3Q4i466efjYJYCHM/SCHEMA/npdb/4.3.4
    • Claim Definition: did:indy:sovrin:5nDyJVP1NrcPAttP3xwMB9/CLAIM_DEF/npdb
    • Revocation Registry Definition: did:indy:sovrin:5nDyJVP1NrcPAttP3xwMB9/REV_REG_DEF/npdb/TAG1
    • Revocation Registry Entry: did:indy:sovrin:5nDyJVP1NrcPAttP3xwMB9/REV_REG_ENTRY/npdb/TAG1?version_id=12345
      • Note that the Rev Reg Entries all have the same name, but are actually deltas – meaning that all are necessary in doing a proof of non-revocation.  The data needed across the transactions are picked up using the transaction: GET_REVOC_REG_DELTA
  • In the examples above, the items after the object type are all controller (client) defined.
    • For all, on right, the following rules would be enforced:
      • For Schema, Claim Def and RevReg Def, duplicates are NOT permitted on the ledger (pre-write check).
      • For RevReg Entry, duplicates are allowed as they are deltas – e.g. all are "live".
  • Questions:
    • Do we need to have the SCHEMA ID within the CLAIM_DEF ID?
      • Sort of not needed – it is included in what is returned.
        • The current GET_CLAIM_DEF call includes the SCHEMA ID as a parameters.
        • Need to change <TBD>
      • However, the Schema is returned as "Ref" and is the sequence number for the schema on the current ledger
      • That would need to be adjusted
    • Could we use a path for the object, e.g: did:indy:sovrin:5nDyJVP1NrcPAttP3xwMB9/3/CL/56495/npdb
      • New Transactions: did:indy:sovrin:5nDyJVP1NrcPAttP3xwMB9/CLAIM_DEF/npdb
      • Legacy Transactions: did:indy:sovrin:CLAIM_DEF?id="5nDy..:3:CL:56495:npdb"
        
      • did:indy:sovrin:F72i3Y3Q4i466efjYJYCHM/SCHEMA/npdb/4.3.4
      • did:indy:sovrin:5nDyJVP1NrcPAttP3xwMB9?CLAIM_DEF=npdb
      • did:indy:sovrin:F72i3Y3Q4i466efjYJYCHM?SCHEMA=npdb:4.3.4
    • What does a minimal DIDDoc look like that we could use if we reference on object without "resource=true" or with "resource=false"?
      • Could return just the identifier of the object.
         

• 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.
    • Link to Google Doc
• 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, KERI

...