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

# Test the live sandbox

> Exercise a real SP-initiated SAML round-trip against FaceSign's own loopback service provider.

You need a phone or laptop with a camera. The round-trip is real: a real AuthnRequest, the live
IdP, a live FaceSign verification session, real signed SAML material, and real signature and
audience validation at the loopback ACS.

<Card title="Open the loopback sandbox" icon="external-link" href="https://idp.facesign.dev/test-sp">
  Opens the launcher in a new tab. Nothing on this page is a control.
</Card>

## What is real, and what is not

<Columns cols={2}>
  <Card title="Real" icon="circle-check">
    An AuthnRequest from a registered SP · the live IdP · a live FaceSign verification session ·
    signed SAML material · signature and audience validation at the ACS.
  </Card>

  <Card title="Simulated or absent" icon="circle-slash">
    The service provider is FaceSign's own. There is no partner SP, no directory, and no
    account. Durable replay enforcement stays the receiving SP's job and is not exercised here.
  </Card>
</Columns>

<Warning>
  This does not emulate any partner service provider and it does not establish partner
  interoperability — that requires your own sandbox SP registered and jointly
  tested. It also proves nothing about account ownership: a pass attests a live human, not that
  the live person is a particular directory identity.
</Warning>

## How the loopback works

A description of the protocol, not a live trace. Nothing here reflects the state of a running
session.

<Steps>
  <Step title="The loopback SP builds an AuthnRequest">
    Deflated and base64-encoded, HTTP-Redirect binding. The issuer is the registered FaceSign
    loopback entityID.
  </Step>

  <Step title="The browser is redirected to the IdP SSO endpoint">
    `/api/saml/sso` validates the issuer against the SP registry before anything else happens.
  </Step>

  <Step title="FaceSign runs the verification">
    A short avatar-led session in the browser. This is the only step a real person sees, and in
    a production integration it is the whole experience.
  </Step>

  <Step title="The IdP issues SAML material">
    On a pass, the root Response and the nested Assertion are both signed. A denial is a signed,
    status-only `Responder` with nested `AuthnFailed` — no assertion at all.
  </Step>

  <Step title="The loopback SP validates at its ACS">
    Status, both signatures, `InResponseTo`, audience, and the released attributes. Your service
    provider must repeat every one of these checks with your own registered SP.
  </Step>
</Steps>

## Test both paths

Running only the happy path tells you half of what you need.

<AccordionGroup>
  <Accordion title="The pass path" icon="circle-check">
    Use a phone if you can — desktop webcams and gaze are less forgiving. Good lighting, face
    toward the lens. Answer the intent question clearly and affirmatively.

    Expect: `Success`, a signed Assertion, and the `facesign.*` attributes at the ACS.
  </Accordion>

  <Accordion title="The denial path" icon="circle-slash">
    Decline the intent question. This exercises a protocol-level refusal deliberately.

    Expect: top-level `Responder` with nested `AuthnFailed`, **zero assertions**, and a valid
    signature on the response. Your SP must reject this as a login while still accepting it as a
    genuine, authentic message. That distinction is the whole point of the test.
  </Accordion>
</AccordionGroup>

## Capture a reference response

The most useful thing you can take from this page is a real response to diff against. Capture it
at your own ACS once your SP is registered, and verify both signatures against the certificate
in the live metadata before you rely on field order or formatting.

## Related

<CardGroup cols={2}>
  <Card title="Validate responses" icon="shield-check" href="/validate-responses">
    The checklist to run against what you captured.
  </Card>

  <Card title="Troubleshooting" icon="wrench" href="/troubleshooting">
    When the round-trip does not complete.
  </Card>
</CardGroup>