# WG Meeting: 2024-04-30
https://hackmd.io/@oidf-wg-sse/wg-meeting-20240416/edit
## Agenda
- Existing action items (0 min)
- Continued discussion (5 min)
- New topics (30 min)
- Open PRs (10 min)
- Recent issues (0 min)

## Attendees
Please add yourself here or enter your name and organization in the chat.
- Shayne Miel (Cisco)
- Sean O'Dell (Disney)
- Tim Cappalli (Okta)
- Elizabeth Garber (OpenID)
- Mohammad Pulak (IRS)
- Apoorva Deshpande (Okta)
- Jen Schreiber (Workday)
- Todd Meyer (IRS)
- Sean O'Neill (Easy Dynamics)
- Jay Leslie (Easy Dynamics)
- Tom Sato (VeriClouds)
- Stan Bounev (VeriClouds)
- Steve Venema (non-affiliated)

## Existing action items
- (Shayne) Add Yair to Slack - [DONE]
- (Apoorva) Typographical PR - [DONE]
- (Shayne) Look into Issue #66 to add well-known to IANA - [DONE]
- (Atul, Shayne) Re-review PR #134 [OUTSTANDING]
- (Yair) Create PR to fix issue #150 [OUTSTANDING]
- (Sean) Use Cases inital pull / feedback from Stan [OUTSTANDING]

## New topics

### `txn` claim in SET (sean)
- (Sean) Adding the `txn` claim helps implementers know what to add without having to follow links
- (Sean) Comment on issue suggesting against it because it is already in SET spec
- (Sean) We left it at "let's make a PR so we can discuss"

### SCIM Events + SSF (sean)
- (Sean) Phil wants to keep SCIM events as a separate thing
- (Jen) Could go in SCIM use cases
- (Sean) Mike, Nancy, etc getting on a call to work it out
- (Jen) SCIM doesn't want to add something that is still in draft form
- (Apoorva) This is the SCIM working group?
- https://datatracker.ietf.org/doc/draft-ietf-scim-events/

### Clarify meaning of adding subjects (shayne)
- (Tim) Assumption is that no events are served by default
- (Shayne) Should we state this in the spec?
- (Apoorva) Since add-subject/remove-subject is optional, Okta assumes all events are sent by default
- (Apoorva) It is transmitter's choice to approve request to add subject
- (Tim) Default open leaves a security hole
- (Apoorva) Default open makes it easier to implement
- (Tim) Why not just use a wild card
- (Shayne) Complex Subject has wild card support
- (Sean) Are large companies going to make the receiver ask for every subject?
- (Sean) Classification of users
- (Shayne) That's what wild cards does
- (Tim) Old single-stream model was bound to the token which made it safer to default open
- (Tim) We could maybe put it in the stream config. If not present, then expected that we default closed
- (Apoorva) How does the multi-stream change things?
- (Tim) Old model binds everything to the token.
- (Apoorva) Authorization is separate from SSF spec
- (Tim) Correct, but we need to authorize subjects differently
- (Shayne) Same model as the way event types are subscribed to
- (Apoorva) We have already kept the federated relationship outside the spec
- (Shayne) We are discussing the interpretation of the existing spec, not a new feature
- (Jen) What is the decision we are trying to make?
- (Tim) Decision is: Should a Transmitter whose Receiver has not explicitly requested subjects start sending events for all subjects by default?
- (Apoorva) What about SCIM? How do they handle it?
- (Sean) It's use case dependent
- (Sean) By default SCIM is closed
- (Sean) Is this an interop spec question?
- (Apoorva) I would vote for it being addressed in the SSF spec since it is the definition of how the stream works
- (Stan) From a practical point of view, Receiver might want to get all subjects or subset. Is there a way to allow that?
- (Shayne) We've talked about Complex Subjects allowing wildcard like behavior.
- (Tim) Essentially, the claims act like wild cards if you don't define them
- (Sean) How does the receiver know the tenant values to "ask for"?
- subject: {
format: complex
}
- (Stan) If Receiver wants to get all events from a single domain. Can we do "*@acme.com"?
- (Shayne) I don't think that ability exists
- (Sean) It is on the Transmitter to define the logic that a specific tenant/account relates to a specific domain
- (Apoorva) There is no way to validate that the Transmitter is sending the right thing
- (Shayne) We intentionally left out "list subjects" for security reasons
- (Steve) The flip side is that it fails silently, because the Receiver can't verify whether a subject is in a stream
- (Steve) It seems like we might want some way to confirm whether a subject is in the stream
- (Sean) We've never talked about splitting event types by subject, correct?
- (Shayne) Correct. If you want that, set up multiple streams

### [Event dictionaries as JSON schema definitions](https://github.com/openid/sharedsignals/issues/158)

### Should we reserve SSF well-known in the IANA registry? https://github.com/openid/sharedsignals/issues/66 (Apoorva)

options in a non-normative way

### Federated Identity Working Group ###
https://www.w3.org/groups/wg/fedid/
Is interesting with `session presence` new CAEP event type :)

## Continued discussion (5 min)
### Use cases document (sean, stan)
- (Stan) Not able to connect since last meeting. Will update at next meeting.

## Open PRs (10 min)
### [142: Clarify verify event response code](https://github.com/openid/sharedsignals/pull/142) (apoorva)
- (Apoorva) Abandoned

### [148: Optional receiver_key to enable encryption of SETs](https://github.com/openid/sharedsignals/pull/148) (shayne)
- (Shayne) Need to rework to be non-normative

### [134: Include OAuth specifics in the interop spec](https://github.com/openid/sharedsignals/pull/134) (apoorva)
- (Apoorva) Updated as per requests. Needs re-review

## Recent Issues (15 min)

## New Action Items