Summary
| Excerpt |
|---|
|
Recording from the call: <ToBeAdded>
|
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
...
- Stephen Curran
- Daniel Bluhm(Indicio PBC) <daniel@indicio.tech>
- Paul <paul.bastian@bdr.de>
- Lynn Gray Bendixsen(Indicio PBC) <lynn@indicio.tech>
Collaboration Channels
indy-did-method on RocketChat - https://chat.hyperledger.org/channel/indy-did-method
indy-did-method on Discord - https://discordapp.com/channels/905194001349627914/941708981825576960- Invitation: https://discord.gg/hyperledger
- indy-did-method repo using SpecUp
- Published specification: https://hyperledger.github.io/indy-did-method
...
- Update from the implementation team
- Implementation Plan: https://hackmd.io/@dbluhm/did-indy-impl
- Is there a better place for this document?
- DID Doc support is well defined
- Investigation into required changes for resolving AnonCreds objects is ongoing
- Walked through the process of adding the DIDDocContent to NYM
- Assessment so far – no need for separate storage
- Dominic's branch was very useful – especially on version
- New take on self-certifying DIDsStatus of the plan? Phase 1 deliverable.
- Implementation Plan: https://hackmd.io/@dbluhm/did-indy-impl
- GitHub PRs for review
- 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?
- For implementers to determine:
- What would it mean to not have the schema on the same ledger? Is that easy to do?
- Possible solution: Have endorsers require that they verify the schema on another ledger exists.
- Daniel Bluhmand team to review and come back with a decision.
- Previous discussion:
- Possible: Put a reference on NetworkB to schema on NetworkA
- Idea: Inter Blockchain Communication Protocol (IBC Protocol) - genesis transaction from NetA on NetB, when write reference to Schema from A to B, can include state proof
- NetworkB becomes a client of NetworkA
- CLAIM_DEF MUST reference the local instance of the SCHEMA
- Extend definition of SCHEMA to include an optional reference to the original schema (DID URL and state proof from other ledgers)
- Idea: Put this as future work? Put this in as a consideration for issuers.
- Don't allow for now – future work to enable cross-ledger references
- Allow but do no extra checking – future work to constrain
- Idea: Don't allow Claim_Def to reference object on another ledger – schema MUST be on the same ledger.
- Options:
- Do nothing, allow this and ignore the "network can go away" issue.
- Do nothing, don't allow this.
- Don't allow, but allow some way to have a local copy of the schema.
- For implementers to determine:
- 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
- Create an Indy HIPE that points to the spec.
- Define the backlog of tasks:
- indy-node
- indy-plenum
- indy-vdr
- universal resolver image