Verifiable Credentials for Identity Issuers
Redefining digital membership for organizations
When an organization issues a digital identity, it’s done so members of the group can prove their membership in that group. This is because being a member of a given group generally has some benefits assigned to it — having a drivers license means you can drive, an email address with a given domain means you are employed at that company, a student ID shows membership in an educational institute, etc. These memberships can be used not just in the context in which they were issued, but also any context you choose.
These memberships are often used not just to verify yourself with the organization but also for third party groups to gain access to their services. For example, Spotify offers a discount for users with a student email.
Let’s take a look at some popular ways that organizations provide you with digital proof of membership in their group, and how they compare to Verifiable Credentials (Self Sovereign Identity):
This type of gatekeeping is the most effective, easy to set up and common gatekeeping found on digital services. Email domains denote organizations, and every member of that organization is allowed to access whatever services are provided.
While this may seem easy, it requires the issuer to buy and maintain a domain and then run email inboxes for every member of their organization. Members then have yet another email to maintain and check instead of just being able to use their main email accounts.
Furthermore, this doesn’t differentiate between employees of an organization vs members of the organization. It gives no info on organizational structure, permissions, or anything else except that this person does in fact belong to the organization. It’s a cumbersome model, and one without significant benefits.
Switching over to SSI, issuers would only need to maintain their own wallets, and could issue a credential attesting to a user’s membership without needing to maintain any infrastructure or fight over an increasingly small number of domain names. On the users side, they get an easy new identity to add to their wallet without needing to think / check up on it.
Certificates
Apart from membership in a group, often organizations make attestations to their members having achieved something — for example school diplomas.
These organizations maintain databases of the certificates they have passed out and when a student is asked for their certificate, they can ask the organization to send a copy to the requesting institution. However, as it often happens, when a for profit school shuts down, students are unable to get their diplomas validated.
In the SSI world, certificates would be stored with the user and the validating credentials memorialized on chain, so no matter what happens to the issuing organization, the user will always have access and a way to prove their credentials.
Digital Accounts
Another very popular method of authenticating a user is to just have them create an account with the service. Then, when they want to use their membership within a given service to authenticate themselves, the service can go through something called an Oauth flow. This is how Facebook/Google/etc build their special “Login with [Service]” buttons.
For an organization that wanted their own “Login with _____” button, they would need to create and secure a set of servers to provide Oauth service and fulfill those requests. At the same time, they would need to go convince webapps and services to implement their “Login with ______” anything button so their service is actually used.
On the verifier side, they need to implement a new API and add a new button for each and every “Login with” button they want to implement. This leads them to only support the top two or three platforms.
These third party services (such as Facebook and Google) also get to soak up data on where, when, and how often their users use other applications and then sell that data to advertisers.
Verifiable Credentials / Spaceman ID’s “Login with Anything” button means that verifiers only need to implement one API, and can accept credentials from any verifiable credential issuer. Issuers no longer need to run infrastructure, or worry about convincing verifiers to use their credentials!
Manual Verification
One of the most tedious ways that online identity verifiers check ID documents is through manual verification — a user uploads pictures of their ID documents and then a human looks at them to verify if they are legit.
Not only is this insecure, but also massively inefficient, unscalable, and otherwise cumbersome for these services. They generally outsource this model to third party companies to do this, but that’s not really a technological fix, more like a logistical liability shift. The worst part is that a user might have go through this process multiple times, instead of just doing it once and having a reusable verification.
Another instance of manual verification that’s necessary is when the verification is done for membership in a group that doesn’t have a way of giving it’s members a unique digital presence. Joining a soccer league, being part of a co working space, being on the local business advisory board — all of these are memberships that would need a human to connect with the staff of the organization to verify the user’s membership there. This makes making services with gate keeping for select groups very difficult.
All this changes if the systems in place use Verifiable Credentials. With Verifiable Credentials, users maintain the proof of their verification of membership within the credential itself. They can easily showcase that yes, this is a valid credential, which was signed by the correct issuing authority without needing a human to interpret the data.
Implementing Self Sovereign Identity doesn’t have to be a pain — to build identity systems that are private, secure, and portable with the minimum investment in new technology, consider using Spaceman.ID’s set of developer tooling.
