ASL Verifier — Source library
Public documentation snapshot: 2026-09-08
Confirm it is them. Without building a face database.
A one-to-one face check that compares a person to their own ID, and never searches a database.
Confirm it is them. Without building a face database.
Built for: The support lead who has to decide, on a phone call or a web form, whether the person asking to get back into an account is really the account holder · A small firm signing up clients remotely who needs a defensible record that an identity check happened, without keeping anyone's face on file · A product owner who wants a face check as one more signal in a sign-in flow they already have, not as a replacement for it · The privacy or compliance reviewer who has to approve a facial-recognition purchase and needs the boundary written down in plain language
ASL Verifier exists because of this.
Somebody contacts you and says they are locked out. They know the email on the account. They know roughly when they signed up. They sound completely sincere. You have thirty seconds to decide whether to let them back in, and either answer can go badly: turn away the real person and you have a furious customer, let in the wrong one and you have handed over somebody else's account. Most teams settle this with a gut call and a note in the ticket. The note says the caller answered the security question. It does not say who actually turned up. So you look at face verification, and the shopping trip goes wrong almost immediately. Nearly every option quietly does more than you asked. You wanted to check one person against the ID they just showed you. What you get offered is a face search: an engine that can be pointed at a gallery, that guesses age and gender on the side, that keeps a copy of the face so it can compare it to others later, and that ships the photograph to somebody else's servers to do it. The moment you buy that, you own a face database you never wanted, in a category of technology your customers already distrust and your state legislature is already writing about. The project never starts, because nobody will sign off on it. And then there is the paperwork. If you do run a face check, you need to be able to say afterwards exactly what the person was told before the camera turned on, exactly what they agreed to, what the answer was, and what happened to the images. Most tools give you a score and a log line. A score is not consent. A log line is not evidence. When somebody asks six months later why they were refused, you need something better than a number nobody can explain and a photo you should not still have. The last problem is the one nobody warns you about: the vendor who will not tell you what has actually been proven. Every face product in this market arrives with accuracy figures. Very few will tell you who measured them, on which build, and which gates the product has not passed. That is the difference between a claim you can take to a review board and a claim you have to defend on faith.
ASL Verifier exists because of this.
One-to-one only, enforced in the code rather than promised in a policy document. It cannot be pointed at a gallery.
ASL Verifier exists because of this.
Images are never stored. There is no upload directory and no retention path, so there is nothing to breach, subpoena, or forget to delete.
ASL Verifier exists because of this.
The engine fails toward review, never toward approval. A pass requires every single required check to be present and passing.
ASL Verifier exists because of this.
A face result never signs anyone in by itself. It is handed to your existing sign-in as one piece of evidence, which keeps a camera glitch from becoming an account lockout.
ASL Verifier exists because of this.
It publishes what has not been proven, not only what has. The accuracy figures name the build they were measured on, and the gates that remain open are listed on the page.
ASL Verifier exists because of this.
Scores and templates never leave the engine. Not to the browser, not to the app, not into the decision record.
ASL Verifier exists because of this.
The live challenge is ordered randomly per attempt, so a recorded session cannot be replayed into the next one.
How ASL Verifier works, start to finish.
ASL Verifier does exactly two things, and refuses to grow past them. The first is the real job: compare the portrait printed on an identity document with the face of the person in front of the camera right now, and return one clear answer. The second is a deliberately separate utility that compares two still photographs to each other, for cases like reviewing suspected duplicate accounts. The two live behind different result contracts on purpose, so nobody can take the answer from the photo comparison and treat it as an approval. The live check is a short guided sequence, not a single selfie. The person is asked for the front of their ID with the rear camera, with a plain-language screen explaining what happens next before the camera flips. Then the front camera captures eight frames across a head-turn challenge: two looking straight ahead, two turned left, two turned right, and two back to centre. The order is chosen fresh each time by the service, so the sequence cannot be recorded once and replayed. The service checks the sequence for a consistent identity, for stable distance, and for frames that are simply the same picture submitted twice. Every step of that flow exists in English and in Spanish. What comes back is one of three answers, and pass is the hardest of the three to earn. A missing signal, a failed check, an engine that could not run, or a policy that does not line up all resolve to review or fail. There is no path through the code that falls back to pass because something was unavailable: an answer is only a pass when every required check is present and every one of them passed. When the answer is review, the person is told a broad reason in ordinary words, such as the reference image quality or an inconclusive live sequence, and is offered a retry or a human. They are never shown the internal score, and neither are you: exact similarity numbers stay inside the engine and never appear in a result, a receipt, or a decision record. What the service keeps is the interesting part. It keeps no images. The submitted bytes are held in working memory for the length of the request, used, and cleared; there is no upload folder and no retention path anywhere in the flow. What survives is a decision record with no face in it, holding the outcome, the moment, the broad reason category, the account it belongs to, and a reference you can quote back. The person's identifier is stored only as a keyed one-way digest, so the record cannot be read back to a name. Consent is recorded against the exact wording that was shown, and a notice that has changed, or one accepted more than ten minutes earlier, is rejected before any comparison runs. It is built as a single self-contained service: the comparison happens on the machine running it, with no outside processor in the path and no image sent anywhere else. A face result is treated as evidence and nothing more. It never opens an account on its own; every result is marked non-authorising, and whatever already owns your sign-in still has to check its own session, its own second factor, and its own policy before anyone gets in. Choosing not to use the camera is a first-class path, not a punishment. Someone can decline, use a passkey or another method, and the service records no face result at all and no failure against them. There is also an Android companion, distributed to invited accounts, that captures with the device cameras and holds no permission to read the photo library at all.
Everything in the current release.
Each of these is built and working today. Nothing on this list is a roadmap item.
One person against one document, and nothing else
The identity check is one-to-one by construction. It compares the face in front of the camera to the portrait on the document that person just presented. There is no gallery, no watch list, no stored template to search later, and no code path that could turn it into a face search even if someone asked. The two-photo utility is bounded the same way: it searches only inside the two pictures you deliberately submitted.
Eight live frames in an order you cannot predict
Instead of one selfie, the check captures eight frames across a head-turn sequence: centre, left, right, and back to centre, two frames each. The service picks the order fresh for every attempt, so a recording of one session is useless in the next. The sequence is checked for a consistent identity, for stable distance, and for a frame that is simply the same picture submitted twice, whether byte-identical or re-encoded.
Pass is the hardest answer to get
Every result is pass, fail, or review, and the engine is built to fall the safe way. A required check that is missing, an engine that could not run, an ambiguous outcome, or a policy version that does not match all resolve to review or fail. A pass is only returned when every required check is present and every one of them passed. There is no fallback that turns a problem into an approval, which is the failure mode that makes these systems dangerous.
No images are kept, anywhere
Submitted image bytes live in working memory for the length of the request and are cleared afterwards. There is no upload directory and no image-retention path in the service. If someone later asks you to produce or delete the photograph of their face, the honest answer is that there has never been one to produce or delete.
A decision record with no face in it
Each check writes one durable record: the outcome, the moment, the broad reason category, the account and tenant it belongs to, and an opaque reference. It carries no image, no name, no document number, and no similarity score, and the person's identifier is stored only as a keyed one-way digest so the record cannot be read back to an individual. It is the thing you hand to an auditor or a customer six months later.
A signed approval that can only be spent once
A successful check produces a short-lived signed statement bound to the exact application, tenant, subject, and session it was issued for, valid for at most ten minutes and five by default. The system that consumes it verifies the signature and then burns the identifier, so the same approval cannot be replayed; a consumer that offers no replay guard is refused rather than allowed through. Only the verification service can sign one; the browser and the app never hold a signing key.
Consent tied to the exact words shown
Consent is recorded against a fingerprint of the specific notice that was on the screen, together with its version and the time. A notice that has changed, or a consent older than ten minutes, is rejected before the comparison runs. If you change the wording, old consent does not silently cover the new notice. You can prove which text a person agreed to, not just that a box was ticked.
Reasons a person can understand, without leaking the internals
When a check lands in review, the result carries one broad category in ordinary language, drawn from a fixed set: reference image quality, live image quality, inconclusive active liveness, an inconsistent live sequence, an inconclusive face match, capture or match review, or service unavailable. The person gets something actionable. Nobody gets the score, the threshold, or the internal check codes they could tune an attack against.
Declining the camera is a real option, and costs nothing
A person can stop before submitting and use another sign-in method instead. The camera is shut off, pending captures are cleared, and no face result is created. Choosing another route is explicitly not recorded as a failed verification, so a person who does not want a biometric check is not quietly penalised for saying no. The verifier never asks for or receives the credentials, tokens, passkeys or recovery codes belonging to your sign-in.
Two-photo comparison, deliberately fenced off
A separate feature compares two still photographs you are authorised to use, for jobs like duplicate-account review. It examines up to ten faces in each photo and at most one hundred pairs between them, and it returns match, no match, review, or unavailable. A close runner-up inside the ambiguity margin goes to review rather than picking a winner. It uses a different result shape that can never mint an approval, and it is never presented as proof of identity.
Bounded, checkable inputs
Every submitted image is capped at 12 MiB, between 128 and 8,192 pixels on each edge, and no more than 24 megapixels. The declared dimensions are read before the decoder is ever given memory, then checked again against the decoded image, so a file that lies about its size is rejected before it can cost anything. Only JPEG, PNG and still WebP are accepted; animated files are refused up front.
An Android companion with no access to your photos
The companion Android app captures the ID and the live frames with the device cameras. It asks for two permissions only, camera and network, so it has no ability to read the photo library at all and cannot accept a stored picture as live evidence. Captured buffers are overwritten when replaced, cancelled, or submitted, nothing is written to the photo library, and screenshots are blocked during the normal flow.
A tilted ID gets a second chance, not a lower bar
If the document portrait cannot be read because the ID was held at an angle, the service makes one bounded, deterministic attempt to correct the orientation and read it again. It stops at the first usable correction rather than hunting for the angle that scores best, it never rotates the live frames, and a clear no-match on a readable document is never retried. The rotated canvas is held to the same size limits before any memory is allocated.
English and Spanish through the whole web flow
The web flow is bilingual end to end: the consent notice, the capture guidance, the review reasons, and the result screen all exist in English and Spanish, switchable on the page. This is not a translated marketing page with an English form underneath. The words a person is asked to agree to appear in the language they chose. The Android companion ships in English today.
A shareable receipt that carries nothing sensitive
The result screen can hand the person a short receipt of what happened: the outcome, the mode, the request reference, the broad review category where there is one, the engine version that decided, the completion time, and the safe next step. It never serialises the whole response, and it excludes images, scores, similarity values, access tokens and internal check codes.
Numbers we can stand behind.
Every figure below comes from the product's own release record or test suite, not from a marketing estimate.
Numbers we can stand behind.
Consent is bound to the exact notice text and expires in ten minutes, so you can prove what a person actually agreed to and when.
Numbers we can stand behind.
No demographic or attribute guessing of any kind. It does not estimate age, gender, emotion, or anything else about a face.
Numbers we can stand behind.
The whole comparison happens inside one self-contained service with no outside processor in the path.
Surfaces and status.
Status as of 2026-09-02. The service answered a public request with HTTP 200 on 2026-09-02, returning a 32,879-byte page, and its liveness check reported the running service by name. The running release is 0.5.0-dev.11, cut over on 2026-08-24 at 01:41 UTC after 127 service checks and 53 engine checks passed on the exact release candidate. The Android companion is version 0.1.1 build 2, published to invited accounts through Google Play on 2026-08-23. It is In development rather than Early access because the running service describes itself, in its own interface, as an access-controlled environment whose results are advisory and do not prove legal identity, document authenticity or permission to access an account; because our own records list a consenting physical-device run, a broader independent evaluation and a production authorisation review as gates that remain open; and because no outside application is connected to it yet. It is real, it is running, and you can be shown it today. It is not yet something we would tell you to put in front of your customers unattended.
Worth more together.
Products on this platform share one sign-in, one support queue, and one engineering standard. These pair naturally with ASL Verifier.
ASL Timestamp Anchor
Verifier deliberately keeps no images, so the decision record is the evidence. Timestamp gives that record an independent, verifiable proof of when it existed, which is what turns a short internal record into something you can rely on months later.
ASL Files
If your process genuinely has to retain a copy of a document, keep it somewhere built for it rather than in the verification path. Files stores it encrypted, with access that has to be granted rather than guessed from a link.
ASL Intake
Intake is where a new client first tells you who they are, remotely and often in Spanish. Adding a one-to-one face check at that moment closes the gap between the form and the person filling it in.
ASL Recovery Center
Account recovery is the single place where a wrong yes hurts most. A face check gives a support agent one more piece of evidence before restoring access, instead of leaning on a security question anyone could look up.
ASL Scan
Verifier hardens one step of your flow. Scan looks at the application you are embedding it into, so the careful check is not sitting behind a careless front door.
Recent progress.
This product ships often. The most recent verified changes, newest first.
Recent progress.
2026-08-20 two hardening changes were written and recorded as development work: a strict binding between the running engine and the exact model files it is allowed to load, and a short-lived single-use authorisation on every biometric request so a captured request cannot be replayed. Neither was live that day; the model binding is now confirmed present in the release running today. On.
Recent progress.
2026-08-23 the guided flow shipped: the document step now explicitly asks for the portrait side with the rear camera and stops on its own explanation screen before switching to the front camera, so nobody is surprised by an eight-frame head-turn when they expected one selfie. The same release added a shareable, privacy-minimised result receipt and reduced review reasons to a fixed set of broad plain-language categories. Also on.
Recent progress.
2026-08-23 , the Android companion was published privately through Google Play to invited accounts, first at 0.1.0 and then at 0.1.1 build 2. On.
Recent progress.
2026-08-24 at 01:41 UTC the current release, 0.5.0-dev.11, went live: it can now make one bounded, deterministic attempt to read a document portrait held at an angle, without ever rotating the live frames and without retrying a clear no-match. That cutover passed 127 service checks and 53 engine checks first. Later the same day a further candidate was validated at 127 and 54 checks: it closes a real gap where two different people split evenly across the centred frames could average into a passing face. It is deliberately being held back from release until a run on real phone hardware confirms it does not push ordinary users into review, so that gap is still present in the running release and is stated as a limit on this page. On.
Recent progress.
2026-08-28 a narrated product film and key art were produced.
Recent progress.
Pricing for ASL Verifier is quoted after a short conversation about your situation, because the right scope differs from one team to the next. There is no charge for that conversation.
Is it actually ready to use?
It is running and answering requests today, and we can show it to you, but it is not finished. The service itself says its results are advisory rather than an approval, and our own records list a run on real phone hardware, an independent evaluation and a production sign-off as gates still open. If you want an approved, certified identity-proofing decision engine on day one, wait. If you want to evaluate a careful extra signal with a boundary you can put in front of a privacy reviewer, and you are comfortable being early, that is exactly where it is.
What does it cost?
We have not published a price. Verifier is agreed per deployment because the shape varies a lot: how many checks you expect, where it runs, and which of your systems consume the result. Talk to us and you will get a number and a written boundary rather than a per-check meter that surprises you later.
We already use a verification vendor. Why change?
The question worth asking your current vendor is what they keep and what else the engine can do. If they retain the image or the face template, you now own a face database and its breach risk, its deletion duty, and its legal exposure. Verifier keeps no images and cannot search a gallery. If your existing vendor already meets that bar and is further along than we are, keep them. Plenty do not meet it.
What happens to the photograph of my customer's face?
It is used and dropped. The image bytes are held in working memory for the length of the one request, compared, and then cleared. There is no upload folder and no retention path. What survives is a record of the decision with no face in it, in which the person's identifier appears only as a keyed one-way digest. This is the answer we would rather give a regulator than a retention schedule.
How much work is it to connect to what we already have?
It is designed to sit beside your existing sign-in rather than replace it. Your system asks for a check, the person completes it, and you receive a signed short-lived statement that your own sign-in verifies and then decides what to do with. Nothing about your existing accounts, passwords, or second factors moves or changes, and there is no data migration because there is no stored biometric data to migrate. Be aware that no outside application is connected yet, so yours would be the first and that is a project rather than a key you self-issue.
What happens if we stop paying, or if you disappear?
You lose the ability to run new checks. You do not lose your records, because the decision records contain no face and there is no biometric database of yours held hostage. It is built as one self-contained service rather than a chain of outside processors, which is the property that makes this question answerable at all.
Can it identify someone from a crowd or a database?
No, and it is not a setting we could switch on for you. It compares one face to one reference image supplied in the same request. There is no stored template, no index, and no gallery to search. If you need one-to-many identification, we are the wrong supplier and we will say so.
What if the check fails for someone who really is the account holder?
That is the case the design cares about most. A failure to read a face, a poor photo, or an inconclusive result comes back as review, not as a denial. The person is told a broad reason in plain words, offered a retry, and offered a human. They can also decline the camera entirely and use another method, and that choice creates no face result and is never recorded as a failed verification.
Do we have to tell people this is happening, and can we prove they agreed?
Yes to both, and the second part is built in. Consent is recorded against a fingerprint of the exact notice shown at the time, with its version and timestamp, and a notice that has changed or a consent older than ten minutes is rejected before any comparison runs. That gives you a defensible answer to what were they told, not just a box that was ticked.
Does it work in Spanish?
The web flow does, completely: the consent notice, the capture instructions, the review reasons, and the result screen all exist in English and Spanish and switch on the page. The Android companion ships in English only today. Since consent is legally meaningful, it matters that the wording a person agrees to is in the language they actually chose, which is why the web flow was done properly first.
What has actually been tested, and by whom?
By us, and we will show you the numbers and the gaps together. Our own 500-person photo benchmark, our 694-case synthetic suite, and a small blind check against a family of genuine lookalikes are all measured runs we can reproduce. What has not happened is independent laboratory testing, demographic performance testing, certified presentation-attack testing, and a run on real phone hardware. Those are named gates in our own acceptance document, not oversights we forgot to mention.
Can we run it on our own hardware?
That is how it is architected: one self-contained service that does the comparison on the machine running it, with no outside processor in the path and images that never leave it. Every connected application gets its own revocable credential and a scope the service assigns rather than one the application claims for itself. What we cannot yet tell you is that somebody else has already installed it on their own hardware, because nobody has. It would be a first deployment done together.
What should I know before I rely on it?
We would rather you hear this from us than discover it later. As of 2026-09-02:
What should I know before I rely on it?
It is not yet approved for production use, and we will not pretend otherwise. The running service describes itself as an access-controlled environment whose results are advisory. A consenting physical-device run, a broader independent evaluation and a production authorisation review are written down as open gates and have not been closed.
What should I know before I rely on it?
It does not tell you whether the identity document is genuine. It compares the face printed on the document to the live face. Checking that a licence is real, unaltered, and matches its own machine-readable data is a separate job that is not part of this product today.
What should I know before I rely on it?
The live challenge is an active one: the person is asked to move, and the sequence is checked for a consistent identity, stable distance, and duplicate submissions. It has not been certified against a published presentation-attack standard, so we do not describe it as certified spoof resistance.
What should I know before I rely on it?
There is a known limit in the identity-consistency check on the release running today. It compares the reference portrait against a combined view of the centred frames, and we have demonstrated internally that two different faces split evenly across those frames can average into a passing result. A hardening change that compares the centred frames against each other first has been written and has passed its test suite, but it is deliberately held back until a run on real phone hardware confirms it does not push ordinary people into review. We would rather tell you this than have you find it.
What should I know before I rely on it?
The accuracy numbers on this page come from our own measured runs on a public research photo set and a repeatable synthetic set, on the August 2026 build of the same face-comparison engine family that runs today, not on the exact release currently deployed. They are real and reproducible, and they were produced by us rather than by an outside laboratory. Independent testing, including demographic performance testing, is a gate we have written down and have not yet passed.
What should I know before I rely on it?
A face result never authorises a sign-in on its own, by design. Every result is marked as non-authorising, and a separate second factor is always required. If you need face alone to open an account, this is not that product.
What should I know before I rely on it?
Access today is by a code that ASL issues, not open self-service sign-up. Getting started means a conversation first.
What should I know before I rely on it?
The server-to-server interface for connecting your own application is built and tested, but it has no public route and no outside application is connected to it yet. Connecting the first one is project work, not a self-service key.
What should I know before I rely on it?
The Android companion has been accepted on a simulated device and published privately through Google Play; a full end-to-end run on a physical device camera with a consenting person is a gate we have written down and not yet closed, so we do not claim hardware camera acceptance. That app also ships in English only today, while the web flow is fully bilingual.
What should I know before I rely on it?
The strictness control on the two-photo comparison is presently a development-stage control. It is on the screen and it only ever changes how much facial similarity is required, never face detection or the live-challenge rules, but it is not yet a settled production setting.
Confirm it is them. Without building a face database.
Prefer email? contact@autosecurelogin.com