> ## Documentation Index
> Fetch the complete documentation index at: https://idp-docs.facesign.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Operations

> Failure handling, limits, troubleshooting, and joint UAT for the Silverfort pilot.

## Fail-closed behavior

FaceSign issues `Success` with a `verified_human` assertion only when the current flow completes,
liveness is detected, intent is explicitly confirmed, and no configured deepfake veto fires.
Missing or contradictory evidence cannot become `Success`.

Failures have different wire shapes:

* Some request or session-creation failures return an HTTP error before the verification flow.
* A completed non-pass or analysis failure may return a signed `Responder/AuthnFailed` response
  with no assertion.
* An unreachable, abandoned, or late flow may yield no usable response before Silverfort's timeout.

## Current time and rate boundaries

| Boundary                                  | Current value  |
| ----------------------------------------- | -------------- |
| Overall authentication deadline           | Five minutes   |
| Assertion `Conditions` validity           | Five minutes   |
| Bearer `SubjectConfirmationData` validity | Five minutes   |
| Analysis grace after completion           | 30 seconds     |
| Session creation per client IP and SP     | 20 per minute  |
| Session creation across one SP            | 120 per minute |

AuthnRequests must be unsigned. The receiving SP owns durable Response and Assertion replay
rejection.

## Integration-owned fallback

Silverfort must define behavior for a signed denial, a browser timeout, and an unavailable IdP.
The first is an authenticated non-success. The other two may have no SAML response to validate.
Silverfort should preserve its existing IdP-unavailable controls and must never turn missing
FaceSign evidence into a successful step-up.

Make the full Bridge redirect timeout explicit before UAT. It needs to account for FaceSign's
five-minute authentication deadline and Silverfort's own recovery UI.

<h2 id="troubleshooting">Troubleshooting</h2>

Do not assume every rejection contains a stable public code. When the SSO endpoint does return
one of the current codes below, use it to narrow the check:

| Code                    | Check                                                                                            |
| ----------------------- | ------------------------------------------------------------------------------------------------ |
| `unregistered_sp`       | Compare the wire `<Issuer>` with the coordinated entityID, including case and trailing slash.    |
| `destination_mismatch`  | Re-import metadata and compare `Destination` with the FaceSign SSO URL.                          |
| `acs_mismatch`          | Compare `AssertionConsumerServiceURL` with the exact registered ACS.                             |
| `subject_echo_disabled` | Omit Subject, or confirm that FaceSign approved echo for this isolated sandbox.                  |
| `unsupported_request`   | Remove AuthnRequest signature material and unsupported request options.                          |
| `invalid_request`       | Check XML structure, NameID policy, Subject, requested context, and timing.                      |
| `malformed_request`     | Check XML and the binding's encoding. Redirect uses DEFLATE plus base64; POST uses plain base64. |
| `request_too_large`     | Reduce the encoded request and RelayState payload.                                               |
| `rate_limited`          | Honor `Retry-After` and stop creating parallel sessions.                                         |

If the camera never starts, confirm browser permission for the FaceSign session and close any
application already using the camera. A blocking capture issue may trigger avatar-spoken
correction. Healthy sessions do not receive unsolicited camera coaching.

If FaceSign returns a signed denial, validate it before classifying it. The same
`Responder/AuthnFailed` shape can represent an explicit non-pass or a technical analysis failure.

<h2 id="silverfort-joint-acceptance-checklist">Silverfort joint acceptance checklist</h2>

Use the exact coordinated sandbox entityID, HTTPS POST ACS, sanitized fixtures, and recorded Bridge
build for every acceptance run. Actual names, device identifiers, and evidence stay private.

## Repeatability matrix

Run this matrix: 2 agreed test people × 2 agreed device/browser combinations × 3 fresh
Bridge-initiated pass runs = 12 successful runs.

| Test slot               | Pass 1  | Pass 2  | Pass 3  |
| ----------------------- | ------- | ------- | ------- |
| Test person 1 + setup 1 | Pending | Pending | Pending |
| Test person 1 + setup 2 | Pending | Pending | Pending |
| Test person 2 + setup 1 | Pending | Pending | Pending |
| Test person 2 + setup 2 | Pending | Pending | Pending |

Record every run in the private partner worksheet:

* AuthnRequest ID, FaceSign session ID, Response ID, Assertion ID, and approximate UTC time.
* Exact Subject/NameID and RelayState preservation when those fields are enabled.
* Silverfort signature, Destination, Recipient, Audience, correlation, and time-validation results.
* The policy action and named owner sign-off.

## Negative matrix

| Case                                                      | Expected fail-closed result                                              |
| --------------------------------------------------------- | ------------------------------------------------------------------------ |
| Explicit intent non-pass                                  | Signed `Responder/AuthnFailed`, no Assertion; Silverfort does not grant. |
| Browser abandonment / Bridge timeout                      | No `Success`; the agreed timeout fallback runs.                          |
| FaceSign unavailable                                      | No `Success`; the agreed unavailable fallback runs.                      |
| Tampered Response and tampered Assertion                  | Bridge rejects both.                                                     |
| Duplicate Response ID and duplicate Assertion ID          | Bridge rejects both durably.                                             |
| Wrong Destination, Recipient, Audience, or `InResponseTo` | Bridge rejects.                                                          |
| Expired and not-yet-valid response                        | Bridge rejects outside its recorded skew.                                |
| Unsupported or signed request shape                       | FaceSign rejects before a verification session; no access is granted.    |

## Joint exit criteria

Bridge interoperability may be claimed only after the actual recorded Bridge version and build
have used every production-intended request binding, completed all 12 pass runs and the negative
matrix, accepted FaceSign's fixed `unspecified` AuthnContext, and applied the agreed policy and
fallback outcomes. Named technical owners then provide sign-off. Store the evidence in the private
partner worksheet.

## Support escalation

Email [partnerships@facesign.ai](mailto:partnerships@facesign.ai?subject=Silverfort%20Bridge%20pilot%20support)
with the sandbox entityID, approximate UTC time, request ID, and `facesign.sessionId` if one was
issued. Do not include SAML assertions, real Subject values, credentials, or signing keys in
email.