[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Hi all,
Here are the notes from today's meeting. They are also stored here
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20230926>.

Thanks to all who attended,
Atul

-- 

<https://sgnl.ai>

Atul Tulshibagwale

CTO

<https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
<atul at sgnl.ai>

WG Meeting: 2023-09-26
<https://hackmd.io/tXJMrxV4TcKKY7XByg2w8Q?view#Agenda>Agenda

   - https://github.com/openid/sharedsignals/pull/121

<https://hackmd.io/tXJMrxV4TcKKY7XByg2w8Q?view#Attendees>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)

<https://hackmd.io/tXJMrxV4TcKKY7XByg2w8Q?view#Notes>Notes
<https://hackmd.io/tXJMrxV4TcKKY7XByg2w8Q?view#PR-121>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.

<https://hackmd.io/tXJMrxV4TcKKY7XByg2w8Q?view#Action-Items>Action Items
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230926/b49a0de1/attachment-0001.html>