How Switchboard Tackles the Challenge of Enterprise Identity Management
By Ian Kelly and Nitin Gavhane
Nearly a decade has passed since Marc Andreeson wrote that software was eating the world, by which he meant that software — and ultimately the services that software and the Internet could provide — would increasingly capture value in the economy from traditional firms producing things. A list of the world’s largest companies by market cap suggests Andreeson was right: three of the top five — Apple, Microsoft, and Alphabet — are software-centric digital enterprises.
This digitalization of the global economy has spurred a new wave of Big Data, including data associated with identities. Yet for enterprises around the world, managing identities remains a major information technology challenge.
Challenges in enterprise identity management
In traditional enterprise identity management, identity data is typically highly siloed both within and across organizations, even with respect to individual business processes. Anyone who’s had to separately on-board with two more departments at a single company—such as accounts receivable, a membership department, a software tech team, and maybe a parallel business unit located in another country—knows what we’re talking about.
Enterprises must aggregate, share, and synchronize identity data across databases and directory services. Despite their best efforts, this is cumbersome and inconvenient at best. Plus, managing identities with traditional enterprise IT architectures like these often leads to high administrative and maintenance costs, privacy and security risks, and high compliance costs to mitigate those risks.
We see four key problems with the traditional approach to enterprise identity management:
- Low Interoperability: Centralized systems with information silos increase friction for would-be collaborators due to proprietary processes and architectures.
- Expensive Verifiability: Sharing verified attributes about users and assets (such as energy market participants and distributed energy resources like electric vehicles) is time-consuming and costly.
- Data Protection: Policymakers globally are regulating customer data privacy and ownership via new regulations such as the EU’s GDPR and the California Privacy Act. Complying with these policies using traditional IT architectures and processes—which were not designed with customer data ownership in mind—is increasing operational costs for many companies.
- Security: Even when enterprises attempt to manage data responsibly, vulnerabilities in traditional software and infrastructure systems can result in compromised data.
Taking a smarter approach to identity management using traditional enterprise architectures can address these challenges in part. However, a new approach to enterprise identity management that fully embraces the concept of self-sovereignty can unlock significantly more value.
Benefits of a self-sovereign approach
We at Energy Web believe that an enterprise identity management architecture based on self-sovereign identities (SSIs) enabled by decentralized identifiers (DIDs) and verifiable credentials (VCs) presents the best solution to these challenges.
We believe that DIDs should have four essential characteristics:
- Decentralized: The DID-based system has no central issuing authority.
- Persistent: The DID does not require the continued operation of any underlying organization.
- Cryptographically verifiable: One can prove control of the DID.
- Resolvable: One can discover metadata about the DID.
Using DIDs and VCs to build a SSI system should address the main challenges of centralized IT approaches we described above: interoperability, verifiability, data protection, and security.
Here’s what this could look like applied to a simple example in the energy sector: managing lithium-ion batteries from cradle to grave. The system could assign a DID to each battery when manufactured and the manufacturer could issue claims regarding the battery’s model, serial number, and specifications like capacity and energy. Next, the installer of that battery could add claims related to its purchaser and location. The owner of the battery could add a claim about the transfer of ownership and, at the end of its life, the recycler of that battery could issue a final claim about its retirement. Meanwhile, during its operating lifetime, the battery could enroll via its DID in various energy markets, such as to provide grid flexibility services.
How EW Switchboard brings this architecture to life
We are building this system, which we call EW Switchboard. It allows anyone to create a decentralized identifier based on a public-private keypair, and it provides a way for application owners to manage authentication, authorization, and accounting for their own apps. Like everything we do at Energy Web, it is not a product for sale but an open-source tool, designed for the needs of the energy sector but also sufficiently abstract to be applicable for any user or app owner — even those apps and services that do not use blockchain technology at all.
Switchboard is compliant with the W3C v1.0 decentralized identifier and verifiable credentials standards and is intended to accommodate a variety of approaches to digital identity. It uses a decentralized architecture, meaning that no one person or organization stores sign-in information or other user data or controls authentication or authorization. Each user remains in control over their own data and who has access to it. Thanks to WalletConnect, users can select from a large variety of existing wallets to create their DIDs.
Let’s see how Switchboard works.
We host Switchboard at our own website, meaning that anyone can access Switchboard and use it to create and manage their own DID, enroll in applications, create a DID for their devices, or perform other tasks. Developers or owners of applications can integrate Switchboard into their own apps, using it to manage user authentication, authorization, and accounting (without the user leaving the primary app) so that they need not develop these functionalities from scratch. This latter option means that users could use their DID as a single sign-in for a variety of apps, similar to how many people use their Google or Facebook accounts for single sign-in today, but remaining in control of that DID for life and independent from any one platform. It also means that application developers can focus on other functionalities in their apps and therefore deploy faster.
Once a user has authenticated with Switchboard, they can then use their DID to enroll in applications. This terminology is intentional: the user registers a DID once and owns it for life, and therefore that user need not re-register a new DID every time they want to use a new application. Instead, that user authenticates with their DID and then takes on specific roles in applications.
As the owner of an application, how do you ensure that users take on the correct roles? For example, what prevents an unknown user (i.e., a DID) from enrolling as the owner of a rooftop solar PV system in your app, especially if the architecture is decentralized (meaning neither you nor any other single authority dictates who has what role)?
To do this, Switchboard employs a system of VCs and provides an interface for you to set the roles and role governance for your application (role governance leverages Energy Web’s Ethereum Name Service). In our example above, you could use Switchboard to specify that your app includes the roles PV owner and PV installer, and that in order for a DID to enroll in your app as a PV owner that DID must have proof from a PV installer that the DID does in fact own a home with a PV system on the roof. The DID requests the installer to cryptographically sign a statement that the installer installed a PV system on that DID’s roof, and when the installer signs this statement then the DID can then present it to your app. Your app can verify that the cryptographic signature must have been added by that installer and thus allow the DID to enroll as a PV owner. Of course, you can use Switchboard to set whatever roles and requirements you wish (e.g., “a PV owner must have signed claims from the installer, the PV OEM, and from the PV owner’s distribution utility in order to enroll”).
This approach also benefits from network effects, because the verified claim is specific to the DID but not specific to the application. Continuing our example, imagine a user with a rooftop PV system wanted to enroll in someone else’s application and therefore obtained verified claims from the installer, the OEM, and the distribution utility relating to the specifications, location, and ownership of the rooftop PV system. You can, as the owner of a different application, set your app to allow any DID with those same claims to enroll as a user in your app — if the user can present the verified claims you require, it is not necessary that the user obtained those claims specifically to enroll in your app. The user does not lose the claims in the other app owner’s system, but retains them and can simply present them to your app.
We are releasing an alpha version of Switchboard now, for initial use and feedback from our community. Our intent is then to release a beta version in Q1 of 2021, with a final production version to follow. These future versions will add functionality related to asset management and incorporate Energy Web’s concurrent work with key management solutions and distributed messaging and storage.
