The frontier: machine identity and verifiable credentials

Two frontiers at once

We close the protocols module by looking forward. Identity is being pushed in two directions at the same time, and both are reshaping the standards. One frontier is machines: modern systems are sprawls of microservices, containers, and functions that must authenticate to each other constantly, at a scale and speed no human login model anticipated. The other is people: a movement to give individuals back control of their own credentials, carried in a wallet, presented on their terms. Crudely: machines proving who they are, and humans carrying identity in a wallet.

Neither is science fiction — the workload side is in production at large companies today, and the wallet side is being rolled out by governments. But both are still moving fast, so treat this article as a map of where the puck is going, not a settled reference. We’ll take the machine frontier first, then the human one.

Why this is happening now

Three forces converge to make this the frontier rather than a footnote:

• Scale and architecture. Cloud-native systems replaced a few big applications with thousands of small services and ephemeral workloads, so machine-to-machine authentication went from an edge case to the dominant volume of authentication in a system. Human-login models simply don’t fit that shape.
• The breach pattern. Incident post-mortems keep landing on the same causes: a stolen bearer token replayed elsewhere, a long-lived secret leaked in a repository, a session that stayed valid long after it should have died. Token exchange, DPoP, SPIFFE, and CAEP each target one of those exact failure modes.
• The non-human identity explosion — including AI agents. Service accounts, workloads, and now autonomous AI agents acting on users’ behalf already outnumber human identities by large multiples, and each needs to authenticate, be scoped, and be revoked like anyone else. Giving non-human actors first-class, short-lived, least-privilege identity has become urgent rather than optional.
• Privacy and regulation. On the human side, regulation and public distrust of data brokers push toward models where people present proofs rather than providers brokering their data on every transaction — exactly what wallets and verifiable credentials enable.

The microservices problem

A single user request to a modern app can fan out across dozens of services — an API gateway calls an orders service, which calls payments, which calls a ledger. How does the payments service know the call really represents user María, acting within her permissions, and not a confused or compromised neighbor? The naive answer — forward the user’s original access token to every service — is exactly the anti-pattern: that token is over-privileged for any single hop, and because it’s a bearer token, anyone who captures it anywhere along the chain can replay it everywhere. The frontier standards attack both halves of that problem.

Token exchange: least privilege per hop

OAuth Token Exchange (RFC 8693) lets a service trade the token it holds for a different one — downscoped, re-audienced for the next service, and optionally carrying delegation (“service A is acting for user María”) or impersonation semantics. Each hop requests a token minted for only the next service and only the scope it needs.

sequenceDiagram
  accTitle: OAuth token exchange across microservices
  accDescr: A user calls the orders service with a broad access token. Before calling the downstream payments service, the orders service sends that token to the authorization server's token-exchange endpoint and requests a new token scoped only to the payments service. The authorization server returns a downscoped, re-audienced token. The orders service then calls payments with that narrow token, so each service receives only the privilege it needs and a token captured between hops is scoped to a single audience.
  actor U as User (María)
  participant O as Orders service
  participant AS as Authorization Server
  participant P as Payments service
  U->>O: Request (broad user token)
  O->>AS: Token exchange: "give me a token for payments only"
  AS->>O: Downscoped token (aud=payments)
  O->>P: Call payments (narrow token)
  P->>O: Result

The payoff is least privilege deep inside the system, not just at the front door: a token captured between the orders and payments services is scoped to payments alone and useless against the ledger, and the chain of delegation is explicit and auditable. It’s the JML principle of “only the access the task needs” pushed down to the level of a single inter-service call.

RFC 8693 distinguishes two modes worth knowing. In delegation, the new token records that the service is acting on behalf of María — both identities remain visible, which is the honest, auditable default. In impersonation, the token simply becomes María, with no trace of the intermediary service. Delegation preserves the chain of custody and is what you usually want; impersonation is occasionally necessary but erases who actually made the call, so reach for it sparingly and log heavily when you do.

