Authorize an action
ReadyYdentifi authenticates actions, not just logins — a signed yes-or-no over the exact thing a user is about to do. The text you put in front of them is the security boundary: it is hashed into the signature, so make it specific, and set the strength to match the stakes.
Who this is for: whoever decides what in your product deserves a hard approval and how to phrase it. For the code that issues and verifies the approval, see step-up.
To see an approval from the person’s side, view Approving a sign-in in the authenticator manual.
Not the login — the action#
A login proves someone got in. An action approval proves this person approved this specific thing, right now.
That difference is where phishing and fatigue attacks die. A one-time code or a bare “tap to approve” authenticates a session — an attacker who relays it can then do whatever they like. Ydentifi asks the user to sign the exact operation, so a relayed or altered request — a changed amount, a different destination — produces a signature that will not verify. The approval is bound to the deed, not the door.
What’s worth authorizing#
Anything a user would regret an attacker doing on their behalf. Common ones:
Design the context string#
The context is the exact text the user sees and signs. It is hashed into the signature, so it is the thing being approved — if it is vague, the signature vouches for nothing in particular.
Approve €4,200 transfer to ···· 8842
Withdraw €500 at ATM-Athens-42
Delete production database ‘orders-eu’Every detail the user needs to judge the action — amount, destination, resource — is in the string.
Approve this action
Confirm
Authorize transactionSigns nothing specific — an attacker can attach that approval to a different operation entirely.
Practical rules: write it for a human to read on a phone; include the consequential parameters; keep it unambiguous; and stay within 256 bytes (the app renders it as UTF-8). Treat it like the confirmation line on a wire transfer — because that is exactly what it is.
Set the strength per action#
The approval’s strength is your choice, per action — you are not locked to one factor across the product. Match it to the stakes: a signed biometric approval for most things, add location for a site or branch action, for the highest-value or most sensitive ones. The server enforces it on approvals, and a device that cannot meet what you asked for is refused rather than downgraded. See Factors & levels.
What a signed approval gives you#
- Non-repudiation. You hold a signature, made by a hardware-bound key, over the exact words the user approved. Not “a session was authenticated” — “this user approved this.”
- Phishing & relay resistance. The details are inside the signed bytes, so a man-in-the-middle cannot change what gets done without breaking the signature.
- A clean audit trail. Every approval and denial is a discrete, verifiable event tied to the action — far stronger evidence than a login timestamp.
The deployment already refuses any approval below the tier you requested, so APPROVED means your bar was met. A refusal is not held to that bar — somebody saying no is not made to clear an authentication step first — so the tier on a DENIED frame may sit below what you asked for. The frame tells you more than that. auth_strength is the tier the device actually reached, which can be higher than the one you asked for: request DEVICE_ACCESS and read BIOMETRIC, and the person passed a biometric check rather than typing a passcode. The coarse location result sits alongside it. Read both and put your own policy on top — step up when a device-unlock approval was all you got, flag a far-location approval for review — rather than treating the approval as an opaque boolean.