01
Install a PPIL client
@aithne/ppil-client for Node.js and TypeScript, plus PHP, Python, and Java clients in the roster below. The client mirrors the verified AVP contract and respects merchant-side signing.
Age verification without the PII liability.
Aithne's PPIL client drops age checks into your site in an afternoon. Your users prove their age from their wallet — you never see their identity.
Integration
Three steps, no identity data
02
Configure
Set the AVP URL and license key avp-api-key-aithne from environment only. Keys are never committed, never logged, never displayed as anything but a masked example.
03
Verify
The middleware redirects unverified users to the wallet dialog. Verify attestations via verify(). Verified users short-circuit — no repeat dialogs.
PPIL clients
SDK roster
Five PPIL clients mirror the verified @aithne/ppil-client AVP surface. Each integrates the same way and never touches a user's name, email, phone, address, or payment details.
Node.js
@aithne/ppil-clientLightweight, high-throughput client with age-verification middleware and CTS callback wiring.
DeliveredDocs
TypeScript
@aithne/ppil-clientTyped PPIL client for TypeScript stacks, with the full issue / verify / rotate API surface.
DeliveredDocs
PHP
aithne/ppil-clientPSR-4 Composer client, PHP 8.0+, ext-curl. Mirrors the verified contract for the AVP scope with merchant hooks.
DeliveredContract-tested
Python
ppil-clientPyPI-style package, Python 3.9+, requests. Full issue / verify / rotate / revoke helper surface.
DeliveredContract-tested
Java
com.aithne:ppil-clientMaven artifact, JDK 11+, Jackson. Includes mTLS trust-chain support for the ecosystem trust model.
DeliveredContract-tested
Docs & endpoint
aithne.online/avpStart from the AVP endpoint and the PPIL contract — the single shared surface every client talks to.
Planned
Endpoint & license key
One endpoint. Masked examples only.
# Example configuration — never commit or log real keys.
AVP_ENDPOINT=https://aithne.online/avp
AVP_API_KEY=avp-api-key-•••••• # example, masked — never a real key
# Auth header on every request:
avp-api-key-aithne: <key> # environment-only
AVP_ENDPOINT=https://aithne.online/avp
AVP_API_KEY=avp-api-key-•••••• # example, masked — never a real key
# Auth header on every request:
avp-api-key-aithne: <key> # environment-only
Endpoint
Defined in the ratified AVP contract; availability is confirmed before go-live.
The AVP trusts the wallet attestation and returns a verifiable age claim — nothing more.
Config principles
- Keys from environment only.
- Never committed, never logged.
- Every call carries a
correlationId.
Shown as an example — never publish real keys. Keys are environment-only, never logged, never committed. No code snippet on this site contains a real secret.
Security model
The client never has what it should not hold
Signing stays merchant-side
Private keys and HSM/external signers stay under your control. The client never holds keys and never signs.
No PII ever leaves the wallet
You receive only the age attestation claim. Identity, name, DOB, email, phone, address never transit your site or logs.
Ephemeral tokens
Trust-service tokens are request-lifetime only, masked in logs (maskSensitive ), never persisted.
Compliance framing
Attestation-centric, auditable, honest
Aithne is designed with privacy-by-design thinking and is aligned with emerging wallet / EUDI concepts. We do not claim certification, approval, or guarantees we do not hold.
Attestation-based
Age is proven with an age claim from the user's wallet, verified against the AVP — not by collecting documents or identity data.
Auditable receipts
Merchant-signed verification records give you an audit trail without a PII inventory to breach.
Market-caveated
Requirements vary by market — verify your obligations with legal counsel before go-live.
See the privacy / trust page for hosting, TLS, and cookie posture.
FAQ
Merchant questions, answered plainly
What data does Aithne store?
None. No name, email, phone, address, or payment details are collected, stored, or logged by aithne.online or the PPIL integration. Attestations are receipt-based; you keep merchant-signed verification records.
How does compliance work for age-restricted sales?
Aithne is attestation-based: you verify an age claim from the user's wallet, with auditable receipts and no PII inventory to breach. Requirements vary by market — verify obligations with legal counsel.
Can verified users skip the dialog on return visits?
Yes — a merchant-signed verification in the session short-circuits the age gate, with no repeat dialog for verified users.
Which languages are supported?
Node.js, TypeScript, PHP, Python, and Java clients, all mirroring the same verified AVP contract. See the SDK roster above.
How are license keys managed?
Keys are environment-only (avp-api-key-aithne). They are never committed, logged, or shared. Rotate them like any secret. The site never shows a real key — only masked examples.
Can a verification be revoked?
Yes. The AVP supports revoking a proof token (revoke()); subsequent verify or get calls are rejected. See the AVP glossary entry.