[Openid-specs-risc] Meeting Notes for 04/30/2024

Thu May 2 18:52:45 UTC 2024

Hi all,

Here are the notes from Tuesday's meeting. They can be accessed here<https://hackmd.io/@oidf-wg-sse/wg-meeting-2024-04-30> and all past notes can be found here<https://github.com/openid/sharedsignals/wiki/Meetings>.

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

[cid:e70cca28-5159-4632-ac3a-8e7534c2d652]
[https://duo.com/assets/img/email/spacer.gif]
Shayne Miel  / Principal Engineer (he, him, his)
smiel at cisco.com<mailto:smiel at cisco.com>
(919) 923-6230
cisco.com<https://www.cisco.com/site/us/en/products/security/index.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20240502/6edfebec/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-rc4ehhtt.png
Type: image/png
Size: 13713 bytes
Desc: Outlook-rc4ehhtt.png
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20240502/6edfebec/attachment-0001.png>