New CAEP event - Risk level change event #205

appsdesh · 2024-09-20T21:52:16Z

New CAEP event - Risk level change event

Closes #200

Removed ips claim from the event and created #201 to handle it separately for all CAEP events

Risk level change event

openid-caep-1_0.md

Co-authored-by: Shayne Miel (he/him) <[email protected]>

openid-caep-1_0.md

ysarig75 · 2024-11-05T18:32:15Z

openid-caep-1_0.md

+: REQUIRED, JSON string indicates the reason that contributed to the risk level changes by the Transmitter. Overall this is an OPTIONAL claim, but marked as REQUIRED for Risk Level Change to indicate reasons behind the risk level change.
+
+current_level 
+: REQUIRED, JSON string indicates the current level of the risk for the subject. Value MUST be one of LOW, MEDIUM, HIGH


Mandating the use of a LOW, MEDIUM, HIGH for risk levels may be too restricted for some usage. Some Companies may want to use a numeric range (e.g., 1-5 or 1-10) instead without needing to map it into LOW, MEDIUM, HIGH range.

One option is to add some kind of an optional "risk type" or "risk system" that may indicates to receivers how the risk is calculated and how it is being represented

Assurance level change uses namespace, but in that example, there are standardized ways of representing levels.

In this case, I feel even the numeric system will be subjective, it will not help bring standardization.

Another option is to plainly define a score as an optional attribute that could satisfy your use case, but I believe that could be solved by adopting #221

The assurance level change event has a "Any other value..." escape, that makes it possible to define your own namespace. I feel having a standard set of values - whether Low, Medium, High or 1-10, will improve interoperability, so I'm in favor of keeping it simple. Like Apoorva says, we can include additional information in the "event data" field. I feel the numeric range is slightly more expressive, and you could define LOW, MEDIUM and HIGH as three points in that range, so it subsumes that.

appbugs · 2024-11-05T18:56:54Z

The Risk level change event can be used by implementers as a "catch all" event. For example, an receiver could decide to use Risk level change instead of implementing the CAEP events. If we have a Risk level change event, which is prescriptive, we'd allow implementers to go the easy route and implement ONLY Risk level change event. Is that a behavior we want to encourage?

As we discussed today CAEP events are descriptive, while Risk event is prescriptive. I don't see prescriptive and descriptive events coexist in the same spec. My suggestion is to wait with adding this event to the final spec.

appsdesh · 2024-11-05T19:05:22Z

The Risk level change event can be used by implementers as a "catch all" event. For example, an receiver could decide to use Risk level change instead of implementing the CAEP events. If we have a Risk level change event, which is prescriptive, we'd allow implementers to go the easy route and implement ONLY Risk level change event. Is that a behavior we want to encourage?

As we discussed today CAEP events are descriptive, while Risk event is prescriptive. I don't see prescriptive and descriptive events coexist in the same spec. My suggestion is to wait with adding this event to the final spec.

This event is the same as any other event in the CAEP spec, and it is NO WAY prescriptive. The Reciver may decide to do NOTHING on the risk being HIGH, same way as they chose to ingnore existing Session Revoked or Credential Change events.

Whether and how organizations respond to any of the CAEP events is completely dependent on their risk tolerance levels. The event can describe what led to Tx raising or reducing the risk and description around that, this is very flexible mechanism to share the risks with vendors.

appbugs · 2024-11-05T19:48:45Z

#200

The Risk level change event can be used by implementers as a "catch all" event. For example, an receiver could decide to use Risk level change instead of implementing the CAEP events. If we have a Risk level change event, which is prescriptive, we'd allow implementers to go the easy route and implement ONLY Risk level change event. Is that a behavior we want to encourage?
As we discussed today CAEP events are descriptive, while Risk event is prescriptive. I don't see prescriptive and descriptive events coexist in the same spec. My suggestion is to wait with adding this event to the final spec.

This event is the same as any other event in the CAEP spec, and it is NO WAY prescriptive. The Reciver may decide to do NOTHING on the risk being HIGH, same way as they chose to ingnore existing Session Revoked or Credential Change events.

