# WG Meeting: 2024-04-16
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)
- Apoorva Deshpande (Okta)
- Jen Schreiber (Workday)
- Tom Sato (VeriClouds)
- Palak Arora (AWS)
- Stan Bounev (VeriClouds)
- Yair Sarig (Broadcom)

## Existing action items

## New topics
### Security audit (shayne)
- Please review formal security analysis document sent to mailing list
- (Shayne) Gave overview of doc
- (Shayne) Please leave any feedback in Slack

### `txn` claim in SET (sean)

### SCIM Events + SSF (sean)

### Clarify meaning of adding subjects (shayne)
- (Shayne) Delay until other co-chairs are available
- (Yair) What is the default? Is everything sent or is nothing sent?
- (Yair) Issue with groups - how do Receivers and Transmitters sync knowledge of groups?
- (Apoorva) There has to be identity federation
- (Apoorva) Can we make a recommendation today?
- (Apoorva) Since add/remove subject is optional, recommendation is that by default everything is included.
- (Shayne) Then what happens when a subject is added?
- (Yair) Could we make this a stream configuration?
- (Yair) Enterprise case - there is no choice. But user might want to add specific subjects.
- (Shayne) We have wildcards in the Complex Subject
- (Apoorva) We should define use cases.
- (Apoorva) Even if add-subject is requested, it is ultimately the Transmitter's choice of whether to send it

### What are the next steps to get the specs out of ID? (Apoorva)
- (Shayne) There are a few things that need to happen:
- 1. Issues with typographical nits need PR
- 2. Any changes needed by the security analysis should be implemented
- 3. If any of that is a normative change, we need to release draft 3 and go through a voting process
- 4. If not, we could move to a voting process to move the spec to release. Same is true after draft 3 if we go there.
- (Apoorva) We should take a stand to avoid any normative changes (expect the mandatory things from security review)
- (Shayne) Agree whole-heartedly, expect that I don't if our hands are tied with security analysis
- (Yair) We should clarify the add-subject semantics
- (Shayne) If we can do it in a non-normative way
- (Apoorva) That doesn't seem like a must-have
- (Apoorva) Is there a timeline?
- (Shayne) My task as co-chair is to get the spec to release. Aiming for as soon as possible.

### Should we reserve SSF well-known in the IANA registry? https://github.com/openid/sharedsignals/issues/66 (Apoorva)
- (Apoorva) With ID2 we've reserved a specific well-known url. We should register it with IANA.
- (Shayne) Do you need approval?
- (Apoorva) I don't think so.

### Gartner interop results publication (Apoorva)
- (Apoorva) Are there plans to publish anything?
- (Shayne) There were blogs published by the vendors (SGNL, Okta)
- (Shayne) We should promote those blogs from the working group page
- (Apoorva) They published the metrics

### Circle back on DCR discussion from last meeting (Jen)
- (Jen) If i remember, this was related to interop?
- (Jen) Double checked the DCR - updating is allowed but out of scope
- (Shayne) This was referencing PR #148 - I need to update it to give options in a non-normative way

## 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)
### [149: Stream creation lanaguage imply that transmiter must suport the poll delivery method if delivery method is not specified](https://github.com/openid/sharedsignals/issues/149) (yair)
- (Yair) Language in spec says that if you don't specify a delivery method it should be poll. But poll is considered optional.
- (Yair) Recommend that Transmitter return error code if Transmitter doesn't support poll and Receiver doesn't specify push.
- (Apoorva) What about multi-step stream configuration? One layer could create stream and another layer could configure it.
- (Yair) That would imply poll is required
- (Shayne) What if we allow the stream configuration to leave off delivery method?
- (Yair) We just need to remove the language stating that by default streams are poll.
- (Shayne) This relates to Issue # about marking elements of the Stream Configuration as optional or not
- (Apoorva) Partial configuration is more complicated. We should make them all required unless explicitly marked optional (like "description")

### [150: The examples for stream update requests should not include Transmitter-Supplied fields in the request](https://github.com/openid/sharedsignals/issues/150) (yair)
- (Yair) In stream-update, the examples include some Transmitter-specified arguments. They should be removed.
- (Shayne) They are actually allowed. Does including them make it more confusing or does it help highlight that they are allowed?
- (Yair) In PUT maybe, but not in PATCH

## New Action Items
- (Shayne) Add Yair to Slack
- (Apoorva) Typographical PR
- (Shayne) Look into Issue #66 to add well-known to IANA
- (Atul, Shayne) Re-review PR #134
- (Yair) Create PR to fix issue #150