Although it’s only been a month since our last release notes, our team’s been hard at work and we have a lot to share with you today.
You can find our comprehensive developer update below, but most notably:
- Verity continues to improve, and we are developing a new no-code web application called Verity Flow. (learn more)
- Connect.Me 1.6 is available to those enrolled in the public beta program. (learn more)
- Evernym’s Mobile SDK now also includes a React Native white-label application. (learn more)
- We are publishing the source code for our products to GitLab.com/evernym, where you can find useful documentation and collaborate with us. (learn more)
- Evernym VDR Tools is a new project that will make it easier for our products to interoperate with credentials from other vendors. (learn more)
Read on for more details about those items. You can also find previous release notes and product news on our Developers page.
Verity & Verity Flow
The organization of the Verity code repository is undergoing significant changes, as we are moving to a multi-node Kubernetes deployment using Helm charts and Terraform. This will make it easier for us to scale and manage Verity, reducing downtime during maintenance and upgrades. But it will also make it easier for interested developers to run the Verity code outside of AWS.
The Verity API has recently been extended with a parameter for specifying your own endorser for writing to the Sovrin network. Verity also now supports a per-tenant configuration defining the data retention policy. The configuration describes how long protocol messages should be stored and kept. The lifetime of incomplete protocol messages can be separately specified. This flexibility allows Verity to meet diverse customer requirements. For now, the configuration has to be set by Evernym support, but we plan to add administrative APIs to control it directly.
The availability of Verity Flow means that we can now deprecate the legacy Verity UI that was included in Verity 1 for demonstration purposes. Users of Verity 1 can upgrade to Verity 2 and Verity Flow, or can meet custom use cases by building off of the Verity 2 sample applications.
You can sign up for the Verity Flow waitlist for more updates on this product.
Mobile Products: Connect.Me & the Evernym Mobile SDK
[ Connect.Me is our free digital wallet product, available for both iOS and Android. The Evernym Mobile SDK enables developers to white-label Connect.Me and integrate digital credential capabilities into new or existing mobile apps. ]
Connect.Me 1.6 was recently released to the public beta program and is expected to become the default download before the end of the month. This release contains a number of improvements to the application’s styling and behavior with intermittent network connectivity. You can sign up for the public beta by clicking the link for your mobile operating system.
Developers using the Evernym Mobile SDK will be interested to see that there is a React Native White Label Application that makes it easy to produce your first SSI-powered mobile app. This application has much of the behavior of Connect.Me, without the Evernym branding or Evernym specific functionality. Developers in our beta program knew this application as the “React Native Mobile SDK,” but we ultimately decided that calling it a “White Label Application” better describes its purpose and how to use it.
We recently completed publishing the source code for all of our released products to GitLab.com as part of our participation in the eSSIF-Lab (funded by a grant from the European Union’s Horizon 2020 research and innovation program agreement No 871932). We chose GitLab because we like the integration with our internal build and deployment systems. Our key repositories will be mirrored to GitHub, but any collaboration with us needs to be done through the source repositories at GitLab.com. These repositories are either licensed under the Evernym Business Source License or under the liberal Apache 2 open source license. If you feel inclined to contribute an improvement to our repositories, you can submit a merge request. Our CLA Assistant bot will prompt you to accept the Evernym Contributor License Agreement in a comment on the merge request.
Each public repository contains a “/docs” folder with the documentation for that product. Though having the documentation with the source code makes it easier to keep it up-to-date and find related nuggets when searching for answers, we do plan to publish the documentation in an easy-to-use format alongside our reference documentation for developers. Documentation that applies to multiple projects is in a repository named general-docs. That is where you will find the Customer Manual, which contains guidance for interacting with support and reporting security concerns. This is also where we document policies such as our weekly SaaS maintenance window (on Wednesdays from 04:00-5:00 UTC).
Real world interoperability across digital identity solutions is a common theme of this blog, such as the proposal for interoperability that we floated last year. Previously, we targeted Aries Interop Profile version 1 as part of our collaboration with other vendors at the Trust Over IP Foundation. We initially proved this interoperability by passing the Aries Protocol Test Suite, which provides reference tests for core Aries functionality. We then completed peer-to-peer testing with 5 other vendors and the Aries Cloud Agent Python project (ACAPy). Interoperability is hard to maintain as applications evolve, so we are in the process of adding backchannels to both Verity and the Mobile SDK for the Aries Agent Test Harness that will make it easier to test interoperability on an ongoing basis. This effort has helped us to diagnose and fix a number of interoperability issues with open source projects and commercial products.
Another important type of interoperability is the ability to work with credentials that are not on Sovrin MainNet. You’ll see this capability first in our mobile applications and later in Verity. We will initially support multiple Indy networks, then we will support Cosmos-based DID networks because they will use an API similar to Indy. Finally, we will expand our support to any network offering W3C style DIDs and credentials that are network independent.
To make it easy to support lots of credential networks in a single application, we forked Hyperledger Indy SDK to create a new Evernym project called Verifiable Data Registry Tools (VDR Tools). We were the original authors of the Indy SDK, and we have enjoyed our collaboration with the Hyperledger community on that project. But as adoption has grown, it has been difficult to find a common vision for that project, which led to community fragmentation. The ACAPy community split out the ledger functionality as indy-vdr and adopted a different architecture for key storage in aries-askar. Our VDR Tools is still very similar to Indy SDK (we still need to update the naming of project artifacts). The key change is that it integrates Rust async/.await to improve the threading model according to our proposal in 2020, but which other Hyperledger contributors considered too complicated. Over time, it will support non-Indy ledgers and new credential standards such as those adopted by the Trust Over IP Good Health Pass. VDR Tools will remain Apache licensed and we are happy for others to use it, but we will tailor its architecture and features to support our applications in order to meet the needs of our customers.
One of these changes will be to pull Evernym LibVCX out of VDR Tools into a separate repository. This is similar to what the Hyperledger community has done with aries-vcx, but their goal is to make an enterprise issuer / verifier whereas Evernym LibVCX is the core of our Mobile SDK. Evernym LibVCX used to be the core of our Verity 1 product, but it is not a part of Verity 2, so we can make changes to better adapt it to mobile use cases that previously weren’t possible.
Even though we are no longer participating on the Hyperledger Indy SDK, we are still Hyperledger members and continue to contribute to Indy, Aries, and Ursa. Specifically, we are part of the team upgrading Indy to support Ubuntu 20.04. We appreciate our collaboration in Hyperledger, and we look forward to also collaborating with those interested in using VDR Tools and our other public projects.
We hope this regular update provides insight into the evolution of our products, how to collaborate with us, and what to expect in the future. If you have any thoughts or questions, don’t hesitate to reach out.