FAQs: Meet the Evernym Product Suite

Last Thursday, we organized the first in a series of webinar-style product demos and were humbled to be joined by nearly 100 professionals from 18 countries and just as many industries. For all of us at Evernym, it was a sure sign that decentralized, self-sovereign identity truly is taking off at a global scale.

On the webinar, we gave an overview of Verity (our flagship digital credential platform), a live demo of Connect.Me (the first Sovrin-based digital wallet app), and a sneak peek at what’s coming in our product roadmap. We also reserved time at the end to answer questions from the audience, but ended up with far more questions than time. (So if we weren’t able to address your question live, you’ll find our response below.)

If you weren’t able to make the webinar, we have the full recording available below. You can also dive into our products for free, with our new Developer Plan.

Audience questions

What are some of the institutions that have started issuing digital credentials?

The biggest issuance we know of so far is the Verifiable Organizations Network (VON) from the governments of British Columbia and Ontario in Canada, using the live Sovrin network. Despite the millions of credentials they have issued, they only needed to write fewer than 10 transactions to the Sovrin ledger – their DIDs, schemas, and credential definitions.

How will you approach the scenario where payment is requested for a credential issue?

Please refer back to the original 2016 paper on “The Inevitable Rise of Self Sovereign Identity” and look through the section titled “Premium Claims,” as well as this Sovrin whitepaper that describes how credential exchange and value exchange can be combined using a single protocol.

Could such a “digital identity” be used in a SAML federation architecture?

Federated identity architectures can be enhanced using a credential-centric approach. This applies for SAML, OIDC, and others.

In fact, Evernym is building bridges to legacy systems like these in order to make interoperability as simple as possible, with the first in the pipeline being an OIDC bridge. We believe that enhancing existing identity systems will bring significant benefits and provide a pathway to a far simpler and more secure credential-based ecosystem.

Where do you see peer-to-peer use cases?

In self-sovereign identity, EVERY use case is peer-to-peer. There are no intermediaries between entities that want to connect and exchange credentials, messages, etc. Peers can be people, organizations, or things – there’s no difference in the protocol.

If you mean “person-to-person” use cases, we’ve initially built Connect.Me and Verity to handle enterprise-to-person interactions, as that is what the market is asking for. It’s clear that person-to-person use cases, like private and secure chat, will be possible with this technology, and we know they are being built by several companies already.

Can you share how the shared KYC use case is monetized? Who gets paid for what?

Let’s bring this back to how KYC happens now in the physical world:

I go into my bank branch with some paper/plastic credentials like a passport, birth certificate, or utility bill. The bank checks them, and if they are happy with them, they give me a bank account. The passport office and electric company don’t get paid for this. The bank has made a risk-based decision to accept documents issued by certain third-parties as proof of identity. To reduce risk, they require that the person provides documents from multiple sources. It’s not foolproof, but it’s pretty good.

Now, imagine the digital credential world. It is just like the physical credential world, but instead of pieces of paper, I have digital credentials that can be verified as authentic. The verifier can check four things: who issued the credential, that it was issued only to the person presenting it, that is hasn’t been tampered with in transit, and that it hasn’t been revoked. This is far better than the checks you can do with a paper credential. So KYC can take place remotely, and instantly. And indeed the liability model doesn’t need to change either. This is part of the simplicity of the digital credential model – it’s just like today’s paper credentials in terms of who issues them, who checks them, but it’s far more secure, fast and private.

You can take this a step further. Let’s say that there is an intermediary that calculates something useful like a credit score. They put effort into doing so. They could give the credit score to the person as a credential so the person can use it anywhere they want, but the effort the company has put into calculating that credit score should be rewarded. So there needs to be a way to combine credential exchange with value exchange. Happily, we’ve already thought of this, and it has been articulated in this whitepaper.

We’ve built the infrastructure to allow you to create whatever economic model you want, but we recommend you keep it simple.

What happens if you lose your mobile device, where your credentials are stored?

Digital credentials are far more secure than paper and plastic credentials that you use happily every day. However, this is a question we get at least once a day, so our Chief Architect Daniel Hardman created this excellent paper titled “What if I lose my phone” precisely to describe how much more useful, flexible, and secure a digital credential ecosystem is. You’ll find the paper here. 

What do we do when our driver’s license isn’t electronically verifiable (e.g., the Oregon DL)?

The same thing you do now – you’d have to provide the plastic card. But….there may be a third party who is interested in setting up a business to convert the details on your plastic card driving license into a digital credential and issue it to you.

And eventually, issuers like the State of Oregon will figure out that it’s so easy to issue a driver’s license digitally that they might as well do so at the same time that they issue the plastic card to you. We already know of several U.S. DMVs who are looking seriously at Sovrin and digital credentials, and such a move is likely to be inevitable now open source technology is available.

Where does blockchain fit into the persistence model for digital credentials?

It’s important to first understand what goes on the ledger, which we’ve detailed in this whitepaper.

Basically, the ledger doesn’t contain much at all. It certainly doesn’t contain any credentials. Credentials all live “at the edge” rather than centrally. The ledger is used to hold the public keys of credential issuers, plus some other verification attributes, that allows any verifier anywhere to verify any credential that has been issued. An issuer can issue a billion credentials and only have to write to the ledger twice–once for their DID, and once for their credential definition.

Because the ledger is forever, even if the issuing institution is destroyed in a war, goes bankrupt, or otherwise ceases to exist, the credentials they issued will always be able to be verified as authentic.

Do you plan to integrate a universal resolver to read/use DIDs from networks other than Sovrin?

We’re delighted that so many organizations have jumped on the DID bandwagon. When the DID spec was written, it was designed to be ledger-agnostic. That is why each DID has a “method” that points to where the DID is stored. We predict that this flexibility will enable DIDs to become the dominant identifier standard for people, organizations, and things.

