Summary

  • Status of indy-node CI/CD and the Ubuntu upgrade
  • did:indy PRs
  • Discussion Topic: did:indy resolution of non-DIDs – schema, etc.

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.

Welcome and Introductions

Attendees

Related Calls and Announcements

  • Upcoming Indicio course on Indy Node development - this Thursday
    • URGENT: Finding "good first issues" on the Indy Node and Indy Plenum repos - please take a look!!
  • AnonCreds standardization work has begun. Next meeting is by invite and then we'll have a charter and next steps.

Release Status and Work Updates

Meeting Topics

  • 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).
  • "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. "
      • 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
    • 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>
      • 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.
        • 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:
      • Referencing (or not) the network of the DID in NYMs and in DIDDocContent put on the ledger - Issue #33
      • Verification of the self-certification of a DID - Issue #23
      • Issue: If Indy SDK is not updated, how do we run the Indy Node/Plenum tests?
        • Ideas are brewing on this...

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?
  • 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.

Action items