Why gRPC-only
ReadyYdentifi speaks gRPC, and only gRPC — there is no REST or HTTP/JSON gateway, and there will not be one. gRPC gives a typed contract, a bidirectional stream that lets challenges reach a device with no Apple or Google push in the loop, and mutual TLS as a first-class citizen rather than a bolt-on. If you need a REST edge, you run your own translator inside your trust boundary. Ydentifi will not host one, because a hosted gateway would strip the mTLS the whole design rests on.
Who this is for: anyone surprised there is no REST API, or wondering how a device gets a challenge without push. This is the why; the surface itself is the API reference and Device-facing gRPC.
The thesis#
A second transport is a second contract, and a second contract is a second place for behavior to drift, for a guarantee to be quietly dropped, and for bugs to hide. Ydentifi keeps exactly one. gRPC is not chosen for fashion — it is chosen because three things the design genuinely needs come with it, and come awkwardly or not at all over plain HTTP.
What gRPC buys#
- A contract that cannot drift. The
.protois the single source of truth. Every SDK, in every language, is generated or hand-written against the same definition and held to the same behavior — see SDKs. A REST layer would be a second, hand-maintained rendering of that contract, forever one edit behind. - A stream that replaces push. This is the one that matters. A device holds an open bidirectional stream to the deployment, and challenges arrive down it in real time. That is what lets an approval reach a phone with no APN or FCM in the path — no Apple, no Google, no metadata vantage point on who authenticates when. Plain request/response HTTP cannot do this without exactly the push infrastructure the design exists to avoid. The sovereignty argument in On devices is, mechanically, this stream.
- Mutual TLS as a citizen, not a costume. gRPC runs on HTTP/2 with client certificates as a normal part of the connection, so the deployment authenticates who is calling at the transport, before a single application byte is read. Relying parties and devices are both known by their certificate. This is the floor the whole trust model stands on.
If you need REST#
Some integrations genuinely want a JSON endpoint. The answer is not for Ydentifi to ship one — it is for you to run a thin translator inside your own trust boundary, terminating REST on one side and speaking gRPC to the deployment on the other. You own it, it sits where your other services sit, and it presents the client certificate the deployment expects.
The reason this is your job and not Ydentifi’s is not stubbornness. A gateway that terminates TLS at an edge — a managed proxy, a serverless function, a CDN — strips the client certificate. The deployment then cannot tell who is calling, and mutual TLS, the floor everything stands on, is gone. The system fails closed rather than accept the downgrade. A translator you run inside your boundary keeps the certificate intact; an edge you do not control cannot. This is covered concretely in Deploy.
Why the client is open#
The transport being closed to a second protocol does not mean the code is closed to inspection. The opposite: every piece of Ydentifi that runs outside the server — the SDKs your backend links, the code on your users’ devices — is open source under Apache 2.0. You should be able to read what you embed in your product and ship to your users; a black box on the device would contradict the entire sovereignty pitch. The server internals stay closed, where a smaller attack surface and less to reverse-engineer are a defender’s advantage — but nothing you are asked to trust on your own machines is hidden from you.