Skip to main content

​
AuthnRequest

What FaceSign accepts at https://idp.facesign.dev/api/saml/sso.
​
string
required
Must exactly match a registered entityID. Unregistered issuers are rejected before anything else happens.
​
string
Validated against the SSO endpoint when present.
​
HTTP-Redirect | HTTP-POST
required
Both are supported.
​
not accepted
Signed AuthnRequests are not supported in this release and are rejected. The metadata declares WantAuthnRequestsSigned="false".
​
string
default:"omitted"
Optional, and gated. See NameID echo below — this is the field with the sharpest security consequence on the whole contract.
​
string
Returned untouched so your SP knows where to resume.

​
Released attributes

Present on the assertion, on a pass only.

​
NameID echo

By default the assertion NameID is transient and session-scoped:
If your AuthnRequest carries a <Subject> NameID, the assertion echoes that identity and format straight back — but only for service providers explicitly registered for it. Any other SP sending a <Subject> gets:
The echo binds the assertion to the identity you supplied. It is not an independent confirmation of it. FaceSign proves a live human is present; it has no way to know that the person is that directory identity. Treat an echoed NameID as a correlation hint, never as proof of identity, and keep the directory binding on your own first factor.
This is why echo is off by default. An unsigned AuthnRequest is unauthenticated, so an unguarded echo would let anyone name a victim and receive a signed assertion carrying that name.

​
Denial semantics

Fail-closed. Success with verified_human is issued only for a complete session with liveness detected and intent confirmed. Any strong deepfake signal vetoes the pass. Every other outcome returns top-level urn:oasis:names:tc:SAML:2.0:status:Responder with nested AuthnFailed. A refusal is status-only — no assertion at all, per SAML Core §3.2.2 — and the Response is signed.
A signed denial and a missing response are different things, and your fallback policy should treat them differently. Today every non-pass looks the same on the wire; a more granular status taxonomy is not available in this release.

Validate responses

The checklist your SP must run before trusting anything above.

Test the live sandbox

Capture a real response and diff against it.