June 2022 Release Notes

Time flies when you join a new organization! We’ve been relatively quiet since our acquisition by Avast, but that’s not to say we haven’t been working very hard on the future of digital trust. Over the coming months, we’ll share more about Avast’s plans over the official Avast channels, but in the meantime, we’d like to share some quick updates on the Evernym product stack and the SSI community in general.

In this update, we will discuss:

As usual, you can find more information in our previous release notes and on our Developers page.


Evernym, SecureKey, and Avast combine to form one Digital Trust team

Since our last update, the former Evernym team has become further integrated with our new colleagues at Avast – including the SecureKey team, which Avast acquired in March. Together, we’re setting out to empower consumers with control over their data and to help businesses unlock the benefits of digital trust.

We have previously enjoyed collaborating with members of the SecureKey team at Hyperledger Aries, the Decentralized Identity Foundation, and the Trust over IP Foundation, and we are excited that we can leverage their open source Trustbloc project and Aries Framework Go to improve our platform for issuers and verifiers.

We’re also delighted to announce that Avast is continuing the work that Evernym and SecureKey have put into the SSI community and have renewed our memberships in ToIP, DIF, and Hyperledger under the Avast brand.

As mentioned previously, we’ll be able to share more about our new work at Avast over the coming months. In the meantime, there are several great posts on the Avast blog that show the combined thinking of the Avast, Evernym, and SecureKey teams:


In-Person Conferences

Conference season is in full gear, and our team has been able to attend many of our favorite conferences now that they’re mostly back to physical events.

This month, we spoke at Identiverse, MyData, Consensus, Collision, and the European Blockchain Convention. We also attended Money20/20 Europe, which is increasingly becoming a digital identity event.

Other big events this quarter included:

  • Internet Identity Workshop (IIW): We attended the first in-person IIW since Covid. Though meeting online over the last two years has been useful, collaborating face to face allowed us to dig into sticky issues that have been hard to resolve. Interoperability between vendors was a recurring topic, and there were a number of discussions about how technologies like KERI and Orb can reduce an issuer’s dependence on a specific ledger. The former SecureKey team explained why GNAP is a helpful evolution of Oauth and OpenID Connect. And we heard several updates from our partners at GLEIF about how vLEIs are emerging as important tools for organizations in a variety of use cases.
  • European Identity & Cloud Conference (EIC): EIC was our first major conference as a blended Avast team and offered an ideal stage for sharing our vision for digital trust. Our General Manager, Charlie Walton, presented a keynote on the empowered consumer and the next era of digital identity, while our colleagues Jamie Smith and Drummond Reed presented sessions on the shifting digital identity landscape and Trust over IP. We were also honored to be part of the NHS project that won the award for Verifiable Credentials and Decentralized Identity.

July and August are normally pretty quiet in terms of events, but we’ll be back on the circuit in September/October with the Open Source Summit, Hyperledger Global Forum, Rebooting Web of Trust, Future of Retail, Identity Week US, and Money20/20 US. If you’re attending any of these and would like to meet, please email us at identity@avast.com


An update on Sovrin

As Sovrin announced in August 2021, StagingNet Endorser DIDs will only retain their “Endorser” role for 6 months. As a result, Endorser DIDs on Sovrin StagingNet were disabled in March. Our customers who prefer to endorse their own transactions need to work directly with Sorvrin to maintain their Endorser rights. Those who do not want to work with Sovrin can continue to work directly with us, as we will continue to endorse transactions on behalf of our customers to ensure that they can use the Sovrin ledger.

Sovrin leadership have stated that they do not want companies using BuilderNet for development, so our products will continue to only use Sovrin StagingNet and MainNet. Soon our products will support other DID storage methods so that our customers can select the approach that best meets their needs.


Your questions, answered


We have recently received a number of questions about revocation, so we will briefly cover best practices here.

