SSI: the future of identity management, how does it work?
The problem to solve
“The Internet was designed without a security layer.”
This blunt, cold, but factual statement is the starting point for the thinking that led to the concept of SSI, Self Sovereign Identity.
The Internet was designed to reliably and resiliently interconnect machines, first on a continental scale and then quickly on our planet’s scale.
The Internet is therefore primarily a network of machines, not individuals.
These machines have no intentions (good or bad), it was simply necessary to be able to locate them on the network without having to authenticate or authorize them, TCP/IP was born from this need.
First used by a scientific and academic community, guided by a certain ethic, the Internet gradually opened up in the early 90s to citizens and businesses.
The need for identity management and access control then became prevalent.
Local identity management
The first response took the form of local initiatives.
Each site, each department, each company, each application inherited an identity management and access control system.
First integrated at the application level, it implied for the user the creation (and memorization) of an account for each of them.
Not very convenient, and with a heterogeneous level of reliability / security, it quickly showed its limits.
SSO
The evolution within companies then gave birth to the SSO (Single Sign On): a common identification system for the whole of the company’s applications.
Microsoft popularized the principle with its Active Directory, then open standards such as SAML, SAMLv2 or OpenID Connect took over.
The federation
If the problem had been globally managed within companies, the individual could not benefit from it.
Each new service subscribed to a new company implied a new account.
The idea of interconnecting enterprise SSOs (starting with those offering services to individuals) was therefore born, and OpenID Connect was designed with this in mind.
Identity federations” allow a user to authenticate to the service of company “B” with an account from company “A”.
This is exactly what happens when you authenticate with your Google, Twitter or GitHub account to service(s) that have nothing to do with those companies.
Critical mass
While the principle of federated identity management may seem satisfactory from the user’s point of view, it is not without a number of problems.
First of all, in order to work, service “B” must recognize “A” as an identity provider.
For example, your online medical appointment booking service must recognize Google or FaceBook as its identity provider.
Since sites and services cannot offer an infinite list of recognized identity providers, they will tend to select the most representative ones, since everyone has a Google account, right?
De facto, the system favors a concentration of actors: service providers will tend to choose identity providers that gather a maximum of potential users, and users will tend to choose, for the management of their identity, providers that are referenced on a maximum of sites and applications, the system is self-perpetuating.
The major Internet players are therefore in a central position.
Although they do not monetize their identity management services directly with users, each connection and each authentication that passes through them is a source of enormous information representing a potentially colossal financial windfall.
If Identity Providers do not (in theory) have access to your activity on the “B” service once you are identified, the simple fact of knowing that you have authenticated yourself to access it on such and such a day at such and such a time is monetizable information.
How much would an insurance company be willing to pay to know how often you log in to an online medical appointment booking site?
This hyper-concentration also poses a security problem: if the identity provider’s systems are compromised, the impact is potentially catastrophic for its users.
What has changed
Despite the risks and drawbacks of federated systems, they still represent the majority of identity management systems in use today.
This is because the technologies available at the time did not allow us to do better.
But what could we do better? What would be the characteristics of an optimal system, at the scale of the Internet?
Let’s try to imagine them:
- A system that would allow individuals, but also machines, to authenticate themselves and even to provide the necessary elements to make an authorization decision.
- A system that would avoid users having to manage/memorize a large number of accounts/passwords, regardless of the number of services to which they authenticate.
- A non-centralized system, which would avoid the hyper-concentration phenomenon mentioned in the previous chapter.
- A system that would allow users to disclose only the information necessary to use the service in question (e.g.: I must be able to prove that I am of age without disclosing my date of birth or my age).
- Finally, a system that is obviously reliable (secure) and easy to use.
Many researchers have been working on this problem for the last twenty years without finding a satisfactory solution until recently, the most complicated being to design a system that is both decentralized and “scalable” on the scale of the Internet.
In 2008, the Internet saw the birth of a new technology: blockchain.
Behind its “application demonstrator” that is the cryptocurrency, the blockchain is above all the first “database” system entirely distributed on the scale of the Internet.
It is precisely a distributed ledger, i.e. a database in which it is only possible to add data, but not to delete or modify it, like a ledger.
Although these performances (in transactions per second) are globally very poor, they are quite sufficient for what we are interested in: the creation of a PKI (Public Key Infrastructure).
The PKI is the essential system for the implementation of authentication and signature systems based on asymmetric cryptography.
Until now, they were centralized (or hierarchical, which is the same thing) by nature, and were under the control of an entity (company, organization, government), which made it impossible to scale up to the Internet.
The blockchain opens the way to the principle of distributed PKI, no more central organization managing keys and related information.
This totally distributed PKI is what made technically possible the emergence of the concept of SSI (Self Sovereign Identity), the new identity management mode (it took 6 years to understand it).
SSI: Operating principles
The principle of SSI is relatively simple to understand, especially for non-specialists (who are generally the most confused by the disruptive innovation it represents): we simply reproduce in the virtual world the way you manage your identifiers in the real world.
By “identifier” I mean any information that characterizes you: first and last name, date of birth, physical address, nationality, eye color, hair color, height, etc.
Real world
In the physical world, the first step is usually to buy a wallet.
It becomes “your” wallet, but it doesn’t inherently contain any personal information while it’s empty.
It is “your” wallet because it is in “your” pocket and only you can decide what to put in it: you are in control.
Second step: you start to store identity documents in it: your ID card, driver’s license, passport, sports club membership card, employee badge, credit card, etc. These documents represent information issued by your employer.
These documents represent information issued by an issuer.
For example, your identity card or passport represents identity information issued by your country’s civil registry.
Third and final step: you use your documents to access services.
To rent a car, you take your driver’s license out of your wallet (which you always have control of) and present it to the rental company. To access your favorite gym, you take out your membership card and present it. To enter a new country, you take out your passport and present it.
You present identity attributes to people, entities that will check them.
The customs officer, for example, checks that the photo, the eye color, the height on your passport corresponds to the person he is looking at, but above all, he checks that the document is authentic, i.e. that it was issued by an entity (the government of a country in this case) that he (or rather his country) trusts, and that it has not been falsified (that the information has been modified).
So there is a transitive relationship of trust: the customs officer trusts the information you present to him because he trusts the entity that issued it to you (your government).
He does not need to know you, let alone trust you.
If we briefly summarize the players involved, it might look like this:
In the industry we call this the “triangle of trust”.
It is this principle that allows people who don’t know each other directly to interact with each other in confidence, whether it is about identity information, but also about money (virtual or physical).
Virtual world
Let’s transpose this into the virtual world.
For the first step we need two things, a wallet, just like in the real world, except that here it is a software (which can be installed on your smartphone), but also a support.
In the virtual world there is no paper, no plastic card, no small secure booklet, in short no physical medium on which to print the information and that you would own, over which you would have control.
This medium will take the form of a unique, random identifier created by you.
It carries absolutely no personal information, it is just a random sequence of numbers and characters. BUT it is “attached” to the cryptographic means that you will then use to demonstrate that you have “control” over this identifier.
In plain English, this numerical identifier, or DID, is tied to your self-created private key/public key pair.
When an issuer of identity information “makes” the equivalent of your driver’s license or e-passport, it will do so by indicating that the information is for this particular DID (via the credentialSubject field).
If you have control over the DID (i.e. the private key), then you can cryptographically demonstrate that the information referenced there is about you.
This DID is a URI (Unique Resource Identifier), and the resource is your public key.
This DID/public key pairing (stored in a DID-Document, itself stored in a blockchain) is the basis of the distributed PKI mentioned above.
The second step consists, as in the real world, in receiving certified information characterizing you.
The issuer, the civil status for our example, will issue a set of attributes (name, first name, address, height, eye color …) that it will attach to your DID (via the credentialSubject field) and sign cryptographically with its private key.
This relatively simple principle allows to cryptographically demonstrate that the information :
- Was issued by that particular issuer (e.g. a government).
- Has not been altered or falsified (the signature would no longer be verifiable).
- That it was issued to you (your DID is part of the signed information).
The “document” you receive is called a Verifiable Credential.
In the third step you present attributes to a verifier (a customs officer for example) through a Verifiable Presentation.
The customs officer can cryptographically verify that :
- The information presented to him/her has integrity (I.E. that it has not been altered),
- That they are authentic (that they have been issued to your government) thanks to the signature of the issuer,
- That they concern you (because you will sign your presentation with the private key corresponding to the DID for which the information was issued).
To verify this, the customs officer needs access to the issuer’s public key and to yours.
This is where the blockchain comes into play, it simply serves as a storage medium for the DID/public key pairs.
Using the DID of the issuer and yours contained in the attributes presented, it will “resolve” these identifiers with this storage medium to find the corresponding public keys and perform the signature checks.
The blockchain being unalterable (the information cannot be modified once written), he has the guarantee that if the signatures correspond to the public keys found, everything is in order.
All that remains is to determine whether or not he trusts the issuer of the Verifiable Credentials contained in your Verifiable Presentation, in our example, your government.
Just like in the real world, we have a triangle of trust:
The “Issuer” is your government.
The “Holder” is you.
The “Verifier” is the customs officer.
The field of possibilities
This relatively simple technology (I voluntarily made the omission of a certain number of details), allows to imagine very concrete applications.
- As in the example above, the dematerialization of identity documents (passport, driver’s license, identity card ….) and thus, the automation of their controls (no more queues at the customs),
- The dematerialization of contractual documents or those resulting from commercial contracts: a virtual key for the car you have just rented online (the issuer is the renter, the verifier is the car), a virtual key for the hotel room you have just rented online from such and such a date (the issuer is the hotel website, the verifier is… the electronic lock of the door)
- The securing of your computer access means (no more password, the issuer can be your company, but it can also be your government issued identity attributes)
- A standardization of the means of dematerialization of your means of payment (the issuer is your bank, the verifier the merchant),
- The dematerialization of your health information (which will only be stored in your wallet, under your control; Covid vaccination certificates are based on this technology in many countries),
- The verification of certain characteristics for access to certain services (your age to enter a bar, …or a pornographic site).
The last example uses a verifiable credential function called “Selective Disclosure”.
It allows a holder to choose among the attributes he has received from an issuer which ones he wants to include or not in a presentation.
You could choose, for example, to provide only your date of birth, from your ID card, to access a pornographic site, but not your name or your first name or anything else.
Going further, it is even possible with certain cryptographic mechanisms (ZKP) to prove that you are of age without disclosing your date of birth or age.
Whatever the application, it is always the bearer who agrees (or not) to present the requested information.
This information is only in the possession of the bearer and under his exclusive control.
There is no longer a central system, no monopoly to track your authentications on an online medical appointment booking site.
The trio of DID, Verifiable Credential and Verifiable Presentation represents a universal way to dematerialize, accelerate and secure our economy while preserving our privacy.
But that’s not all.
All the previous examples assume that the bearer and the credentialSubject are humans (and that the bearer IS the credential subject).
SSI is perfectly applicable to other types of entities:
- Objects, such as: containers, your fridge, your TV, the right engine of the plane that transports you
- Programs, which collaborate with each other in a Zero Trust environment ,
- Animals, the bearer would be for example the farmer and the
credentialSubjectthe cow to which have provided traceability or health information,
Conclusion
The IMS is much more than a new authentication or authorization system, it is a universal model of dematerialization of trust.
Each actor chooses who he trusts, who he presents his personal information to and what information he presents.
In the world of “machine to machine”, it opens the way to an interoperability of the systems until now hardly imaginable, the Gaia-X project for example is based on this principle, and it is only one example among many others.
Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing
