Summary
Excerpt |
---|
|
Recording from the call:
Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct. |
---|
Welcome and Introductions
...
- Serialization formats
This Week's Discussion:
- 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):
- Schema: "F72i3Y3Q4i466efjYJYCHM:2:npdb:4.3.4" (<nym_id>:<object version>:<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? I think changing the <nym_id> to a <did> would resolve it.
- 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 version>:<signature_scheme>:<schema_txn>:<tag>)
- Note how the schema is referenced in the CLAIM_DEF identifier – as a transaction ID.
- 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>)
- Schema: "F72i3Y3Q4i466efjYJYCHM:2:npdb:4.3.4" (<nym_id>:<object version>:<name>:<tag>)
...