[Openid-specs-risc] Call notes

[Atul Tulshibagwale]

Link to notes: https://hackmd.io/@oidf-wg-sse/wg-meeting-20241105

On Tue, Nov 5, 2024 at 11:04 AM Atul Tulshibagwale <atul at sgnl.ai> wrote:

> Hi all,
> Thanks for your participation in today's call. Here are the notes. They
> are also stored here.
>
> Atul
>
> --
>
>  Atul Tulshibagwale
>
>  CTO
>
>   <https://www.linkedin.com/in/tulshi/> <atul at sgnl.ai>
> <https://x.com/zirotrust>
>
> WG Meeting: 2024-11-05 <#m_-98438666421278688_Agenda>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
>
> <#m_-98438666421278688_Attendees>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)
>
> <#m_-98438666421278688_Notes>Notes
> <#m_-98438666421278688_Risk-level-change-event>Risk level change event
>
>    - 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
>
> <#m_-98438666421278688_What-issues-to-include-in-SSF-final>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.
>
> <#m_-98438666421278688_SSF-conformance-testing-Thomas>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>.
>
> <#m_-98438666421278688_Action-Items>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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20241105/fa085325/attachment-0001.htm>