The frontier: machine identity and verifiable credentials

Forty minutes too long

On a Friday evening, Sara López’s laptop is stolen from a café. She calls the help desk from a friend’s phone, and within ten minutes her account is disabled and her sessions at the identity provider are revoked. On Monday, the security team reviews the logs and finds that the thief’s browser kept calling the expense API for another forty minutes. The access token it held was a self-contained JWT valid for an hour, and the API had no way of knowing the account behind it no longer existed. While they’re at it, they notice something worse: a build job in the CI pipeline authenticates to production with an API key that has lived in a config file for three years.

Neither problem is exotic, and neither is solved by the core protocols on their own. That’s where the frontier comes in. We close the protocols module by looking ahead, and identity is being pushed in two directions at once. One frontier is machines: modern systems are sprawls of microservices, containers, and functions that authenticate to each other constantly, at a scale and speed no human sign-in model anticipated. The other is people: a movement to give individuals control of their own credentials, carried in a wallet and presented on their own terms.

Neither is science fiction. The workload side is in production at large companies today, and governments are rolling out the wallet side. Both are still moving quickly, though, so read this article as a map of where things are heading rather than a settled reference. Both shifts share one idea: shrinking standing trust. On the machine side that means tokens scoped to a single hop and bound to their sender, and identities that live for minutes. On the human side it means credentials the holder controls and reveals selectively, instead of a provider holding and brokering everything.

Why now

Several forces are pushing these ideas from footnote to frontier. Cloud-native systems replaced a few big applications with thousands of small services and short-lived workloads, so machine-to-machine authentication went from an edge case to most of the authentication happening in a system, and human sign-in models don’t fit that shape. Incident reports keep landing on the same causes: a stolen bearer token replayed somewhere else, a long-lived secret leaked in a repository, a session that stayed valid long after it should have died, exactly what Sara’s team found on Monday. Token exchange, DPoP, SPIFFE, and CAEP each target one of those failures.

Non-human identities have also exploded. Service accounts, workloads, and now autonomous AI agents acting on people’s behalf already outnumber human identities many times over, and each of them needs to authenticate, be scoped, and be revoked like anyone else. And on the human side, regulation and public distrust of data brokers push toward models in which people present proofs instead of providers brokering their data on every transaction, which is what wallets and verifiable credentials allow.

The microservices problem

A single request to a modern app can fan out across dozens of services: an API gateway calls the expenses service, which calls payments, which calls a ledger. How does the payments service know the call really comes from Sara, acting within her permissions, and not from a confused or compromised neighbor? The naive answer, forwarding Sara’s original access token to every service, is the anti-pattern. That token grants far more than any single hop needs, and because it’s a bearer token, anyone who captures it anywhere along the chain can replay it everywhere. The frontier standards go after both halves of the problem.

Token exchange: least privilege per hop

OAuth Token Exchange (RFC 8693) lets a service trade the token it holds for a different one: narrower in scope, addressed to the next service, and optionally carrying delegation (“service A is acting for Sara”) or impersonation. Each hop asks for a token minted for the next service only, with only the scope it needs.

sequenceDiagram
  accTitle: OAuth token exchange across microservices
  accDescr: A user calls the expenses service with a broad access token. Before calling the downstream payments service, the expenses 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 token addressed to payments. The expenses 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 (Sara)
  participant O as Expenses service
  participant AS as Authorization server
  participant P as Payments service
  U->>O: Request (broad user token)
  O->>AS: Token exchange: "a token for payments only"
  AS->>O: Downscoped token (aud=payments)
  O->>P: Call payments (narrow token)
  P->>O: Result

The result is least privilege deep inside the system, not only at the front door. A token captured between the expenses and payments services works at payments and nowhere else, and the chain of delegation is explicit and auditable. It’s the JML principle of “only the access the task needs,” pushed down to a single call between services.

RFC 8693 distinguishes two modes. In delegation, the new token records that the service is acting on behalf of Sara, so both identities stay visible, which is the honest and auditable default. In impersonation, the token simply becomes Sara, with no trace of the intermediate service. Delegation preserves the chain of custody and is usually what you want. Impersonation is sometimes necessary, but it erases who actually made the call, so use 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 basic weakness of any bearer token is that holding it is enough. Steal it and you are its owner. DPoP binds the token to its sender. The client generates a key pair, the token is tied to that public key, and on every request the client signs a small proof with the private key. The server accepts the token only together with a valid proof, so a token lifted from a log or an intercepted call is inert without the private key, which never left the legitimate client. Had Sara’s expense app used DPoP, the token on the stolen laptop would still have been usable, since the key was on that laptop too, but a copy of it leaked anywhere else would have been worthless.

DPoP is the lightweight cousin of the mutual TLS we met among the veterans. It binds the token to its sender at the application layer, over ordinary HTTPS, without issuing a certificate to every client. It’s the answer to the warning in the tokens article that bearer tokens can be stolen, and it’s moving from cutting edge to expected for high-value APIs. A bearer token is cash; DPoP is the chip and PIN that makes a stolen card worthless.

SPIFFE and the service mesh: identity for workloads

Token exchange and DPoP protect the calls; SPIFFE protects the callers. The deeper question in a world of microservices is how a workload gets an identity at all. The old answer, baking a shared secret or API key into each service, produces a sprawl of long-lived credentials nobody rotates, like the CI key Sara’s team found. SPIFFE (Secure Production Identity Framework for Everyone) replaces that with cryptographic workload identity. Every service gets a SPIFFE Verifiable Identity Document, an SVID, which is an X.509 certificate or a JWT naming it, issued and rotated automatically by the runtime, SPIRE.

In a service mesh like Istio, this is the machinery that lets every call between services 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 that last minutes rather than years. As non-human identities outnumber people many times over, this layer is becoming as basic as the human directory. Before long, “who can access this?” will mean a workload as often as a person.

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 stored long-lived secret. A CI/CD job or a function in cloud A proves what it is and receives a temporary credential in cloud B, with no API key to leak and no secret to rotate. That’s how Sara’s team replaced the three-year-old key: the build job now presents a token from the CI platform’s identity provider and gets credentials that expire within the hour. It’s the same instinct as SPIFFE, getting rid of standing secrets, applied across trust boundaries, and it’s quickly becoming the default way to connect cloud systems.

Continuous access evaluation: closing the revocation gap

Back to the forty minutes. As the tokens article explained, a self-contained token stays valid until it expires, so revoking access in the middle of a session is hard. The frontier’s answer is to evaluate access continuously instead of deciding it once at sign-in. The Shared Signals Framework and its CAEP profile (Continuous Access Evaluation Profile) let identity providers and applications exchange security events in real time: this session was revoked, this device is no longer compliant, this user’s risk just jumped.

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 change is conceptual: access stops being a fact established at sign-in and becomes a live subscription that any party can update. When the help desk disabled Sara’s account, a CAEP signal would have reached the expense API within seconds, and the stolen laptop’s session would have ended there instead of forty minutes later. Expect this to spread wherever “valid until it expires” is too dangerous a default.

Zero Trust as the common thread

Every machine-side technology here is, underneath, a way of putting one idea into practice: Zero Trust. The principle, set out in NIST SP 800-207, is “never trust, always verify”: no implicit trust based on network location, every request authenticated and authorized, least privilege everywhere, and assume breach. Token exchange per hop is least privilege per request rather than per session. DPoP, mTLS, and SPIFFE verify the sender instead of trusting possession. CAEP re-verifies continuously instead of trusting a past decision forever. Short-lived workload identities assume any credential may be compromised and make it expire quickly.

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

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) turn that around. An issuer, such as a government, university, or employer, gives you a signed, tamper-evident credential. You keep it in a wallet on your device. When a verifier needs proof, you present it directly, and the verifier checks the issuer’s signature without contacting the issuer. You, the holder, sit in the middle and stay in control.

Two building blocks make this work. A verifiable credential (W3C VC Data Model) is the signed claim itself. A decentralized identifier, or DID (W3C DID), is an identifier the subject controls, anchored to a public registry or ledger instead of issued and owned by a single provider, so the issuer’s signature can be checked against a key governed by the holder rather than by a vendor. Together they make user-held identity possible: the holder decides what to present, to whom, and when.

Selective disclosure: proving less

One quietly radical capability of this model is selective disclosure, presenting only the specific fact a verifier needs rather than the whole credential. With the right cryptography, increasingly including zero-knowledge techniques, a holder can prove “I’m over 18” from a government ID credential without revealing their date of birth, name, or document number. Compare that with handing over a photo of your passport, which exposes everything. Disclosing as little as possible is the privacy gain the wallet model unlocks, and it’s a real improvement over both passwords and today’s federated sign-in.

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, compact published lists, often a bitstring, that a verifier consults to see whether a credential has been revoked without revealing which credential it’s checking. Revocation, issuer key rotation, and wallet recovery, what happens when you lose the phone that holds your credentials, are the unglamorous problems standing between today’s pilots and mass adoption. They’re the kind of detail that separates a demo from a system you can deploy.

OID4VCI and OID4VP: the bridge from OIDC

The risk with a new identity paradigm is that it reinvents everything and connects to nothing. The standards community avoided that by bridging verifiable credentials to the OIDC world this module has covered. OpenID for Verifiable Credential Issuance (OID4VCI) defines how a wallet obtains a credential from an issuer, and OpenID for Verifiable Presentations (OID4VP) defines how the wallet presents one to a verifier. Both run on the OAuth and OIDC machinery, the endpoints, tokens, and flows, so the huge existing ecosystem can issue and accept verifiable credentials without starting over. That 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).

Decentralized doesn’t mean the end of the directory, though. Companies will run directories, OIDC, and SCIM for the foreseeable future. Verifiable credentials add a new model alongside them, strongest where a person needs to prove something across organizations that don’t share a directory. As always in identity, the new layer joins the stack instead of replacing it.

Hype and reality

A frontier attracts hype, so it’s worth being clear about maturity. Token exchange, DPoP, SPIFFE and SPIRE, and workload identity federation are in production at scale in large engineering organizations; the machine frontier is real and arriving fast. CAEP and Shared Signals are past theory, with major providers shipping support, but not yet everywhere. Verifiable credentials and wallets are maturing with serious public-sector mandates behind them, the EU wallet and mobile driving licenses, but interoperability, revocation at scale, and usability are still being worked out.

So the workload frontier is something to learn now because you’ll use it soon, and the wallet frontier is something to watch closely because it’s coming. Neither is finished, which is 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) narrows tokens and readdresses them at each hop, so calls between microservices carry least privilege instead of one overpowered token forwarded everywhere.
2. DPoP (RFC 9449) binds tokens to their sender, so a stolen one is useless without the client’s private key: lightweight proof of possession over plain HTTPS.
3. SPIFFE and SPIRE give workloads cryptographic, automatically rotated identities (SVIDs), a directory and PKI for machines that powers mutual TLS in the service mesh. Workload identity federation extends the idea across clouds without standing secrets.
4. CAEP and Shared Signals turn access into a live subscription, pushing real-time events so sessions can be revoked mid-flight and closing the revocation gap of stateless tokens.
5. Zero Trust is the common thread: these mechanisms are how “never trust, always verify” becomes affordable plumbing instead of a slogan.
6. Verifiable credentials and DIDs put signed claims in a person’s wallet, presented to verifiers who trust the issuer’s signature without a live call and with selective disclosure for privacy. OID4VCI and OID4VP connect that model to OAuth and OIDC, and the new layer joins the stack rather than replacing it.

Hands-on exercises

These are meant to be done, not just read.

1. Trace least privilege. A request flows from the gateway to expenses, then payments, then the ledger. Show where you’d insert token exchange and what audience and scope each hop’s token should carry, then explain what a token stolen between expenses and payments could and couldn’t do.
2. Justify DPoP. 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 instead of plain bearer tokens.
3. Design workload identity. Twenty microservices authenticate to each other with a shared API key stored in an environment variable. Describe how SPIFFE and SPIRE change that and name three concrete risks it removes.
4. Close the revocation gap. An employee is let go and must lose access to ten SaaS apps immediately, but all of them use 15-minute JWTs. Explain how CAEP and Shared Signals solve this and what each app has to support.
5. Walk the triangle. Using the trust triangle, describe issuing an “over 18” credential and presenting it to a venue’s age-check site with selective disclosure. Name who signs, who stores, and who verifies, and exactly what the verifier does and doesn’t learn.
6. Map it to Zero Trust. Take one real failure, the CI key in a config file or the stolen laptop’s still-valid JWT, and name the frontier technology that addresses it and the Zero Trust principle it puts into practice.

Three questions to test yourself

1. Explain how token exchange and DPoP address 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?