Security at
every layer.
Request-bound encrypted wallet responses, exact-byte document binding, signed webhooks, KMS-encrypted evidence, and immutable audit records—with the limits stated plainly.
How Alentra protects your identity
Provider-controlled approval
The operating-system wallet owns user authentication and consent. Alentra never receives a face or fingerprint template.
Encrypted wallet response
Each request advertises an ephemeral P-256 public key. Supported responses are encrypted to Alentra using JWE or HPKE and bound to the request transcript.
Government-verified
Alentra validates the selected credential profile and device authentication against its configured issuer trust material. Current route availability is pre-launch and environment dependent.
KMS envelope encryption
Signer and wallet evidence use a fresh AES-256-GCM data key per audit record; Google Cloud KMS wraps only that data key.
WYSIWYS document binding
For sign, the developer uploads the files. Alentra computes their manifest hash and serves those same bytes for review before recording the response.
Tamper-evident audit
Each completed step receives an immutable record hash, a previous-record hash, and a stable audit ID; RFC 3161 timestamping is attached or deferred explicitly.
Signed end to end
Wallet responses use request-bound encrypted transport. Documents are hashed server-side, signer evidence is KMS-encrypted, and completed steps are hash-linked.
Wallet-controlled keys
Alentra verifies provider wallet evidence; key protection and user authentication are controlled by the wallet platform and credential implementation.
SHA-256 document hashing
Alentra computes per-file SHA-256 values and a manifest hash from uploaded bytes, preventing a developer-supplied-hash substitution.
On-device signing
The wallet returns signed presentation evidence over a nonce bound to the current session and document hash; Alentra verifies it server-side.
Full audit transparency
Audit output is primitive-specific. Sensitive signer and wallet evidence is sealed at rest and disclosed only through the appropriate business or legal tier.
Immutable, tamper-evident records
Step returns an audit ID
Every completed identify, age_verify, light_sign, or sign step exposes a deterministic audit reference.
Store ID safely
Store the audit ID and X-Alentra-Delivery-Id with your own transaction record; webhooks are delivered at least once.
Query for verification
The owning active business can query the scoped audit view. age_verify remains identity-redacted to the business; full disclosure is restricted to authorized legal staff.
What each reference reveals
Primitive-specific proof
Claims digest, age verdict, terms hash, or document manifest and signature—depending on the completed primitive.
Precise timestamp
Verified occurrence time plus an RFC 3161 token when available; outages are marked for append-only backfill.
Chain position
Session, stage, wallet, delivery mode, client reference, previous hash, and current record hash.
Retention made
explicit
- Alentra does not collect or store biometric templates; device authentication stays with the wallet provider
- Credential attributes and session results are processed and stored where the primitive requires them
- age_verify exposes only the verdict to the business but retains encrypted signer evidence
- Firestore rules and server authorization scope customer access by business ownership
- Completed results, original signed documents, signatures, proofs, and audits are not customer-deletable
- Account closure and privacy requests are staff-reviewed and remain subject to evidence-retention obligations
Built for trust.
Review encrypted wallet transport, signed webhooks, document binding, and immutable audit evidence ahead of the 2027 launch.