Skip to main content

​
Fail-closed behavior

FaceSign issues Success with a verified_human assertion only when the deployed verification flow completes and its result is verified_human. That requires detected liveness, explicit intent confirmation, and no configured deepfake veto. Missing or contradictory evidence cannot become Success. Failures have three wire shapes:
  • A request or session-creation failure can return an HTTP error before verification starts.
  • A completed non-pass or analysis failure may return a signed Responder/AuthnFailed response with no Assertion.
  • An unreachable, abandoned, or late flow may produce no usable response before the SP timeout.

​
Current time and rate boundaries

The current flow stores one terminal Success or denial durably and returns the same byte-identical SAML result to later status polls, including when another application instance handles the poll. The 120-second analysis grace never extends the five-minute authentication deadline. Missing analysis at the applicable cutoff becomes a signed, status-only denial. AuthnRequests must be unsigned. FaceSign rejects duplicate AuthnRequest IDs for the same SP during the 10-minute reservation. The receiving SP separately owns durable Response and Assertion replay rejection.

​
Fallback

The receiving SP defines fallback for a signed denial, browser timeout, and unavailable IdP. A signed denial is an authenticated non-success. Timeout and unavailability may produce no SAML response to validate. Never turn missing FaceSign evidence into a successful sign-in or step-up. Set the full redirect timeout before UAT. It must account for FaceSign’s five-minute authentication deadline and the receiving application’s recovery UI.

​
Troubleshooting

Every handled GET/POST SSO response includes an X-FaceSign-Attempt-ID header. Error JSON also includes the same value as attemptId. Share that identifier and the UTC test time when asking FaceSign to trace a failure. Do not share a live login_hint, full request URL, raw SAMLRequest, or raw RelayState. When the SSO endpoint returns one of these current codes, use it to narrow the check: If the camera never starts, confirm browser permission for the FaceSign session and close any application using the camera. A blocking capture issue may trigger avatar-spoken correction. Healthy sessions do not receive unsolicited camera coaching. Validate a signed denial before classifying it. The same Responder/AuthnFailed shape can represent an explicit non-pass or a technical analysis failure.

​
Before UAT

  • Register the exact sandbox entityID and HTTPS POST ACS.
  • Confirm the SP sends unsigned AuthnRequests and either omits RequestedAuthnContext or sends exactly one Comparison="exact" reference to FaceSign’s fixed unspecified class.
  • Use synthetic Subject or login_hint and RelayState fixtures. For Redirect, put the hint in the query; for POST, put it in the form body. Verify that RelayState is preserved but never treated as identity evidence. Encode a literal + in a hint as %2B.
  • If the SP reads response Attributes instead of NameID, record the exact bounded list of one or two Attribute Name and NameFormat behaviors and confirm that FaceSign configured that list for this exact SP. An omitted NameFormat must be explicitly agreed. Expect no correlation Attributes until that per-SP list is configured.
  • Exercise success, explicit non-pass, timeout, and IdP-unavailable paths. None of the last three may become Success.
  • Validate signatures, correlation, audience, recipient, destination, time bounds, and durable replay rejection at the receiving SP.