Response contract - FaceSign SAML IdP

Success response

A successful response contains one Assertion. FaceSign signs the root Response and the nested Assertion separately. This sample is abridged and uses synthetic values:

<samlp:Response
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  ID="_response-001"
  Version="2.0"
  IssueInstant="2026-08-11T12:00:00Z"
  Destination="https://bridge-sandbox.example.invalid/saml/acs"
  InResponseTo="_request-001">
  <saml:Issuer>https://idp.facesign.dev/api/saml/metadata</saml:Issuer>
  <ds:Signature>...root Response signature...</ds:Signature>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
  </samlp:Status>
  <saml:Assertion ID="_assertion-001" Version="2.0" IssueInstant="2026-08-11T12:00:00Z">
    <saml:Issuer>https://idp.facesign.dev/api/saml/metadata</saml:Issuer>
    <ds:Signature>...nested Assertion signature...</ds:Signature>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
        facesign-session:session_example_001
      </saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData
          Recipient="https://bridge-sandbox.example.invalid/saml/acs"
          InResponseTo="_request-001"
          NotOnOrAfter="2026-08-11T12:05:00Z" />
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2026-08-11T12:00:00Z" NotOnOrAfter="2026-08-11T12:05:00Z">
      <saml:AudienceRestriction>
        <saml:Audience>https://bridge-sandbox.example.invalid/saml/metadata</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2026-08-11T12:00:00Z" SessionIndex="_session-001">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>
          urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
        </saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
      <saml:Attribute Name="facesign.verdict"><saml:AttributeValue>verified_human</saml:AttributeValue></saml:Attribute>
      <saml:Attribute Name="facesign.sessionId"><saml:AttributeValue>session_example_001</saml:AttributeValue></saml:Attribute>
      <saml:Attribute Name="facesign.coercionScore"><saml:AttributeValue>0.05</saml:AttributeValue></saml:Attribute>
      <saml:Attribute Name="facesign.deepfakeResistanceScore"><saml:AttributeValue>0.92</saml:AttributeValue></saml:Attribute>
      <saml:Attribute Name="facesign.repudiationArtifactPresent"><saml:AttributeValue>false</saml:AttributeValue></saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

Released attributes

Attribute	Current success value	How to use it
`facesign.verdict`	`verified_human`	The only verdict currently released in a success assertion. A non-pass has no assertion.
`facesign.sessionId`	String	Correlation identifier for support and audit.
`facesign.coercionScore`	Decimal string from 0 to 1	Bounded launch-profile output. It is not a calibrated probability or an independent authorization signal.
`facesign.deepfakeResistanceScore`	Decimal string from 0 to 1	Bounded launch-profile output with the same caveat.
`facesign.repudiationArtifactPresent`	Literal string `"false"`	Reserved. Do not branch on it.

NameID behavior

By default, success uses a transient facesign-session:<sessionId> NameID. An approved isolated sandbox may echo the Subject NameID supplied by Bridge. That echo is correlation data from the unsigned request, not FaceSign proof of the workforce identity.

Denial response

A completed non-pass or analysis failure may return a signed denial. It has no Assertion, NameID, or attributes. Only the root Response is signed.

<samlp:Response
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  ID="_response-deny-001"
  Version="2.0"
  IssueInstant="2026-08-11T12:00:00Z"
  Destination="https://bridge-sandbox.example.invalid/saml/acs"
  InResponseTo="_request-002">
  <saml:Issuer>https://idp.facesign.dev/api/saml/metadata</saml:Issuer>
  <ds:Signature>...root Response signature...</ds:Signature>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
      <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:AuthnFailed" />
    </samlp:StatusCode>
    <samlp:StatusMessage>Verification did not pass</samlp:StatusMessage>
  </samlp:Status>
</samlp:Response>

Signature profile

The deployed build emits RSA-SHA256 signatures, SHA-256 digests, and exclusive XML canonicalization. On success, it signs the root Response and nested Assertion separately. On denial, it signs only the root Response; there is no Assertion. Trust the current X.509 certificate from the live metadata. Do not pin a certificate copied from an example or sample response. Incoming AuthnRequests remain unsigned; if Bridge requires signing, record that incompatibility before UAT.

Validation checklist

Read Status first

Continue only when the top-level status is Success. Reject any non-success as a login and reject a non-success response that contains an Assertion.

Validate the required signatures

On success, validate the root Response signature and the nested Assertion signature against the certificate in FaceSign metadata. On denial, validate the root Response signature.

Correlate the request

Match InResponseTo on the Response and bearer confirmation data to an outstanding request.

Check where and when it applies

Validate Destination, Recipient, Audience, NotBefore, and both NotOnOrAfter values. Apply Silverfort’s documented clock-skew policy.

Reject duplicates durably

Store accepted Response and Assertion IDs in a durable duplicate store and reject reuse.

Validate RelayState separately

Use RelayState only to resume application state. It is not identity or authentication evidence.

Replay responsibilities

InResponseTo provides correlation, but it does not by itself prevent replay. The deployed IdP does not reject a repeated AuthnRequest ID on Silverfort’s behalf. Silverfort must durably reject duplicate Response and Assertion IDs and consume each outstanding request once.

Fallback semantics

A signed Responder/AuthnFailed is an authenticated non-success. A pre-flow HTTP error and an unreachable or late flow may produce no usable SAML response. Silverfort owns the fallback for each case. None may be converted to Success or treated as a valid step-up.

​Success response

​Released attributes

​NameID behavior

​Denial response

​Signature profile

​Validation checklist

​Replay responsibilities

​Fallback semantics