DPoP: making stolen tokens useless

Token exchange narrows what a token can do; DPoP (Demonstrating Proof-of-Possession, RFC 9449) narrows who can use it. The core weakness of any bearer token is that possession equals authority — steal it and you are it. DPoP sender-constrains the token: the client generates a key pair, the token is bound to that public key, and on every request the client signs a small proof with the private key. A server accepts the token only alongside a valid proof, so a token lifted from a log or an intercepted call is inert without the private key that never left the legitimate client.

This is the lightweight cousin of the mutual TLS we met among the veterans — it achieves sender-constraining at the application layer, over ordinary HTTPS, without provisioning a certificate to every client. It’s the answer to the “bearer tokens are stealable” caveat we flagged in the tokens article, and it’s moving from cutting-edge to expected for high-value APIs. If you internalize one rule from this whole module, let it be this: a bearer token is cash, and DPoP is the chip-and-PIN that makes a stolen one worthless.

SPIFFE and the service mesh: identity for workloads

Token exchange and DPoP secure the calls; SPIFFE secures the callers. The deeper question in a microservices world is: how does a workload have an identity at all? The old answer — bake a shared secret or API key into each service — is a sprawl of long-lived credentials nobody rotates. SPIFFE (Secure Production Identity Framework for Everyone) replaces that with a cryptographic workload identity: every service gets a SPIFFE Verifiable Identity Document (an SVID, an X.509 certificate or JWT) naming it, issued and automatically rotated by the runtime (its implementation, SPIRE).

In a service mesh like Istio, this is the machinery that lets every service-to-service call run over mutual TLS with both sides cryptographically identified — without developers managing a single certificate. SPIFFE is, in effect, a directory and PKI for machines: where Active Directory answers “who is this user,” SPIFFE answers “which workload is this,” with credentials measured in minutes rather than years. As non-human identities come to outnumber humans by large multiples, this workload-identity layer is becoming as foundational as the human directory. Put bluntly: within a few years, “who can access this?” will as often mean a workload as a person, and the systems that answer that question for machines are being built right now.

Workload identity federation

A close relative solves the cross-cloud version of the same problem. Workload identity federation lets a workload in one environment authenticate to another using a short-lived, OIDC-based assertion of its own identity, instead of a long-lived stored secret. A CI/CD job or a function in cloud A proves what it is and is granted a temporary credential in cloud B — no API key to leak, no secret to rotate. It’s the same “eliminate standing secrets” instinct as SPIFFE, applied across trust boundaries, and it’s quickly becoming the default way to wire cloud systems together.

Continuous access evaluation: closing the revocation gap

Remember the unsolved problem from the tokens article: a self-contained token stays valid until it expires, so revoking access mid-session is hard. The frontier answer is to make access continuously evaluated rather than decided once at login. The Shared Signals Framework and its CAEP (Continuous Access Evaluation Profile) let identity providers and applications exchange real-time security events — “this session was revoked,” “this device is now non-compliant,” “this user’s risk just spiked.”

flowchart LR
  accTitle: Continuous access evaluation via shared signals
  accDescr: An identity provider detects a security event, such as a session being revoked, a device becoming non-compliant, or a user's risk level rising. Through the Shared Signals Framework it pushes a security event signal to each subscribed application in real time. Each application receives the signal and immediately re-evaluates or terminates the affected session, instead of continuing to trust an already-issued token until it expires.
  EV[Security event<br/>session revoked · device risk · anomaly] --> IDP[Identity provider]
  IDP -->|push signal| A1[App A re-evaluates / ends session]
  IDP -->|push signal| A2[App B re-evaluates / ends session]
  IDP -->|push signal| A3[App C re-evaluates / ends session]

The shift is conceptual: from access as a fact established at login to access as a live subscription that any party can update. It’s a direct, ecosystem-scale answer to the revocation weakness of stateless tokens — and it’s how a compromised session can be killed across many apps in seconds rather than lingering until expiry. Expect it to spread wherever “valid until it expires” is too dangerous a default.

The other frontier: verifiable credentials and wallets

Now the human side. Today, when you prove something about yourself — your age, your degree, your professional license — you usually do it by letting a provider vouch for you in real time, which means that provider sees every transaction and holds the data. Verifiable credentials (VCs) invert this. An issuer (a government, university, employer) gives you a signed, tamper-evident credential; you keep it in a wallet on your device; and when a verifier needs proof, you present it directly, and they check the issuer’s signature without contacting the issuer. You — the holder — are in the middle, in control.

Fullscreen

Two building blocks make this work. A verifiable credential (W3C VC Data Model) is the signed claim itself. A decentralized identifier (DID) (W3C DID) is an identifier the subject controls — anchored to a public registry or ledger rather than issued and owned by a single provider — so the issuer’s signature can be verified against a key the holder, not a vendor, governs. The combination enables genuinely user-held, privacy-respecting identity: the holder decides what to present, to whom, and when.

The open problem: revocation at scale

The trust triangle has a catch that mirrors the token revocation problem: if a verifier checks a credential without contacting the issuer, how does a leaked, expired, or withdrawn credential get revoked? The emerging answer is status lists — a compact, privacy-preserving published list (often a bitstring) that a verifier consults to see whether a credential has been revoked, without revealing which credential is being checked. Revocation, issuer key rotation, and wallet recovery (what happens when you lose the phone holding your credentials?) are the unglamorous problems standing between today’s pilots and mass adoption — and they’re exactly the kind of detail that separates a demo from a deployable system.

Selective disclosure: proving less

A quietly radical capability of this model is selective disclosure — presenting only the specific fact a verifier needs, not the whole credential. With the right cryptography (and, increasingly, zero-knowledge techniques), a holder can prove “I am over 18” from a government ID credential without revealing their birth date, name, or document number. Compare that to handing over a photo of your passport, which exposes everything. Minimizing what’s disclosed is the privacy frontier the wallet model unlocks, and it’s a genuine improvement over both passwords and today’s federated login.

OID4VCI and OID4VP: the bridge from OIDC

The risk with a new identity paradigm is that it reinvents everything and integrates with nothing. The standards community avoided that by bridging verifiable credentials to the OIDC world we spent this module learning. OpenID for Verifiable Credential Issuance (OID4VCI) defines how a wallet obtains a credential from an issuer; OpenID for Verifiable Presentations (OID4VP) defines how the wallet presents one to a verifier. Both ride on the OAuth/OIDC machinery — endpoints, tokens, flows — so the enormous existing ecosystem can issue and consume verifiable credentials without starting over. This pragmatism is why the wallet model has real momentum, most visibly in the EU Digital Identity Wallet (under eIDAS 2.0) and the ISO mobile driving license (mDL, ISO 18013-5).

The Zero Trust through-line

Step back and every frontier technology here is, at bottom, an implementation detail of one idea: Zero Trust. The principle — codified in NIST SP 800-207 — is “never trust, always verify”: no implicit trust from network location, every request authenticated and authorized, least privilege everywhere, and assume breach. The frontier standards are how that philosophy becomes affordable plumbing:

• Per-hop token exchange = least privilege per request, not per session.
• DPoP and mTLS / SPIFFE = verify the sender, never trust mere possession.
• CAEP / Shared Signals = re-verify continuously, never trust a past decision forever.
• Short-lived workload identities = assume any credential may be compromised, so expire it fast.

Zero Trust is the philosophy (we met it back in identity-centric security); these protocols are the machinery that makes “verify every time” cheap enough to actually do at scale. When someone says “we’re doing Zero Trust,” this stack is much of what they should mean — otherwise it’s a slogan without plumbing.

Hype versus reality

A frontier attracts hype, so it’s worth being clear-eyed about maturity:

• In production now: token exchange, DPoP, SPIFFE/SPIRE, and workload identity federation are deployed at scale by large engineering organizations. The machine frontier is real and arriving fast.
• Emerging fast: CAEP / Shared Signals is past theory, with major providers shipping support, but not yet ubiquitous.
• Early but government-propelled: verifiable credentials and wallets are maturing, with serious public-sector mandates (the EU wallet, mDLs) driving adoption — but interoperability, revocation at scale, and UX are still being worked out.

The honest stance: the workload frontier is a “learn it now, you’ll use it soon” topic; the wallet frontier is a “watch it closely, it’s coming” topic. Both are worth understanding, neither is finished, and that’s exactly what makes them the frontier.

Recap

The frontier pushes least privilege and user control further than the core protocols did:

1. Token exchange (RFC 8693) downscopes and re-audiences tokens per hop, so microservice calls carry least privilege instead of forwarding one over-powered token.
2. DPoP (RFC 9449) sender-constrains tokens so a stolen one is useless without the client’s private key — lightweight proof-of-possession over plain HTTPS.
3. SPIFFE / SPIRE gives workloads cryptographic, auto-rotated identities (SVIDs) — a directory and PKI for machines — powering mutual TLS in the service mesh; workload identity federation extends it across clouds without standing secrets.
4. CAEP / Shared Signals makes access a live subscription, pushing real-time events so sessions can be revoked mid-flight — closing the stateless-token revocation gap.
5. Verifiable credentials + DIDs put signed claims in a user’s wallet, presented to verifiers who trust the issuer’s signature without a live call — with selective disclosure for privacy.
6. OID4VCI / OID4VP bridge the wallet model onto OAuth/OIDC, which is why it has real momentum (EU wallet, mDL). The new layer joins the stack; it doesn’t replace it — the same lesson every era of this module has taught, from LDAP to the wallet.
7. Zero Trust is the through-line: token exchange, DPoP/SPIFFE, CAEP, and short-lived workload identity are how “never trust, always verify” becomes affordable plumbing rather than a slogan.

Hands-on exercises

These are practical — do them, don’t just read them:

1. Trace least privilege (use case). A request flows gateway → orders → payments → ledger. Show where you’d insert token exchange and what audience/scope each hop’s token should carry, then explain what a token stolen between orders and payments could and couldn’t do.
2. Justify DPoP (use case). A team says “we use HTTPS, so token theft isn’t a concern.” Explain the gap DPoP closes that TLS doesn’t, and when you’d require it versus plain bearer tokens.
3. Design workload identity (use case). Twenty microservices currently authenticate to each other with a shared API key in an env var. Describe how SPIFFE/SPIRE changes that and three concrete risks it removes.
4. Close the revocation gap (use case). A user is fired and must lose access to ten SaaS apps immediately, but they all use 15-minute JWTs. Explain how CAEP / Shared Signals solves this and what each app must support.
5. Walk the triangle (use case). Using the trust-triangle diagram, describe issuing an “over-18” credential and presenting it to a bar’s age-check site with selective disclosure — name who signs, who stores, who verifies, and exactly what data the verifier does and doesn’t learn.
6. Map it to Zero Trust (use case). Take one real failure — a leaked CI secret, or a fired employee whose JWT is still valid — and name which frontier technology addresses it and which Zero Trust principle (“verify the sender,” “least privilege per request,” “re-verify continuously,” “assume breach”) it embodies.

Three questions to test yourself

1. Explain how token exchange and DPoP attack two different weaknesses of forwarding a bearer token through a chain of microservices.
2. Why is SPIFFE described as “a directory for machines,” and what problem with shared secrets does automatic SVID rotation solve?
3. In the verifiable-credentials model, how can a verifier trust a credential without ever contacting the issuer, and what does selective disclosure let the holder avoid revealing?