Skip to main content
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.

Open the loopback sandbox

Opens the launcher in a new tab. Nothing on this page is a control.

​
What is real, and what is not

Real

An AuthnRequest from a registered SP · the live IdP · a live FaceSign verification session · signed SAML material · signature and audience validation at the ACS.

Simulated or absent

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

​
How the loopback works

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

The loopback SP builds an AuthnRequest

Deflated and base64-encoded, HTTP-Redirect binding. The issuer is the registered FaceSign loopback entityID.
2

The browser is redirected to the IdP SSO endpoint

/api/saml/sso validates the issuer against the SP registry before anything else happens.
3

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

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

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.

​
Test both paths

Running only the happy path tells you half of what you need.
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.
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.

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

Validate responses

The checklist to run against what you captured.

Troubleshooting

When the round-trip does not complete.