Evernym contributed to Hyperledger Indy an implementation of privacy preserving revocation using accumulators and a tails file. Though our VDR Tools and VCX libraries support this approach, we did not implement this in our products as we found scalability problems beyond tens of thousands of credentials when the tails file grows too large to manage on a mobile device. Sharding can help, as can defining fine grained credentials, or delegating the proof of non-revocation to a cloud agent. But we instead collaborated with the Indy community on a novel approach that replaces tails files with merkle trees. Our testing of a merkle tree based revocation registry showed that the calculations and storage requirements are feasible for most smartphones, but we paused our efforts when Mike Lodder proposed an alternative approach that could eliminate tails files completely at the cost of more frequent communication with the ledger to track changes in the accumulator state. The DIF Applied Cryptography Working Group continues to explore various approaches, and we look forward to adopting an interoperable, privacy-preserving approach to revocation when it exists.

If credential issuance and verification are performed by the same organization, or if the issuer and verifier have a business relationship, then customers can implement a centralized revocation registry. In this approach, you would store revoked credential serial numbers in a trusted store which can be checked by verifiers without notifying issuers. This can be achieved by:

  • including a serial number as an attribute in a credential;
  • checking the serial number against the revocation list when you receive a proof.
  • Optionally, you can include logic in your mobile wallet to compute the proof of non-revocation using your revocation registry which can be checked by the verifier. The Evernym Mobile SDK can be extended for this purpose.

This approach would not be appropriate in many circumstances, as the operator of the revocation registry could monitor credential usage and the credential serial number could be used to track holders or reveal the status of the credential validity to a third party observer.

Another approach is to include a “time” attribute (e.g., “effective revocation date & time”) in a credential. Verifiers will then be able to check against this expiration date at the verification time. This works well in scenarios where credentials are intended to be short lived, such as with a Covid test.

SecureKey’s TrustBloc product supports W3C Revocation Status List 2021. This approach is better than existing alternatives in many scenarios, and we expect to integrate this capability across our products while continuing to work on other approaches. We are also exploring improvements to the revocation status list approach that will increase the privacy protections and which could make it appropriate for enough use cases to replace accumulator based revocation registries.

Guardianship and Delegation

Similar to revocation, guardianship and delegation are major gaps in applying verifiable credentials to many real-world use cases which people regularly ask us about.

This webinar from December of 2019 is an excellent introduction to the topic. It will help you understand different aspects of the problem, and approaches that can be used in many scenarios today. If it is acceptable for the issuer to be involved in transferring a credential, then many use cases can be modeled with existing VCs. Similarly, DIDDoc annotations can be used to define scopes of guardianship and delegation, and transferred on a peer-to-peer basis.

For more complex use cases, we envision chained credentials similar to chaining in X509 certificates. We are very interested in the work the GLIEF team is doing on a credential format called Authentic Chained Data Containers (ACDC) that helps to address their use case of employees acting on behalf of their organizations, but we still need to validate that it will work at scale.

We are happy to collaborate with you in designing a credential solution that will meet your specific use case.

Managing Multiple Architectures on Android

We added a section to the Mobile SDK FAQ that explains how to manage APKs for multiple architectures on Android so as to minimize your maintenance effort.

QR Code Changes in Sample Apps

Recent changes to ngrok prevent displaying QR codes via an ngrok URL, so we updated our sample applications to output invitation URLs with instruction to use an external QR code generator.



As mentioned, we’ve been relatively quiet and should have more to share on our product roadmap in the coming months. We continue to be impressed with the greater Avast team and their commitment to privacy, security, and digital freedom, and we’re excited about what the integration of Avast, Evernym, and SecureKey mean for the adoption of decentralized identity. We believe our combined team can deploy modern identity solutions on a scale beyond any other vendor.

In the near future, we’ll start to migrate over to some new Avast Digital Trust Services communication channels. For now, though, the best way to stay up to date is to follow Evernym on LinkedIn and Twitter.