Why identity benefits from protocol-shaped APIs

If HTTP had been locked behind one institution, the web would not exist in its current form.

That observation is an inspiration for Alentra, not a claim that the current service is an open internet standard. Alentra is a hosted private-beta product. Wallet providers still approve production relying parties, issuers control credentials, and the supported surface is deliberately narrow.

The useful design question is smaller: what would an application-facing identity API look like if it borrowed the discipline of a protocol?

Keep the verbs small

Alentra currently ships four primitives:

• identify asks for explicit credential claim blocks.
• age_verify produces a business-redacted threshold verdict.
• sign binds a wallet response to original uploaded document bytes.
• light_sign binds approval to short inline terms.

Those are the verbs. A customer arranges them into a reusable, versioned workflow; every launch creates a fresh session that preserves that published order for one subject. An API-only workflow may pause after a non-final step so the developer can inspect the signed webhook and call continue or stop. Business policy remains in the developer's application.

The small surface makes behavior easier to document and test. It does not eliminate provider dependencies or turn Alentra into a decentralized network.

Separate workflow from policy

Identity products tend to absorb the customer's decision rules. The verifier starts deciding which country is allowed, whether an age result grants access, whether a signature is sufficient, and what to do after an exception.

Alentra draws the line differently. It sequences steps, verifies wallet evidence, preserves completed records, and reports results. The customer decides what the result means. A gate is a neutral pause, not a rules engine.

That separation keeps the API reusable without pretending that one vendor can encode every regulated workflow correctly.

Make evidence behavior explicit

“Permanent reference ID” is not enough. A production evidence system needs a defined record shape, retention model, access tiers, integrity mechanism, and honest statement of what can be independently verified.

Alentra currently creates one immutable, hash-linked audit row per completed step. Sensitive signer and wallet evidence is envelope-encrypted using Google Cloud KMS. Completed sign evidence includes the original signed documents. Customers cannot delete completed results, original documents, signatures, proofs, audits, or integrity links.

Every audit row now carries a public P-256 Cloud KMS signature, with current and retained keys in JWKS. The offline verifier checks the complete terminal flow, record and chain hashes, trusted time, retained originals, and—when authorized disclosure includes it—the original issuer/device evidence and same-subject commitment. Alentra still does not publish a public daily chain head or bundle a proof ZIP, and it does not call the signing key HSM-backed unless the deployed key actually uses Cloud HSM.

Do not call data “gone” when it is retained

A protocol-shaped API should make disclosure boundaries observable.

For age_verify, the business receives only satisfied and min_age. Alentra still processes DOB and retains encrypted signer evidence. That is a meaningful privacy boundary, but it is not “no PII” and not “no retention.”

For sign, the original documents are deliberately retained with completed evidence. Account closure does not delete them. Transient uploads for a session that never completes may be purged.

Those facts belong in the contract and privacy policy, not just architecture notes.

Publish routes honestly

The Commission EUDI reference wallet is Alentra's no-hardware private-beta sandbox provider across the real EU country routes, while Google Utopia remains an Android test route. The public ledger also tracks Google, Apple, and EUDI country/profile/provider routes, but every production route remains coming soon until provider approval, issuer trust, credentials, browser/device support, a real presentation, and Alentra release approval are complete.

Direct national-wallet APIs, multi-party envelopes, notarization, delegated signing, and reusable cross-service Alentra credentials are not current capabilities. A truthful route ledger is more useful than a global coverage claim that the runtime cannot support.

What “open” can mean today

For Alentra today, “protocol-shaped” means:

• one documented session endpoint;
• explicit parameters and states;
• primitive-specific outputs;
• signed, timestamped, at-least-once webhooks;
• stable delivery and audit IDs;
• customer-owned business rules;
• canonical record hashes that other implementations can recompute;
• public documentation of limitations and retention.

It does not mean anyone can run Alentra infrastructure, bypass provider or issuer approval, reuse an Alentra credential across borders, or assume a coming-soon route is live.

That is the honest starting point. The aspiration is interoperability; the production obligation is to describe exactly what exists.

See the developer overview, security model, and coverage model.