# WG Meeting: 2022-06-20
## Agenda
- Which Issues must be addressed before requesting another implementer's draft
- Issue [#53](https://github.com/openid/sharedsignals/issues/53) - ComplexSubject should have a format field
- Issue [#52](https://github.com/openid/sharedsignals/issues/52) - Should subject identifier be pulled out of the event definitions?
- Issue [#60](https://github.com/openid/sharedsignals/issues/60) - Are subjects required in SSF events?

## Attendees
- Atul Tulshibagwale (SGNL)
- Topher ()
- Shayne Miel (Cisco)
- Mike Kiser (SailPoint)
- Tim Cappalli (Microsoft)
- Apoorva Deshpande (Okta)
- Eric Karlinsky (Okta)

## Notes
### Which Issues
- [Atul] Let's try to submit a new implementer's draft for review in the next 10 days. (Before June 30th)

### Issue [#53](https://github.com/openid/sharedsignals/issues/53) - ComplexSubject should have a format field
- Steve Venema's suggestion on email: Add value for the field "format" as "complex"
- [Tim] Would this lead to an issue in nesting, where a nested value could also be complex
- [Shayne] Suggesting something like this:

~~~ json
subject: {
"format" : "complex",
"user" : {

},
"tenant": {

},
"device": {

}
}
~~~
- [Shayne] So we just add a field named "format":"complex" and keep the rest of the spec the same
- [Atul] The Array option we discussed the last time allows for duplicate entries
- [Shayne] Prefer either this new one we discussed today or the first one in last week's [notes](https://hackmd.io/@oidf-wg-sse/wg-meeting-20230613) (a field named format, and a field named value)
- [Shayne] Any component could benefit from using the "format" field to make a decision on subject processing
- [Tim] We could get the same effect by adding a field named "type", which could be "simple" or "complex", and then the subject value
- [Tim] We could go with Steve's proposal but we may now have to add processing logic in the spec (not just because of Steve's proposal, but because of the complexity in general)

### Issue [#52](https://github.com/openid/sharedsignals/issues/52) - Should subject identifier be pulled out of the event definitions?
- [Shayne] This was Phil's request from a couple of calls ago
- Why did RISC originally move the subject identifiers to a different claim than the top-level "sub" claim in JWTs?
- Mike Kiser to ask Phil for clarification
- [Tim] We can add a stream ID in the event for clarity / routing purposes. It could help in auditing
- [Apoorva] A Transmitter implementation may become complex if we add a stream ID in the event, because the Transmitter cannot reuse the event across different streams
- [Tim] It's optional so should it be a problem
- [Atul] Will it affect interoperability
- [Tim] JSON objects are intended to have optional values, without affecting interoperability
- [Atul] Won't the transmitter have to generate a new event for every receiver anyway (event-id, aud, etc.)
- [Apoorva] 'aud' is a list, so you could define a list of all receivers, and reuse the same event

### Issue [#60](https://github.com/openid/sharedsignals/issues/60) - Are subjects required in SSF events?
- [Shayne] We can add a qualification that the subject value is required for all events other than "stream updated" and "verification" events.
- [Eric] It feels a little contorted to do it this way. Can we instead make the "stream updated" event not SSF conformant?
- [Atul] We can add a stream ID subject in the "stream updated" event.
- [Shayne, Eric] We should have thst subject to be opaque, and specify how it should be defined
- [Eric, Shayne, Atul] like the "Add stream id as subject" option more
- [Shayne] what about subscription to that subject?
- [Atul] Should be automatic
- [Shayne] The receiver should be able to remove that subject if needed
- [Atul] That could be problematic, we should not allow removal of that subject

## Action Items
- Atul to add PR to add subject to "stream updated" and "verification" events