Security
Keys, data and disclosure
How signing keys are protected, where data is held and who processes it, and how to report a problem.
Signing keys
- Generated on the device. Each inspector’s key is created by the browser’s WebCrypto as a non-extractable Ed25519 key. It cannot be exported, even by the application, and the operator never receives it.
- Published, not shared. Only the public key leaves the device. It appears in the organisation’s identity document once enrolled.
- Approved before trusted. By default a new key is pending until an administrator approves it (practice statement §4.1).
- Revocable. A lost device’s key can be revoked at once. Earlier seals stay valid, and new ones are refused.
- Algorithms: Ed25519 (RFC 8032), SHA-256 and RFC 8785 canonical JSON, as the W3C
eddsa-jcs-2022cryptosuite. No custom cryptography.
What a device key cannot protect against
A key bound to a device trusts whoever is signed in on that device. An inspector who signs a false finding produces a valid signature on a false statement. A signature proves origin and integrity, not truth (§1.3).
Data residency and sub-processors
| Sub-processor | Purpose | Location |
|---|---|---|
| Amazon Web Services | Compute, database, identity hosting, content delivery | Africa (Cape Town) and Europe (Ireland). Database primary in Ireland, replicated to Cape Town. CDN edge worldwide. |
| Functional Software, Inc. (Sentry) | Error monitoring for the inspection application | As configured for the operator’s account |
What a credential contains. Inspection credentials carry the inspection site, totals, the inspector names recorded on the sheet, and hashes. Anyone you hand a credential to can read it. The public register endpoint returns only proof and status facts, never record contents. Credentials about people (in development) will use selective disclosure, so the holder reveals only the facts asked for. TrustedAnchor signs and returns them without keeping the personal details.
This website sets no cookies, runs no analytics and loads nothing from third parties. Fonts are self-hosted. The verifier checks signatures in your browser. A credential is sent to the register only if you leave the register check ticked.
Reporting a vulnerability
If you believe you have found a security issue in TrustedAnchor, its identity documents or the verification API, please report it privately: support@trustedanchor.io.
- We will acknowledge a report within 5 working days and keep you informed until it is resolved.
- We will not pursue legal action against good-faith research that avoids privacy violations, avoids degrading the service, and gives us reasonable time to fix the issue before disclosure.
- Please do not access other organisations’ data beyond what is needed to show the issue.
A machine-readable contact file (/.well-known/security.txt, RFC 9116) is published once the security mailbox is live.
Service status and incidents
There is no public status page yet, and we make no uptime commitment on this site. Incidents that affect the validity of records or identities will be described here with a dated post-incident note.
No incidents to report.