| AudienceStep | Requires the "aud" claim to name this receiver. RFC 8417 Section 2.2 only RECOMMENDS the claim, but a receiver that skips the check accepts events addressed to somebody else - the separate-audience strategy of Section 4.2 works only when audiences are actually checked - so the default profile checks, and a receiver in a closed deployment removes the step as a named decision rather than by leaving an option empty. |
| EventsPresenceStep | Requires the "events" claim to be a JSON object holding at least one statement: "The 'events' claim value MUST be a JSON object that contains at least one member" (RFC 8417 Section 2). A JWT without it is not a SET at all - which doubles as the confusion detector RFC 8417 Section 4.3 recommends, "reject JWTs containing an 'events' claim unless the JWT is intended to be a SET" read from the receiving side. |
| ExpAbsenceStep | Requires the claims to carry no "exp". Its absence is the wall between a SET and the ID and access tokens an attacker would substitute one for (RFC 8417 Sections 4.1 and 4.2), so a token carrying it is treated as another kind of JWT in a SET's clothing. |
| IssuedAtWindowStep | Requires the "iat" claim to be present - it is REQUIRED (RFC 8417 Section 2.2) - and within the receiver's freshness window on either side of its clock. |
| IssuerAllowlistStep | Requires the "iss" claim to name an issuer this receiver accepts events from. The claim is REQUIRED (RFC 8417 Section 2.2), and running the check before the signature step keeps an unknown issuer's token from costing a key resolution: the signature step's resolver would refuse it anyway, but refusing here names the reason precisely. |
| JwtIdPresenceStep | Requires the "jti" claim to be a non-empty string: "This claim is REQUIRED" (RFC 8417 Section 2.2). The identifier is what every receiver-side replay accounting keys on, so a SET without a usable one is rejected here rather than reaching a consumer that cannot track it. |
| ParseStep | Takes the compact serialization apart and parses its header and claims, WITHOUT trusting either: parsing establishes shape, and everything read here stays in the context's unverified half until the signature step speaks. |
| PayloadDeserializationStep | Deserializes every event payload through the registry - into its registered model, or the raw passthrough for a type the registry does not know - so the consumer receives typed events instead of repeating this work per statement. |
| SignatureStep | Verifies the token's signature and, on success, promotes the claims from parsed shape to the issuer's words: this is the step that sets the context's validated token, which every step reading trusted claims requires. |
| TimeOfEventStep | Requires the "toe" claim, where the transmitter chose to send one, to be a date the receiver can read. Its absence is allowed - it is OPTIONAL (RFC 8417 Section 2.2) - and its value is not judged, since a profile may make it approximate. |
| TypHeaderStep | Requires the "typ" header to name a SET. A JWT accepted as a SET, or the reverse, is the token confusion class RFC 8417 Section 4 is about, and the explicit type is its most direct wall (Section 4.3). |