Decentralised Identity Verification Service
This service does one thing: given an identifier, confirm whether a valid attestation exists for it and return the verified claim. It is small on purpose. Anything sitting on an authentication path is a target, so the scope is kept tight enough to reason about completely, and the hardening — schema validation at the boundary, rate limiting, security headers, structured logging — is disproportionate to the line count by design.
Single-purpose HTTP service with no persistent storage of its own
Documented as an architecture record. A verification endpoint on a live network is not something to expose from a portfolio page.
A verification request end to end
Four steps and no database. The absence of stored state is the security property worth noticing.
Needs to know whether a valid attestation exists for an identifier.
What happens, and what deliberately does not.
Highlights
Small surface, hard edges
The service is a thin, hardened boundary in front of on-chain attestation data. It stores nothing, which means the worst case of a compromise is denial of service rather than disclosure.
HTTP boundary
Accepts lookup and verification requests, validates them, and applies protective middleware.
- Schema validation on every input before any logic runs.
- Rate limiting, security headers and an explicit CORS policy.
- Structured logs that record attempts without recording claim contents.
Verification
Resolves the attestation and checks its signature and validity.
- Trust derives from the attestation's signature, not from this service's assertion.
- A caller can independently verify the same claim.
Chain access
Reads attestation records from the network.
- Read-only — the service never writes to the chain.
- Holds no local copy, so there is nothing to keep in sync.
The whole service
Thirteen files, and that is the point — the surface is small enough to audit completely, which is what you want from something on an authentication path. 12 units across 4 groups.
Source tree
4Hardening
5Chain access
2Observability
1Stack by layer
Delivered work
Service
- Single-responsibility verification and lookup endpoints.
- Boundary schema validation on every input.
- Rate limiting, security headers, CORS policy and compression.
- Structured logging that records attempts without recording claims.
- Stateless design with no local identity storage.
Modules and demo strategy
Narrow scope
Makes the service auditable in full.
- One responsibility, thirteen files.
- Small enough that the whole attack surface fits in your head.
Statelessness
Removes the identity database as a target.
- Worst-case compromise is denial of service, not disclosure.
Boundary hardening
Protection proportionate to exposure, not to size.
- Validation and throttling run before any business logic.