Why an identity vendor will not ship offline verification
This is not a criticism of any particular company's integrity. It is an observation about what a business model makes easy to build and what it makes structurally hard.
Why won't identity vendors ship offline verification?
Because the call is the product. Vendors such as Okta and Stytch meter on active users and API volume. A verification that requires no call produces no usage, works during their outage, survives cancellation and needs no account from the relying party. Every one of those is good for the customer and bad for the vendor's metrics.
- Identity platforms monetise on active users and API volume; a verification that requires no call produces no measurable usage.
- Offline verification also makes switching cheap, because the receipts remain valid without the vendor.
- The property is available from a format and published keys rather than from a service — which is why it tends to come from protocol layers.
Part of Category comparisons
What offline verification actually means
A relying party holds a receipt and a published key. They verify the signature locally. No request reaches the issuer, the issuer learns nothing about the verification, and it works if the issuer is unreachable or no longer exists.
That last clause is the commercially significant one.
The incentive analysis
| Property | Effect on a usage-priced vendor |
|---|---|
| No API call at verification | No metered usage from the highest-value operation |
| Works during a vendor outage | Removes a dependency the vendor benefits from |
| Receipts remain valid after cancellation | Removes a switching cost |
| Any party can verify without an account | Removes a reason for relying parties to become customers |
| Vendor cannot observe verification | No data on how the product is used |
Every row is good for the customer and bad for the vendor's metrics. A product manager proposing this feature would have to argue against all five, and would lose.
Being fair about it
This is not bad faith. Companies build what their model rewards, and a usage-priced platform genuinely does provide value through the services it meters: directory, policy, session management, lifecycle, connectors.
There are also legitimate technical reasons a platform prefers a callback: real-time revocation, policy evaluated at verification time, richer context. Those are real benefits and they trade against availability and independence.
The point is narrower. If offline verifiability is what you need, expect to get it from somewhere other than a platform whose revenue depends on the call.
What offline verification requires
Notably little, which is itself the argument.
- A canonical serialisation, so the digest is reproducible.
- A fixed signature algorithm.
- Public keys published at a stable location, retained for the retention period.
- A self-contained statement — no identifiers into systems that change.
- A verifier small enough to be audited or reimplemented.
None of that is a service. It is a format and a published key, which is why the property tends to emerge from specification work rather than from product roadmaps.
Why it matters to a buyer
Three scenarios where the difference is concrete.
| Scenario | Callback verification | Offline verification |
|---|---|---|
| Your vendor has an outage | Approvals cannot be verified | Unaffected |
| An auditor examines records from four years ago | Requires vendor cooperation and retention | Receipts plus published keys |
| You switch vendors | Historical approvals may become unverifiable | Historical receipts remain valid |
The second is the one that surprises people. Audit retention is typically longer than vendor relationships, so records generated under a platform you no longer use need to verify without it.
What to ask in procurement
- Can a third party verify an approval from your platform without calling your API? If not, what happens in year six of our retention period?
- If we terminate, do approvals issued during the contract remain verifiable? Get this in writing.
- Is the verification format documented sufficiently for us to write our own verifier?
- How long do you retain signing keys, and is that in the contract or in a policy you can change?
The fourth question has the most consequential answer and is almost never asked. A key retention policy that is not contractual can be shortened, and when it is, your historical evidence stops verifying.
What the metric does to the roadmap
Imagine proposing offline verification inside a usage-priced identity platform. You would have to argue against five things at once, and you would lose on all five.
| Property a buyer wants | What it does to the vendor |
|---|---|
| No API call at verification | Removes metered usage from the highest-value operation |
| Works during a vendor outage | Removes a dependency the vendor benefits from |
| Receipts stay valid after cancellation | Removes a switching cost |
| Any third party can verify without an account | Removes a reason to become a customer |
| Vendor cannot observe verification | Removes usage telemetry |
None of that is bad faith. Companies build what their model rewards, and metered identity platforms deliver genuine value in the services they meter: directory, lifecycle, policy, connectors, session management. There are also legitimate technical reasons to prefer a callback — real-time revocation and policy evaluated at verification time. Those trade against availability and independence, and reasonable architects weigh them differently.
Objections and honest limits
“Some vendors do publish keys.” Several publish signing keys for tokens, which is necessary and not sufficient. The questions are how long old keys stay published, whether that is contractual, and whether the record is self-contained enough to mean anything once your tenant is gone.
“This is an argument for building it yourself.” It is an argument for the format being open and the keys being yours. Who operates the issuer matters less than whether a third party can verify without asking anyone's permission.
What offline verification costs you: real-time revocation. A signed list published every minute closes most of that gap, and the residue is a genuine trade rather than a free lunch.
Four questions for procurement
- Can a third party verify without calling your API? If not, ask what happens in year six of our retention period.
- Do approvals stay verifiable after termination? Get the answer in writing, in the contract rather than in a policy.
- Is the format documented well enough to write our own verifier? If the answer is no, the evidence is only as durable as the vendor.
- How long are signing keys retained, contractually? A retention policy the vendor can shorten is one that can silently invalidate your historical evidence.
Terms used here
- Offline verification
- Checking a receipt using only the receipt and a published key. No network call, no account, no dependency on the issuer still existing.
- Metered pricing
- Charging by monthly active users or API volume. It makes any feature that reduces calls structurally unattractive to build.
- Switching cost
- What it costs to leave a vendor. Records that stop verifying on cancellation are a switching cost paid in evidence.
Frequently asked questions
Are vendors acting in bad faith? No. Companies build what their model rewards, and metered services provide real value. The point is that offline verification is structurally unattractive to them.
Are there legitimate reasons to prefer a callback? Yes — real-time revocation, policy evaluated at verification time, richer context. Those trade against availability and independence.
What does offline verification require? A canonical serialisation, a fixed algorithm, durably published keys, a self-contained statement and a small verifier. A format, not a service.
What should procurement ask? Whether approvals remain verifiable after termination, and how long signing keys are retained — contractually, not as a policy the vendor can change.
Are identity vendors acting in bad faith? No. They build what their pricing model rewards, and the services they meter deliver real value. The point is that offline verification is structurally unattractive for them to build.
Are there good technical reasons to prefer a callback? Yes — real-time revocation, and policy evaluated at verification time with richer context. Those trade against availability and independence.
What should we insist on contractually? That approvals issued during the contract remain verifiable after termination, and how long signing keys are retained — in the contract, not in a policy the vendor can change.
Where this fits in Manav
Manav's verification requires the receipt and a key published at a well-known URL. There is no call to us, no account needed, and a Manav outage cannot stop a verification. The verifier is small enough to read, and you are free to write your own.
Sources and further reading
- FTC — business guidance on marketplaces and consumer protection
- Published guidance on vendor lock-in and exit planning.
- RFC 7517 — JSON Web Key
- Audit retention requirements in common compliance frameworks.