Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Understanding the x5t#S256 Header Claim

Anchor
x5t_S256
x5t_S256
a[name="x5t_S256"]

In the process of creating the JWS, it's essential to include the x5t#S256 header claim. This claim plays a crucial role in preserving the accuracy and security of the metadata. x5t#S256 stands for "X.509 Certificate SHA-256 Thumbprint," and it serves as a thumbprint for the X.509 certificate used for signing within the SAML metadata.

...

  1. Check the exp Claim: First, verify the exp (Expiration Time) claim in the JWS payload. Ensure that the current timestamp is before the specified expiration time. If the data is past its expiration time, it should not be considered valid.

  2. Validate the Digital Signature: To verify the authenticity of the metadata, use the alg (Algorithm) and x5t#S256 header claims in the JWS header.

    • alg Claim: Ensure that the algorithm specified in the alg claim matches the one used for signing (e.g., "ES256" for ECDSA with P-256 and SHA-256).

    • x5t#S256 Claim: This claim specifies the SHA-256 thumbprint of the signing key used for the JWS. It should correspond to the thumbprint of the certificate used for signing in the SAML metadata.

      • Retrieve the certificate from the SAML metadata, and calculate its SHA-256 thumbprint (see How to Implement Group Representative Information Exchange) .

      • Compare the calculated thumbprint with the x5t#S256 claim in the JWS header. If they do not match, it indicates a potential security issue, and the metadata should not be trusted.

  3. Check the Issuer (iss) Claim: Verify that the iss (Issuer) claim in the JWS payload matches the expected issuer URI. This ensures that the metadata is coming from a trusted source.

  4. Validate the iat Claim: Ensure that the iat (Issued At) claim is a valid NumericDate representing the time when the data was issued.

...