Digging Deeper into Self-sovereign Identity and Access Management
Everyone is talking about self-sovereign identities (SSIs) and how they allow users to control their data and identity. We at Energy Web believe that this is only the first step in the journey to a decentralized application landscape.
Indeed, being able to authenticate with a certificate has been possible for a long time now but it has never been widely adopted due to technical limitations. Until recently, there’s been the need to create centralized public key infrastructure systems—with a key shortcoming being that one certificate would only give you access to one application. So while the identity might remain self-sovereign to the ID owner, it still lacks the efficiency of a more-decentralized system in which a master ID ‘passport’ could be used seamlessly across multiple apps.
This is because most implementations of SSI focus on the authentication portion. This is the first step and a mandatory one. But as long as there is no standardized manner to exchange profile data, this will only be a global certificate system, allowing passwordless login but not permission management. This is what we want to change with Energy Web Switchboard, our recently released one-stop solution for access management.
Requirements
A permission management system—or Authentication, Authorization, and Accounting (AAA)—is the basis for every Identity and Access Management (IAM) solution. It fulfills three basic functions:
- Authentication: Verify that the user is in possession of the credentials (in our case, the private key).
- Authorization: List the roles that have been assigned to the user in order to do Role-Based Access Control (RBAC).
- Accounting : Keep a log of the operations performed by the user.
In order to create a decentralized version of IAM we have to enable the above functionality, while at the same time make sure our system has the following properties:
- Censorship Resistance: A user can use their credentials whenever they want.
- Data Confidentiality: It must not be possible to list the users who have access to a specific system.
- Decentralized Infrastructure: Nodes must not be able to misbehave; either they perform correctly or not at all.
Let’s look at each one of these requirements in more detail.
Censorship resistance
When using a centralized system like Google or Facebook, these entities have complete control over the data that your application receives. They have little incentive to withhold information from you specifically but they could if they wanted to. And as we don’t know their motives, it is difficult to assess the probability of this occurring. Even in a system like OpenID, there is an administrator for the database and unless that administrator is you, their interests might diverge from yours.
Being resistant to censorship means that there is no actor in the system that has the power to selectively limit the information other actors have access to. In other words, everyone has access to the same information at the same time and there is nothing the creator of the information (or anybody else) can do about it.
This matters because there are a few data points that you do not want to be withheld from you when using an IAM system. You must know as soon as possible:
- If a permission has been revoked. You would not want to give access to someone who should not have it.
- If a key has been invalidated. If a key has been compromised, all the permissions granted by it should be revoked or it should not be able to authenticate anymore.
- If a permission has been granted. Once a permission has been granted, it must be possible to verify it every time it is presented.
A blockchain fulfills these requirements by design. Since the state is kept in sync over all the participating nodes, once something has been published, it is either known to all or none of the nodes. Additionally, the cryptographic proofs contained in the transactions allow the offline verification of the data.
This is why all the permissions are anchored on chain. The descriptions of roles are held in an ENS smart-contract; the successful granting of a permission is noted in the DID document of the user. Each user holds their credentials and is the only one to have unrestricted access to that data.
Confidentiality
As an application developer, I don’t want the world to be able to make a list of my app’s users and even less, a list by roles. It is therefore crucial that when a user is granted a role, this event not be made public.
Centralized systems are not terrible in this use case, as they will not disclose your information to third parties but they themselves will record all the activities of your users. This is a feature of the platform. It is a tradeoff you’re willing to make in order to give convenience to your users.
In the EW Switchboard solution, no third party has the full list of users of an application. This is guaranteed by the permission-granting process:
What we’d like to highlight in this simplified process is the fact that it is the user who stores the claim and anchors it on chain. Also, because it is a private claim, the contents are provable but not disclosed. The user can therefore prove that they have been granted a certain privilege, but unless they elect to disclose this information, it is impossible for a third party to find out.
And as the users must anchor the claim on-chain themselves, there is no opportunity for an observer to make a list of the addresses added to a particular smart contract or any other indirect way to observe the activities of the IAM. The only information an observer can garner is that the user has added a claim to their DID document but not the content, origin, or nature of the claim.
Decentralized infrastructure
We have mentioned the Energy Web Chain and IPFS, which are both peer to peer networks and lack a central point of control. There is one piece of infrastructure we have not mentioned yet: the message transport between users.
How the user and the role admin in the above sequence diagram exchange information is through a service bus: the EW-DOS messaging component. This component is decentralized in the same manner IPFS is: there is no centralized control but there is no consensus either. Each client must pick the service node they want to connect to and if this service node does not deliver the expected service, it is the responsibility of the client to connect to a different service node.
As every message must be signed by the sender there is no opportunity for the service provider to alter messages in transit. Either messages are delivered as received or they are rendered invalid by the update and the recipient would notice immediately. The messaging service therefore fulfills the requirement of not being able to misbehave. It either fulfills its duty correctly or not at all.
Conclusion
With Switchboard, we provide application developers an alternative to centralized authentication and authorization systems like OAuth with Google and Facebook or Azure Active Directory. Obviously we still have a lot of features to add in order to compete with these established services, but EW Switchboard is the first fully decentralized IAM solution. You can use the installed version today on the EWC or deploy your own from source on any EVM chain.
