Shayne Miel (he/him)

This is the section of the spec you are referring to, correct? > delivery > A JSON object containing a set of name/value pairs specifying configuration parameters for the SET...

@TakahikoKawasaki That is a great way to solve this problem! We could add an optional, receiver-supplied field to the StreamConfiguration (to be set by the receiver on stream creation or...

I think you meant to say "server to client communication". And that _is_ a match for the Transmitter to Receiver flow of SSF. While Server Sent Events are commonly seen...

Some discussion about this issue happened in the [SSF slack](https://oidf.slack.com/archives/C02Q0762E83/p1709733523083919). Trying to summarize here: SSF was explicitly designed to be server-to-server. It is possible to open up other use cases,...

The following examples either need `subject` removed from the event, `sub_id` added to the base SET, or both: - subject-ids-ex-simple - subject-ids-ex-complex - subject-properties-ex - subject-custom-type-ex - risc-event-subject-example - caep-event-properties-example...

From the discussion today, here is the reformatted version of Steve's proposed SET: ``` { "iss": "https://idp.example.com/", "jti": "756E69717565206964656E746966696572", "iat": 1520364019, "aud": "636C69656E745F6964", "sub_id": { "format": "aliases", "identifiers": [ {...

I think that once we realized that the Aliases format does not carry the same semantic information as the Complex format, the issue was dropped. That is, you _could_ put...

Closed by https://github.com/openid/sharedsignals/pull/180

Is the goal of this metadata to enable headless use of the SSE framework? As it currently stands, there is some out-of-band agreement between the transmitter and receiver that communicates:...

@jischr I think that's correct. We should update the CAEP and RISC specs, not the SSF spec. If we wanted to limit this change to the SSF spec, we could...