-
Notifications
You must be signed in to change notification settings - Fork 14
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.
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
New CAEP event - Risk level change event #205
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -822,6 +822,60 @@ 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} | ||
|
||
risk_reason | ||
: REQUIRED, JSON string indicates the reason that contributed to the risk level changes by the Transmitter. | ||
|
||
current_level | ||
: REQUIRED, JSON string indicates the current level of the risk for the subject. Value MUST be one of LOW, MEDIUM, HIGH | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Assurance level change uses 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 |
||
|
||
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 {#risk-level-change-examples} | ||
The following is a non-normative example of a Risk Level Change 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, | ||
"risk_reason":{ | ||
"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. | ||
|
||
|
There was a problem hiding this comment.
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:There may be other values that we should include in this enum as well.
There was a problem hiding this comment.
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.