By Richard Esplin, Head of Product at Dock Labs
The Way We Have Always Done I.T.
Most identity and access management (IAM) systems hold sensitive data that is critical for our organizations to function. Though it is theoretically possible to use hashing, salting, and encryption techniques to secure an IAM database against attackers, in the real world these systems are juicy targets for hackers who can make a profit from selling the data or holding it hostage.
The traditional approach to securing these systems is to host them in fortified castles surrounded by walls of authentication, moats of firewalls, and locks of encrypted storage.
Applications that connect to these systems are either deployed within the trust boundary, or require integration through APIs that tunnel through the layers of security. Each of these integrations can be a new attack vector that has to be protected lest the entire network is compromised.
Over time, IAM systems become more complicated as schemas are updated and the number of authorization policies grows. As a single point of failure, administrators are cautious about making changes to the centralized IAM directory to adapt to new use cases. This lack of flexibility incentivizes the creation of silos that undermine governance policies.
And Then Systems Propagate
As additional teams set up new applications, they are encouraged to integrate with the centralized IAM. If this is complicated due to firewall access or because they want more control over their critical systems, they may choose to set up siloed IAM systems—sometimes without IT approval. The resulting identity sprawl undermines organizational governance.
When there are multiple external applications, IAM architects may try to reduce the propagation of silos by creating a secondary IAM directory with its own security boundary which then has to be synchronized with the main directory. This results in two security boundaries that have to be policed, and a vulnerability in either boundary can leave the other one at risk. These directories have a tendency to drift apart over time causing failures in synchronization, inconsistent access controls, and a lack of central visibility for audit and compliance teams.
And Hackers Infiltrate
It has become clear over the past decade that authentication systems and firewalls are not sufficient to keep attackers out of our networks, especially in a complicated organization. It’s naive to trust that systems within the firewall are secure. Zero trust network architectures promote perimeterless security, where every system authenticates every interaction.
A zero trust architecture provides robust security when implemented correctly, but real world environments often fall short as developers tasked with complicated integrations struggle to federate with an identity provider while also following zero trust principles like risk-based adaptive access, fine-grained policy orchestration, continuous authentication, and context-aware authorization.
So We Decentralize
Verifiable credentials are a new technology that avoids the problems of federation by enabling a decentralized architecture. Credentials contain signed attributes that are issued from an identity proofing system into a wallet for identity data that is controlled by the subject of the credentials—often referred to as the credential holder.
The holder takes these credentials with them to the applications where the holder needs to interact as a user. These applications verify the credentials by checking that they come from a trusted issuer and that the cryptography ensures that they have not been modified since they were issued. Once the integrity of the credentials are established, the information can be used for authentication. When combined with the authorization policy of an application, the credential data can also be used to grant appropriate access to the user.
The wallet is considered an untrusted application, and does not have access into the security boundary. When a user’s identity needs to be checked, the verifying application requests a proof from the user’s wallet and the application can reject the information if anything appears suspicious. Using a standard credential presentation API to pull data from the user’s identity wallet replaces the need to federate with a centralized identity provider. Because verifiable credentials can contain significant amounts of data, they can simplify context-aware authorization and fine-grained policy orchestration. Credential data can also be used by session telemetry systems to inform anomaly detection.
Not only does an architecture built around exchanging verifiable credentials support zero trust principles, it is also flexible because it is easy to introduce additional issuers, credential types, and applications based on the evolving needs of the organization. Having the applications manage their own authorization policies reduces the need for cross-team coordination and simplifies governance. In addition, this architecture distributes the storage of identity data across the users’ wallets, so there is no single database to attack.
But Isn’t Decentralization Hard?
Introducing an identity wallet into an existing IAM architecture seems like a big change, but it’s a very similar user experience to current login processes that require an authenticator app for a password, OTP code, or passkey. In practice, a verifiable credential functions much like a passkey, but with the additional flexibility of containing tamper proof identity data.
Networks can evolve through a hybrid stage where the federated IAM systems issue and verify credentials across security boundaries, and then provide traditional IAM services to legacy applications. New applications can directly access the user’s wallet.
As use cases are moved to the decentralized architecture, less data needs to be held centrally, thereby reducing the IAM database’s attractiveness as a target for hackers. Over time, the centralized IAM directory becomes easier to secure, and in some cases can be eliminated.
Moving from a centralized directory to decentralized credential storage may require new approaches to observability and policy enforcement. Applications acting as relying parties can continue using existing tools to ensure that VC-based access is provided according to centralized security policies, though event reporting will likely need to be updated to reference the credential data used to make authentication and authorization decisions. Verifiable credentials also provide new capabilities for the governance of schemas in ecosystems of trust, expiration and revocation of credentials, and secure wallet recovery. These aspects of credentials can compliment traditional enforcement mechanisms.
Modern threats require new tools. Verifiable credentials not only help us to secure our systems, but also improve our ability to evolve our IAM architectures to address the needs of fast paced organizations. If you’re navigating these same challenges, we’d love to hear how you’re approaching them.
I acknowledge that JC Ferguson, Sooraj Payyoormana, and Mike Parkhill kindly provided educational feedback on the ideas in this article, but all mistakes in this analysis are my own.
