Zero Trust is one of the most cited frameworks in enterprise security and one of the most inconsistently applied. Organizations declare Zero Trust compliance while their IAM directory sits behind a firewall, trusted implicitly by every application that depends on it. The architecture looks modern on the outside and carries a classic perimeter assumption at its core.
That gap is what our team and Justin Richer, Senior Staff Engineer at MongoDB, examined in a recent session on Zero Trust and federated identity. Richer has spent more than 20 years contributing to identity standards including OAuth, GNAP, and US federal identity standards published by NIST. He co-authored "OAuth 2 in Action" and was recently named to the 2026 Identity 25 by Okta Ventures.
The conversation covered the history and principles of Zero Trust, why federated identity architectures tend to recreate the perimeter problem, how verifiable credentials offer a structural alternative to directory synchronization, and what the emergence of agentic systems means for identity architecture going forward.
The Zero Trust Problem Starts With the Wrong Question
- The most important question in any Zero Trust initiative is not "are we doing Zero Trust?" but "Zero Trust in what, exactly?" Justin Richer framed this directly: the original coiners of the phrase meant zero trust in the local network, not zero trust in everything.
- Most organizations declaring Zero Trust compliance still trust their internal identity directory implicitly, which recreates the perimeter they were trying to eliminate.
- The classic failure pattern: an organization sets up a Zero Trust architecture and then places its IAM directory at the center of it, protected by a firewall. The directory becomes the "soft chewy center" the whole framework was designed to get rid of.
- Richard Esplin described this as the "castle and moat" failure: you end up with a hard perimeter and a soft interior, which is exactly the Cadbury egg metaphor from the 1994 Network World article that first named the problem.
Federated Identity Amplifies the Trust Fragility Problem
- The common enterprise response to multi-domain or post-acquisition identity challenges is to synchronize directories. Richard Esplin described this as manageable for the first two silos but increasingly unworkable as the number of directories grows.
- Synchronization introduces brittleness: when sync breaks, or when a new data element needs to be added to the primary directory, the ripple effects can touch every application in the ecosystem.
- Justin Richer extended this point to acquisitions specifically: syncing between a parent company and an acquired subsidiary creates what looks like distributed architecture but actually dilutes trust throughout the whole system rather than isolating it.
- The "gold source" illusion is common: every copy of the directory gets treated as authoritative, which means no single source of truth actually exists.
Verifiable Credentials as a Design Pattern, Not Just a Technology
- Richard Esplin's core argument is that moving identity data into a user wallet shifts the IAM directory from the "center of everything" to an identity proofing server, which is a meaningful architectural change.
- Verifiable credentials are designed for an untrusted wallet: every time data is presented from the wallet, it must be re-authenticated (is it signed by a trusted authority, has it been tampered with, does it contain the right information). Each interaction is Zero Trust by default.
- The practical benefit for enterprises is that introducing a new data element does not require changing the central directory or breaking existing integrations. A new credential is just another credential.
- Richard framed this explicitly as a design pattern for flexibility, not a Truvera-specific feature: "There is no single approach to do this."
- Justin Richer pushed back usefully on the framing of the wallet as "untrusted": the carrier of a credential does not need to be a previously known or highly trusted component, but the applications are still trusting the credential service provider (CSP) that did the identity proofing. Trust is transitive and often transient, not absent.
X.509 and VCs: The Same Problem, A Different Era
- Justin Richer described verifiable credentials as "taking another swing at reinventing X.509 certificates" but for an online, dynamic world.
- The original PKI infrastructure was designed for a disconnected world: you trace the chain back to a certificate authority offline. Everything built on top of it (OCSP, CRLs, certificate pinning) is a workaround for the fact that X.509 was never designed for online, real-time use.
- A concrete illustration: US federal PIV cards have a six-year lifecycle. If someone changes their name, email, or affiliation within two months of issuance, the credential is already stale but still valid.
- VCs are designed for shorter issuance lifetimes, online presentation, and selective disclosure. The verification is dynamic rather than static.
- The key conceptual shift Justin highlighted: with X.509, you send the same document to every verifier for the life of the certificate. With VCs, the presentation can differ each time, which enables minimal disclosure and supports Zero Trust principles at the data layer.
Shared Signals: Valuable but Structurally Asymmetric
- Shared Signals and Events (SSE) is well-suited for propagating security events across distributed systems, but it only addresses one part of the Zero Trust problem.
- Justin Richer noted a structural problem in how large-scale providers engage with SSE: they are often willing to receive signals from outside parties but reluctant to share signals about what they observe. The trust relationship is highly asymmetrical.
- Non-standard extensions and incompatible implementations are a known limitation. The standard works well within a contained ecosystem but becomes harder to rely on across trust boundaries.
- Richard's assessment: SSE is something every identity practitioner should understand and use, but it does not solve the full problem of dynamic authorization and trust model flexibility.
GNAP: The Right Answers, Limited Adoption
- Justin Richer, as a contributor to the GNAP specification, was direct about its current state: GNAP solves multi-party delegation, ephemeral clients, and fine-grained access natively, but has seen limited adoption where existing OAuth ecosystems were already in place.
- The core insight: if you are not bound by a legacy OAuth system, GNAP does many things cleanly that OAuth is still catching up to. If you are embedded in an existing OAuth ecosystem, OAuth plus extensions will get you very far.
- One example of GNAP's influence on OAuth: Rich Authorization Requests (RAR), which backported GNAP's fine-grained access model into OAuth 2. In GNAP, fine-grained access is a core architectural principle. In OAuth, it has to coexist alongside scopes, resource parameters, audience parameters, and multiple policy extension mechanisms.
- Justin's practical guidance: OAuth for existing systems; GNAP for greenfield or ecosystem-specific deployments where its native capabilities fit better.
SPIFFE: Strong in Its Lane, Scoped by Design
- SPIFFE and its open-source implementation SPIRE are well-adopted for workload identity in cloud-native environments, with short-lived credentials and federation across trust domains within a single infrastructure.
- Justin Richer framed SPIFFE's focus on non-user-facing flows as a strength rather than a limitation: any protocol that claims to solve all identity problems across an entire stack should be treated with skepticism.
- The core innovation is automating certificate issuance for ephemeral workloads: traditional CSR processes that work fine for servers with multi-year lifetimes are "orders of magnitude too slow" for workloads that spin up and down in seconds.
- The trust model in SPIFFE is opinionated: a workload trusts the sidecar agent deployed by the platform, not its own ability to attest to its identity. This is a deliberate design choice that returns to the fundamental Zero Trust framing: zero trust in what?
Agentic Identity Is Pushing the Industry Beyond Current Models
- Justin Richer's most substantive point on AI agents: we are hitting agentic systems with two hammers: the human identity hammer (authentication, delegation, on-behalf-of semantics) and the workload identity hammer (SPIFFE, ephemeral credentials). Neither fits cleanly.
- The distinction between "acting on behalf of" and "acting for the benefit of" is a meaningful semantic difference with practical consequences. An agent acting on behalf of someone is a tool executing a known intent. An agent acting for someone's benefit may be taking actions the person would not have chosen and could not have predicted.
- This distinction matters for auditability, observability, and liability. When an agent acts for someone's benefit and something goes wrong, who is responsible?
- Justin credited George Fletcher for articulating this framing, and noted that work in the OpenID Foundation's "digital estate" working group is pushing similar questions around delegation semantics in human identity contexts.
- Richard noted that agents introduce a new axis to the "zero trust in what" question: trust in the intent and scope of an autonomous system acting within your infrastructure.
The Architecture Shift: From Directories to Ecosystems
- Richard Esplin referenced Justin Richer's "identity bubbles" framing: instead of granting access to a central directory, identity becomes about moving data between bounded trust domains (bubbles). Over time, those bubbles form a resilient foam.
- The practical transition path Richard outlined does not require every application to support wallets immediately. The wallet can be introduced at the domain boundary, replacing directory synchronization with credential presentation. Applications behind the boundary do not need to change.
- Over time, the IAM directory becomes an issuer and verifier rather than the center of the trust graph. Applications can then be migrated to work directly with credentials, deprecating IAM-specific integrations incrementally.
- Justin's closing answer to the question "what would a Zero Trust native identity architecture look like from scratch?" was: start by answering what you want to have zero trust in. Without that answer, any architecture is solving a problem that has not been fully articulated.
