<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">

</head>

<body>

openid/sharedsignals event <br>

<br>

Issue opened <br>

Issue Title: New events to represent risk level changes <br>

https://github.com/openid/sharedsignals/issues/200 <br>

<br>

### Context A software 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 to communicate any modifications in a subject's assessed risk level between trusted entities. This event indicates

 whether the risk level has increased, decreased, or remained unchanged since the last assessment. ### Example Scenarios: - Device Risk Assessment - A transmitter initially determines a device's risk-free status, assigning a LOW risk level. During a routine

 health scan, new software is detected. If the vendor assesses this software as legitimate but unauthorized, the risk level may be adjusted from LOW to MEDIUM. Conversely, if the software is identified as malicious and harmful, the risk level may be elevated

 from LOW to HIGH. This event could be used in addition to the device-compliance-change when risk determination may/may not affect compliance policies. - User Risk Assessment - If multiple failed login attempts are detected, the user's risk level may increase

 to MEDIUM. Should it be discovered that the user’s password has been compromised, the risk may escalate to HIGH. Conversely, if the user subsequently resets their password and adopts high-assurance authentication methods, the risk level might be reduced. This

 event could complement events like session-revoked. It could also help drive softer remediations by prompting for MFA, quarantining users, etc. - Tenant Risk Assessment - A tenant is under DDoS or has experienced a similar attack. The vendor wants to share

 this information with other entities. Vendors may decide to ingest risks from various sources/providers, add weights to the risks calculated, and make their own policy determinations. The nonprescriptive nature of this event helps communicate the change in

 posture for the subject and leaves out the actions. ### Risk Level Classification: The transmitter may utilize numeric ranges to categorize risk levels into predefined buckets such as LOW, MEDIUM, or HIGH. This classification helps in standardizing the risk

 communication and facilitating consistent risk management across different systems. ### [Event-Specific Claims](https://openid.github.io/sharedsignals/openid-caep-specification-1_0.html#name-event-specific-claims-4) 1. `current_level` - REQUIRED, JSON string

 indicates the current level of the risk for the subject. Value MUST be one of LOW, MEDIUM, HIGH 2. `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. 3. `ips` - OPTIONAL, The array of IP addresses of the subject as observed by the Transmitter. The value MUST be in the format of an array of strings,

 each one of which represents the RFC 4001 [RFC4001] string representation of an IP address. (NOTE, this can be different from the one observed by the Receiver for the same user because of network translation) ``` { "iss":"https://idp.example.com/3456789/",

 "jti":"07efd930f0977e4fcc1149a733ce7f78", "iat":1615305159, "aud":"https://sp.example2.net/caep", "events":{ "https://schemas.openid.net/secevent/caep/event-type/risk-level-change":{ "subject":{ "user":{ "format":"iss_sub", "iss":"https://idp.example.com/3456789/",

 "sub":"jane.smith@example.com" } }, "current_level":"LOW", "previous_level":"HIGH", "ips":[ "98.87.234.76" ], "event_timestamp":1615304991643, "reason_admin":{ "en":"User's password detected in the pwned password dump" } } } } ``` ### Why CAEP event? - Introducing

 a new profile will be a slow process - CAEP has accommodated events that are not directly related to the session eg. device-compliance-change - https://github.com/openid/sharedsignals/issues/158 proposes all the events to be in the JSON dictionary format,

 rather than in the spec. In the future, all the CAEP, RISC events could be converted to the JSON dictionaries. A use case could be conceptualized by creating profiles of the events.

</body>

</html>