As we start a new year, we’re proud to share a few updates on what our team has been working on. In this post we’ll update you on:
- Evernym’s new home at Avast
- The launch of cheqd
- Verity infrastructure upgrades
- Improvements to our mobile products
- An update on interoperability
- Progress on Verity Flow
Evernym Acquired by Avast
In December, we announced that Evernym was in the process of getting acquired by Avast. That deal has since been completed, and we couldn’t be more excited about what’s ahead.
Avast’s mission of “protecting digital freedom for everyone” is a clear extension of Evernym’s founding mission and one we are proud to advance together. We’re confident that our new home at Avast will allow us to drive the adoption of self-sovereign identity at a pace and scale that we couldn’t before.
cheqd is Launched
We are also proud of our involvement in the launch of the cheqd network.
This is a significant milestone toward the vision we laid out when we helped found the Sovrin Network in 2018. Though we plan to stay close to cheqd, we are glad that their team is now fully self-sufficient. They have their own roadmap and a community of engaged collaborators, and we can focus on our current customer deployments and new organization.
We also plan to continue participating in the Sovrin Network. We are glad that there are multiple ledgers that each offer their own governance model and capabilities, thus providing a range of options to meet the needs of our diverse customers. This year, we intend to adapt our products to work with decentralized identifiers (DIDs) wherever our customers choose to anchor them.
Verity Infrastructure Upgrades
We reached another major milestone in November when we completed migrating our production Verity environments to use Kubernetes. This new infrastructure allows rolling updates with no downtime, which allows us to release improvements more frequently. We’ll continue using the Wednesday morning release window for the occasional updates that might require some downtime, but going forward we expect to be releasing new goodies multiple times per week.
As part of these infrastructure changes, we migrated our URL shortener from YOURLS to a custom implementation. This shortener supports the longer URLs created by Aries out-of-band invitations, and we now expire URLs after 14 days. Hijacking an invitation URL is one way that an attacker can subvert the security model of DIDComm, so we plan to provide configuration options to control the expiration of invitation URLs based on your use case.
In addition to rendering invitations as QR Codes or embedding them in emails, Verity’s SMS service can be used to send invitations as deeplinks to mobile phones. Our SMS provider recently got acquired by Infobip, and so we have migrated to Infobip’s services to ensure a stable experience for our customers.
With our new infrastructure in place, we plan to start the year with another round of load testing to better understand the capabilities of the service and where we should invest to further increase stability and scalability. We are also migrating customers from our old on-premise Verity 1 product built on LibVCX to the Verity 2 SaaS service. Those migrations are scheduled to complete in the first half of the year, so we currently plan to end-of-life Verity 1 in July of 2022.
For those who want to know if we are impacted by the recently disclosed Log4J vulnerability, you will be glad to hear that we audited our code and we are not vulnerable. A non-vulnerable version of Log4J is used by VDR Tools within our test infrastructure, but it is not used by our products. Verity uses Logback to fulfill the SLF4J dependencies. During this audit, we made a list of other dependencies that need to be updated. We will upgrade the Verity Node.js SDK to support the latest version of Node, which will result in our dropping support for the long deprecated Node.js version 8. We will also drop support for deploying the Verity SDKs on Ubuntu 16.04; going forward, we will only test installing on Ubuntu 18.04 and 20.04.
Improvements to Our Mobile Products
In our last product update, we discussed the Mastercard identity document verification (IDV) capability that we are adding to Connect.Me. We decided to wait until after the holidays to roll out such a significant new capability, so expect that release of Connect.Me later this month. The IDV service is already incorporated into the example React Native whitelabel application, and we are currently working on the Mobile SDK documentation for how to incorporate the Mastercard IDV into your mobile app.
This new documentation will be part of a round of improvements to the Mobile SDK documentation that we are publishing. There is a new article on the SDK’s internal storage, and a new article on connection invitations with attachments (one type of Aries out-of-band message). We also updated the Connection, Credential, and Proofs documentation with examples of the Connection Application object that matches the sample applications. You’ll see more improvements in the coming weeks as we continue to review and improve our documentation.
Developers using the Mobile SDK are probably aware that the connection object includes a protocol_type configuration that lets the connection know what types of protocols the other end of the relationship supports. The next release introduces a new protocol_type for Communication Protocol 4.0 which supports the latest flavors of the Aries protocols. This is the recommendation for new projects, but we kept the default setting to protocol_type=3.0 (which is our implementation of Aries Interop Profile 1.0) in order to allow maximum compatibility with old versions of the Mobile SDK. The next release of the Mobile SDK and Connect.Me will support a protocol for upgrading the protocol type used by connections, so that existing connections can leverage the newest protocols. But it won’t be until the related changes are done on the Consumer Agency Service and Verity.
Previous editions of this blog mentioned that Connect.Me can hold credentials from multiple Indy ledgers simultaneously. This reduces the need for the “Use Staging Net” slider that is on the bottom of the setup screen but does not allow us to remove that option. Flipping that switch still changes the behavior of the application to:
- Use the demo environment for the Mastercard IDV issuer service,
- Use the demo agency for connections that rely on the pre-Aries connection protocol,
- Only accept credentials anchored on Sovrin Staging Net, which can help with testing.
Interoperability with applications from other providers has been a common theme in this blog throughout the year. Our new try.connect.me demo site has been useful for interoperability testing. The new URL shortener in Verity is more compliant with the Aries out-of-band RFC, but we still see that many mobile wallets are unable to process the QR codes provided by try.connect.me. Our investigation suggests that this is due to our use of the Aries Out-of-Band 1.0 protocol for connection invitations. Many agents do not yet support out-of-band invitations and instead expect the DID Exchange Protocol or the older Connection Invitation protocol. If your solutions need to interop with these agents, then you should use the Verity APIs that support these protocols.
We’ve also found a few agents that have already implemented the Aries Out-of-Band 1.1 protocol without implementing the previous versions of Out-of-Band. These agents also fail testing with try.connect.me. Our Mobile SDK already supports the new variant, but we still need to make the changes to Verity so that try.connect.me can offer those invitations.
During November and December, the Hyperledger Aries Working Group held an Aries Mobile Summit. One of the sessions discussed how to reduce these problems with interoperability, and the attendees agreed on a plan to transition to Aries Out-of-Band invitations. We have nearly completed our transition, and we expect interoperability to increase as other agents adopt the newer protocols.
While we didn’t achieve our goal of launching the general availability of Verity Flow by the end of 2021. Our current plan is to gradually onboard customers for early access so that we can monitor usage and get feedback on the graphical tool for building custom credentials and proof requests. This tool will initially support a limited set of proof requests, and we’ll be working with our early adopters to prioritize the most useful capabilities. We will also be getting customer feedback on how to handle the billing of ledger writes, since changing schemas will generate Sovrin fees.
A lot of our recent work on Verity Flow has been on the backend. An example of this is our refactoring of the internal REST APIs to use GraphQL. This will allow the UI to request just the data for the current page, reducing the traffic between the backend and frontend. We are also caching more data on the frontend, which will increase the speed of responses and reduce the calls to the AWS Lambdas. We like how GraphQL APIs make data exploration easier and makes the frontend app more manageable. Finally, we are now leveraging optimistic updates to further improve performance.
We will keep you updated as we progress toward a generally available release. If you haven’t already, you can join the Verity Flow waitlist for more updates and early access.
We achieved another goal in December by ensuring that our entire team took some time off in staggered turns. You probably noticed the reduced activity in our repositories. Now that our team is back together, we are rested and ready to tackle the challenge of securing digital identities in 2022. We’ll continue to provide regular product updates, with the next one scheduled for March.