Whether and how organizations respond to any of the CAEP events is completely dependent on their risk tolerance levels. The event can describe what led to Tx raising or reducing the risk and description around that, this is very flexible mechanism to share the risks with vendors.

The Risk level change event does not prescribe what to do, it just augments different security events into the Risk level change event. The question is do we need to have an event that factors other CAEP events to come up with Low/Medium/High or a Tx can just use the existing CAEP events. If there are other events that Risk level change is factoring, can we just add those events as stand-alone events to the CAEP spec?

appsdesh · 2024-11-05T20:15:01Z

#200

The Risk level change event can be used by implementers as a "catch all" event. For example, an receiver could decide to use Risk level change instead of implementing the CAEP events. If we have a Risk level change event, which is prescriptive, we'd allow implementers to go the easy route and implement ONLY Risk level change event. Is that a behavior we want to encourage?
As we discussed today CAEP events are descriptive, while Risk event is prescriptive. I don't see prescriptive and descriptive events coexist in the same spec. My suggestion is to wait with adding this event to the final spec.

This event is the same as any other event in the CAEP spec, and it is NO WAY prescriptive. The Reciver may decide to do NOTHING on the risk being HIGH, same way as they chose to ingnore existing Session Revoked or Credential Change events.
Whether and how organizations respond to any of the CAEP events is completely dependent on their risk tolerance levels. The event can describe what led to Tx raising or reducing the risk and description around that, this is very flexible mechanism to share the risks with vendors.

The Risk level change event does not prescribe what to do, it just augments different security events into the Risk level change event. The question is do we need to have an event that factors other CAEP events to come up with Low/Medium/High or a Tx can just use the existing CAEP events. If there are other events that Risk level change is factoring, can we just add those events as stand-alone events to the CAEP spec?

As discussed in the call, risk indicators are a function of the Tx maturity. Risk calculations are outside the scope of this specification. Risk may encompass things described outside CAEP and RISK specs. You are free to propose any new events that describe your usecases.

This event is standalone and represents risk as a first-class object to be shared with the co-operating parties. There is no implicit dependency on presence or absence of other events.

FragLegs · 2024-11-25T21:45:22Z

openid-caep-1_0.md

+### Event Specific Claims {#risk-level-change-event-specific-claims}
+
+risk_reason
+: REQUIRED, JSON string indicates the reason that contributed to the risk level changes by the Transmitter.


Suggested change

: REQUIRED, JSON string indicates the reason that contributed to the risk level changes by the Transmitter.

: REQUIRED, JSON object: a localizable message indicating the reason that contributed to the risk level changes by the Transmitter. The object MUST contain one or more key/value pairs, with a BCP47 {{RFC5646}} language tag as the key and the locale-specific administrative message as the value.

Why is this REQUIRED? It seems like it ought to be an optional field

risk_reason is marked required since, without this, there is no benefit for the receiver to process such an event. Transmitter updating the risk will be a black box process and hinder the visibility.

Also, it may not make sense to localize the message as this is intended for the receiver to make sense why Tx decided to update the risk. This could become ENUM between Tx-Rx. (Happy to update the description if that clarifies)

User-visible messages would be part of reason_admin and reason_user which could be localized

openid-caep-1_0.md

FragLegs · 2024-11-25T21:47:12Z

openid-caep-1_0.md

+: REQUIRED, JSON string indicates the current level of the risk for the subject. Value MUST be one of LOW, MEDIUM, HIGH
+
+previous_level 
+: OPTIONAL, JSON string indicates the previously known level of the risk for the subject. Value MUST be one of LOW, MEDIUM, HIGH. If the Transmitter omits this value, the Receiver MUST assume that the previous assurance level is unknown to the Transmitter.


Suggested change

: OPTIONAL, JSON string indicates the previously known level of the risk for the subject. Value MUST be one of LOW, MEDIUM, HIGH. If the Transmitter omits this value, the Receiver MUST assume that the previous assurance level is unknown to the Transmitter.

