Think about the last time you added "confirm this with your fingerprint" to something you built. The fingerprint was the easy part. The hard part was everything around it: an identity provider to register with, a WebAuthn ceremony to host, a public key to store and rotate, a server endpoint whose only job was to receive a "yes, they authenticated" message and decide whether to believe it. Days of plumbing so that a stranger across the internet could be convinced, secondhand, that a finger went down.

Now picture the same feature on NAOMS. You make one call — authorize this action — and that's the integration. Your user touches their sensor. The action proceeds. There was no login to stand up, no ceremony to host, no key for you to keep, and no message from somewhere else that you had to choose whether to trust.

The reason it collapses like that is simple: the part of NAOMS that guards your user's data runs on the same machine as the sensor. So the program that asks for the fingerprint is the program that reads the answer — no errand across the internet, because there's no stranger at the other end. You don't verify a claim that someone tapped; the tap is checked at the only place it can't be forged, and you just receive the result.

flowchart LR
  YA["Your app:
'authorize this action'"] --> D["NAOMS, on the user's machine,
asks the OS to prompt"]
  D --> O["Operating system
checks the fingerprint"]
  O --> D
  D --> G["The same program releases the grant
and your action proceeds"]
  D -. nothing leaves the machine .-> N([no server · no internet])

It also fails the way you'd want a security primitive to fail. If an action needs a fingerprint and there's no sensor, the answer is no — it refuses rather than waving the action through. You can build on that default instead of defending against it; it's the same fail-closed instinct behind every permission decision NAOMS makes.

What you can build on today — and what's still coming

The rule here is to never dress a draft up as finished, so here's the exact line.

Build on this now. The gate underneath is live: every sensitive action in NAOMS already requires a fresh, per-request proof it was really the user. And the core biometric move — our program triggering the OS fingerprint prompt to release a protected key, entirely on the user's machine — is real, and we tapped it this week.

Still coming. Making one touch the approval for every kind of grant — one unified path rather than several — is freshly designed and in implementation, not yet signed off. Worth planning around: a developer build that isn't formally code-signed can't reach the protected store the way a shipped, signed app can, so there's a clearly-labeled development-only stand-in while we sort the signing path. We say so plainly because the point is you can see exactly how the thing guarding your users' data works.

Where it sits

This builds on the rule that no sensitive action happens without a fresh, explicit yes, and it unlocks the simplest shape of that yes: one touch. It rhymes with how authority already moves in NAOMS, where permission is something a person holds and delegates rather than something a server hands down.

So look at what you're building and find the moments that should be hard to fake — the payment, the share, the key. Imagine each of them behind one touch your user makes on their own device, with nothing on the internet getting a vote, and no auth server of yours to run. That's the primitive we're handing you.

Written by AI agents from real project logs; owned and edited by Mujo.