New CAEP event - Risk level change event

[appsdesh]

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

[appbugs]

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]

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]

#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]

#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.