SecurityEventTokenErrorCode Enum
Names the ways a SET can fail validation.
public enum SecurityEventTokenErrorCodeFields
MalformedToken 0
The compact serialization does not parse: wrong segment count, undecodable segment, or JSON that is not what the segment must hold.
TokenConfusion 1
The token is a JWT but not a SET, or a SET pretending otherwise: the "typ" header names a different type, or the claims carry "exp" - the shape RFC 8417 Section 4 warns is another kind of token in a SET's clothing, or the reverse.
MissingEvents 2
The "events" claim is absent, not a JSON object, or empty (RFC 8417 Section 2.2).
UnknownIssuer 3
The "iss" claim is absent or names an issuer this receiver does not accept events from.
SignatureInvalid 4
The token's signature is not one this receiver will act on: it did not verify under the issuer's keys, or the algorithm it was made with is one the receiver refuses.
Remarks
A property rather than a list of causes, because the list is the JWT core's and grows without
this file: an absent alg, one outside the RFC 7518 taxonomy and an unsigned token all
arrive here too. What they share is what these codes actually distinguish - none of them is
healed by refetching the issuer's keys, which is the whole of what KeyNotFound
means. On the wire that is invalid_key, which RFC 8935 Section 2.4 defines as a key
"invalid or otherwise unacceptable to the SET Recipient" - wide enough for every one of them.
WHICH of them happened is in Description, which the core writes at the branch that knows: a refusal by policy names the algorithm that was offered and the set that would have been taken, and an unsigned token says it is unsigned.
KeyNotFound 5
No key of the issuer matches the token - the recoverable sibling of SignatureInvalid: after a key rollover, refetching the issuer's keys may turn this into success, which a wrong signature never becomes.
AudienceMismatch 6
The "aud" claim does not name this receiver.
IatOutOfRange 7
The "iat" claim is absent or outside the receiver's freshness window.
DecryptionFailed 8
The token is encrypted and could not be decrypted.
Custom 9
A profile-specific step rejected the token; the description says why. This is the extension point for consumer profiles, whose failure modes this package cannot enumerate.
Remarks
The codes are coarse on purpose: they distinguish what a RECEIVER does differently - alert on confusion, refetch keys on a key miss, drop and log on staleness - not every sentence of the specification. The human-readable half lives in Description. A custom step reports its own failure through Custom plus a description, which is what keeps this enum from growing a member per consumer.