Architecture & topology
ReadyYdentifi is a small set of parts you run: a server (one container + PostgreSQL), the apps and SDKs at the edges, and a CLI to operate it — with no Ydentifi cloud in the authentication path. One deployment can serve many relying parties, and because it holds only opaque tokens, you can host it anywhere while your personal data stays isolated wherever the law requires.
Who this is for: architects and decision-makers working out where Ydentifi runs, how tenants are separated, and where data lives. For the step-by-step of standing it up, see Deploy.
The shape#
Ydentifi is deliberately small: one engine you host, thin clients at the edges, and a hard line between the opaque tokens it holds and the personal data it never sees.
opaque_id → person mapping.One deployment serves many relying parties — here, three regional subsidiaries. Each RP’s users are faceless opaque tokens to Ydentifi; the real personal data sits isolated in whatever jurisdiction the law requires, in systems Ydentifi never touches.
One deployment, many relying parties#
A single deployment can serve many relying parties at once — separate apps, business units, or, as above, regional subsidiaries. Each RP authenticates with its own mutual-TLS client certificate, and every call is implicitly scoped to that certificate. One RP can never see another’s users or challenges; a cross-tenant read returns NotFound, so existence never leaks across the boundary.
This is why the request bodies are so lean: the certificate already says who is calling, so most RPCs carry no tenant identity at all.
Where your data lives#
Ydentifi stores no personal data — only opaque identities and cryptographic material. The mapping from an opaque token back to a real person lives entirely on your side, in systems Ydentifi never touches.
Two consequences fall straight out of that:
- Host it anywhere. Because the deployment holds no regulated personal data, it is not bound to the jurisdiction where that data must legally reside. Run the authentication layer wherever it is cheapest, fastest, or most convenient — even fully air-gapped. The deployment never phones home to Ydentifi on any tier: it runs on a license file until that file expires, then you install the next one (see Get a license).
- Data residency stays yours. Your personal data sits exactly where the law requires (an EU store, in the diagram), isolated from the auth layer. You remain the data controller. Ydentifi is neither controller nor processor: your users’ data never reaches it.
Nothing in the authentication path carries a name, email, or number. That single pillar is what lets one deployment safely serve subsidiaries across different regions while each keeps its own personal data where it belongs. See Security model for who secures what.
The moving parts#
- The server — the engine you self-host: enrollment, challenges, policy, licensing. One container plus a PostgreSQL database. It makes no outbound calls on the auth path.
- The authenticator app — native iOS and Android apps at launch, holding enrollments and signing challenges. Or embed the ceremony in your own app with the Swift device SDK — Kotlin for Android, both at launch.
- The backend SDKs — eight languages that wrap the gRPC API, or call it directly. This is how your product talks to the server.
- The CLI — one tool to provision, deploy, operate, and simulate the whole system. The CLI is the product surface; there is no GUI-only operation.
- The trust chain — your own certificate authority, and the RP certificates it issues. You hold these keys; Ydentifi never does.
No cloud in the path#
Every RP-facing call is gRPC over mutual TLS — there is no HTTP gateway and no Ydentifi-hosted service in the authentication path. Challenges reach devices by QR or a pull-stream, so there is no Apple or Google push for a platform vendor to throttle or observe. A deployment that has been licensed can run entirely offline. See Why gRPC-only for the reasoning.