Welcome to Evernym’s developer toolkit for INTEROPen’s NHS Digital Staff Passport Hackathon.
Evernym is the supplier of the digital credential technology and mobile app being used in the existing NHS Digital Staff Passport program. Our friends at Sitekit have embedded our Verity credential exchange platform into their hospital credential issuing and verifying solution that has already been tested, released, and deployed to NHS hospitals as part of the program. Doctors and other staff use our Connect.Me app to obtain and use their staff passport credentials.
Evernym is a pioneer in verifiable credentials and self-sovereign identity. We created Sovrin, and wrote most of the code that makes up Hyperledger Indy, Hyperledger Aries, and Hyperledger Ursa. We are the people that brought you decentralized identifiers (DIDs), and we contribute heavily to the open standard communities on DIDs and Verifiable Credentials at the W3C.
Our main business is the provision of our world’s leading credential platform, Verity. As a hackathon attendee, you’ll be able to use Verity and our pre-defined schemas to quickly build your own digital credential solutions that will integrate with the NHS digital staff passport.
Our software is used in digital credential projects around the world, with use cases as diverse as doctor identity, supply chain certification, financial services authentication, portable identity across online gaming environments.
If you missed our staff access and decentralized identity master class at the recent NHS Hackathon, you can find our full slides here.
You can also request free access to Verity through our Developer Plan to browse our full developer resources and start building today.
This Learnathon is particularly focused on the new Pan NHS Authenticator proposition. The current NHS Digital Staff Passport uses the Connect.Me app from Evernym (now part of Avast). This app already contains the functionality for several authentication mechanisms that completely remove the need for usernames and passwords, and include multi-factor authentication as standard.
If you are going to be interacting directly with a Verity tenant, please read this getting started guide in conjunction with the info below.
The four mechanisms available for authentication are as follows:
Proof of possession of a unique private key embedded in a decentralised identifier (DID). This is a beautifully simple method that is very user friendly and virtually instantaneous, requiring nothing more than scanning a QR code or clicking a link. It includes multi-factor authentication by default.
When you set up a relationship (a “connection”) between a digital staff passport holder and hospital, for example by scanning a QR code with Connect.Me, what happens behind the scenes is that the app and the hospital each create a new “peer DID”. Each peer DID contains a unique public key for this relationship, and the associated private key is stored in the app for the holder, or in the hospital’s Verity wallet. The peer DIDs are then exchanged.
Once each party has the other’s peer DID, party A can encrypt a message using party B’s public key that only party B can decrypt. That message can be signed with party A’s private key, and that signature can be verified by party B using party A’s public key contained in the peer DID that was exchanged. This protocol is called DIDComm and is embedded in all transactions used by Connect.Me back to Verity by default.
Using DIDcomm connections, it is therefore possible for subsequent interactions between party A and party B to be immediately authenticated. Any transaction across a DIDcomm is signed by the relevant peer DID keys. Therefore a returning user simply has to execute a DIDcomm transaction to be authenticated, as they are proving a) possession of the phone that is bound to the wallet b) possession of a biometric or passcode to unlock the phone, and to unlock the wallet, and c) possession of the unique private key used for this relationship.
When used for authentication, this approach is called DIDauth.
The easiest way to use it within a Connect.Me + Verity environment is to use “connection reuse”. When a holder scans a QR code for a hospital that they have previously connected with, Connect.Me will respond with a signed message saying “hey, it’s me coming back” and Verity will authenticate this message as being signed by the private key of a DID that it already knows. A guide and example for how to implement this is here.
Committed Answer builds on top of DIDauth. It can be used to convey an on-screen message and selection choice for the Connect.Me holder, such as “Are you trying to log in to System X yes/no” or “Please select the number displayed on the ESR system login screen: 3743, 5764, 9034” etc.
It uses the same peer DID based authentication mechanisms under the skin as in DIDauth and therefore benefits from the same multi-factor authentication characteristics.
The hospital system is set up to push a message to a known DID connection that is the a Connect.Me holder. This can be done in response to a user transaction (eg a returning user scans a QR code as in DIDauth, or clicks a button etc). The message that pops up on the Connect.Me screen is configurable. It can contain two or more optional responses. If there are just two options, Connect.Me will display “yes” and “no” boxes. If there are more than two options, Connect.Me will display a set of radio buttons containing those options.
The response from the Connect.Me holder is signed using the private key for this specific peer DID relationship.
A guide to use of the Committed Answer protocol can be found here.
CredAuth is a fancy name given to what is simply a standard proof request and response transaction. It uses the same underlying relationship authentication as DIDauth, and benefits from the same multi-factor authentication capability.
It also adds a new factor, which is the proof of possession of a credential containing information about the Connect.Me holder. This could be proof of name, employment number, role etc.
In this case, the hospital system that is running Verity will, after a DID-based connection has been established, request a proof from the Connect.Me holder. The Connect.Me holder will see this request flash up on the screen and Connect.Me will have pre-filled the response with all the data required to satisfy the proof data requirements.
The response is encrypted using the same DIDcomm mechanisms as for DIDauth, so the hospital will know it has come from the correct unique DID. The data in the proof will then be verified as authentic by checking the signatures within, and confirming the source and integrity of that data. The verifier can then examine the data and execute the required transaction knowing that the data has come from the right place and hasn’t been changed in transit.
This approach allows a verifying system to know that it is dealing with a returning user, the user is Jane Doe with employee number 1234567, so it can log that person in and possibly customise the UI with that person’s details immediately (e.g. “Welcome back Jane Doe”).
Examples of “proof presentation” in various languages are available. Here’s the Java sample code.
Decentralised Permissions are CredAuth + access rights held as attributes within a credential.
This approach allows the access rights to various systems be held by the user themselves, rather than in some central database. It is quite a departure from the status quo of a large central user registry containing access rights to every system that the user is allowed to log in to. In the case of the NHS, there are many of these registries sitting in silos in different trusts.
By giving the access rights information to the user, they can go to any location and log into any system, and the system can know it is the right user and that they are allowed to log in.
Implementation of this capability is a matter of adding one or more attributes to a credential that is given to a user. For example, a new “Access Rights” credential could be defined containing 3 attributes like this:
The access rights bitstring might be, for example, 128 bits long. Each bit could represent a system that the employee is allowed to log into. If the ESR system is system number 34, and bit 34 is set to true, the employee can log into the ESR system.
Once this credential is issued to the employee, they can present it whenever required. If they want to log into the ESR system, the ESR system can request this bitstring attribute in a proof request that has a nice title such as “Please confirm you want to log into the ESR system”, and when the employee provides the bitstring in the proof the ESR system will know a) that the data in the bistring is genuine i.e. it came from a valid source and has not been altered, and the ESR system can also to the same verification steps of the peer DID keys as described in the DIDauth section.
This mechanism therefore provides multi-factor authentication, an informative user interface, and decentralised proof of access rights, all in a simple one-shot transaction.
Self-sovereign identity (SSI) is an approach of identity management that puts the user in the driver’s seat, giving her for control over control of her data and how it is used.
It’s the inverse of how we interact with today’s digital world, where our data is stored across hundreds of company servers, to be used however that company sees fit, with or without our consent.
Yet, it’s far from a new concept. We’ve had self-sovereign identity for over 2,000 years in the physical world, tracing back to the first known ‘passport.’
In the physical world, we are by-and-large the owners of our identities. We carry with us a wallet that contains a series of form of ID, like driver’s licenses, insurance cards, and student IDs. We call these paper credentials and use these to prove our identity when we open a bank account, order a drink, and book a hotel in-person.
These credentials are verified by the trusted authorities that issued them, perhaps a government office or a university. And, we can use them wherever, whenever, and however we want, without the issuer having to approve or be involved. We don’t have to have an ID card for every organization that needs to verify our identity; we have one that’s universally trusted.
Self-sovereign identity is the simple notion of taking these physical wallets and paper credentials and making them digital. Just as you can you walk into any business and flash your passport as proof of your identity, SSI allows you to visit any website or any access control system and flash a digital credential to prove your identity—in a way that’s far more secure and privacy-protecting than usernames and passwords, and far more trustworthy and tamperproof than today’s analog equivalents.
Watch the recording of one of our recent webinars, where Evernym’s Andy Tobin provided a detailed introduction to self-sovereign identity:
Verity is Evernym’s flagship digital credential platform designed for enterprise-grade stability, performance, and scale.
Verity makes it easy for organizations to:
You can access Verity by registering a free Developer Account or through the resources made available for the NHS Hackathon.
To learn more about building on Verity, check out our recent product demo webinar:
