ForbidSubStep Class

Requires the claims to carry no "sub": SSF identifies the subject through the structured top-level "sub_id" alone, and "The JWT 'sub' claim MUST NOT be present in any SET containing an SSF event" (SSF 1.0 Section 4.1.2) - one of the restrictions Section 4.1.3 adds to keep SSF SETs from being confused with other kinds of JWTs.

public sealed class ForbidSubStep : Abblix.SecurityEvents.Validation.ISecurityCriticalValidator, Abblix.SecurityEvents.Validation.ISecurityEventTokenValidator

Inheritance System.Object → ForbidSubStep

Implements Abblix.SecurityEvents.Validation.ISecurityCriticalValidator, Abblix.SecurityEvents.Validation.ISecurityEventTokenValidator

Remarks

The check is on the member's PRESENCE, before any signature work, for the same reasons the core profile checks "exp" that way: a malformed "sub" marks a non-SSF token exactly as a well-formed one does, and a rejection this cheap should not cost a signature check.

Methods

ForbidSubStep.ValidateAsync(SecurityEventTokenValidationContext, CancellationToken) Method

Checks the token in flight.

public System.Threading.Tasks.ValueTask<Abblix.SecurityEvents.Validation.SecurityEventTokenValidationError?> ValidateAsync(Abblix.SecurityEvents.Validation.SecurityEventTokenValidationContext context, System.Threading.CancellationToken cancellationToken);