> ## 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.
# Security and operations
> Fail-closed semantics, the limits your service provider must design for, and our assurance posture.
## Fail-closed by design
`Success` with `verified_human` is issued only for a complete session with liveness detected and
intent confirmed. Any strong deepfake signal vetoes the pass outright.
Missing evidence produces a denial, never a pass. If the analysis backing a verdict cannot be
completed, FaceSign refuses rather than issuing an assertion that skipped a security layer.
## Scope of the attestation
A `verified_human` verdict attests that a real, willing person is present. It does not attest
that the person is the directory identity your service provider authenticated.
This boundary is deliberate. FaceSign holds no directory and performs no one-to-one match
against a user record — it answers presence and intent, and nothing else. That is what makes it
safe to place in front of an account your SP has already authenticated: FaceSign cannot become a
second, weaker source of identity truth.
The practical consequence is on the `` NameID. When your AuthnRequest carries one,
FaceSign echoes it back in the assertion — for explicitly registered service providers only.
That echo binds the assertion to the identity **you supplied**; it is not independent
confirmation of it. Any SP that treats an echoed NameID as proof of identity has built an
impersonation path. Keep the directory binding on your own first factor.
## Responsibilities
| | FaceSign | Your service provider |
| ------------------------------------------------------------------- | -------- | --------------------- |
| Prove a live, willing person is present | ● | |
| Sign the Response and the Assertion | ● | |
| Know the person's directory identity | | ● |
| Validate both signatures, `InResponseTo`, audience, time conditions | | ● |
| Reject duplicate assertions (replay) | | ● |
| Make the final access decision | | ● |
Replay rejection is worth calling out: it is a standard SAML service-provider responsibility and
FaceSign does not enforce it on your behalf. Record assertion IDs and reject duplicates.
## Limits to design for
| Limit | Value | Why it matters to you |
| ------------------------- | --------------------------------- | ---------------------------------------------------------------------------------------- |
| Authentication deadline | 5 min | Your SP's timeout must exceed this, or you will abandon sessions that would have passed. |
| Analysis grace | 30 s | Time allowed after the conversation ends before a verdict is required. |
| SSO session-creation rate | 20/min per IP+SP · 120/min per SP | Load tests hit the per-SP limit first. |
If your platform enforces its own hard timeout on the redirect, set it comfortably above five
minutes, or ask us to lower the authentication deadline to sit inside yours. Mismatched
deadlines are the most common cause of an integration appearing to fail for reasons unrelated to
verification.
## Current limitations
Stated plainly so you can design around them rather than discover them.
**Signed AuthnRequests are not supported.** The metadata declares
`WantAuthnRequestsSigned="false"`. If your SP signs by default and cannot be configured
otherwise, raise it before integration begins.
**Denial reasons are not differentiated on the wire.** A refused verification and a verdict we
could not produce currently return the same signed status-only shape. If your fallback policy
needs to treat "the check failed" differently from "the check could not run", tell us — it
changes what we expose.
**`facesign.repudiationArtifactPresent` is reserved.** The field is present and currently always
`"false"`. Do not branch on it.
## Assurance posture
What has been validated, and how, so a security reviewer can judge the evidence rather than take
a claim on trust.
**Validated against FaceSign's loopback service provider.** A real SP-initiated round-trip
completes against the live IdP, with signature and audience validated at the loopback ACS. Both
the root Response and the nested Assertion are signed on success. A refusal returns signed,
status-only SAML with no assertion. Subject echo is refused for service providers not registered
for it.
**Validated independently.** The success and denial contracts have been reproduced offline
against a third-party `php-saml` service provider — signatures verified against the published
certificate, with correct Audience, Recipient and Conditions.
**Reproduce it yourself.** Run the [sandbox](/test-the-live-sandbox), capture the response at
your own ACS, and verify both signatures against the certificate in the
[live metadata](https://idp.facesign.dev/api/saml/metadata). If your service provider validates
only one of the two signatures, it will accept material this implementation considers invalid.
**Your own integration is validated when you validate it.** Interoperability with any specific
service provider is established by registering your sandbox SP and running a joint test — see
[Test the live sandbox](/test-the-live-sandbox). We do not claim it before you have seen it.
## Service health
[Service health](https://idp.facesign.dev/api/health) checks that the IdP can generate metadata
and that its signing key matches the certificate it advertises.
It does not run an end-to-end verification, so it cannot tell you a round-trip will succeed. A
failing signing-key check means assertions issued since the last deploy may be unverifiable at
your ACS — that is an incident, not a status colour.