[Openid-specs-risc] Meeting notes

[Atul Tulshibagwale]

Hi all,
Here are the notes Shayne and others took during the meeting today (I was
unable to attend). The notes are also stored here
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20240910>.

WG Meeting: 2024-09-10
*Agenda*

   - Formal security analysis approval
   - Risk level change event Issue 200

*Attendees*

   - Shayne Miel (Cisco)
   - Marcus Almgren / Thomas Darimont (OIDF)
   - Rajvardhan Deshmukh (Cisco)
   - Stan Bounev (VeriClouds)
   - Swathi Kollavajjala (Cisco)
   - Apoorva Deshpande (Okta)
   - Tom Sato (VeriClouds)
   - Sean O'Dell (Disney)
   - Steve Venema (Microsoft)

*Notes*
*Formal Security Analysis Approval*
(Shayne) Report was posted in Issue 198
(Marcus) Group should agree that there is nothing left outstanding
(Apoorva) Do we have a list of what changed between draft 2 and 3?
(Shayne) Apologies, I did not see that request. Will gather for next meeting
(Apoorva) Let's wait until next meeting to approve

*Risk Level Change Event*Issue 200
(Apoorva) - Proposal of a generic way of communicating risk to different
parties
Sub could be user, device tennant.
was a topic to put in RISC vs CAEP…Keep in in CAEP.
Is this going to be generic or specific.
(Stan) - What is going to measure this risk event or define the criteria
for it to happen?
(Apoorva) - Different companies or systems factor in "risk" and is very
subjective
(Stan) - There might be confusion in this case with the subjectivity and
different levels or risk. If bucketed under this event there can be
discrepancies between vendors and "relative risk".
(Stan) - We should consider this Risk event to be more agnostic between
vendors. When to act vs when not to.
How would the vendors accept it.
(Apoorva) - getting to a common ground might be subjective.
using "admin_reason" could be a way to be more discreet about the
subjectivity. But the goal was to be subjective / abstract to cover use
cases.
this is very similar to "claims changed event" in CAEP
(Stan) - Tx sends event of what happened and here it is sent to the Rx.
The name is going be confusing with RISC spec as it has "risk" in it.
Ensure that it is clear in the name between the RISC spec and event name in
the CAEP Spec. Suggestion is for a better name to avoid confusion.
(Sean) - Used internally by some companies, but has a lot of value and was
proposed in the latest 2 caep events
(Shayne) - Risk of what? what is the Risk
(Apoorva) - Subjectivity is key but coming up with the enums will be
difficult
(Shayne) - Do we want risk of "x" events?
(Stan) - be more specific
(Shayne) - Do we want events for each type of risk vs parsing from a text
string in "admin_reason". If it is general..something has happened might be
more precise
(Steve) - This convo might lead to an enumerated type or a risk registry.
(Sean) - Wait for the registry the risk were too big to enumerate
(Apoorva) - We need a container to communicate
If you think an enum would work…that could work
Adding one event per type may not scale (opinion)
(Shayne) - Differentiation of metadata per event per type might matter.
Downloading something with a virus versus cred was pwned.
(Stan) - Metadata is a way that could help, from the POV of the Rx. The Rx
will need context of the metadata/dictionary and a common dictionary.
To help the implementers we could create 3 or 4 events.
(Apoorva) - What is important to Steve vs Jen vs Harry might differ
(Stan) - Lets see if we can get to those 3 events for the implemented
(Apoorva) - There could be risk events that would be hard to enumerate… 15+
(Stan) - Start with the most common to tackle?
(Apoorva) - Defining just another event might flood the network.
(Stan) - There might be too many feeds and types of risk that are sent that
you risk a signal to noise ratio being too high. The Tx might need to use
the common taxonomy to put the data in the feed.
(Shayne) - This might be a new profile of events. Might be a generic risk
event but not specific and expand the specifics as we need to.
(Apoorva) - Moving to dictionaries versus profiles (as indicated in Issue
200)
Confusion for new implementers on which one to use. How do we avoid the
confusion in the future?
(Raj) - This seems like a stop gap until the JSON Registry is up and
running.
(Apoorva) - This is a need that we see, Okta, and there is a demand for it
(Shayne) - What risks are you communicating?
(Apoorva) - Every provider has different types of Risk and the bigger
spectrum.
(Shayne) - You have a list of IP's in the data here. He complained about it
in the session established event and will do so here. Maybe introduce a new
subject type
(Sean) - Previous context versus current…is that your intent?
(Apoorva) - Same guidelines as claims changed event.
(Shayne) - Device, Tenant and User Risk. How would you interpret the risk
based on the subjects identified?
(Apoorva) - Means to feed data that is abnormal and reactivate
infrastructure
(Shayne) - The subject is used to identify the risk, ok.
(Apoorva) - It can be a mixture of both
(Stan) - We should keep account level subjects risk to the RISC Spec, not
CAEP
(Stan) - Some vendors can have high low medium without sending any data (so
minimal to no metadata)
(Apoorva) - Should not have to restrict anything as the profiles might
become moot with a dictionary/schema
-When we are accepting the events the "reason_admin" it should/would be
implemented as mandatory.
(Shayne) - Isn't "reason_admin" optional? We all think so…Shayne is
checking and it is called out as optional in the CAEP Profile.
*Where are we at with the RISC Spec?*
(Stan) - Where are we at with it to get to the next draft?
(Shayne) - They might go together
(Stan) - We have not worked on the RISC spec for a while and we maybe
should?
At least consisency.
(Shayne) - Is there anything to review for the 2 new specs? Dont think
there is.
(Stan) - Agrees.
(Sean) - We need the schema/dictionary sooner rather than later
(Stan) - agrees
(Apoorva) - agrees
(Shayne) -agrees. Rather have schema/dictionary vs final review


*Action Items*(Shayne) - Compile changes from ID2 to ID3 security analyses
(Apoorva via Shayne) - Add a new subject type in the SSF Spec. Apoorva is
working on the Issue
(TBD) - Double check the RISC spec for consistency with CAEP (syntax)
(Jenn and Sean) - See about plausibility for review of the JSON Schema and
applicability for the 2 profiles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20240910/aa7f803e/attachment.html>