Skip to main content
FaceSign is a SAML 2.0 identity provider for one narrow job: establish a verified_human attestation and return it to a service provider. FaceSign establishes verified_human; it does not establish workforce identity. The receiving SP keeps account identity, policy, and the final authorization decision.

Run a live SAML sign-in

Sends a real AuthnRequest through FaceSign and validates the signed result at a FaceSign-operated test SP. Opens in a new tab, asks for camera access, and takes about 30 seconds.
The loopback request uses the reserved .invalid synthetic Subject loopback.user@example.invalid with NameID Format urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress. On success, its own ACS proves that exact echoed NameID and the two success-only Attributes in FaceSign’s durable default correlation profile, named http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name and http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, both with SAML Attribute NameFormat urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified. They repeat caller-supplied test input; they are not identity proof.

​
The browser carries the SAML flow

The browser transports the AuthnRequest to FaceSign and posts the result back to the receiving SP. It also hosts the camera-based verification step.

​
What verified_human means

verified_human means the deployed verification flow completed, liveness was detected, the person explicitly confirmed the intended action, and no configured deepfake veto fired. It does not prove directory identity or the absence of coercion.
FaceSign does not perform a one-to-one identity match. By default, success uses a transient, session-scoped NameID. An approved sandbox may echo an XML Subject or a separately enabled, non-SAML login_hint compatibility input for correlation, but that unsigned input is not identity proof and must not authorize access. The loopback exercises FaceSign’s durable default correlation profile at FaceSign’s own test SP; an external SP receives no conditional correlation Attributes until FaceSign registers its exact one-or-two-Attribute mapping.

​
Ownership boundary

Incoming request replay protection and the receiving SP’s response replay protection are separate controls. AuthnRequests must be unsigned. Registration of the exact service-provider entityID and HTTPS ACS is required before direct integration testing. Prefer to read first? The walkthrough covers the three outcomes, what can cause a denial, and what to check on the result page.

​
Continue

Configure

Register the SP, import metadata, and set the supported request profile.

SAML messages

Review request, success, and denial XML plus the validation checklist.

Test loopback

Run the FaceSign-owned test and inspect a real signed result.

Troubleshooting and limits

Plan timeouts and fallback, then diagnose current SSO errors.