Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

New CAEP event - Risk level change event #205

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

New CAEP event - Risk level change event #205

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4287686
Risk level change event
apoorvadeshpande-okta Sep 20, 2024
5499837
Update openid-caep-1_0.md
appsdesh Nov 5, 2024
4dc0213
Added risk_reason
appsdesh Nov 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 55 additions & 0 deletions openid-caep-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -822,6 +822,61 @@ The following is a non-normative example of a Session Presented event:
}}
~~~

## Risk Level Change {#risk-level-change}
Event Type URI:

`https://schemas.openid.net/secevent/caep/event-type/risk-level-change`

A vendor may deploy mechanisms to gather and analyze various signals associated with subjects such as users, devices, etc. These signals, which can originate from diverse channels and methods beyond the scope of this event description, are processed to derive an abstracted risk level representing the subject's current threat status.

The Risk Level Change event is employed by the Transmitter to communicate any modifications in a subject's assessed risk level at the time indicated by the `event_timestamp` field in the Risk Level Change event. The Transmitter may generate this event to indicate:

* User's risk has changed due to potential suspecious access from unknown destination, password compromise, addition of strong authenticator or other reasons.
* Device's risk has changed due to installation of unapproved software, connection to insecure pheripheral device, encryption of data or other reasons.
* Any other subject's risk changes due to variety of reasons.


### Event Specific Claims {#risk-level-change-event-specific-claims}
The following optional claims MAY be present in a Session Presented event:
appsdesh marked this conversation as resolved.
Show resolved Hide resolved

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add a field that describes the type of risk? You mention in your example user risk and device risk. What if we had a field called risk_type whose values were an enum:

  • DEVICE
  • USER
  • ACCOUNT
  • OTHER

There may be other values that we should include in this enum as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@FragLegs I thought we could drive the type using the subject claim. With a single enum it would be hard to flag a single risk event if it applies to more than 1 entity like USER + DEVICE etc.

reason_admin
appsdesh marked this conversation as resolved.
Show resolved Hide resolved
: 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
Copy link

@ysarig75 ysarig75 Nov 5, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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.


### Examples {#session-presented-examples}
The following is a non-normative example of a Session Presented event:

~~~json
{
"iss": "https://idp.example.com/123456789/",
"jti": "24c63fb56e5a2d77a6b512616ca9fa24",
"iat": 1615305159,
"aud": "https://sp.example.com/caep",
"txn": 8675309,
"sub_id": {
"format": "iss_sub",
"iss": "https://idp.example.com/3456789/",
"sub": "[email protected]"
},
"events":{
"https://schemas.openid.net/secevent/caep/event-type/risk-level-change":{
"current_level": "LOW",
"previous_level": "HIGH",
"event_timestamp": 1615304991643,
"reason_admin":{
"en": "User's password detected in the pwned password dump"
}
}
}
}
~~~

# Security Considerations
Any implementations of events described in this document SHOULD comply with the Shared Signals Framework {{SSF}}. Exchanging events described herein without complying with the Shared Signals Framework {{SSF}} may result in security issues.

Expand Down
Loading