...
Recording from the call: 20210413 DID Indy Specification Call Recording.mp4
Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct. |
---|
...
- 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:
- 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
- Schema:
- 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".
- For all, on right, the following rules would be enforced:
- 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
- Sort of not needed – it is included in what is returned.
- 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
- 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.
- Could return just the identifier of the object.
- Do we need to have the SCHEMA ID within the CLAIM_DEF ID?
...