Security

Handling API keys

• Store keys in a secret manager. Never in source control, a container image, a log line, a bug report or a frontend bundle.
• Keys are shown once. If you lose one, rotate it; it cannot be recovered.
• Never embed a key in browser or mobile client code. Anything shipped to a device is public — call DiligenceID from your backend.
• Give each integration and each environment its own key, so the audit trail identifies the caller and a compromise has a bounded blast radius.
• Rotate on a schedule, and immediately whenever someone with access leaves or a key may have been exposed.
• Set an expiry where you can.

If a key is exposed, revoke it first and investigate second. Revocation is immediate.

Handling credential data

• Disclosed claims are personal information. Store only what you need, for as long as you need it.
• Do not log claim values, presentation tokens, proofs or nonces.
• Prefer storing a verification id over storing the claims a verification disclosed.
• Ask for the narrowest policy that answers your question. A policy that discloses a date of birth when you only needed proof of age is over-collection.

Authentication is not identity verification

An authenticated session tells you which account authenticated. It does not, by itself, tell you that a person's real-world identity has been verified, or that they hold authority to act for an organisation.

DiligenceID keeps these distinct, and so should your integration. A verified credential carries the evidence its issuer asserted, under the policy it was issued against — no more. Do not treat a successful verification as a general assertion of identity, accreditation or authority unless the policy you used actually establishes it.

Nothing in this API asserts government accreditation, statutory trust or conformance certification.

Transport

TLS is required. Send keys in the Authorization header only — never in a URL, where they would reach access logs, browser history and referrer headers.

Tenant isolation

Your key is bound to your tenant by its own record; request headers cannot move it. A resource in another tenant is reported as 404, never 403, so no response confirms that an identifier exists elsewhere.

Reporting a vulnerability

See SECURITY.md in the repository.