SSF is the pipe and not the vocabulary. It says how two parties agree a stream, who the events are about and how they get delivered — and exactly two events of its own, both about the pipe. CAEP and RISC are two different vocabularies spoken over it, and they answer two different questions: CAEP says this session is no longer trustworthy, RISC says this account is no longer trustworthy. That distinction is the whole reason there are two specifications.

Choosing one narrows every event list on this page — the stream’s events_requested checkboxes and the Transmit pane’s menu — so that a stream cannot be agreed for events this page will not then send. Nothing is hidden: the pipe is the same machinery underneath all three, and every pane below is used by every profile. CAEP additionally brings up the CAEP session pane, which is the thing its eight events are about.

SSF 1.0 section 8 requires a transmitter’s stream management, status, subject, verification and poll endpoints to be protected, and it has the transmitter publish what it accepts in authorization_schemes — so a receiver discovers the scheme rather than guessing. Almost every transmitter names OAuth 2.0, and this workflow gets its token the way the SCIM page does: it sends you to the OAuth2 / OIDC workflow, you run any grant there, and the tokens come back here.

The whole set comes back, not just the bearer token, and that is why this pane can name you: an access token this service issues is opaque to a client, and the identity is in the ID Token. Every set is kept below for the length of this tab — the same Token History the OAuth2 / OIDC results page keeps, for the reason a stream outlives the token that created it.

Everything the panes below read, with the source of each. The transmitter’s own endpoints are not here: SSF fixes no paths, so every one of them is discovered from the metadata document in the next pane and this page composes none.

SSF 1.0 section 6. Every endpoint this workflow calls comes out of this document and none is composed here — a transmitter that publishes its stream management API at /v1/streams/manage is driven with nothing typed. It is looked for at /.well-known/ssf-configuration in both shapes: RFC 8414 inserts the well-known segment before the issuer’s path and OpenID Connect Discovery appends it, and insertion is tried first.

The control plane. One path and five methods, which is the specification’s own shape: the configuration endpoint is the resource. Read events_delivered rather than events_requested when the answer comes back — the first is what will be sent and the second is what you asked for, and SSF has no refusal for an event type a transmitter will not agree to. Its absence from that list is the only notice you get, so this page says so out loud.

Status. A paused stream keeps queueing and delivers nothing, so what happened while it was paused is still there when it is enabled again; a disabled one drops it. That is the difference between “I was not listening” and “it did not happen”, and it is why a receiver taking a maintenance window pauses rather than disables.

Verification is the only end-to-end test a stream has. Everything above exercises the management API and proves nothing about whether an event can actually be delivered; this asks the transmitter to send one down the ordinary path. The state comes back inside the event unchanged, and it is the only thing tying the two together.

RFC 9493 gives eight formats and SSF adds the complex subject, whose members are each themselves an identifier. That is what makes “this session was revoked” expressible at all: the person is not revoked, one session of theirs is.

Each format’s member set is closed. A subject carrying an extra member is one a conforming receiver must reject — it cannot tell whether the member narrows the subject — and it looks perfectly fine in a log. This page refuses it and names the member, which is what the Check button is for.

What an empty subject list means is default_subjects in the metadata: with ALL the stream is about everybody and adding a subject narrows nothing; with NONE it is about nobody until one is added. Guessing wrong gets you every event in the estate or none, and both look like a broken transmitter.

Poll delivery works in this browser and push delivery cannot, and that is a property of the two specifications rather than of this tool. RFC 8936 has the receiver come to the transmitter, which a page can do; RFC 8935 has the transmitter POST to the receiver, and a page is not an HTTP server. So the api layer hosts an endpoint on this page’s behalf — and on a deployment with no api there is nothing to host, which is exactly what the hosted static sites are.

Anything that arrives is decoded and every check is reported by name. A single “valid” over a token whose audience is somebody else is the most dangerous thing this page could say.

The other half of the protocol, and the one a receiver under test needs: build any event SSF defines, sign it, and push it to somebody’s RFC 8935 endpoint. The media type is the thing that is silently wrong everywhere — RFC 8417 section 2.3 gives a SET application/secevent+jwt, and a receiver that dispatches on the type drops one sent as application/jwt with no error anybody sees. This page can send either, on purpose.

Every Security Event Token this page sent or received, whole, with what it decoded to and what every check said. The tokens are kept because a SET is evidence rather than a credential — holding one grants nothing and presenting one achieves nothing — and evidence is what a debugger most needs to survive a navigation. What is stripped is the Authorization header of the exchange that carried it, which is a credential.

What went out and what came back. On the browser call path this is what the page can see, which is less than the whole: a browser withholds the headers it adds and CORS withholds most of those that come back. The api path is made by the backend and can therefore be reported in full, which is one of the three reasons that path exists.

One row per call, newest first. Sent is not a success: it means the call left this page and nothing came back to resolve it.