Launch on 01/01/2027Licenses available from 01/01/2027
Docs / Orientation / What is Ydentifi

What is Ydentifi

Ready
TL;DR

Ydentifi is a sovereign, self-hosted, embeddable multi-factor authentication and action-authorization layer. You run it on your own infrastructure, you hold the keys, and it holds no end-user personal data. Its one job is to prove that a real, enrolled person approved a specific action — the phone signs the exact details shown, so nobody can change them in transit — and you add it to products you already run.

Who this is for: anyone landing here for the first time who wants the shape of the thing before the details. Two minutes here, then Quickstart to see it work or The ceremony to see how.

In one sentence#

Ydentifi answers one question, well: is this really your user, and do they approve this?

Two objectives, one mechanismThe right-hand column is the left-hand column plus the details of a specific action.AuthenticationTHE QUESTION IT ANSWERSIs this the right person, on their ownphone, right now?WHAT THE CUSTOMER SUPPLIESwhich user is being askedhow strong a check is requiredhow long the request stays openWHAT COMES BACKapproved, refused, or expiredsigned by a key inside that phonea record of when, and which deviceAction authorizationTHE QUESTION IT ANSWERSDid this person agree to this exactthing, and can it be shown later?WHAT THE CUSTOMER SUPPLIESeverything on the left, and:the words the user will reada number they must type backwhere they must be standingWHAT COMES BACKeverything on the left, and:a signature over the words shownthe reason, when refusedSame exchange. Same key. Same phone.What differs is what the customer puts in — and what they hold afterwards.
Authentication and action authorization: the question each one answers, and why they are not the same question.

Not “are they logged in” — your own system already handles that. Ydentifi is the layer you reach for when an action matters enough to want a second proof: a login from a new place, a payment, a settings change, a privileged operation. It issues a challenge bound to that exact action, the user approves it on a device only they hold, and the device signs the decision. Your deployment checks that signature before it reports the result. Passwords stay your job; Ydentifi does the hard part — proving presence and intent without either of you trusting the network in between.

The mental model#

Six words carry the whole system. You will meet them everywhere, so it is worth pinning them once — the Glossary has the full definitions.

What changes, and what does notYdentifi is inserted into the login the customer already has. It does not replace any part of it.TODAY — PASSWORD ONLYUser signs inThe login pagethe customer builtCheck thepasswordnothing hereSession openedA stolen password is enough.Nothing in this path can tell a copy from the original.WITH YDENTIFIUser signs inThe login pagethe customer builtCheck thepasswordAsk the phoneto signSession openedOne box is added.Everything the customer already built stays exactly as it is.
A password-only login, and the same flow once Ydentifi is added.
Deployment

Your running Ydentifi — server + database, on your infrastructure. There is no Ydentifi cloud in the loop.

Relying party (RP)

Your application, the thing asking for a proof. One deployment can serve several.

Opaque user

A person, to Ydentifi, is just an opaque id — no name, email, or number. You stay the controller of who they are.

Device

An enrolled phone holding a hardware-bound key in its Secure Enclave or Keystore. The key cannot be copied off the phone.

Challenge

A single request to approve one named action, with a short life. Approve, deny, or let it expire.

The ceremony

The four-move round trip — issue, deliver, approve, verify — that turns “approve this” into a signed proof. See The ceremony.

Around that core sit the factors — two signed levels, plus location, number matching and codes as separate dimensions — and you choose what a given action demands per call, not once per user. That is Factors & levels. For the same picture written for evaluators, see the product overview.

What “sovereign” buys you#

Sovereign is not a slogan here; it is a set of concrete properties that fall out of the design:

  • You host it. Any cloud, on-prem, or fully air-gapped. The authentication path makes no outbound calls — not to Ydentifi, not to Apple or Google push. See Architecture.
  • You hold no user data — because there is none to hold. Users are opaque ids; you remain the sole controller of the person behind one. This is what keeps Ydentifi out of your data-protection surface.
  • You hold the keys. The trust chain is your PKI, minted on your machine. Ydentifi never has a key to your deployment.
ⓘ Nothing reaches us

The running deployment makes no calls to Ydentifi — not to renew, not ever. When you need the next license, you pull it from your terminal and drop it in; the server never phones home. Everything a person does stays local. See Get a license.

What it is not#

Not an identity provider. No OIDC, no SAML, no SSO. Ydentifi does not own your users or your login — it authenticates an action inside the product you already have.
Not a passkey replacement. Passkeys fix login; Ydentifi authorizes the action past it. If you use passkeys, keep them — see On passkeys.
Not a consumer product. There is no Ydentifi account for your end users. They enroll a device against your deployment; they never have a relationship with Ydentifi.
Neither controller nor processor of your users’ data. You run the deployment, and Ydentifi has no access path to it, so your users’ data never reaches Ydentifi. That is a structural fact, not a policy setting — there is no configuration that turns it on.
Not a black box. The device SDK you embed — the code that does the cryptography on the phone — is licensed Apache 2.0, and its source is published at launch, so the security-critical path can be audited. The parts kept closed are the server internals.

Where to go next#

  • Quickstart — bring the whole thing up locally and drive a real signed approval, in about five minutes.
  • The ceremony — the four moves, what gets signed, and why it resists phishing.
  • Architecture & topology — the components, the listeners, and where trust sits.
  • Glossary — every term above, defined once.
  • API reference — when you are ready to integrate.
Relates to
← Previous
How to read these docs
Next →
Glossary
QuickstartThe ceremonyGlossary
Opens on 01/01/2027

Available at launch

Until then, you can try the whole ceremony on your own phone.

Try the live demo