Summary
Excerpt |
---|
|
Recording from the call: <to be added>
...
- None
This Week's Discussion:
Unresolved question from the network Discovery process:
- Should we document in the DID Indy Method Spec. the centralized publishing of ledger config files?
- All the publishing of ledger config files in a known place – e.g. github – and under the control of an entity such as Hyperledger or DIF
- This is centralized control because the maintainers accept the PRs that update the data
- Decision: Do we want to propose a location to publish config files?
- If yes, Decision: Where?
- All the publishing of ledger config files in a known place – e.g. github – and under the control of an entity such as Hyperledger or DIF
Demo - resolving with version-id and version-time
From Dec. 1 Meeting about NYMs / ATTRIBs and DIDs / DIDDocs
- DIDs / DIDDocs and NYMs / ATTRIBs - Discussion summary from last week:
- No one likes the "don't change" Indy limitation – we'll have to change Indy to ensure consistency.
- No on likes the possibility of inconsistent results from non-transactional (in the database sense) updates to separate ledger objects.
- Desire is to have the NYM controller information in the DIDDoc either by the ledger verifying it is there or by injecting it during the writing or resolution.
- Questions:
- Should this be automatic (injected into the DIDDoc) or a MUST for the DID writer?
- If automatic should it be on writing or resolution?
- How would that impact signatures on transactions?
- If the DIDDoc has in it multiple signature requirements, does Indy enforce that? How would that merge with Indy permission rules (e.g. endorser+author to write object)
- Questions:
- Need to make sure that an ATTRIB-less NYM continues to resolve to a DIDDoc – can't lose that.
- Decision: Should an ATTRIB-less NYM return a DIDDoc conforming to (or aligning with) the did:key specification?
- Decision: Should a DIDDoc be assembled from just the ATTRIB, from the NYM+latest(ATTRIB) (could be a specific ATTRIB version) or from the NYM+set(ATTRIBs)?
- General feeling is not just the ATTRIB – can't separate out the NYM controller information
- My feeling is that assembling for a set of DIDDocs makes resolution more complex than necessary. For example, this requires rules about how to replace sections when merging ATTRIBs. Doable, but requires complexity that I think is unnecessary.
- General feeling is not just the ATTRIB – can't separate out the NYM controller information
- Decision: Does any assembly of the DIDDoc occur by the ledger, or does the ledger return the pieces to an external resolver that assembles the DIDDoc?
Demo - resolving with version-id and version-time
Unresolved question from the network Discovery process:
- Should we document in the DID Indy Method Spec. the centralized publishing of ledger config files?
- All the publishing of ledger config files in a known place – e.g. github – and under the control of an entity such as Hyperledger or DIF
- This is centralized control because the maintainers accept the PRs that update the data
- Decision: Do we want to propose a location to publish config files?
- If yes, Decision: Where?
- All the publishing of ledger config files in a known place – e.g. github – and under the control of an entity such as Hyperledger or DIF