> ## 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.

# FaceSign SAML IdP

> Add FaceSign step-up verification to any SAML service provider. Standard SAML 2.0 — configuration, not custom code.

Your service provider redirects the person to FaceSign. FaceSign runs a short avatar-led
verification and returns a signed SAML assertion carrying the verdict. Standard SAML 2.0 —
configuration, not custom code.

## How it fits

<Steps>
  <Step title="Your SP decides a step-up is needed">
    Your policy engine, your trigger. You already know who the person is.
  </Step>

  <Step title="You send a standard AuthnRequest">
    HTTP-Redirect or HTTP-POST. Import our metadata and you are configured.
  </Step>

  <Step title="FaceSign verifies a live person">
    A short avatar-led session in the browser. This is the only part the person sees.
  </Step>

  <Step title="You receive signed SAML and decide">
    A signed assertion on a pass, a signed status-only refusal otherwise. The access decision
    stays yours.
  </Step>
</Steps>

## What the verdict attests

<Warning>
  A `verified_human` verdict attests that **a real, willing person is present**. It does not
  attest **who** they are.
</Warning>

This is deliberate, and it is the most important thing to understand before you build against
it. FaceSign performs liveness and intent checks; it holds no directory and performs no
one-to-one match against a user record. Your service provider has already authenticated the
identity — FaceSign answers the separate question of whether a live human is really there and
really means it.

Keep the directory binding on your own first factor, and treat the assertion as evidence about
the person's presence and intent, not their name. [Validate responses](/validate-responses)
covers what this means in practice, including when your AuthnRequest carries a `<Subject>`.

## Who does what

|                                                                     | 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                                      |          | ●                     |

## Current limitations

**Signed AuthnRequests are not supported.** The metadata declares
`WantAuthnRequestsSigned="false"`. Send unsigned requests, and plan for request signing to be a
later change on your side. If your SP signs by default and cannot be configured otherwise, raise
it before you begin — it changes the integration scope.

## Where to go next

<CardGroup cols={2}>
  <Card title="Quickstart" icon="rocket" href="/quickstart">
    Metadata in, service provider registered, round-trip run.
  </Card>

  <Card title="SAML request contract" icon="file-code" href="/saml-request-contract">
    Endpoints, released attributes, and what a denial looks like on the wire.
  </Card>

  <Card title="Test the live sandbox" icon="flask-conical" href="/test-the-live-sandbox">
    A real SP-initiated round-trip against FaceSign's own loopback SP. Needs a camera.
  </Card>

  <Card title="Security and operations" icon="shield" href="/security-and-operations">
    Fail-closed semantics, the limits to design for, and our assurance posture.
  </Card>
</CardGroup>