Skip to main content
Alentra treats a credential route as three separate facts:
  1. Jurisdiction — the issuing country or test jurisdiction.
  2. Credential profile — the signed format, doctype/namespace, claims, and issuer trust policy.
  3. Presentation provider — the wallet rail that carries the credential to the browser.
A country can expose several profiles/providers, and a provider can carry credentials from several countries. Alentra validates the exact tuple server-side and locks it for the whole session. The provider brand is never used as a substitute for issuer trust.
Google Utopia is the active private-beta sandbox route. A route marked coming_soon is discoverable, not usable or promised live.

​
Canonical ledger

The public GET /v1/catalog is the runtime authority. It currently tracks:
  • Google Wallet: US mDL; US/Brazil/Singapore/Taiwan/UK Google ID Pass; India Aadhaar.
  • Apple Wallet: participating US state IDs, US passport-derived Digital ID, and Japan My Number Card.
  • EUDI Wallets: EU Person Identification Data routes for all 27 EU Member States, with gradual rollout.
  • Google Sandbox: fictional Utopia ID Pass.
Production routes remain coming_soon until Alentra has the exact provider/issuer approval, trust material, browser path, claim mapping, and real-presentation acceptance evidence. US state mDL routes are marked partial; country support never implies every issuer or every resident has an accepted credential.

​
Enable coverage for your business

Global availability and business availability are separate. In the Alentra dashboard, open Coverage, select every country/wallet route you want, choose the primitives you intend to use, and submit one organization packet. Alentra deduplicates that selection:
  • Google routes become one Verifier Registrar client enrollment managed by Alentra. You create no Google key, account, or direct integration.
  • Apple routes use the Alentra-managed verifier path only after Apple confirms that model; they remain coming soon meanwhile. Alentra will expose a guided per-brand path only if Apple requires it.
  • Aadhaar and EUDI selections create waitlist requirements until their exact issuer/conformance path is ready.
A new session can use only the intersection of a globally available route, your saved selection, and approved provider requirements. Alentra snapshots that set when the session is created, so removing coverage affects new sessions without changing an in-progress one. The hosted page receives only those non-sensitive route ids and never offers the signer a wallet choice your business cannot use.

​
How the wallet flow works

Alentra’s implemented presentation rail uses the W3C Digital Credentials API. The browser, not your application, talks to the wallet.
1

Resolve

Alentra’s hosted page reads the public catalog and offers only routes whose exact available value is true, whose provider can complete every session step, and whose route is in the session’s create-time business coverage snapshot.
2

Request

The server resolves the selected country/profile/provider tuple, pins it to the session, and builds a credential request with a fresh nonce, origin binding, and per-request response-encryption key.
3

Present

The user approves in their wallet. The wallet returns an encrypted, signed response to the hosted page, which relays it to Alentra.
4

Verify

Alentra decrypts the response and verifies the profile’s doctype, issuer chain, signed claims, device signature, nonce/transcript, validity, and disclosure allow-list.
Your application hands over only the hosted session URL. It does not call the hosted page’s internal request/response routes or implement wallet polling.

​
Environments

Local synthetic fixtures may bypass the public ledger for service tests. The catalog itself never marks a coming_soon route available; its real Utopia sandbox route remains usable for end-to-end development.
Exactly one route is available: UT / utopia-id-pass / google-wallet. Alentra uses Google’s published sandbox request signer, RP metadata, Utopia IACA, signed OpenID4VP request, encrypted response, and strict issuer/device verification. Production signer/root material must be absent.
Only ledger routes explicitly promoted to live can become available. The deployment must also enable the provider, register its adapter, supply its request credentials, and load authenticated trust roots for the exact credential profile. Missing security dependencies fail boot; missing route approval remains unavailable.

​
Capability versus route availability

Provider capability answers “can this adapter implement sign?” Route availability answers “may this exact country/profile/provider tuple start here?” Both must be true. The legacy public GET /v1/wallets exposes the first; new integrations should use /v1/catalog, which includes both.