How we protect the integrity of coaching credentials
Certified Coach is built on cryptographic proof, not promises. Every credential is signed with post-quantum algorithms inside FIPS 140-3 Level 3 hardware security modules, logged to an immutable audit trail, and independently verifiable by anyone.
Six principles of trust
These aren't aspirations — they're how the platform works today. Each principle is backed by specific technology choices that you can inspect and verify independently.
Every certificate is digitally signed
When an issuing organisation awards a credential through our platform, we create a digital signature using ML-DSA-65 (NIST FIPS 204) post-quantum cryptography. The payload is canonicalised with JCS (RFC 8785) before signing, ensuring deterministic serialisation with prototype pollution guards. If even a single byte changes, the signature breaks.
Organisations attest, we sign
The issuing academy or governing body confirms that a coach has met their standard. Certified Coach then signs the credential with our platform key held in AWS KMS FIPS 140-3 Level 3 hardware security modules. The key material is generated in-hardware, non-exportable, and never leaves the HSM boundary — not even to AWS engineers.
Anyone can verify, instantly
Every signed certificate can be checked without contacting us. Our public key is published in a DID Document at /.well-known/did.json following the did:web specification. Verification uses @noble/post-quantum, a pure TypeScript library that passes NIST ACVP test vectors and runs in any JS runtime with zero native dependencies.
Revocation is permanent and public
If a credential is revoked — whether for misconduct, expired training, or any other reason — the revocation is recorded as an immutable lifecycle event. Revoked certificates always show as revoked, even if the original signature was valid.
Audit trail you can inspect
Every certificate is hashed into a Merkle tree (SHA-256). The root hash is published periodically, creating a tamper-evident commitment to the state of all credentials. If any record were altered after the fact, the hash chain would break. Every signing operation is also logged to AWS CloudTrail — an immutable, cryptographically sealed audit trail.
Post-quantum from day one
We chose ML-DSA-65 (NIST FIPS 204) before most platforms have begun migration planning. This lattice-based algorithm resists attacks from both classical and quantum computers. There is no "upgrade later" — every credential issued today is already protected against future quantum threats.
What a verified credential means
- The credential was issued through our platform by a registered organisation
- The digital signature is cryptographically valid and unaltered
- The credential has not been revoked or superseded
- The credential has not expired
- The issuing organisation is in good standing on our platform
What we don't verify
We believe honesty builds more trust than overpromising. Here's what falls outside our verification scope:
- —The quality or rigour of the issuing organisation's programme
- —The coach's actual on-court ability or teaching skill
- —Whether a governing body itself is accredited by a national authority
- —Credentials issued outside our platform (self-reported qualifications are shown separately and clearly marked)
Under the hood
For those who want to verify our claims independently, here's exactly how the system works. Algorithm names, key sizes, standard references, operational controls, and audit mechanisms — all public.
Cryptographic foundations
Signing algorithm
ML-DSA-65 (NIST FIPS 204), a lattice-based digital signature algorithm selected by NIST to replace RSA and ECDSA for post-quantum security. Payloads are canonicalised with JCS (RFC 8785) using prototype pollution guards before signing, ensuring deterministic byte-level representation.
Public key: 1,952 bytes · Signature: 3,309 bytes · Security level: NIST Category 3 (128-bit post-quantum)
Credential format
W3C Verifiable Credentials Data Model 2.0 with Open Badges 3.0 vocabulary, encoded as a signed JWT (VC-JWT). This is an open standard — credentials can be verified by any compliant software, not just ours.
Standards: W3C VC 2.0 · Open Badges 3.0 · IETF JWS · RFC 8785 (JCS)
DID Document
Our platform identity is published as a Decentralized Identifier following the did:web specification at a well-known URL. The document includes our full public key and maintains key history, enabling backward verification of credentials signed with previous key versions.
View DID DocumentMerkle audit trail
Every certificate is hashed into a SHA-256 Merkle tree. The root hash is published periodically, creating a public commitment to the state of all credentials at that point in time. If any record were altered, the hash chain would break — the published root would no longer match.
Hash: SHA-256 · Cadence: daily · Published to DB + GitHub
Operational security
Immutable signing audit trail
Every signing operation is logged to AWS CloudTrail with timestamp, caller identity, key ID, and operation result. CloudTrail logs are cryptographically sealed — any tampering with the log files themselves is detectable. Logs cannot be deleted or modified, even by account administrators.
AWS CloudTrail · Log file validation enabled · S3 bucket: all public access blocked
Threat detection
AWS GuardDuty continuously monitors for credential compromise, unusual API call patterns, and anomalous signing activity. Alerts fire on: signing requests from unexpected principals, geographic anomalies in API access, and brute-force attempts against key resources.
AWS GuardDuty · CloudTrail event analysis · Automated alerting
Operational containment
The signing key is scoped to a dedicated IAM principal with least-privilege access. Audit log storage uses a separate S3 bucket with all public access blocked and log file validation enabled. Budget alerts detect runaway costs from compromised credentials before they escalate.
IAM least-privilege · S3 Block Public Access · AWS Budget alerts
Key lifecycle and verification independence
Hardware key isolation
Signing keys are generated inside AWS KMS FIPS 140-3 Level 3 hardware security modules. Keys are non-exportable by design — they cannot be extracted, copied, or read by any party, including AWS engineers. All cryptographic operations execute within the HSM boundary.
AWS KMS · FIPS 140-3 Level 3 · Non-exportable key material
Key rotation and versioning
Key rotation is supported without breaking existing credentials. When a key is rotated, the DID Document is updated to include both the current and previous public keys. Certificates signed with an older key version remain independently verifiable using the key history.
DID Document key history · Automatic version tagging · No verification downtime
Verification independence
No vendor lock-in. Any party with our public key can verify credentials independently — no API call to us required. The verification library (@noble/post-quantum) is pure TypeScript with zero native dependencies, runs in any JS runtime, and passes NIST ACVP test vectors. The full chain: DID Document → public key → signature → certificate payload.
@noble/post-quantum · NIST ACVP validated · Pure TypeScript · No native deps