Shayne Miel (he/him)

I have now seen three possibilities for defining the `aud` value in implementations. We should decide which of these is the "correct" way to do things so that Transmitters and...

Section 2.3.1 says > The Transmitter Configuration Metadata MUST have a spec_version field, and its value MUST be 1_0-ID2 or greater Should we update that to be `1_0` (the final...

[Complex Subjects cannot have nested Complex Subjects](https://openid.github.io/sharedsignals/openid-sharedsignals-framework-1_0.html#name-complex-subject-members), so your first example is not a concern. But I agree that we should say something about subjects that have lists in their...

Shoot. I started adding examples for this and realized that we should probably treat array values as an ANY match (i.e. if the event's value matches any of the values...

Can we also say that the version should be the version that we are in progress towards? So, while we were working on draft 4, the version would have been...

The `add_subjects` endpoint allows the Receiver to express the subjects that it is interested in receiving. It is up to the Transmitter whether or not to actually send an event...

The members of a Complex Subject are all Simple Subjects. I think what we need is a new Simple Subject instead of a new Complex Subject field. So a new...

We have added two Simple Subject formats in the Shared Signals spec already: [jwt_id](https://openid.github.io/sharedsignals/openid-sharedsignals-framework-1_0.html#name-jwt-id-subject-identifier-f) and [saml_assertion_id](https://openid.github.io/sharedsignals/openid-sharedsignals-framework-1_0.html#name-saml-assertion-id-subject-i). So this would simply be a third one. The `opaque` format doesn't work quite...

It's not essential. We can wait until after v3, since it is just a clarity edit.

Pull this out of #195 into its own PR since it is a normative change