[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-20240611>.

Thanks to all who attended,
Atul

-- 

 Atul Tulshibagwale

 CTO

  <https://www.linkedin.com/in/tulshi/> <atul at sgnl.ai>
<https://x.com/zirotrust>
--
WG Meeting: 2024-06-11
Agenda
Open items for SSF ID-3 candidate
Open items for interop spec
CAEP "session presented" event
Attendees
Atul Tulshibagwale (SGNL)
Shayne Miel (Cisco)
Jay Leslie (Easy Dynamics)
Sean O'Dell (Disney)
Sean O'Neill (Easy Dynamics)
Stan Bounev (VeriClouds)
Steve Venema (Microsoft)
Apoorva Deshpande (Okta)
Alex Ilie (Veridium)
Jen Schreiber (Workday)
Notes
Open items for SSF ID-3 candidate
(Atul) Three cancdidate specs to possibly go out around June 15:
SSF
Interop-spec
CAEP
(Apoorva) Why is June 15 important?
(Atul) Working backwards from when we need a final spec (around Gartner IAM
summit in Dec)
3 Open PRs:
#180
#168
Language for Txn Claim in SSF
(Shayne) This one is ready to go, just needs approval
Default for subjects in a stream (#168)
(Apoorva) Adding the field in the Transmitter Configuration Metadata
pollutes it with stream-specific information
A transmitter may want different default behaviors for different streams
(Shayne)
(Atul) you can have a global level setting at the the trasmitter level and
an override at the stream level…going forward
We can add it in later if we need to. (Shane echoed)
This could be expressed in the stream configuration response (for this
stream this is my behavior)
(Sean) Would like to define the difference between a stream and a client
from a mgmt level
(Shayne) We can move this field to the stream configuration instead of the
Transmitter Configuration Metadata
(Apoorva) Why is this a priority for v3? SCIM doesn't spell this out
(Apoorva) SCIM is default all
(Shayne) That's how we started with this, because some want all and some
want none
(Sean) This was also called out in the security review
(Shayne) How about doing both - in the TCM and in the stream config
That way we will know ahead of time (before stream creation), how the
transmitter is going to behave
(Nancy) In either case, we need to be clear about the expected stream
behavior, but I agree with Shayne that it can be in both places
(Apoorva) Why is it better? It could cause more confusion
(Nancy) It has clarification at both levels
(Apoorva) Adding it in both places is going to cause confusion
(Atul) We do not have a use case for overriding the default
(Steve) We just need t omake sure we don't break backward compatibility if
we add it later
(Apoorva) Where would we put the status of the stream when it gets created
(Atul) I propose we keep it in the TCM
(Steve) If one stream has voluminous output and you don't want to get
inundated,
(Apoorva) I've provided an example in the first comment (
https://github.com/openid/sharedsignals/pull/168/files#r1612134035)
(Nancy) I see Apoorva's point, so you would need the flexibility for
different streams
(Atul) Why have it both places?
(Shayne) A Transmitter may behave in a certain way for all streams, except
where for particular streams it wants the other behavior
(Sean) Do you anticipate one audience per stream, or multiple audiences
(Apoorva) One audience per stream
(Sean) why?
(Apoorva) Our audience is tenant based
(Sean) Some people are viewing audience and stream both as first-class
citizens
(Atul) The spec forbids having multiple audiences in the stream
(Sean) How many people would need different defaults per-stream?
(Apoorva) It also depends which partner you are implementing with
(Sean) I vote for putting it in both places
(Sean) I see use cases where a Transmitter could override for specific
streams
(Apoorva) I'm not opposing adding it in the stream configuration
(Shayne) Should I rename the values? Instead of "all" or "none", we could
clarify "receiver needs to add subjects" and "receiver doesn't need to add
subjects"
(Shayne) Apoorva's original concern is that when Tx A creates streams with
Rec B and Rec C, they want to send different user constituencies to Rec B
and Rec C
(Apoorva) If we clarify what "all" or "none" means wrt a stream in the TCM,
I am good with that
(Shayne) I can clarify that
CAEP Session Presented event #183
(Atul) Reason why I had "risk score" as a part of the "SEssion Presented"
event is because generally, a risk score is computed as a part session
presence
(Shayne) I don't associate risk scores with sessions - they are usually
associated with devices or users. There are a lot of risk and security
elements that we can add to a session, and it could be dissociated from the
"Session Presented" event. We could have a session specific subject to a
"risk score change" event
(Apoorva) I agree
(Sean) I wanted to propose something in SSF that indicates "confidence" in
an event
(Apoorva) Should we also wait until the dictionary thing comes up before we
introduce new events
(Atul) Since the "session established" event is already in, we should add
the "session presented" event right now
(Apoorva) Should we defer other events until later?
(Atul) Yes, if we have a defined timeline for the new way of doing things
(Jen) We don't yet have a timeline for it
(Sean) In the "session presented" event, you have a lot of properties such
as IP address, etc. So I would like to know the "risk score" as well. I get
that it is subjective, but it is a good start. I like the "risk score" in
the session presented event a lot
(Sean) All these claims are optional
(Shayne) But it might get in the way of doing things the right way
(Stan) What needs to happen if we say we need to add this event to the next
version, how much work is that?
(Atul) Include it in the new draft that is sent for review
(Stan) It makes sense to have a session risk in general, but we need to
think about how this fits with other types of risks. Think about session
risk, device risk, credential risk, etc. How do they prioritize that?
Action Items
(Shayne) To update #168 to reflect audience scope language
(Atul) To separate the "Risk score" as a separate PR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20240611/d6236b45/attachment-0001.html>