...
Excerpt |
---|
|
Recording of Call: 20220201 Indy Contributors Call Recording.mp4
Chat from Call:
- 08:10:56 From Daniel Bluhm : Link to the agenda: https://wiki.hyperledger.org/display/indy/2022-02-01+Indy+Contributors+Call
- 08:17:57 From Lynn Bendixsen : I think it might be because of key rootation...
- 08:21:55 From Markus Sabadello : "The meaning of colons in the method-specific-id is entirely method-specific. Colons might be used by DID methods for establishing hierarchically partitioned namespaces, for identifying specific instances or parts of the verifiable data registry, or for other purposes. Implementers are advised to avoid assuming any meanings or behaviors associated with a colon that are generically applicable to all DID methods. "
- 08:23:45 From Christian Bormann : https://github.com/hyperledger/indy-did-method/issues/30
- 08:24:49 From Paul Bastian : I like it
- 08:35:26 From Paul Bastian : I'm thinking if it makes sense to squash anoncreds/v1/<object_type> to a single path like anoncredsv1_NYM if you would evolve only certain objects to next generation
- 08:47:31 From Richard Esplin : Referencing a schema on another ledger seems like a bad practice and should be discouraged.
- 08:48:30 From Mirko Mollik - TrustCerts : I think ist really cool since you can treat it as the hosted one on Schema.org
- 08:49:17 From Richard Esplin : Until the schema changes unexpectedly. Sam Smith pointed out how it changes the attack surface of the solution.
- 08:49:34 From Sam Curren (TelegramSam) : we can require imutability?
- 08:49:54 From Richard Esplin : Then what is the value of it being somewhere else instead of working with a copy on your ledger?
- 08:50:11 From Mirko Mollik - TrustCerts : Correct, you depend on another ressource
- 08:50:23 From Richard Esplin : The approach of BBS+ to bundle the schema with the cred is the right solution.
- 08:50:51 From Mirko Mollik - TrustCerts : but if it is the trusted network of the Government, it can be treated as the Standard. E.g. for University Degrees.
- 08:51:08 From Sam Curren (TelegramSam) : it means it's the same object, and can be referred to by governance frameworks etc.
- 08:52:38 From Mirko Mollik - TrustCerts : Even when you make your Schema not immutable, you can reverence it with a Version time and a hash. We did this with JSON-LD schemas, addressing them with DIDs and a Version time and hash
- 08:53:21 From Sam Curren (TelegramSam) : Mirko it does require trust that it will consistently resolve.
- 08:57:34 From Dominic : I think weekly would be good
- 08:58:05 From Daniel Bluhm : Agreed, judging from how long it took to discuss issues today
Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct. |
---|
...
- Update on CI/CD Update and Ubuntu Upgrade: Status Document
- Indy-Plenum Status:
- Done, 16.04, 20.04, Jenkins and GHA
- Indy-Node Status:
- Done, 16.04, 20.04, Jenkins and GHA
- One 20.04 running in the IDUnion network of 16.04 nodes
- Preparing and executing the automated release process.
- indy-test-automation Status:
- Circular dependency broken.
- Developer tools
- indy-node-container (move to Hyperledger in progress) and GitPod tools available (node and plenum)
- On plenum – error with building the dev containers about Indy SDK version – need to get the metadata version correct (https://github.com/hyperledger/indy-sdk/issues/2473)
- Indy-SDK build progress
- Unblocked – builds are going and PRs are being reviewed (and rebasing PRs).
- Indy-Plenum Status:
- "did:indy" DID Method
- Pull Requests:
- New method for self-certifying NYMs - #27 - updated per discussion last meeting
- Change to use SHA-256, but use the full public key as input
- Decision: Go ahead and merge.
- Proposal - change the separator for the sub-network from ":" to "." - #31
- Decision: No based on Markus's input in the comments:
- "The meaning of colons in the method-specific-id is entirely method-specific. Colons might be used by DID methods for establishing hierarchically partitioned namespaces, for identifying specific instances or parts of the verifiable data registry, or for other purposes. Implementers are advised to avoid assuming any meanings or behaviors associated with a colon that are generically applicable to all DID methods. "
- Decision: No based on Markus's input in the comments:
- Fix Typos - #24 – Decision: go ahead and merge.
- Newly Merged: Add the new Indy DID method to the W3C registry: https://github.com/w3c/did-spec-registries - #393
- New method for self-certifying NYMs - #27 - updated per discussion last meeting
- Discussion topic - referencing non-DIDs via DID Indy and other DID Methods
- Restricting the <namespace> part of the DID to lower case #30 – yes!! Christian Bormann to PR
- Issue raised to adjust the method: #32 – agreed to use the revised approach – Daniel Bluhmto PR
- Simple Issue: Change format from
<did>/<object-type>/<object-type-identifier>
, to<did>/anoncreds/v1/<object-type>/<object-type-identifier>
- Simple Issue: Change format from
- Related issues (raised in comment):
- Is this the best approach from a DID Resolution perspective? – Response: this is good.
- What object would we expect to get back from such a DID resolution? Presumably an object of the desired type, but should it be a DIDDoc with the object embedded?
- Easy for did:indy, but for the broader use of AnonCreds, will this work with other DID Methods?
- Response – good ahead for did:indy and as a part of the AnonCreds work, determine what else can be done.
- Easy for did:indy, but for the broader use of AnonCreds, will this work with other DID Methods?
- Would other common DID Methods be able to support this? E.g. What other DID Methods are important for AnonCreds and could they support this approach?
- Response – Leave this issue for the AnonCreds discussions.
- Not Discussed:
- Restricting the <namespace> part of the DID to lower case #30
- Issue: If Indy SDK is not updated, how do we run the Indy Node/Plenum tests?
- Ideas are brewing on this...
- Issue: If Indy SDK is not updated, how do we run the Indy Node/Plenum tests?
- Pull Requests:
Future Calls
- Ideas for "Good First Task" for the Indicio class coming up in two weeks
- Issues that could impact indy-node on 20.04
- indy-sdk: needs an upgrade to OpenSSL 1.1 to properly support Ubuntu 18.04/20.04. For indy-node, just using indy-sdk as is.
- Multiple libsodium versions could impact consensus – intermittent issue on a mixed network.
- Plans for a new Indy-SDK release?
- A few people from the community have asked.
- The most recent request has been for a release to include this feature; https://github.com/hyperledger/indy-sdk/pull/2400
- Focus: Indy Generation Next
- Audience: Organizations building Indy Instances, applications built on Indy
- Not going for casual, independent developers, more on organizations that can assign developers to work on the project for a set chunk of time (e.g one month)
- Key Features:
- Indy network of networks support
- Indy support for W3C DID Standard 1.0
- Tasks:
- Update NYM to support new "diddoc_content" data element
- Indy-sdk, indy-vdr support for new "diddoc_content" data element
- Indy DID Resolver support for new "diddoc_content"
- indy-sdk, indy-vdr support for multiple ledgers
- Support for new ledger object identifiers
- Handling cred_defs that references schema on other ledgers
- Possible: support for NYM "keri_keystate" data element, indy-sdk/indy-vdr support and DID resolver support
- Other?
- Foundational Work:
- did:indy spec. as a spec.
- Tasks in GitHub Issues - tagged for campaign
- Getting started with developing indy-plenum and indy-node
- Tutorial: Sample feature to add to indy-node
- Example: rich schema feature flag
- Tutorial: Sample feature to add to indy-node
Campaign work - Landing page
- Video: Intro to Indy Generation Next Meetup channels
- Status of Indy-SDK
- Statement on the future of the Indy SDK: PR 2329
- Plans for future of Indy CLI (move to Indy VDR?)
- Indy SDK in test for Indy Node (move to Indy VDR?)
- Status of GitHub Actions for the Indy-SDK
- Indy bugs
- Using GitHub tags "Good First Issue" and "Help Wanted"
- Node 1490: problems with large catch-up
- Plenum 1506: view change message consensus calculation error
- Hyperledger campaign to recruit additional developers.
...