Three-layer request authentication
Every request must satisfy all three layers at once. They are not alternatives — a request missing any one of them is rejected before it reaches identity services. See Authentication for the full signing and encryption mechanics, including working code.
API key + HMAC-SHA256
Every request is signed over a canonical string built from the method, path, timestamp, nonce, and body. A forged request requires the secret key, not just the key id.
mTLS client certificates
A client certificate issued by the third-party CA is required on every connection. A leaked HMAC secret alone is useless without the matching private key.
AES-256-GCM encryption
The request and response bodies are encrypted end to end with a per-application key, on top of transport-layer TLS — so the payload is opaque even to anything positioned between the API edge and the identity services behind it.
Credential isolation
Every application gets its own independent set of credentials — never shared with, or derived from, any other application's:
| Credential | Scope |
|---|---|
| API key | One application |
| HMAC secret key | One application |
| Payload encryption key | One application |
| mTLS client certificate | One application |
A compromised credential for one application never grants access to another application's traffic — and never to another organization's applications entirely. Blast radius is bounded to the single application the credential belongs to, by construction, not by a policy that could be misconfigured.
Environment isolation
Production and staging (sandbox) are genuinely separate systems, not one system behind a feature flag:
- Separate databases — sandbox traffic never touches production data, and never can, since there is no shared data store to touch.
- Separate credential material — sandbox API keys, secrets, and certificates are issued independently and are not valid against production, or vice versa.
- A sandbox credential presented against the production host fails authentication the same way an invalid credential would.
See Sandbox & environments for how promotion from sandbox to production works.
Data minimization through scopes
RDCPASS returns citizen data, so the platform controls exactly how much. Every identity response contains basic KYC only, unless additional scopes pass three independent gates: the organization subscribes to the scope, the application selects it, and the request does not narrow it away. Each response lists scopes_applied and scopes_withheld, so you can prove afterwards what you received. Request only the scopes your declared purpose needs — scope justifications are reviewed during application due diligence, and changes to production applications are re-reviewed.
- Purpose binding — every request carries a purpose approved for the application; any other value is rejected with purpose_not_approved.
- Signed URLs for files — document images and biometric files are delivered as single-tenant URLs valid for 5 minutes. Fetch them server-side and never store the URL.
- No silent over-collection — a scope that is not granted fails with scope_not_granted rather than being ignored.
See KYC scopes & subscriptions for every scope and its tier.
Special-category data: sensitive and biometric scopes
Religion and ethnicity (sensitive tier) and selfie, fingerprint and iris data (biometric tier) receive additional protection at every step:
- Enhanced due diligence before access: a data-protection impact assessment, a named data-protection officer, a documented legal basis and an on-site or video audit.
- A penetration-test report is part of the application due-diligence dossier for these tiers.
- Every returned sensitive or biometric record is logged with the application, purpose and timestamp, and is reviewable by RDCPASS and by your Compliance officer.
- Biometric templates are delivered in standard ISO/IEC 19794 formats, encrypted in transit like every payload; you must store them encrypted at rest and delete them under your declared retention policy.
Face Recognition: audited reason
Every Face Recognition call carries a mandatory, human-readable reason. RDCPASS stores it with the request and audits it against the reason policy approved during enhanced due diligence — 1:N identification in particular is reviewed for proportionality. Write reasons a reviewer can check, such as "Branch account opening, Gombe agency, ticket OB-2291", never a generic placeholder.
Member access: MFA and roles
Console access is as tightly controlled as API access. Members sign in with their own RDCPASS identity, multi-factor authentication is mandatory, and each member holds a role — Owner, Administrator, Developer, Financial officer, Compliance officer or Marketing — that limits what they can do. Developers cannot create production keys or change the scopes of production applications, and every console action is written to the audit log. See Teams & roles.
Revocation
Any credential — API key, HMAC secret, payload encryption key, or mTLS certificate — can be revoked instantly from the console by an Owner or Administrator, independently of the others. Revocation fails closed immediately: a revoked credential is rejected on the next request, with no propagation delay and no window where a revoked credential still works while the change rolls out.
Abuse prevention
Beyond authenticating who is calling, RDCPASS constrains how much and how often:
- Replay protection. Every request carries a nonce that can be consumed exactly once; a reused nonce is rejected outright, so a captured request can't be replayed even by an attacker who can't read its encrypted body.
- Rate limiting. Per-application request limits protect the platform, and each application, from being overwhelmed by any single caller.
- Per-service quotas. Independent quotas on top of rate limits, tuned to what each identity service can safely sustain.
See Rate limits & quotas for current thresholds and the headers returned on every response.