How it fits
1
Your SP decides a step-up is needed
Your policy engine, your trigger. You already know who the person is.
2
You send a standard AuthnRequest
HTTP-Redirect or HTTP-POST. Import our metadata and you are configured.
3
FaceSign verifies a live person
A short avatar-led session in the browser. This is the only part the person sees.
4
You receive signed SAML and decide
A signed assertion on a pass, a signed status-only refusal otherwise. The access decision
stays yours.
What the verdict attests
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 covers what this means in practice, including when your AuthnRequest carries a<Subject>.
Who does what
Current limitations
Signed AuthnRequests are not supported. The metadata declaresWantAuthnRequestsSigned="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
Quickstart
Metadata in, service provider registered, round-trip run.
SAML request contract
Endpoints, released attributes, and what a denial looks like on the wire.
Test the live sandbox
A real SP-initiated round-trip against FaceSign’s own loopback SP. Needs a camera.
Security and operations
Fail-closed semantics, the limits to design for, and our assurance posture.