WG Meeting: 2024-11-05

# WG Meeting: 2024-11-05 ## Agenda - Review the new proposed [CAEP event](https://github.com/openid/sharedsignals/pull/205): "Risk level change" - Reviews issues that should be included SSF-final ## Attendees - Atul Tulshibagwale (SGNL) - Apoorva Deshpande (Okta) - Thomas Darimont (OIDF) - Yair Sarig (Omnissa) - Stan Bounev (VeriClouds) - Martin Gallo (Individual) - Sean O'Neill (EasyDynamics) - Tushar Raibhandare (Google) - Sean O'Dell (Disney) - Keiko Itakura(Okta) ## Notes ### Risk level change ev)nt - https://github.com/openid/sharedsignals/pull/205 - (Atul) Can we call this something else to avoid confusion with RISC - (Apoorva) I was thinking of Threat Level Change, but open to other suggestions. - (Atul) How is this different from "assurance level change"? - (Apoorva) Assurance level change is about policy, this is about risk, so this could be an event that leads to generating an "Assurance Level Change" event. - Everyone please review this event and add your comments. - (Yair) Can we be more flexible than saying "low/medium/high"? This is common, but there could be other ways in which we can express this. - (Apoorva) We could have a numeric "risk score" if needed. - (Stan) How can this event provide consistency between different vendors in what they mean by "low/medium/high" - (Apoorva) We could incorporate a classification from MITRE, or it could be an offline agreement between the parties - (Yair) Maybe adding an optional "risk type" can help in this regard? The "risk type" can provide the same classification - (Apoorva) There is an existing comment along these lines that Shayne has made. - (Apoorva) The thought behind this PR was that having a singular scale - (Apoorva) We could distinguish the type based on the subject claim - (Yair) How does one know what the other party means by "low/medium/high" - (Apoorva) We can do that, but it will be hard to standardize, because each organization can perceive risk differently. - (Thomas) Perhaps we can calculate score based on [NIST vulnerability score](https://nvd.nist.gov/vuln-metrics/cvss/v4-calculator) - (Thomas) Perhaps something like this already exists - (Apoorva) CVSS may not directly apply here. These may not be vulnerabilities. - (Thomas) Perhaps something similar (not the same) can work - (Stan) Everytime there is a risk level change, the Tx will send this event. The Tx can send this event based on any event that we have already in CAEP. All other events could be made obsolete by this. Is this correct? - (Apoorva) It's not, because each Tx may define risk differently. E.g., "session revoked" can be a completely different thing. Or "assurance level change". This will go hand-in-hand with the other events - (Stan) So if I implement both "risk lc" and "assurance lc", then how will I determine which one to use? - (Apoorva) Assurance level change could just be normal behavior (e.g. user has used MFA), whereas the risk level change could indicate something completely different such as a session token being stolen. - (Stan) So say if an Rx receives two events: "credential revoked", and "risk lc" (medium). The question is, are those two about the same thing, or are they describing something else that is going on. As an implementer it will be difficult to go to the bottom of things if there is a "risk lc" event, which doesn't actually say what the risk is, and other events that may be specific. - (Apoorva) You are asking for a prescriptive way of doing things, whereas CAEP is descriptive - (Apoorva) The Tx also could insert a message in the event to say why, which could help reconcile. - (Atul) We could use "txn" to correlate events - (Sean O'Dell) raises thumbs up paddle - (Thomas) Does the “risk” level combines multiple facets? E.g. “impact” and “urgency”? Or is this about the outcome, e.g. what is affected? E.g. authentication level is “weaker” or “higher” because of the event. - (Apoorva) It will be transmitters prerogative to determine the risk - (Thomas) It's not clear to me if a one-dimensional 3-level scale can capture the risk adequately - (Apoorva) This will be based on the maturity of the ITDR of the transmitter, but each Transmitter will be different - (Sean O'Dell) This could be an additive signal, not a prescriptive signal. - (Apoorva) We can learn as we start implementing, but we can start here. - (Apoorva) Going back to Yair's point, the same thing could be said about the numeric scale - (Yair) That's why we need to indicate the scale we are using in the event. - (Atul) We did something similar in the "Assurace LC" event, we added the "namespace" field to capture the scale we are using in the event. - (Yair) The scale could default to "low/medium/high", so if the scale indicator doesn't exist, it is that. If it is specified, the value is from that scale. - (Apoorva) The processing of the event will be difficult if the scale is not the same from each transmitter (interoperability will be harder) - (Yair) It's upto the Receiver to determine what it can support. - (Apoorva) Please add examples of requiring different scales - (Atul) One other concern is whether it is sufficient to determine what the event is about based on the subject format. - (Yair) Agree with this concern. What happens when the subject is a complex subject and has say, an email and a device identifier. What is the event about? - (Apoorva) So you're saying we need to pinpoint what the risk is about (device, user). - (Apoorva) We can consider the risk to be about everything the subject indicates. - (Atul) Please provide this language in PR - (Apoorva) Will think about this ### What issues to include in SSF-final - (Atul) We do not need to go to ID-4 in order to call a revised spec final. We can propose a revised spec as the "final" proposed spec and vote on that. - (Apoorva) Can we verify that? - (Apoorva) My suggestion is to not take up anything unless it is urgently required. i.e. Let's take ID-3 to final. - (Yair) What is the criteria for calling an issue to be in "v1Final"? - (Tushar) I have a question about v1Final vs vFuture. There are some quality of life changes that could be included. - (Atul) Call to action: Please review the issues, and if you believe something needs to be in "v1Final", tag it and comment on the issue as to why you believe it should be so. ### SSF conformance testing (Thomas) I wanted to take a moment to say “thank you” for providing the SSF Enabled environments to the OIDF to support SSF conformance test development. This has already been a great help! Thanks Atul (caep.dev), Thanks Yair (Omnissa), Thanks Apoorva (Okta) - (Thomas) It's a Java Spring Boot project that you can run to test your implementation. It should be ready in a few weeks. - You can find the current (working) version [here](https://gitlab.com/openid/conformance-suite). ## Action Items - (All) Call to action: Please review the issues, and if you believe something needs to be in "v1Final", tag it and comment on the issue as to why you believe it should be so.