# WG Meeting: 2023-09-26
## Agenda
- https://github.com/openid/sharedsignals/pull/121

## Attendees
- Atul Tulshibagwale (SGNL)
- Apoorva Deshpande (Okta)
- Tim Cappalli (Microsoft)
- Shayne Miel (Cisco)
- Yair Sarig (VMWare)
- Victor Lu ()
- Phil Hunt (Independent Id)
- Sean O'Dell (independent)

## Notes
### [PR 121](https://github.com/openid/sharedsignals/pull/121)
- The audience claim in a Stream's events, the Receiver must be able to specify the audience (i.e. the value of the `aud` claim in the events)
- (Shayne) It was originally Transmitter specified because it was tied to the bearer token. Now that we are decoupling authorization from the stream identification, we can make it Receiver specified
- (Yair) If the Receiver can specify the audience, then a Receiver can specify an audience for some other Receiver. If it is completely determined by the Receiver, then it opens up the possibility of abuse.
- (Atul) Can we append the stream Id to the Receiver specified audience?
- (Phil) Any automatic binding may create utility issues, because the actual receiver may not be the one that the Transmitter sends it to
- (Phil) If in a customer config, you set up a project, I'm going to specify the audience in "*.example.com",..., so there should be some OOB way for the Transmitter to determine the audience for each registered client.
- (Yair) Can we add another claim in the event that identifies the stream?
- (Phil) I'm differentiating streams with different access tokens, each of which is bound to one stream
- (Phil) So you could have a token returned in the stream configuration, which is stream-specific. When you need to renew, you can get the stream configuration again, and get a new token.
- (Shayne) In the POLL model, the Transmitter must specify different endpoints for each stream.
- (Sean) In our case the audience is Transmitter supplied, and the authorization token is bound to an audience.
- (Apoorva) It's not just audience, the delivery endpoint could be changed to some other stream. We are not solving anything by just talking about audience here.
- (Phil) The security consideration has to be that the Tx and Rx must be able to figure out between themselves which stream each event is meant for
- (Yair) Aud claim is a security consideration, so it should not be determined by the Receiver. The Transmitter can set another claim in the event to disambiguate if necessary.
- (Atul) Would having a unique identifier in the POLL endpoint satisfy the requirement?
- (Apoorva) There would need to be some out of band communication about what the Audience should be. We should then make it clear in the spec. We must require that the Transmitter doesn't have the same audience for multiple receivers.
- (Sean) JWT signatures help disambiguate the issuer.
- (Phil) Impersonation is handled by signature. Re-using the JWT meant for someone else is still possible.
- (Apoorva) There is not logical concept of a Receiver in the spec(!)
- (Phil) Having the audience to be Transmitter supplied restricts the spec to not allow certain use cases.
- (Shayne) Security Events situation is a different use case than getting access tokens. It hard to use a fake token in access token situations. But with SETs, we're doing other things, the threat model is fairly different. We have to consider what is the actual threat model.
- (Phil) What I'm describing is that the core claims in JWT are still the same, e.g. the audience. If you are putting restrictions on the aud claim that is unlike how it is used in JWT, you should define a new claim.
- (Phil) The JWT spec simply says that the value of the aud claim should be what the Receiver expects it to be.
- (Atul) Need to end call. We do not have consensus yet.

## Action Items