: OPTIONAL, string: indicates the previously known level of the risk for the subject. Value MUST be one of LOW, MEDIUM, HIGH. If the Transmitter omits this value, the Receiver MUST assume that the previous assurance level is unknown to the Transmitter.

I think the second statement ought to be a SHOULD:

If the Transmitter omits this value, the Receiver SHOULD assume that the previous assurance level is unknown to the Transmitter.

Following the same convention of the other CAEP events

FragLegs · 2024-12-03T18:06:41Z

openid-caep-1_0.md

+         "current_level": "LOW",
+         "previous_level": "HIGH",
+         "event_timestamp": 1615304991643,
+         "risk_reason":{


This should be a string, not be a dict of language to string

FragLegs · 2024-12-03T18:13:16Z

openid-caep-1_0.md

+    },
+    "events":{
+      "https://schemas.openid.net/secevent/caep/event-type/risk-level-change":{
+         "current_level": "LOW",


Can we add "principal" to the example?

Risk level change event

4287686

Risk level change event

appsdesh requested a review from a team as a code owner September 20, 2024 21:52

FragLegs requested changes Sep 24, 2024

View reviewed changes

openid-caep-1_0.md Outdated Show resolved Hide resolved

openid-caep-1_0.md Outdated Show resolved Hide resolved

openid-caep-1_0.md Show resolved Hide resolved

Update openid-caep-1_0.md

5499837

Co-authored-by: Shayne Miel (he/him) <[email protected]>

ysarig75 reviewed Nov 5, 2024

View reviewed changes

openid-caep-1_0.md Outdated Show resolved Hide resolved

ysarig75 reviewed Nov 5, 2024

View reviewed changes

Added risk_reason

4dc0213

FragLegs reviewed Nov 25, 2024

View reviewed changes

Shayne's review

5376434

FragLegs reviewed Dec 3, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

New CAEP event - Risk level change event #205

New CAEP event - Risk level change event #205

appsdesh commented Sep 20, 2024

ysarig75 Nov 5, 2024 •

edited

Loading

appsdesh Nov 15, 2024

tulshi Nov 19, 2024

appbugs commented Nov 5, 2024

appsdesh commented Nov 5, 2024 •

edited

Loading

appbugs commented Nov 5, 2024 •

edited

Loading

appsdesh commented Nov 5, 2024 •

edited

Loading

FragLegs Nov 25, 2024

FragLegs Nov 25, 2024

appsdesh Nov 26, 2024

FragLegs Nov 25, 2024

FragLegs Nov 25, 2024

appsdesh Nov 26, 2024

FragLegs Dec 3, 2024

FragLegs Dec 3, 2024

	: REQUIRED, JSON string indicates the reason that contributed to the risk level changes by the Transmitter.
	: REQUIRED, JSON object: a localizable message indicating the reason that contributed to the risk level changes by the Transmitter. The object MUST contain one or more key/value pairs, with a BCP47 {{RFC5646}} language tag as the key and the locale-specific administrative message as the value.

	: OPTIONAL, JSON string indicates the previously known level of the risk for the subject. Value MUST be one of LOW, MEDIUM, HIGH. If the Transmitter omits this value, the Receiver MUST assume that the previous assurance level is unknown to the Transmitter.
	: OPTIONAL, string: indicates the previously known level of the risk for the subject. Value MUST be one of LOW, MEDIUM, HIGH. If the Transmitter omits this value, the Receiver MUST assume that the previous assurance level is unknown to the Transmitter.

New CAEP event - Risk level change event #205

Are you sure you want to change the base?

New CAEP event - Risk level change event #205

Conversation

appsdesh commented Sep 20, 2024

ysarig75 Nov 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

appbugs commented Nov 5, 2024

appsdesh commented Nov 5, 2024 • edited Loading

appbugs commented Nov 5, 2024 • edited Loading

appsdesh commented Nov 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ysarig75 Nov 5, 2024 •

edited

Loading

appsdesh commented Nov 5, 2024 •

edited

Loading

appbugs commented Nov 5, 2024 •

edited

Loading

appsdesh commented Nov 5, 2024 •

edited

Loading