Skip to main content
Alentra’s security model has two halves: proving a result is genuine (covered in Verification & trust) and protecting the data around it. This page covers the second.

​
In transit & at rest

TLS everywhere

All API calls and webhook deliveries are over HTTPS/TLS.

Encrypted responses

The wallet encrypts its response to a per-request key; only Alentra’s server can decrypt it. The hosted page relays ciphertext it cannot read.

PII sealed at rest

Private session data, sign documents, webhook payloads, signer identity, and wallet evidence use application-layer envelope encryption outside local development. Ciphertext is bound to its object and purpose with AAD.

Signed webhooks

Every delivery is HMAC-SHA256 signed; verify it before trusting a payload (see Webhooks).

​
Anti-replay & binding

  • Per-step nonce + origin. The holder’s signature covers a fresh nonce and your origin, so a captured response can’t be replayed against another request.
  • Explicit-start binding. Loading a link is read-only. The first browser whose user presses Start secure session is bound to it; no other device can submit a response.
  • Idempotency. An Idempotency-Key on create makes retried creates safe; webhook X-Alentra-Delivery-Id makes retried deliveries safe to dedupe.

​
Data handling & retention

Alentra minimizes each disclosure, but it deliberately preserves completed evidence:
  • Only what you request. identify discloses exactly the blocks you ask for.
  • age_verify reveals a boolean and threshold to you, not the birth date; the underlying identity is sealed in the audit and flagged redacted.
  • Completed evidence is immutable. A verified sign promotes its original file bytes to retained evidence. The completed result, original, audit, signature, and integrity links cannot be customer-deleted or time-purged.
  • Transient artifacts are separate. Only uploads explicitly marked transient because no sign result completed may be removed by scheduled cleanup. Terminal webhook-delivery copies expire after their operational window; they are not the canonical result.
  • No standing identity. There’s no Alentra login the user maintains; each session is a fresh, consented disclosure from their wallet.

​
Your responsibilities

The hosted url is a capability URL — deliver it only to the intended user. Server-side previews no longer consume the binding, but anyone who obtains the URL can try to start it before the recipient.
Recompute the HMAC over the raw body and compare in constant time. Reject stale timestamps to bound replay windows. Dedupe on the delivery id.
Keep your API key and webhook secret server-side. Rotate the webhook secret from the dashboard if exposed. API keys are scoped to your business.

​
Compliance posture

  • Tamper-evident, append-only audit records with sandbox/production Alentra signatures and independently checkable RFC 3161 status — designed to support evidentiary review, without promising admissibility or legal effect.
  • Data-minimizing disclosure (selective fields; age_verify is anonymous to the business, not to Alentra).
  • Production government-issuer–anchored verification, not document scraping; sandbox uses Google’s fictional test issuer.
The current managed deployment processes data in US regions, with global Google Cloud KMS key resources. Production contracts must state the retention period, legal-hold process, and any required transfer safeguards. Account closure starts a review; it does not erase completed evidence.
Have a specific regulatory requirement (GDPR data-processing terms, retention, residency)? Use the private contact form.