In the fourth installment of our monthly product release notes series, we’re excited to share several big updates including:
- Recent pricing changes at Sovrin
- An update on our standardization efforts
- Useful additions to the product documentation
- Automated interoperability testing
- Adapting our VDR tools for the cheqd network
Read on for more details about those items. You can also find previous release notes and product news on our Developers page.
Changes at Sovrin
On August 17, the Sovrin Foundation announced new policies and pricing for their networks.
These changes do not impact existing credentials anchored on the Sovrin networks, but they do impact how customers will write to the network going forward. The most important changes are:
- A fee will be charged on a regular basis to remain an endorser on either MainNet or StagingNet.
- In addition to the endorser fee, write fees will now be charged for transactions on Sovrin StagingNet in a similar fashion to the existing fees on Sovrin MainNet.
- The current Sovrin Self Serve website will stop being used to become an endorser on StagingNet, and instead endorsers will be charged a fee after registering.
These changes will impact our customers in the following ways:
- Our products will be updated so that new accounts will use Sovrin BuilderNet instead of StagingNet by default.
- In March 2022, existing DIDs will be disabled and customers who endorse their own transactions will need to pay the Sovrin endorser fees and write fees on StagingNet and MainNet.
- Once Evernym is charged the new fees, customers who ask us to endorse their transactions on Sovrin StagingNet or MainNet will be invoiced for the cost of those transactions including a surcharge to cover the endorser fees.
We’ll provide more information as we better understand Sovrin’s plans for rolling out these changes. Let us know if you have questions. We look forward to partnering with you to select the identity networks that best meet your specific circumstances.
Standardization Efforts
As mentioned previously on this blog, we hold leadership roles on the W3C Working Groups to standardize Verifiable Credentials and Decentralized Identifiers (DIDs) and wanted to share some quick updates from the standards community.
DIDs: The path to becoming a W3C Recommendation
The W3C DID Working Group recently completed their work and submitted the DID Core Specification for approval from the Advisory Committee. As part of the process, some Advisory Committee Members objected to proceeding with the standard. These objections are part of the normal process and do not mean that the standard will not be approved. The objectors met with the DID WG leadership to discuss their concerns, but consensus was not reached within that group on a path forward. In our opinion, the objections are based on misunderstandings of the effort and do not indicate a need for substantive changes to the specification. Coin Center published an open letter detailing some of these misunderstandings.
The next step is for the W3C Director to study the problem and make a decision. We have confidence that the W3C Director will choose to publish the DID Specification as a W3C Recommendation, rather than allow a small but vocal minority of detractors to stop or delay the work.
Implementing the Good Health Pass recommendations
We also previously blogged about our desire for broad adoption of BBS+ as the verifiable credential format of choice. We have been working with the Good Health Pass and Trust over IP communities to standardize this format in a manner that is W3C compliant, provides strong privacy protections, and is likely to receive broad industry adoption. The result of this effort is the Good Health Pass Interoperability Blueprint.
Our implementation of the Good Health Pass recommendations is expected to include support for DIDComm 2, JSON-LD credentials, BBS+ LD-Proofs and Signatures, and the DIF Presentation Exchange Format, including the interoperability profile for Wallet and Credential Interactions for Presentation Exchange (WACI PEX). Though these standards are all defined as optional parts of Aries Interop Profile 2.0, many of these specifications are not yet formalized. While we continue to work on the various committees finalizing the specifications, we believe they have matured enough for useful implementation. We also recognize some parts of the specifications could still change, and the various implementers will need to do additional testing and updates to achieve meaningful real-world interoperability.
The most important remaining work on the current iteration of the standard is to define how to do private holder binding (“link secrets” in Indy anoncreds), and how to selectively disclose without an identifier being inferred from the JSON-LD semantic context.
The future of Good Health Pass
Other concerns have been raised about JSON-LD being a part of Good Health Pass, but we don’t think they should prevent us from adopting this standard which is backed by a very large section of the decentralized identity community. Good Health Pass keeps the difficulties manageable by limiting the use of JSON-LD to canonical ordering. We can address the remaining difficulties in future versions of the specification.
We want to see future iterations of the standard include some of the recommendations from Sam Smith, which we think will increase the adoption of Verifiable Credentials. We also expect future versions to further improve privacy during selective disclosure and add support for zero-knowledge proof (ZKP) predicates similar to what exist in Indy today. We are excited to be part of the group making progress on these initiatives in the Applied Cryptography Working Group at the Decentralized Identity Foundation.
Documentation and Samples
We’ve also published several useful additions to our documentation:
- Guidance on selecting either the Verity SDK or REST API;
- Details about the size of a credential;
- A tutorial for using the SSI Authentication Demo application;
- An explanation about the different Verity environments;
- A how-to for creating “multi-tenant” applications; and,
- An improvement to the REST API Sample Web App pages for issuance and setting up a proof to use text fields to enter attribute values instead of requiring them to be entered as a JSON string.
Automated Interoperability Testing
In August, we mentioned our work to confirm that Connect.Me works with credentials issued by ACAPy, IDRamp, and Trinsic. We also confirmed that Verity works with ACAPy and the mobile wallets from Trinsic and Lissi for both issuing and verifying credentials. Our goal at the time was to integrate the Aries Agent Test Harness in our pipelines to automatically test compatibility on an ongoing basis.
This effort was harder than we expected, and we ended up having to move on without finishing it. We think the Test Harness is well thought out, and we appreciate how responsive the Test Harness team was in modifying the approach to testing transitional protocol states in order to work with Verity. But then we struggled because the Test Harness uses docker-in-docker, which isn’t supported by GitLab CI runners—forcing us to reassemble the Test Harness components as GitLab services. We had to be cautious not to allow the Test Harness to pull resources from its GitHub repo which could result in our pipelines being unstable. Mobile testing was also a struggle, as we couldn’t get it to drive our UI test tools. The existing vcx backchannel used to work with our Mobile SDK when we used the Hyperledger Indy SDK, but appears to be out-of-date. The newer aries-vcx backchannel is more current, but is still an unmerged pull request.
We discussed our concerns with the maintainers of the Aries Test Harness, and we decided we need to come back to this effort at some point in the future. We contributed a basic backchannel for Verity, which currently only tests the connection protocol for certain roles. The backchannel uses the NodeJS APIs to drive Verity, and includes a Docker image that has all the resources necessary to run it. In the future, we would like to add additional protocols so that developers of other products can easily test compatibility with Verity.
VDR Tools and cheqd
We have renamed the VDR Tools library from “libindy” to “vdr-tools,” and it now builds for the environments needed to integrate into Verity and the Mobile SDK. We are grateful to the team at Absa who collaborated with us on Hyperledger Indy and Aries VCX, and are now helping to improve VDR Tools by contributing an interface to consume VDR Tools from another Rust crate and a dependency upgrade.
We also continue to make progress in adapting VDR Tools for the cheqd network. cheqd’s Cosmos API is a lot different from the API previously used by Indy, so we implemented a higher level API that will make it easy for application developers to send requests to either network. This new API is designed to be sufficiently generic to support with minimal changes any additional ledger types that we might want to add in the future. We’re interested in your feedback as you play with the library.
The cheqd network continues to grow, with 14 validators in consensus on the Test Net. They recently upgraded to the latest Cosmos and updated the network parameters based on feedback from the validator community. We at Evernym are keen to get our applications working on that network.
Until next month
We have more that we’re excited to share, but we’ll hold back for the next post as this update is pretty long already. We have a lot of exciting announcements planned for October, so look for another Product Release Notes near the end of the month.
