Summary
| Excerpt |
|---|
|
Recording from the call: 20220215 Indy DID Method 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. |
|---|
Welcome and Introductions
...
- Update from the implementation team
- Implementation Plan: https://hackmd.io/@dbluhm/did-indy-impl
- GitHub PRs for review
- Discussions: Dealing with the Indy SDK while testing Indy Node and self certifying DIDs transition – from Daniel Bluhm
- For transaction creation, we can sidestep this problem without too much trouble. The general workflow is build transaction then prepare and send transaction. We simply insert into that workflow modifying the transaction before preparing and sending or just create a transaction object directly. The volume of transactions that we'd need to modify to test the new behavior is low enough that this is not burdensome. However, you could call this technical debt simply due to it being a special case that doesn't look the same as the other tests. I consider this an acceptable trade off in the short term. The changes to the ledger are also backwards compatible with the structures generated by the SDK meaning current deployments depending on the SDK will not be broken by updates to the ledger.
However, the new DID self-certification requirement is low key the biggest breaking change in compatibility with the SDK. All DIDs generated by the SDK and newly published on the ledger are considered invalid. This has implications for both the tests and current deployments. For one thing, all of the many tests (virtually all of them) dependent on the generation of a DID that can be written to the ledger break with the self-certification requirement.
Anyone have thoughts on a migration plan? Do we make enforcement of self-certification configurable and allow each ledger to decide when to flip the switch? Is that something that should be configured through the config ledger or statically?
- GitHub Issues for review
- Leftover from the last meeting (a long time ago...)
- DECISION NEEDED: Schema on NetworkB, Claim_Def on NetworkB; NetworkA goes away. Can a holder proof/verify from a credential?
- Decision: For now, Indy will only support Schema on the same ledger as Claim Defs, etc.
- DECISION NEEDED: Schema on NetworkB, Claim_Def on NetworkB; NetworkA goes away. Can a holder proof/verify from a credential?
- To Do:
- How far to take a DID Resolver in indy-vdr vdr – decided:
- Create an Indy HIPE that points to the spec.
- Define the backlog of tasks:
- indy-node
- indy-plenum
- indy-vdr
- universal resolver image