# WG Meeting: 2023-11-28
## Agenda
- Interop profile discussion:
- Stream pause / restart ability
- Should we require Push support for interoperability?
- Implicit subjects

## Attendees
- Atul Tulshibagwale (SGNL)
- Shayne Miel (Cisco)
- Sean O'Dell (Disney)
- Yair Sarig (VMWare)
- Tim Cappalli (Microsoft)
- Nancy Cam-Winget (Cisco)

## Notes
### Session-revoked event
- Receiver SHOULD transmit back to the Transmitter that they've revoked a session
- Command versus "past tense"
- CAEP is descriptive versus being prescriptive

### Push Support
- Atul summarized the approach that push is a bar set for Receivers to be interoperable, but doesn't preclude them from implementing Poll
- (Shayne) Worried that forcing people to implement Push will make it harder for Receivers to have something in time
- (Shayne) I'd lean toward the interop spec requiring Poll, but not Push
- (Sean) Even though it's possible to use unsigned events in the Poll model, I wouldn't remove the signing requirements
- (Sean) It becomes harder for a Transmitter to sign some events not others
- (Yair) It's not hard to do signature verification, why is this a question

### Implicit Subjects
- Atul explained that the draft doesn't expect each subject to be added
- (Shayne) The spec draft should be improved to clarify this, but the premise is good

### Start / stop ability
- (Sean) I think the pause / restart ability needs to be included in the interop spec. There may be a large update the Transmitter is doing, and they may want to temporarily pause the stream while that update is going on
- (Yair) There's ambiguity about how long the Transmitter should hold events
- (Sean) It may be OK to get duplicate events after restart due to the complexity of trying to prevent duplicates
- (Atul) Can we specify both in terms of time and number of events?
- (Sean / Yair) The interop spec should just say it is "time and quantity based", but the actual numbers can be determined by the specific Transmitter
- (Atul / Sean / Yair) We may need to add something to the Transmitter Configuration Metadata to communicate this
- (Atul) Should we for now not specify how to communicate the constraint numbers?
- (Yair) If we don't specify, then each implementation could diverge
- (Shayne) This isn't going to be a surprise, because this will be negotiated between the parties offline
- (Yair) You could write code that knows how to handle such situation
- (Atul) Does this need to be handled in code at all?
- (Yair) We may require events to be sent to the data center for logging, but if a Transmitter is not very reliable, then that could be omitted

### Implicit Subjects post ID-2
- (Sean) As a post ID-2 item, I would like the "AddSubject" to be more generic than specifying specific sugjects
- (Shayne) Does the wild-carding in complex subjects help here?
- (Sean) In which way?
- (Shayne) The Receiver can say that they are interested in a specific tenant, but not specify each entity within that tenant
- (Yair) Should we have a way to specify whether the Transmitter supports implicit subjects or do the subjects need to be added explicitly
- (Sean) The wildcarding can only be for "addsubject" and not for actual events
- (Sean) follow the SCIM format in specifying what should be in the stream
- (Shayne) We can do that today in the spec using complex subjects
- (Tim) That's what it is intended to be
- (Atul) Can we add an example in the spec that clarifies this?

### Voting on the ID-2
- (Atul) Use [this link](https://openid.net/foundation/members/polls/322) to vote on the draft

## Action Items
- Atul to remove the "Push" requirement from the interop doc
- Atul to add the "pause and restart" capability
- Atul to add time and resource constraint in the interop spec, but not specify how much constraint
- WG to work on specifying how to communicate resource constraints in the Transmitter Configuration Metadata as a post ID-2 item
- Shayne to work on an example about add subject for a collection of users
- WG to work on clarifying the implicit subjects part post ID-2 in the SSF spec