October 2021 Release Notes

Another month has flown by, and we have a lot of updates to communicate. And this month our marketing team included a video too!

Read on for more details about those items. You can also find previous release notes here and other product news on our Developers page.


Document Verification in Connect.Me and our Mobile SDK

During our August webinar, we gave a sneak peek at our new partnership with Mastercard to provide document verification capability in Connect.Me and the Evernym Mobile SDK.

These new features allow users to take a picture of a government-issued identity document (such as a passport or driver’s license) and complete a facial/liveness scan to ensure the individual scanning the document matches the photo ID. If it’s a match, Evernym will issue you a digital version of the document in the form of a verifiable credential, which can be shared with verifying parties to prove basic autobiographical details. You can read more about it here.

We expect this Identity Document Verification (IDV) credential to be initially adopted in the travel and health industries where people need to tie themselves to their COVID-19 vaccination status or test results. But this credential can be used in lots of other scenarios too, such as anywhere age verification or proof of residency is required.

Identity document verification in Evernym's Connect.Me and Mobile SDK


The code is included in the next release of Connect.Me, but the functionality will be hidden until we complete user testing. We are currently in the process of adding this capability to our Mobile SDK so that it can be easily included into other digital wallets. You should contact us if you are interested in using this feature. We’ll publish more information on this new capability in the coming weeks.


New Demo Site for Learning about Self-Sovereign Identity and Verifiable Credentials

Playing with verifiable credentials is the easiest way to understand them. The concepts can be hard to explain, but using credentials in common scenarios shows that they are a natural and intuitive way to bring existing identity interactions into the digital realm—with additional privacy and security advantages.

To help people through this process, we created a new demonstration site that allows anyone to obtain example credentials and use them in everyday scenarios. Those familiar with our old demo site will notice a refreshed look-and-feel, several more credentials available to demo, additional use cases such as passwordless authentication, and advanced workflows leveraging compound proofs and newer Aries protocols.

Demo self-sovereign identity in action with TryConnectMe

The demo works in conjunction with our Connect.Me digital wallet app and walks users through a day in the life of Alice, a healthcare professional who just landed her dream job and is getting ready to embark on a new adventure. Over the course of eight demo scenarios, you’ll see how verifiable credentials can make time-consuming processes, like applying for a mortgage or checking in for a flight, faster and more secure.

You can use the site to explore the use cases that best match your interests. There is a progression through the use cases, such that credentials obtained in the first use cases can be used to fulfill more complicated use cases later on, but the order of events is up to you.

Within each use case, you’ll be prompted to make connections, receive credentials, and share proofs. The variety of use cases leverage different Aries protocols such as Connection, Issue Credential, Present Proof, Question-Answer, and Out-of-Band. The demo illustrates the end-user benefits and experience, and doesn’t require any prior knowledge of verifiable credential technology.

Over time, we will add additional use cases that leverage more of the capabilities of our products. We also hope that this site makes it easy to test interoperability between our issuer and verifier services and other credential wallets. The most common interoperability hurdles we find are differing approaches to shortened URLs in QR codes, and lack of support for connections that use the Aries out-of-band protocol. Eventually, we hope that any digital identity wallet can be used to complete the user journeys on our demo site.

We encourage you to walk through the interactive demo at try.connect.me. We’ve also put together a short video showing one of the demo modules, which shows the verification of compound proofs and use of structured messaging to offer a survey.


Verity Flow Custom Credentials

As mentioned during our August product webinar, we intend for Verity Flow, our no-code web app, to be generally available by the end of the year. It is already being used by over 1,000 COVID-19 testing laboratories that have partnered with IATA, and our current focus is on making it easy to configure the application for other use cases.

Below is a preview of the new administration panel, where admins can configure the attributes that a custom credential should have:

The administrative panel in Verity Flow

Once that panel is complete, we will build a tool for configuring the attributes requested during verification. We are also in the process of shifting the internal APIs to GraphQL, upgrading our automated test framework, and preparing the source code for publication.

You can learn more about Verity Flow and sign up for the waitlist here.


Updated Recommendation for Securing Verity Webhooks

Our flagship credential exchange platform, Verity, provides asynchronous responses by writing to a tenant’s webhook. The first adopters of Verity were instructed to secure their webhooks by whitelisting the IP addresses used by the system. Now that Verity supports OAuth2, users can deploy this additional tool to meet their security requirements. OAuth2 can authenticate Verity as the caller, whereas IP whitelisting restricts the number of potential callers which reduces the number of addresses that could be used to abuse the service through a denial of service attack.

Some users might choose to use OAuth2 instead of IP whitelisting to avoid the need of tracking details about Evernym’s infrastructure. For instance, as part of migrating Verity to a Kubernetes environment, the IP addresses that must be whitelisted will have to be changed to our SNAT addresses. As we approach the upgrade to Kubernetes, we will be asking customers to whitelist the new IP addresses and then remove the old IP addresses after the upgrade. As these addresses continue to change from time-to-time, we will keep the up-to-date address ranges in our documentation on Verity environments.

The next release of Verity will include support for OAuth bearer tokens when protecting webhooks. In the future we will provide additional options for securing webhooks that further simplify the process.


Other Updates

The cheqd network recently upgraded Test Net to enable the features they want to have at Main Net launch. The remaining work mostly involves finishing the implementation of identity transactions. After collaborating with the team at Cosmos Cash, cheqd decided to prioritize W3C-compliant DID Docs ahead of keeping a common API with Indy. The Evernym team is supportive of this move because the resulting ledger implementation will be cleaner and the API will be more consistent. But it does make it harder for us to add support for cheqd to Evernym applications, meaning our applications probably won’t be ready to use the cheqd ledger at the launch of the network. You can read more about the cheqd identity implementation in the Architecture Decision Record. Launching an identity network in less than a year requires a fast pace, and we have been so busy working with cheqd and helping validators onboard that we might not have our own node ready for Main Net at launch! To learn more about cheqd’s progress toward their vision, you can watch our recent joint webinar.

In the next release of Verity and the Mobile SDK, VDR Tools will replace the Indy SDK. VDR Tools bundles supported payment and database interfaces, eliminating the need to install separate plugins. SQLite and MySQL are both supported providers for database storage in the first release. The previous Indy SDK plugins for LibNullPay, LibSovToken, and MySQL are now deprecated.

This release of VDR Tools is backwards compatible with the LibIndy API, and will also contain experimental support for the cheqd network, including the cheqd payment interface. The cheqd API in VDR Tools is experimental as it is still evolving to match cheqd’s new DID Doc-centered ledger API. We are also adding a new experimental API that can work either with Indy or cheqd, which application developers can adopt to easily integrate with both networks.

Additional enhancements to Verity include a new URL shortener that will handle longer messages. And the team published new documentation about the internal architecture of Verity, which should help people who are interested in how Verity works under-the-hood. We will incorporate the relevant parts of this new material into the getting started documentation of the Verity SDK so that it is easy for new developers to digest.

Our long-term customers have mostly replaced their on-premise deployments of the original Verity (“Verity 1”) with the current SaaS-based “Verity 2” solution. Those customers who still need to migrate will no longer get Verity 1 artifacts from the password-protected Evernym Customer Portal, but will instead be able to find those artifacts in the Evernym LibVCX repository in GitLab. Once we have everything migrated, the legacy Customer Portal will be retired.



Stay tuned for more

We continue to move at a fast pace, so look for another full update in about a month (we are likely to adjust the schedule due to the end-of-year holidays). In particular, we’re excited to talk more about Verity Flow as we rapidly approach its launch.