Security Assertion Markup Language (SAML) 2.0 assertions inherently support a limited lifetime and are self-verifiable. The lifetime is enforced by the element, which specifies NotBefore and NotOnOrAfter timestamps, defining the assertion's validity period. The self-verifiable nature comes from the use of XML Signature. The identity provider (issuer) digitally signs the assertion, and the service provider (recipient) can independently verify its authenticity and integrity using the issuer's public key without needing to contact the issuer directly for verification.

B. Managed key rotation: This is a critical operational security practice for systems using SAML, but it is not a feature defined or managed by the SAML 2.0 protocol itself.

D. Compact data representation: SAML assertions use XML, which is known for being verbose. This contrasts with more compact formats like JSON, which is used by JWTs.

E. Refresh without a new challenge: This is a core feature of the OAuth 2.0 framework, which uses refresh tokens to obtain new access tokens. SAML does not have a native concept of refresh tokens.

1. Google Cloud Apigee Documentation

"Validate SAML Assertion policy": This document describes the policy's function

stating

"The policy validates that the assertion has not expired" (supporting limited lifetime) and "The policy validates the digital signature in the assertion" (supporting self-verifiable content).

Source: Google Cloud Apigee Documentation

policies/validate-saml-assertion-policy.html.

2. OASIS Security Services Technical Committee

"Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0"

March 2005:

Section 2.5.1

"Element ": This section defines the NotBefore and NotOnOrAfter attributes that "specify the time interval during which the assertion is valid." This directly supports the "Limited token lifetime" requirement.

Section 5

"SAML Profiles of XML Signature": This section details how SAML assertions MUST be digitally signed for many profiles

making them verifiable by the recipient. This supports the "Self-verifiable content" requirement.

Source: OASIS Standard

saml-core-2.0-os.pdf.

3. Google Cloud Apigee Documentation

"Securing APIs with SAML": This guide explains the flow where Apigee validates an incoming SAML assertion. It notes

"Apigee acts as a service provider (SP)... It extracts a digitally signed SAML assertion... and validates the assertion." This confirms the standard use of verifiable signatures.

Source: Google Cloud Apigee Documentation

api-platform/security/securing-apis-saml.html.