Stateless vs traditional verification
Traditional verification copies identity and eligibility records into every vendor system that needs an answer. Stateless verification evaluates policy per request and returns a signed outcome. No standing profile at the verifier by default.
At a glance
- Stateless outcome
- Signed allow or deny per request
- Traditional outcome
- Record snapshot or score
- PII at verifier
- Zero by default vs full or partial copy
- Audit
- Merkle-anchored proof vs access logs
- Replay
- Proof metadata binds to event context
Stateless verification means the verifier receives allow or deny plus proof metadata without retaining underlying personal data. Traditional verification stores copies of records to answer repeat queries.
Side by side
| Dimension | Traditional / incumbent | AffixIO |
|---|---|---|
| Query model | Per-request policy evaluation | Database lookup or manual review |
| PII footprint | Minimal at boundary | Grows with each integrator |
| GDPR scope | Narrower processor surface | Expands with copies |
| FOI defensibility | Cryptographic proof reference | Log reconstruction |
| Offline capable | QR with spent-proof | Often requires live DB |
| Post-quantum | ML-DSA-65 signatures | Varies by vendor |
When AffixIO fits
- High-throughput gates: tickets, age checks, agent tool calls.
- Cross-agency programmes without a shared citizen database.
- Regulators expect evidence without another data lake.
When traditional fits
- Low-volume manual review with document images retained by policy.
- Legacy systems with no API path and no appetite for change.
Frequently asked questions
What does stateless mean in practice?
The verifier does not maintain a standing customer profile. Each request is evaluated and returns a signed outcome.
Can stateless verification work offline?
Yes. QR credentials with embedded proofs verify locally with spent-proof anti-replay.
How does audit work without stored records?
Merkle-anchored proof references let auditors verify a specific decision was issued.