Trust & Security

Security by architecture

Precise, engineering-forward documentation of Persora's security model and trust assumptions.

Threat Model

In scope

Attestation tampering, unauthorized revocation, status forgery, replay attacks, issuer impersonation.

Out of scope

Physical facility attacks, client-side device compromise, social engineering of issuer organizations.

Data Handling

Stored

Attestation hashes, issuer DIDs, revocation status, timestamps, verification metadata.

Not stored

Audit evidence, raw control data, PII, issuer private keys, organizational security posture details.

Status-Only vs Private Verification

Status-only (public)

Attestation validity (valid/expired/revoked) is externally checkable. No claim content or control details are exposed.

Private

Specific claim attributes are disclosed only to authorized relying parties via selective disclosure protocols.

Key Management

Issuer keys

Persora never holds issuer private keys. Issuers maintain full custody of signing keys in their own HSMs or key management systems.

Platform keys

Persora's operational keys are used only for log integrity and API authentication — never for signing attestations on behalf of issuers.

Revocation & Freshness

Revocation

Issuers can revoke any attestation at any time. Revocation is immediate and globally visible.

Freshness

Attestations carry time-bound validity. Verifiers always see the most current status, not cached snapshots.

API Security

Authorization

All API access is authenticated and scoped. Private claim queries require verifier authorization.

Rate limiting

All endpoints are rate-limited and monitored. Abuse triggers automatic throttling.

Operational Security

Logging

All platform operations are logged with integrity protection. Logs are append-only and tamper-evident.

Availability

Verification endpoints are designed for high availability with redundancy across regions.