Receivers should validate aud value in StreamConfiguration response

[FragLegs]

The first recommendation from the final security audit:

While Receivers are mandated to validate
the audience value in SETs (due to [RFC7519, Section 4.1.3]), they are currently not required to
validate the audience value in stream configurations returned by a Transmitter, e.g., in a stream
creation response. Our Receiver model respects this and hence mostly ignores streams’ audience
values. For SET validation, our Receiver model instead compares the SET’s audience value against
an expected value based on the access token used by the Receiver when requesting creation of
the stream (since this is where the Transmitter is required to derive an audience value from the
Receiver’s authorization, see [15, Section 7]).
However, it is likely that implementers use the stream’s audience value to validate SETs against,
hence, we recommend to mandate Receivers-side validation of stream audience values.

[FragLegs]

The following was not covered in the security audit, but came up during the interop:

We should provide some guidance on how aud values are set. It seems like implementers are settling on having the Transmitter generate a new aud value per stream. We may not be able to require that behavior without breaking backwards compatibility, but we can at least recommend it.

[thomasdarimont]

While Receivers are mandated to validate
the audience value in SETs (due to [RFC7519, Section 4.1.3]), they are currently not required to
validate the audience value in stream configurations returned by a Transmitter, e.g., in a stream
creation response.

FYI I just added a check for the first part to the conformance tests. In the openid-ssf-transmitter-events we now verify that the verification SET aud matches the aud from the stream, and produce a warning if that is not the case.

Is the reference [RFC7519, Section 4.1.3] okay, or should I use another reference here?

[SECtim]

@thomasdarimont I am not familiar with the conformance tests, but this looks to me like a test case for the Transmitter, i.e., validating that a Transmitter uses the same aud in (probably?) stream creation responses and (in this case: Verification) SETs.
If that understanding is correct, then this test does not touch on what the security analysis originally pointed out: The SSF spec does not require the receiver of a stream configuration to validate that configuration's aud.