It’s also worth noting that DIDs can be public (e.g., those of a credential issuer that are written to the Sovrin ledger) or private (e.g., “peer DIDs” established just between two parties for the purpose of setting up a private, secure communications channel).

You can find the DID spec on the W3C website.

What functions exist in Evernym’s software to limit the verification of false information or information sharing to third parties?

There are two questions here.

1. How do you stop false information being put in a credential?

2. How do you restrict onward sharing of information once initially shared?

Let’s answer them in turn:

1. This is just like the physical world. The credential verifier (e.g., a bank) needs to trust the credential issuer (e.g., a passport office) to do their job properly. The technology of credential exchange does not remove the need for human trust between verifiers and issuers. What the technology does is enable the verifier to confirm four things: the credential came from the issuer, it hasn’t been tampered with in transit, it was issued only to the holder that is presenting it, and it hasn’t been revoked by the issuer.

If the issuer puts false data into the credential (on purpose or accidentally), the verifier won’t know unless they check with other sources (for example, comparing credentials from multiple issuers, just like you do today when you ask for a passport, driving license, and utility bill). Issuers who persistently fail to provide accurate genuine data in credentials will soon drop down the human trust scale and may be blacklisted. You can take this further and use some very cool technology to create verifiable reputation scores if you want to.

2. There is nothing in Sovrin, or any other tech that I’m aware of, that allows you to “suck back” the data you present to someone. Once the verifier has received some data from you, they can put it in a database or print it, and then do what they want with it. This is just like today’s world of paper credentials.

However, there are some major benefits to digital credentials. Firstly, you will have irrefutable evidence that you shared data with that verifier, what you shared, and when. The verifier is unable to deny that you shared it. So if you think the verifier has misbehaved with your data, but they deny doing so, you can prove that they did. You can then request that the verifier deletes your data, and prove that you’ve done so. This way, a verifier must comply, lest the GDPR police will descend like a ton of bricks. Lastly, you can now minimize what you share to just a single attribute, or even better, a zero-knowledge proof that does not reveal the underlying data. It’s likely that the force of regulation and the risk of a data breach will encourage companies to only ask for the minimum possible information, which they can delete once they have executed a transaction.

As with many things in the world of self-sovereign identity, first ask the question “how does this work today for physical credentials?” and you’ll find the answer for digital credentials as the processes are much the same.

How do you see the SSI market regarding compatibility between the different approaches and how can they work together? 

We’re delighted with the momentum that SSI has gained. When we started on this journey in January 2016, we would never have envisaged that progress would have been so fast, with interest from around the world. We have been staggered by how quickly things have moved, and we believe that “open” will beat “closed.” We’ve seen it happen time and again. The Internet beats the walled gardens that were set up in the early days, simply because it is easier, ubiquitous, and standardized. Once you have an open, standardized infrastructure, new business models can blossom and innovation can explode.

So you can think of the two main building blocks of SSI–DIDs and verifiable credentials–as the new TCP/IP or SMTP, open standards that usher in a new world of amazing capabilities. From the outset, we wanted SSI to be a global public utility for everyone, that we could all use and anyone could improve.

When do you expect SSI to start rolling out?

2016 was the genesis year for Sovrin. 2017 was the year of R&D. 2018 was the year of PoCs. 2019 is when those PoCs go into production. It’s already happening and the future looks amazing.

How is the Connect.Me mobile agent’s URL configured, since mobiles cannot have a persistent URL endpoint? How does the try.connect.me website know which agent URL to hit?

In the Indy architecture, there are “edge agents” (e.g., the Connect.Me app) and “cloud agents” (which provide a persistent always-on endpoint). The Connect.Me app communicates with its cloud agent. The cloud agent is essentially a store and forward router to route requests to and from the Connect.Me edge agent. This means that, even if your phone is switched off or out of coverage, messages are not lost. Anyone can run cloud agents, and you can self-host or build your own (it’s all open source). Evernym runs a free consumer cloud agent service already (that Connect.Me uses), and we also run an enterprise cloud agent service for enterprises that don’t want to self-host.

You can read more about the agent protocol here.

When can we try Connect.Me with real entities, instead of the demo entities available in try.connect.me?

In the UK, US, and Canada, you can do it right now. You can get a real credential based on your ID card, driver’s license, or passport from our friends at Onfido.

How can the Verity backend be integrated by an enterprise?

For generic use cases that you want to create for yourself, the full-featured Verity product comes with a sophisticated SDK that is very simple for developers to use, with commands such as “credential.send(context);” and “credentialValues.put(“name”,”Joe Smith”);”

For use cases like authentication and onboarding, our Verity Auth and Onboard products come with SDKs that are dedicated to those two use cases. They also come with pre-defined credential definitions and proof requests to enable you to get up and running as fast as possible without needing to worry about the underlying infrastructure.

We’ve built things this way in response to feedback from our customers who want to focus on getting up and running as fast as possible and don’t want to spend months learning how the underlying Hyperledger Indy codebase functions.

Can Verity be eIDAS compliant?

eIDAS compliance is a very interesting topic. A notified eIDAS identity provider could easily give a customer a credential containing their identity attributes. This credential could also contain a “qualified certificate,” using the capabilities of the Hyperledger Indy/Aries credential exchange protocol to allow the holder to prove they are the owner of the certificate. This would substantially simplify the underlying eIDAS architecture, as it would mean that national hubs are no longer required. User experience would be transformed (no more multiple-layered federated login screens), and a citizen’s eIDAS credentials could be used anywhere in the world, for anything.

How can we start to integrate Verity/Auth and other solutions?

You can start working with it now by creating a free developer account, which will get you access to Verity, Connect.Me, and all of our developer documentation.