# WG Meeting: 2024-05-21
## Agenda
- RISC: What is next for the RISC spec
- One event per SET [Issue 167](https://github.com/openid/sharedsignals/issues/167)
- Default stream behavior (no subjects / all subjects) [PR 168](https://github.com/openid/sharedsignals/pull/168)
- (smiel) How to describe "internal" implementations [Issue 160](https://github.com/openid/sharedsignals/issues/160), [Issue 161](https://github.com/openid/sharedsignals/issues/161), [Issue 162](https://github.com/openid/sharedsignals/issues/162)
- (atul) CAEP Session Established event [PR 154](https://github.com/openid/sharedsignals/pull/154)
- (atul) Should we cancel next week's meeting?

## Attendees
- Steve Venema (soon to be Microsoft)
- Atul Tulshibagwale (SGNL)
- Shayne Miel (Cisco)
- Stan Bounev (VeriClouds)
- Yair Sarig (VMWare)
- Sean O'Dell (Disney)
- Jen Schreiber (Workday)

## Notes
### RISC Spec roadmap

* What are we going to do about the RISC spec
* (Atul) There haven't been changes to the RISC spec after the last Implementer's Draft (ID), so we should bring it to final along with the SSF spec
* (Stan) We have advanced the SSF spec (multi-stream, etc.)
* (Steve) It may be worth updating the RISC spec to comply with the new SSF spec
* (Shayne) We need to change the location / name of the "subject" field
* (Shayne) I have done this already in my recent PR. The spec is updated

### One event per set discussion
* [Issue 167](https://github.com/openid/sharedsignals/issues/167)
* Last discussion we arrived at only requiring one key value pair
* (Jen) Would existing implementations be looking up the event URI within the JSON object value of the "events" claim
* (Sean) If you take the SET spec out of the equation and look at other data structures, such as Kafka queues, it's one-to-one
* (Sean) I see both sides, but it's usually one-to-one
* (Atul) what will we gain by doing this?
* (Sean) The txn claim could link multiple transactions in the same event?
* (Jen) We could just leave the language as it is
* (Atul) We could address this in the interop spec

### Language in [PR 168](https://github.com/openid/sharedsignals/pull/168) (smiel)
* (Atul) My confusion, now resolved.

### How to describe "internal" implementations (smiel)
* Issues 160-162
* (Atul) Is the problem that the stream API does not require authorization?
* (Sean) It is two things: Stream registration and the lack of authorization when you are polling for SETs.
* (Atul) So the Stream API does not require authorization and the Poll endpoing does not require authorization
* (Yair) If you don't specify authorization, any implementation will be insecure. How will specifying that you need authorization without specifying the details does not make sense
* (Shayne) We can say something like "If you have some other way of assuring trust, then you can forgo authorization"
* (Yair) We should be prescriptive about the authorization to be used
* (Atul) I think we decided to let the implementers use the OPRM spec to determine what type of authorization. [OPRM](https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/)
* (Jen, Sean) There could be multiple authorization methods based on the data and functionality
* (Sean) So stream creation could have a different authorization than stream operations
* (Atul) Can we classify the endpoints into 3 categories?
* Stream creation
* Stream operations
* SET delivery
* (Sean) Can we address this in the interop spec?
* (Shayne) We should specify that these endpoints must be secure in the SSF spec, but which method to use should be specified in the interop spec
* (all) Agreed to take the approach that:
* SSF spec should specify that unless there is another way of establishing trust, the endpoints should be secured.
* Interop spec should specify which types of authorizations are to be used for specific endpoints.

### CAEP Session Established Event [PR 154](https://github.com/openid/sharedsignals/pull/154)
* (Atul) Can everyone please take a look to see if they need to do anything in that PR?
* (Shayne) Does this change the version of the CAEP spec
* (Atul) Yes, because the changes are normative

### Next week's meeting
* (Shayne) Happy to host in person in the OpenID room
* (Sean) When?
* (Shayne) Let's keep the current time, and have people join virtually too.

## Action Items
* (Jen) To interpret Section 10.1.7 with a concrete example in the interop spec
* (Shayne) To communicate this approach to the security researchers to understand if it addresses their concerns.
* (Shayne) To figure out room logistics with Mike L for next week's meeting