# WG Meeting: 2024-05-14
## Agenda
- SSF spec timeline

## Attendees
- Atul Tulshibagwale (SGNL)
- Shayne Miel (Cisco)
- Chelsea Munk ()
- Alex Ilie (VeridiumID)
- Jay Leslie ()
- Jen Schreiber (Workday)
- Mohammad ()
- Sean O'Dell (Disney)
- Steve Venema ()
- Todd Meyer ()
- Yair Sarig (VMWare)
-

## Notes
### SSF Spec Timeline
- (Shayne) Try to get a v1 spec by the end of the year
- In order to do that we need to get to a release draft by ?
- We did not want to make changes, but there are a few security issues pointed out by the Stutgart researchers
- Because these are normative changes, we will make a few outstanding changes
- Not going too wild with the changes
- None of the changes are unlikely to break existing implementations, but after digesting all the security issues, something might come up
- Try to get to a draft 3 by June 15.
-
- (Todd) Shayne, could you please outline the security issues raised?
- (Shayne) One issue is that we did not make certain parts mandatory, some usage could create some security gaps, so we need to specify that
- E.g. when a stream is created, we do not mandate authorization
- In general it does not appear to be threatening
- (Sean) If you allow anonymous add subject...
- (Yair) There's a topic Issue #163, that would be a breaking change from draft 2.
- (Atul) If we added something to the Transmitter metadata to indicate their default behavior, then it won't be a breaking change
- (Yair) agreed
- (Sean) Not allowing a transmitter to send upon a receiver being configured _might_ break bacwards compatibility.
- (Shayne) There's nothing in the spec that says only the receiver should call the stream "add subject" endpoint.
- (Yair) Likes Atul's suggestion for the default behavior of the transmitter with subjects.
- (Atul) Not sure what is to be gained by adding a subject in the stream creation call
- (Sean) We have also had a conversation about wildcards in subject Ids
- (Yair) We should add an example in the spec for the default behavior of various transmitters.

- (Atul) Adding a txn claim
- (Sean) The txn claim is needed when you want to prevent multiple events about the same initial event
- (Sean) We can close the loop with certain events, e.g. Tx A went to Rx B, and then Tx B went to something else in relation to the same event
- (Sean) It should not be required, it should be optional
- (Sean) It's already in RFC...
- (Shayne) If it's already optional in the SET spec, do we need to say anything? Just include it in the examples?
- (Sean) I was just going to include it in the examples
- (Atul)
- (Sean) Session revoked might need to specify it as a mandatory
- (Shayne) This shouldn't be in the events, it should be in the top-level spec
- (Shayne) We can't say it is mandatory only for "session revoked"
- (Steve) Sean's example of the ledgering is applicable to all types of transactions or is it just one-way?
- (Sean) The ledger is interesting and you can use it to close the loop. (E.g. session revoked back and forth)
- (Jen) Would you want to specify "jti" per transaction?
- (Atul) It would need to be unique per event
- (Jen) We should keep in mind when we are adding the language to specify how it is different from jti

- (Sean) The complex subject definition in the SSF spec doesn't specify that the subject is "AND" of all complex subject members, it should specify that more clearly (language in section 3.3.1 needs to be improved)
- (Shayne) When we update this language, we should also clarify the wildcard nature of the complex subject members

- (Jen) Does SSF specify that a SET must include only one event? (10.1.7)
- (Shayne) Section 10.1.7 seems to say that
- (Jen) When would you want different URIs for the same event?
- (Sean) Let's say internally you use a different URI, and externally you have another event?
- (Jen) The language is confusing
- (Atul) Agree
- (Atul) The language also seems to allow multiple different event definitions when using different URIs, we should not allow that
- (Yair) One might have more information than the other, but they may be the same event
- (Shayne) If we really want to restrict it, we should ideally change the data model.
- (Yair) We could start supporting "event"
- (Jen) That would be a big change
- (Atul) I won't want to do that because it is a big change
- (Atul) We should update the language to permit only one event in an "events claim"

- (Atul) Should we move to a weekly cadence until we have 1.3
- (Steve) STan had brought up the timeline for the RISC spec as well.
- (Sean) We can talk about it in the beginning of the next call.
- (Atul) Should we discuss the time for the in-person meeting on email / slack?
-

## Action Items
- Possibly add a metadata configuration parameter with default behavior?
- Jen to draft the PR for making the language change to only allow one event.
- Sean to draft the PR for the txn changes
- Sean to update the language in section 3.3.1 for clarity
- Atul to follow up with Mike L for the new meeting invites