From github at oidf.org Mon May 4 20:42:15 2026 From: github at oidf.org (github at oidf.org) Date: Mon, 4 May 2026 20:42:15 +0000 Subject: [Openid-specs-risc] openid/sharedsignals: Comment created on issue 131 Message-ID: openid/sharedsignals event Issue Comment created on issue 131 Issue Title: [CAEP] device management change is not captured in the existing events https://github.com/openid/sharedsignals/issues/131 Comment: I've attended some of latest calls and listened to the conversation, although not very vocally participating. I do agree there's a gap that can be filled in, and understand the reasoning. As others suggested I believe adding "unmanaged" as a potential state can be confusing as it doesn't necesarily directly reflect a potential state from a pure "device compliance" standpoint. If I think about potential states, the main combinations can be: | Device Management | Device Compliance | Example scenario | |--------|--------|--------| | Unmanaged | Unknown | Default state for personal, non-corporate devices or devices not enrolled into MDM | | Unmanaged | Compliant | Rare state; compliance is usually not possible to determine without management | | Unmanaged | Non-Compliant | Rare state; compliance is usually not possible to determine without management | | Managed | Unknown | Device is enrolled into MDM but has not yet reported compliance status | | Managed | Compliant | Device is enrolled into MDM and meeting all policies; Ideal state | | Managed | Non-Compliant | Device is enrolled into MDM but is failing a policy and identified as non-compliant | I do see value on adding "unknown" to the device compliance event and rather go with that semantics for the device compliance event instead of introducing an "unmanaged" state as proposed in #329. I've also added to the PR a separate comment about consistency regardless of the semantic we decide to use. -------------- next part -------------- An HTML attachment was scrubbed... URL: From github at oidf.org Thu May 7 16:22:55 2026 From: github at oidf.org (github at oidf.org) Date: Thu, 7 May 2026 16:22:55 +0000 Subject: [Openid-specs-risc] openid/sharedsignals: New Issue opened Message-ID: openid/sharedsignals event Issue opened Issue Title: Add `UNKNOWN` as a valid value for `current_level` / `previous_level` in `risk-level-change` https://github.com/openid/sharedsignals/issues/330 ### Context The [risk-level-change event](https://openid.github.io/sharedsignals/openid-caep-specification-1_0.html#name-risk-level-change), introduced in #200, defines `current_level` as REQUIRED with values restricted to `LOW`, `MEDIUM`, or `HIGH`. There is no way for a Transmitter to communicate "I do not currently have enough signal to assess this subject's risk." This conflates two distinct states: - **HIGH:** the Transmitter has high confidence the subject is risky (e.g., suspected non-authorized user, compromised credential, malicious software). - **No assessment available:** the Transmitter previously had a risk level but signal has gone stale, the subject is idle, or upstream data sources are unavailable. Today, Transmitters facing the second case must choose between three bad options: 1. Emit `HIGH` (fail-closed). This is semantically incorrect, it overstates the Transmitter's confidence and can drive unwarranted remediations like forced re-auth or session revocation. 2. Continue reporting the last known level. The Receiver has no way to know the assessment is stale. 3. Stop emitting events. The Receiver cannot distinguish "signal lost" from "no change." ### Proposal Add `UNKNOWN` as a permitted value for `current_level` and `previous_level`. - `current_level: UNKNOWN` indicates the Transmitter does not currently have sufficient signal to assess the subject's risk. - `previous_level: UNKNOWN` is semantically equivalent to omission (already defined as "unknown to the Transmitter") but allows explicit transitions, e.g., `UNKNOWN -> LOW` when signal is re-established. ### Example Scenarios - **Continuous behavioral authentication:** A Transmitter assessing a user via behavioral biometrics loses signal when the user goes idle or the agent disconnects. Transitioning to `UNKNOWN` lets Receivers apply their own policy (e.g., step-up on next sensitive action) without the Transmitter falsely asserting risk. - **Device posture:** A device's compliance agent stops checking in. The Transmitter can emit `UNKNOWN` rather than guess, letting Receivers decide whether absence of signal warrants remediation. - **Upstream provider outage:** A Transmitter ingesting risk from a third-party provider can communicate signal loss without retracting prior assessments or fabricating a level. ### Event-Specific Claims (updated) 1. `current_level` - REQUIRED. Value MUST be one of `LOW`, `MEDIUM`, `HIGH`, `UNKNOWN`. 2. `previous_level` - OPTIONAL. Value MUST be one of `LOW`, `MEDIUM`, `HIGH`, `UNKNOWN`. Omission continues to mean the previous level is unknown to the Transmitter. ### Example ```json { "events": { "https://schemas.openid.net/secevent/caep/event-type/risk-level-change": { "subject": { "user": { "format": "iss_sub", "iss": "...", "sub": "..." } }, "current_level": "UNKNOWN", "previous_level": "LOW", "risk_reason": "SIGNAL_UNAVAILABLE", "event_timestamp": 1615304991 } } } ``` ### Considerations - Receivers MUST NOT treat `UNKNOWN` as ordered relative to `LOW`/`MEDIUM`/`HIGH`; it is an absence-of-assessment state, not a level on the risk scale. - Receivers SHOULD apply local policy to decide how to react to `UNKNOWN` (ignore, step-up, fall back to last known, etc.). --- *Disclosure / motivation: This proposal comes from operating a continuous behavioral authentication transmitter ([Twosense](https://twosense.ai)) where signal availability is inherently intermittent (user idle, agent disconnect, device sleep). The `UNKNOWN` gap is something we hit in production, not a hypothetical.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From github at oidf.org Fri May 8 01:12:43 2026 From: github at oidf.org (github at oidf.org) Date: Fri, 8 May 2026 01:12:43 +0000 Subject: [Openid-specs-risc] openid/sharedsignals: Comment created on issue 131 Message-ID: openid/sharedsignals event Issue Comment created on issue 131 Issue Title: [CAEP] device management change is not captured in the existing events https://github.com/openid/sharedsignals/issues/131 Comment: @martingalloar The main use case for this change is to be able to notify the receiver that the device became unmanaged which mean that they will no longer get device compliance updates about the device. Sending "unknown" instead of "unamanged" doesn't serve the same purpose as it only tells the receiver that the transmitter doesn't know the status of the device **right now** but it is not clear if they will know it in the future. In a nutshell, "unknown" can be added independently from "unmanaged" to `current_status` but it doesn't replace "unmanaged". -------------- next part -------------- An HTML attachment was scrubbed... URL: