Can you verify a credential without phoning the issuer?

Almost every trustworthy check on the internet works by asking a third party a question, which means your verification is only as available, as private and as permanent as somebody else's API. The web PKI already fought this battle over certificate revocation and reached a clear conclusion. This is what it learned, and how to apply it to credentials.

The Friday afternoon when nothing could be verified

Picture an operations lead at a mid-size lender, four o'clock on a Friday. Twenty-two loan files are queued for final approval. Each one needs an identity check re-run against the verification vendor before funds release, because that is what the procedure says and what the auditor will look for.

The vendor's API starts returning timeouts. Not errors with useful codes, just silence and then a gateway timeout. The status page says all systems operational, which is what status pages say for the first forty minutes of every incident. Support ticket goes in. Nobody picks it up before the weekend.

Here is the thing that should bother you about this scene. Nothing changed about any of those twenty-two borrowers. Their identities were verified weeks ago. The evidence exists. Someone competent looked at documents, matched a face, ran the checks, and recorded a result. That work was done and paid for.

But the lender cannot use it, because the way they hold that evidence is as a promise that a third party will answer a question if asked. The evidence was never in their hands. It was always a phone number they could call, and on Friday afternoon nobody picked up.

Multiply that by every verification in the economy and you have the quiet architectural decision that nobody voted on: the internet decided that trust means being able to call someone.

What are you actually doing when you verify a credential?

Strip away the vocabulary and every verification answers four questions.

Did the issuer really say this? This is authenticity. It is the question cryptography answers best, with a signature.

Is it about the person in front of me? This is binding, and it is the one most systems handle worst. A credential that anyone can present is a bearer token wearing a suit.

Is it still true? This is status. Licences get revoked, employees leave, cards get cancelled. This question is where the callback usually sneaks in.

Is it recent enough for what I am about to do? This is freshness, and the correct answer depends entirely on the value of the action. Checking a bar membership before a coffee is not checking a surgeon's licence before an operation.

The interesting observation is that only the third and fourth questions have any reason to involve the issuer at the moment of use. Authenticity and binding can both be settled with material the holder carries. Yet in practice, systems phone home for all four, because calling the issuer is the simplest thing to build and it answers every question at once.

Why does almost everything phone home?

Because it works, it is easy, and for a long time nobody counted the cost. Here is the cost, in four parts.

Availability coupling

Your verification is only as available as the least available party in the chain. This sounds obvious and is routinely ignored in architecture reviews, because the issuer is usually up and the failure is rare enough to feel theoretical.

It stops feeling theoretical when it happens. In October 2023 Okta disclosed unauthorised access to its customer support case management system, affecting customers who had uploaded diagnostic files. In July 2024 a faulty CrowdStrike sensor content update took down a very large number of Windows hosts worldwide, with knock-on effects across airlines, hospitals and banks, and CrowdStrike published detailed remediation guidance afterwards. Neither of those was a verification outage specifically, and it would be sloppy to claim otherwise. What they demonstrated, at a scale everyone remembers, is the shape of the risk: when a component sits on the critical path for thousands of organisations, its bad day is everyone's bad day.

The relevant question for an architect is not how reliable the vendor is. It is what your process does when the vendor is unreachable, and whether the honest answer is "stops".

Privacy leakage

This one deserves more attention than it gets, because it is not a side effect. It is a structural property.

If verifying a credential requires contacting its issuer, then the issuer learns, in real time, every place that credential is used. A university learns which employers are checking a graduate's degree. A government learns which bars a citizen walks into. A verification vendor learns the customer list of every relying party who calls it.

Nobody designed that surveillance. It fell out of the architecture, which is exactly how the most durable surveillance gets built.

Latency and cost

A network round trip is between tens and hundreds of milliseconds, and it can be seconds when things are unwell. That is tolerable once at login. It is not tolerable when an agent system verifies thousands of delegations per second, which is the direction the machine population is heading, as we discussed in the piece on identity fan-out.

Per-verification pricing also means the cost scales with your success, which is a fine business model for the vendor and a poor one for a relying party whose margin does not.

Gatekeeping

The subtlest cost. If verification requires the issuer to answer, the issuer can decline. They can rate limit you, price you out, change terms, go out of business, or simply decide they would rather not serve your use case.

The holder of the credential, the person it is actually about, has no say in any of this. Their evidence about themselves is held hostage to a commercial relationship between two other parties.

What happened with certificate revocation, and why is it the best lesson available?

The web PKI has already fought this exact battle, in public, for twenty years. If you want to understand offline verification, this is the case study, and the ending is genuinely instructive.

The problem, in 2000

Certificates expire, but sometimes a key is compromised before expiry and the certificate must be killed early. The first answer was certificate revocation lists: the authority publishes a list of every revoked serial number, and clients download it. Lists grew large, downloads got expensive, and freshness suffered.

The second answer, standardised as the Online Certificate Status Protocol in RFC 6960, was elegantly simple. Before trusting a certificate, ask the issuing authority whether it is still good. One question, one answer, always current.

Why it broke

Three problems, and they are precisely our four costs wearing different clothes.

First, privacy. The browser told the certificate authority which website the user was visiting, at the moment they visited it. The authority became an unintentional log of the user's browsing.

Second, availability. If the responder was slow or down, what should the browser do? Blocking would mean an authority outage breaks the web. So browsers chose to continue, which is known as soft-fail, and the consequence is worth stating baldly: an attacker positioned to use a revoked certificate is generally also positioned to block the revocation check. A check that fails open against an active attacker is decorative.

Third, latency. An extra round trip before every new connection, on the critical path of page load.

How the industry actually fixed it

Not with one clever trick. With a combination, and this is the part worth copying.

Stapling. The server fetches a signed status response from the authority periodically and includes it in the handshake. The client gets fresh status with no extra round trip and no privacy leak, because the client never contacts the authority. Notice what happened structurally: the status became something carried with the credential rather than something fetched about it. That single move is the whole idea of this article.

Shorter lifetimes. If a certificate is only valid for a short period, revocation matters less, because the credential expires on its own. The industry has been steadily shortening certificate lifetimes for exactly this reason. Freshness by expiry rather than by interrogation.

Aggregate, compressed status. Mozilla's CRLite work showed that the revocation state of the entire web PKI can be compressed into a structure small enough to push to clients periodically. The client then answers revocation questions locally, with no network call and no leak.

Retiring the per-check callback. Let's Encrypt announced in December 2024 that it would end OCSP support in favour of certificate revocation lists, citing privacy among its reasons. The largest certificate issuer in the world concluded that asking the issuer per check was the wrong design.

That is the arc. Twenty years, real pain, and the conclusion is that status should travel with the credential, expire quickly, or be distributed in aggregate. Not fetched per use.

What does offline verification actually require?

Three components, and once you see them the rest is engineering.

One: a signature over a published key

The credential carries a signature. The verifier holds, or can fetch once and cache for a long time, the issuer's public key. Verification is then local arithmetic.

The key distribution is the part people wave at, so let us be precise. Publishing keys at a well known location, in a standard format such as a JSON Web Key Set, is well understood. The hard parts are rotation, which needs overlapping validity so old material still verifies, and compromise, which needs a way to say a key should no longer be trusted from a given date without invalidating everything it ever signed. These are solved problems in the PKI world and they are still real work.

Two: an explicit validity window

The credential states when it was issued and when it stops being good. This is freshness by construction. A verifier that receives an expired credential rejects it without asking anyone.

The design decision here is the interesting one. A short window means less revocation exposure and more re-issuance traffic. A long window is convenient and dangerous. The right answer is per action class, not global, which we come back to at the end.

Three: status without a per-check callback

The remaining question is whether something valid-looking has been revoked early. There are three good answers and you can combine them.

Make the window short enough that early revocation is rarely needed. Distribute status in aggregate, so the verifier holds a structure covering many credentials and consults it locally. Or have the holder present a recent signed status assertion alongside the credential, which is stapling by another name.

Putting it together

# Verify a receipt with no network call to the issuer.
# The verifier holds: published_keys (fetched rarely), status_list (refreshed hourly).

def verify(receipt, now, published_keys, status_list):
    key = published_keys.get(receipt["kid"])          # key id from the receipt
    if key is None or now > key["retired_after"]:
        return "unknown or retired signing key"

    if not ed25519_verify(receipt["signature"],
                          canonical_bytes(receipt["payload"]), key["pub"]):
        return "signature does not verify"            # authenticity

    p = receipt["payload"]
    if not (p["not_before"] <= now <= p["not_after"]):
        return "outside validity window"              # freshness

    if status_list.is_revoked(p["status_index"]):
        return "revoked"                              # status, checked locally

    if p["holder_key"] != presented_holder_key:
        return "presented by someone other than the holder"   # binding

    return "valid"

Read the four checks again and note that each one maps to one of the four questions from earlier. Authenticity, freshness, status, binding. No call to the issuer appears anywhere. The two pieces of external data, the key set and the status list, are fetched on a slow schedule and cover many credentials at once, which is what makes them cheap and non-identifying. The issuer learns nothing about where the credential was used, because the issuer was never in the conversation.

The last check is the one most systems forget. Without a holder binding, an offline-verifiable credential is a bearer token: whoever holds the bytes can present them. Binding it to a key the human controls, which is what a device-held passkey gives you, is what turns a valid credential into a valid credential about the person standing here.

What has the standards world already built?

A great deal, and anyone framing this as unexplored territory is not being straight with you. Three bodies of work matter.

W3C Verifiable Credentials. The Verifiable Credentials Data Model gives a standard shape for a credential with an issuer, a subject, claims and a proof. Crucially, the companion Bitstring Status List specification defines exactly the aggregate status mechanism described above: the issuer publishes a compressed bitstring, each credential carries an index into it, and the verifier checks a bit locally. It is the CRLite lesson, generalised and standardised.

SD-JWT and SD-JWT VC. Work in the IETF on selective disclosure for JSON Web Tokens lets a holder reveal some claims and withhold others while keeping the issuer's signature verifiable. This addresses a real problem: offline verification should not require handing the verifier your entire credential when they only needed to know one attribute.

ISO/IEC 18013-5. The mobile driving licence standard was designed from the start for offline presentation. A police officer at the roadside, a bartender in a basement, a verifier with no connectivity. It specifies device retrieval over local transports and a security model where the verifier checks the issuer's signature without any online contact. This is the standard that proves the model works in the physical world at national scale.

Manav's position on all of this should be plain: these are the serious prior art, the direction is right, and the correct posture is to conform and interoperate rather than to invent a competing envelope. Where the standards leave a gap is not the format. It is adoption, and the binding of a credential to a specific enrolled human whose continuity can be re-established later.

How do Manav's receipts do it?

Concretely, so you can judge it rather than take a claim.

A receipt is a small document recording that a specific enrolled human authorised a specific action. It contains the canonical payload of the action, the human's assertion over the hash of that payload, a validity window, a key identifier, and an Ed25519 signature. The signing keys are published at a well known endpoint. A verifier fetches that key set rarely, caches it, and from then on checks receipts with local arithmetic.

The properties that follow are the ones this article has been building toward. The issuer is not on the critical path, so an outage at Manav does not stop a verifier from verifying. The issuer does not learn where receipts are presented, because there is no callback to observe. Verification cost is a signature check, which is microseconds. And a receipt from 2026 still verifies in 2036 provided the key material has been archived, which is a filing problem rather than a service dependency.

Being straight about what is not shipped matters more than the pitch. Selective disclosure inside receipts, so a verifier sees only the field they need, is roadmap and not shipped. Zero knowledge predicates, such as proving a threshold without revealing the value, are roadmap. Threshold and multi-party signing are roadmap. Manav has filed drafts describing the receipt and delegation chain formats with standards bodies, and filed is not ratified, which is a meaningful distinction that vendors routinely blur.

How do the models compare?

Read down the middle two columns and the pattern is stark. Every model with immediate revocation is a model where the issuer watches. Every model where the issuer is blind has revocation measured in minutes or hours. That is not an implementation detail anyone has failed to optimise. It is the tradeoff itself.

The tradeoff nobody can engineer away

Here is the honest centre of this whole subject, and it is the part vendor material tends to skip.

Offline verification buys independence, privacy and availability by paying in revocation freshness. If nobody is asked at the moment of use, then nobody can report a change that happened five minutes ago. You cannot have instant revocation and issuer blindness at the same time. The best you can do is shrink the window and be deliberate about where you set it.

So the design question is not "online or offline". It is: for this action, how much staleness is acceptable, and what does it cost me to reduce it?

A useful way to reason about it is exposure per window. If a credential can be revoked at most once per refresh interval, and the action it authorises is worth some amount, then the expected cost of staleness is roughly the rate of revocation multiplied by the window multiplied by the value at risk. Shrink whichever of those three you can afford to shrink.

In practice that yields a simple policy shape. Low value and high volume, such as a content gate or a rate limit exemption, tolerates a long window and a plain signature check. Medium value, such as an employment claim or a login to a business system, wants an aggregate status list refreshed hourly. High value and irreversible, such as a large payment release or a controlled substance order, wants a short lived credential re-minted for the occasion, and quite reasonably may also want a live check, because at that value the availability cost of a callback is worth paying.

The mistake is not choosing online or offline. The mistake is choosing one of them globally and applying it to everything.

Honest limits

You cannot escape the issuer entirely. You have replaced a per-check dependency with a periodic one. If the issuer never publishes a key rotation, or the status list stops updating, you degrade. That is a far better failure mode, because it is slow and visible rather than sudden, but it is not nothing.

Key management becomes your problem. Archiving key material so a 2026 receipt still verifies in 2036 is a real records management discipline. Organisations that are bad at this today will be bad at it then.

Offline does not mean anonymous. A receipt still contains whatever the payload contains. Without selective disclosure, which is roadmap rather than shipped, a verifier sees the full payload. Minimise what goes into the payload in the first place.

Binding is doing heavy lifting. Everything above assumes the credential is bound to a key the correct human controls. If enrollment was sloppy, offline verification will faithfully and efficiently verify the wrong person's credential forever.

Some domains genuinely require live checks. Sanctions screening changes by the hour and the regulatory expectation is a check at the time of the transaction. Do not use this article to argue your way out of a rule that exists for good reasons.

What to do this week

1. Draw your callback dependency map. List every identity or credential check on a critical path and mark which third party must be reachable for it to succeed. Most teams find between four and ten and are surprised by at least two.
2. Write down what happens when each one is unreachable. If the answer is "we stop", you have found a business continuity issue that is currently filed as a vendor issue.
3. Measure the privacy exposure. For each callback, ask what the third party learns about your customers' activity from the pattern of your queries. Then ask whether you have told your customers that.
4. Classify actions by value and reversibility and assign each class a maximum acceptable staleness. This single exercise will settle most of the online versus offline debates in your architecture.
5. Pick one high volume, low value check and take it offline. A signature check against a cached key set is the cheapest possible win and it proves the pattern to sceptics.
6. Read the Bitstring Status List specification. It is short, and it will change how you think about revocation whether or not you adopt it.
7. Ask your vendors one question: can we verify your result without calling you? The answer, and the speed of the answer, tells you a great deal about the shape of the relationship.
8. Archive key material deliberately. Decide now where published keys and enrollment records live for the longest lived credential you issue, and who is responsible for them in ten years.

You can see the receipt format and the verification procedure in the developer documentation, watch a receipt being produced and checked in the verification lab, and read the delegation chain version of the same idea in the piece on the authority graph, where the same offline walk answers the question of what an agent was permitted to do.

Frequently asked questions

How can a credential be verified without calling its issuer? The credential must carry a signature that checks against a published key, an explicit validity window, and a status mechanism that does not need a per-check callback, such as a short lifetime or an aggregate status list. The verifier fetches keys and status on a slow schedule and then verifies locally, offline, without the issuer learning where the credential was used.

What happens to verification when the identity provider is down? With callback-based verification, it stops. Your process is only as available as the least available party in the chain, which is why an outage at a widely used provider becomes an outage for thousands of organisations at once. Offline verification degrades slowly instead: you keep verifying with the key set and status list you already hold, and only freshness decays.

Is OAuth token introspection a single point of failure? Yes, by design. RFC 7662 introspection puts the authorisation server on the critical path of every check. That gives immediate revocation, which is genuinely valuable, at the cost of availability coupling, latency, and the server observing every use. Short lived self-contained tokens are the usual trade in the other direction.

Why did the industry move away from OCSP? Three reasons. It told the certificate authority which sites a user visited, which is a privacy leak. It added a round trip to connection setup. And because blocking on failure would break the web, clients failed open, which meant an attacker able to use a revoked certificate could usually also block the check. Stapling, shorter lifetimes and aggregate lists replaced it.

Does a blockchain make credentials verifiable offline? No, and it is a common confusion. Offline verification comes from the credential carrying a signature that checks against a published key. That works with an ordinary key server. A blockchain adds cost and latency without removing the dependency on the issuer's signing keys, and reading current chain state is itself a network call.

What is the tradeoff you cannot engineer away? Revocation freshness against issuer independence. If nobody is asked at the moment of use, nobody can report a change that happened five minutes ago. You can shrink the staleness window with shorter lifetimes or faster status refresh, but you cannot have instant revocation and issuer blindness at the same time. Set the dial per action class.

Do W3C Verifiable Credentials and mDL already solve this? They solve the format and much of the mechanism, and they are the serious prior art. The Bitstring Status List specification defines exactly the aggregate status approach described here, and ISO 18013-5 was designed for offline presentation from the start. What formats do not supply is verifier adoption and the binding of a credential to a specific enrolled human.

Sources

1. RFC 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol, rfc-editor.org.
2. RFC 7662, OAuth 2.0 Token Introspection, rfc-editor.org.
3. Let's Encrypt, Intent to End OCSP Service, December 2024, letsencrypt.org.
4. Mozilla Security Blog, CRLite: all web PKI revocations, compressed, blog.mozilla.org.
5. W3C Verifiable Credentials Data Model 2.0, w3.org.
6. W3C Bitstring Status List, w3.org.
7. IETF Selective Disclosure for JWTs (SD-JWT), datatracker.ietf.org.
8. ISO/IEC 18013-5, Personal identification, mobile driving licence application, iso.org.
9. Okta security advisory on unauthorised access to its support case management system, October 2023, sec.okta.com.
10. CrowdStrike, Falcon content update remediation and guidance hub, July 2024, crowdstrike.com.

Every model with instant revocation is a model where the issuer watches. That is the tradeoff, and it is the only one that matters.