How a combination of Federated identity and Verifiable Credentials can help with Customer onboarding

Published in

BLOCK6

6 min readJul 17, 2021

Introduction

Before we dive into how Federated systems like OIDC and SAML along with Verifiable Credentials (VC) can help improve customer onboarding to your application, let us first understand what are the current methods being used for onboarding.

Simple signup

Traditionally, onboarding new customers into an application involved a sign up process, this requires the users to choose a username and password with which they can login into the application, the process may also require the user to fill a form to provide additional details like phone number, first name,last name,email etc.

Once the details are collected a verification process takes place wherein a link is sent to the user’s email address or an OTP is sent to the user’s phone number, the user then proves he owns the email address or phone number by clicking on the link (incase of email) or by typing the OTP into the application onboarding this user, but why is this done? This is done so that the identity created for the user can be linked to something unique that the user can prove belongs to them.

This process is the least user friendly of all the processes we will discuss here as it involves the user having to enter the above information and then validate email/phone number, the user also has to remember the password he has used for this application, when a single user is signed up with multiple applications this can pose a problem as he would need to remember all of the passwords.This in addition to the strict password policies(such as length and complexity of a password, as well as password rotation policy) that some applications enforce can be a nightmare for users who would have to remember all of their passwords. Many users in such cases simply choose to use the same password for different applications, the risk here is that if there is a data leak in one of the applications where the user has signed up and his password is cracked, the attackers can then use this information to try and access other applications that the user is signed up with.

Federated identity

In a Federated identity system, there is an Identity provider (IDP) which maintains the user’s identity and multiple Service providers (SP) which rely on the IDP for the authentication of users.

When the user decides to signup with an application (SP), the application can simply redirect him to an IDP where he has an account (for example Google,Facebook), the user can then take advantage of the session he has with that IDP to sign up with the services of the application(SP).

In this approach, the user need only remember the username/password of his account with the IDP. Many applications nowadays support this approach and make use of what is known as social login (i.e making use of user’s accounts with Google,Facebook,Twitter etc.)

Since the IDP has already done the verification steps (email/phone number) and the SP trusts the IDP , the SP need not repeat the same verification process, this greatly improves the user experience for the customers of said SP applications.

Even with the greatly improved user experience, the user still needs to have an account with the IDP. If your service provider application does not support the IDP where your customer has an account, then your customer would need to be onboarded using the traditional method of username/password. This means that the businesses are more inclined to support popular applications as their IDPs. Most systems that use customer-facing Federated identity systems support social login (as social networking websites are very popular and very likely the user has an account with them).

The above approach however acts as a barrier for new entrants to the identity arena who may provide more privacy enhancing features and would be specialized in identity management.

Verifiable Credentials

Verifiable credentials are cryptographically generated attestations of a user’s identity.The biggest difference between a verifiable credential and a standard digital proof of identity is that they need not be stored on a centralized database, rather they can be saved on the user’s device. This gives the user greater control of whom he shares his data with (as opposed to his data stored on a centralized identity system where a user has little to no control of how is data is used and monetized), there are also a number of privacy preserving features that VC support such as zero knowledge proofs, selective disclosure ,pseudonymous identifiers etc.

The biggest hurdle for any company moving its customers to a VC based system is the infrastructure and migration cost.

Most of today’s VC solutions run on a ledger and require a cryptographic wallet to be downloaded and installed by the customer. They work if a group of companies get together and form a consortium of partners that onboard and retain customers in their networks. This requires coordination on areas like which party will host which service? Which schemas would they support ? Would they all use the same VC wallet ? If each party has their own wallet, would the VC they save be interoperable?

A lot of companies using legacy systems may be unwilling to migrate their entire authentication system to a VC based system due to the above mentioned reasons.

But what if there was an easier way? A way by which a company with only a few minimal changes to their existing systems can use VCs.

The Combination

The primary idea here is to take advantage of the federated nature of systems that use OIDC, SAML etc. in order to introduce VC based authentication.

This means that as an SP application that trusts the IDP you need to do only minimal changes to support VC for end users.

The IDP would need to do changes to add support for VC based authentication, however platforms like Hyperledger Aries provide a REST based interface which makes adding support for VC based authentication much simpler.

Aries handles everything from managing the IDP’s keys and generation of presentation requests to handling connection with the ledger and providing a webhook facility to send updates about the state of a verification request to IDP’s server. Aries also supports the DIDComm protocol which makes it usable with any wallet that supports that protocol ,meaning that the IDP need not develop their own identity wallets for their users and can instead rely on wallets produced by others as long as they use the same ledger network ( eg Sovirin network) and the DIDComm protocol.

The IDP after authentication can pass the result to the SPs using standard OIDC/SAML protocols.

So the IDP need not worry about connecting to a ledger, building a backend to integrate SDKs of various VC solutions etc. The IDP can simply startup an Aries instance that connects to the ledger and call the REST APIs to use the necessary functionalities.

What does it mean for all the concerned parties?

Service providers: This means that they can now add support for VC authentication to their existing systems with minimal changes. Their customers need not have to use their social logins(which is good news for privacy conscious customers). Since a customer need not have to create an account with an IDP, it can help bring in customers who can re-use their VCs issued by other parties (like the Government).
Customers: Better user experience, no need to remember username and password of each of the applications you signed up with simply just scan a QR code, no need to worry if Google ,Facebook or the other social media giants are tracking which applications you signup with,complete control of your data.
Identity providers: Smaller companies can compete with social media giants and keep their business focussed on privacy rather than on monetizing user data. The IDP need not worry about maintaining large silos of user data as most of the user data will be on the respective user’s devices. As the VC space keeps growing and more and more interoperable solutions come into the market, we may reach a point where all the IDP needs to do is just call a REST service that connects to a global ledger to verify a login/signup request.