As August draws to an end, we’re excited to share several updates that our Product and Engineering teams have been working on over the past month.
The highlights are:
- Verity is now deployed in a cluster and supports OAuth for authenticated webhook responses. (learn more)
- Verity Flow is expected to be Generally Available by the end of this year and we’ve opened a waitlist. (learn more)
- Connect.Me 1.6 has been released and supports multiple Indy ledgers. (learn more)
- Evernym’s Mobile SDK supports mobile device proving. (learn more)
- We configured GitLab SAST into our pipelines. (learn more)
- We are adding support for the cheqd network to VDR Tools. (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 is our flagship platform for issuing and verifying credentials. You can learn more about it here and try it out with a free Developer Account. ]
In last month’s update, we described our preparations to deploy Verity in a multi-node Kubernetes cluster. The next step in that process was to deploy a three node Akka cluster split across two AWS availability zones based in Frankfurt. That deployment went smoothly, and our tests show that the cluster is resilient to the most common types of failures. Next steps include ensuring that we can perform rolling upgrades across the cluster and moving to Kubernetes. Then we can focus on increasing scalability and testing additional failure cases.
As documented in the Verity SDK, most Verity APIs are asynchronous. To get a response back, solution builders have to register a webhook which we recommend protecting from unknown sources. With the deployment of Verity in a cluster, you will need to add IP addresses to your whitelist for each server in the cluster. The list of IP addresses for the whitelist is kept in the Verity SDK. Alternatively, you can now protect your webhook with OAuth and configure Verity to provide the OAuth credentials with each response. This is documented in the UpdateEndpointAuth schema in the updateEndpoint REST API of the Swagger API documentation.
Last month, we also mentioned that Verity now supports a per-tenant configuration defining the data retention policy. We published a document describing this configuration, and you can contact Evernym Support if you want to change the settings for your tenant.
Finally, our support team has been adding answers to common questions to the Verity FAQ. That is a great place to learn more about how Verity works.
Verity Flow
[ Verity Flow is our no-code visual interface for issuing and verifying credentials. Sign up for the waitlist here ahead of its Q4 2021 release. ]
If you weren’t able to attend our webinar on Verity Flow last week, you can watch the recording on our YouTube. We’ve also included a short demo of the verification process below:
The most important information is that we are working for a General Availability release before the end of this year. We currently have the application in production with 1,500+ COVID-19 test labs around the world who are issuing test result credentials, and we are adding functionality to allow the application to be adapted to other use cases. If you think Verity Flow would help out your organization, you can join the waitlist and we’ll invite you to the Early Access program when we expand it to a broader group of customers.
If you are already using Verity Flow, you will soon see our new bug reporting tool. A click on the lower left corner will make it easy to record the screen and configuration, and submit the report to our team so that we can understand and fix any problems you encounter. That release will also include a number of layout fixes that make it easier to use the app regardless of the size of your browser window.
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 has been released. In addition to the UI and performance improvements discussed in last month’s release notes, this launch also includes support for multiple Indy ledgers. If a verifier issues a credential from a public ledger that is known to Connect.Me, then Connect.Me will automatically use that ledger when fulfilling proof requests. This capability also exists in the Mobile SDK for other application developers to leverage.
This multi-ledger support allows our applications to store credentials for Sovrin MainNet alongside the other Sovrin ledgers. In the next release, we will remove the “developer mode” toggle in Connect.Me for connecting to Sovrin StagingNet and BuilderNet. As customers request networks besides Sovrin, we will be able to add them in future releases.
The Mobile SDK contains another new feature that we are experimenting with: the ability for a mobile app to present a proof as a QR code, and for that QR code to be scanned by a different mobile app to verify the proof. The holder caches the information needed to present the proof, so only the verifier has to be online. The proof results will show up in the connections view of the verifier. We created this feature to make it easy to share a proof of vaccination, or other well-known credentials. The proof can be shared when visiting a location where the holder has no network access. However, the current implementation is limited to proofs that currently contain six attributes or less. This is an experimental feature and is likely to evolve as we get feedback from users. We look forward to seeing how application developers incorporate this capability into their user experience. You can learn more about this feature in the “Advanced” section of the Mobile SDK documentation.
Tooling
We evaluated a range of products for static code analysis, otherwise known as Static Application Security Testing or SAST, and concluded by enabling GitLab SAST in our code pipelines. It supports our environments, integrates nicely into the pipeline, and can be used alongside other solutions if in the future we decide we want to continue using other tools. As you watch the commit history in our repositories, you will see that we are gradually implementing the recommendations from the tool.
Last month, we mentioned our work on the VDR Tools library. Most of our work since then has been maturing the CI / CD pipelines so that we have artifacts that can be confidently consumed by our other libraries. However, you can play with “work in progress” merge requests that implement experimental support for BBS+ credentials and add support for the cheqd network. It is Apache licensed in order to make it easy for other users of the cheqd network to adopt the library in their applications. The team at cheqd mirrored the repo to make it easy for people to consume the library independent of Evernym.
We’re excited that the cheqd network has open sourced their implementation. Having all of the documentation public makes it much easier to set up our validator node. We are learning that Cosmos makes different assumptions about trust than Indy does; it expects clients to rely on trusted observers instead of validating state proofs. We’re going to have to adapt our application architecture to this new network until they deploy a more robust solution, but we are excited that cheqd is benefiting from the fast pace at which the Cosmos ecosystem is advancing.
We hope that these notes are making it easier for you to learn about digital identity and Evernym Products. Feel free to reach out with any feedback. We’re interested to know if you have questions, or if there are other topics that you would find useful for us to cover.
