Glossary

Your application — the tenant that integrates Ydentifi. Every call is implicitly scoped to the RP identified by its mutual-TLS client certificate, so one deployment can serve many RPs without their data ever crossing.

One self-hosted Ydentifi instance that you run — a server container and a PostgreSQL database, on your own infrastructure. A deployment owns its own trust chain and requires a license. There is no Ydentifi cloud in the authentication path.

The four-move shape behind every authentication and approval: a device enrolls once via a single-use QR, then per action the server issues a challenge, the device signs the exact details under a biometric, and your server verifies the signature.

A single request for proof over one specific action. It carries the exact on-screen details (e.g. “Approve €4,200 transfer”) and a required tier, reaches the enrolled device over the challenge stream (or by scanning a QR), and resolves once to a terminal state (approved, denied, rejected, dismissed, expired or superseded).

How a challenge travels, with no third-party push in the path. Two distinct streams are involved. The device-facing one is a long-lived bidirectional connection the enrolled device holds open to the deployment, down which challenges arrive in real time (no Apple/Google push). The relying-party-facing one is AwaitChallenge — a server-stream the SDKs wrap into a single blocking call that returns the terminal verdict.

The deterministic serialization the device actually signs — binding the challenge id, a digest of the displayed action text, the device key, and the verdict. Because the action text is hashed into it, altering what the user saw invalidates the signature.

Authenticating a specific action — a signed yes/no over an exact request — rather than just a login or session. This is where Ydentifi is phishing-resistant: the details the user saw are what the phone signs, so nobody can change them in transit. Number matching stops a blind tap. A plain login that a look-alike site relays unchanged is not covered.

Binding an authentication to the content of one operation, so that the approval is valid only for that content. The term comes from Article 5(1) of the EU’s regulatory technical standards on strong customer authentication (Delegated Regulation 2018/389), which requires for a remote payment that the payer sees the amount and the payee, that the authentication code is specific to them, and that any change to either invalidates it. In Ydentifi the phone signs a digest of the exact text it displayed, so when the amount and payee are in that text, a change to either produces a signature that does not verify. Ydentifi supplies the mechanism; whether a payment service provider’s authentication as a whole meets the standard is that provider’s assessment.

Requiring a stronger check for a particular operation than the one the user passed to sign in. A session established with a device unlock can be asked, at the moment of a payment or a change of account details, for a biometric with no passcode fallback, number matching or a location condition. In Ydentifi the minimum is set on each challenge by the relying party’s backend, which is the only component that knows what the operation is worth; a phone that cannot meet it is refused rather than silently downgraded, and the strength actually reached is signed into the response.

A check that the person approving is looking at the screen where the operation started. The relying party shows a short number on its own page, and the authenticator asks the user to type it before the approval can be signed. A user who did not start the operation does not have the number, so a request that arrives unexpectedly cannot be approved by reflex. It is requested per challenge and is independent of the two strength levels: it says nothing about who holds the phone, only that the approver can see the originating screen.

An attack on push-based MFA by an attacker who already holds a user’s password: repeated sign-in attempts send prompt after prompt to the user’s phone until one is accepted, by mistake or to make them stop. It depends on prompts that arrive unrequested and can be accepted with a single tap. Ydentifi removes both conditions. There is no platform push, so a request is seen only when the user opens the app; and number matching, where requested, leaves a user without the number shown on the originating screen about one chance in a hundred of guessing it.

Which check the user passed, stated inside the signed response and returned to the relying party as auth_strength: 1 the device was unlocked, 2 a biometric check with no passcode fallback. Location, number matching and codes are separate dimensions, not higher levels. The RP requests a minimum per action; a device that cannot meet it is refused, not downgraded. The level returned is the one reached. On an approval it is at or above the minimum requested; on any other status read it as a report of what the device did rather than a promise about that minimum.

A phone bound to an opaque identity through the QR code-based enrollment ceremony. It holds a hardware-bound key and is the only thing that can sign that identity’s challenges.

A private signing key generated inside the device’s secure hardware — the Secure Enclave on iOS, StrongBox/TEE on Android — that is non-exportable. Only the public key is registered; there is nothing in a device backup for malware to lift.

Evidence from the phone’s platform about the app that is answering. At launch, the Ydentifi iOS app uses Apple’s App Attest, so a deployment can check that a request comes from the genuine Ydentifi app on a genuine Apple device. It says nothing about which check the person passed. That is the device capability: what the phone reports it can do (passcode, Face ID or Touch ID), signed into each response with the phone’s own key. It is the phone’s statement about itself. The deployment refuses an approval below the level the action asked for.

The native iPhone app your users install to hold enrollments and approve challenges — blank until an RP invites them. An Android app arrives at launch. If you would rather build the ceremony into your own app, use the Swift / Kotlin device SDKs instead.

The hardware names that appear in the factor tiers. A TEE (Trusted Execution Environment) is an isolated region of the processor for secrets and cryptography; the Secure Enclave (iOS) and StrongBox (Android) are hardware-backed instances of that idea, where a hardware-bound key lives. Class 3 is Android’s strongest biometric grade (spoof-resistant, hardware-backed). On Android, the biometric-only level requires this grade.

The transport for every RP-facing call: both sides present certificates, so the connection is encrypted and the client is authenticated. The RP’s client certificate is what identifies the tenant — which is why most requests carry no identity in the body.

The certificate hierarchy your deployment owns — your certificate authority and the RP certificates it issues. You issue, store, and rotate these keys; Ydentifi never holds them for you.

The module-lattice digital signature algorithm NIST standardised in FIPS 204 (2024), designed to resist forgery by a quantum computer. Ydentifi uses the ML-DSA-65 parameter set, at NIST security category 3, whose public key is 1,952 bytes and signature 3,309 bytes. It is always paired with a classical signature — Ed25519 for the root key and licenses, ECDSA P-256 for approvals on devices enrolled for post-quantum signing — and both signatures are verified, so a forgery requires breaking both schemes.

The signed grant that permits a deployment to run and bounds it — its user cap and validity window. Enforced by the server itself; there are no external API calls in the auth path.