Repository navigation
[CAEP] device management change is not captured in the existing events #131
Description
In the world of device management, the device management signal is very important. It does not directly map to the device compliance status.
Device compliance status could be the result of evaluating the compliance policy (output of a policy decision engine). In certain cases, device management status maybe needed to evaluate policies (input to the policy decision engine).
Given that a managed device may or may not be compliant and this information is important in the continuous access evaluation.
I am proposing following change to the device compliance CAEP event
Option 1 - Management status via new keys
- Mark existing
current_statusandprevious_statusas optional to avoid mandating compliance status - Add additional 2 keys
current_management_statusandprevious_management_statusas OPTIONAL fields to communicate current and previous management status.
Pros -
- Transmitter is able to combine compliance and management changes in the same event, helpful in the scale.
Cons -
- Increased event size in the case when both compliance and management status is conveyed
Option 2 - Extend the values of existing keys
- Allow new values in the
current_statusandprevious_statuskeys
** managed
** not-managed
Pros -
- No size increase for the event, reusing the keys
- Transmitter is able to combine compliance and management changes in the same event, helpful in the scale.
Cons -
- May not be able to represent management change and compliance change together, due to key reuse
Option 3 - A new event called device management change
Define a new event as device management change to solely communicate device management change. This new event will have current_status and previous_status keys and values defined in the Option 2
Pros -
- Cleaner separation of two constructs
Cons -
- A new event to fire and consume for Tx/Rx pair
Activity
[-]CAEP device management change is not captured in the existing events[/-][+][CAEP] device management change is not captured in the existing events[/+]timcappalli commentedon Dec 6, 2023
I'd prefer option 3. Device management status and device compliance are very different signals.
Device management status is often one piece of context that is used to determine device compliance.
appsdesh commentedon Dec 6, 2023
I agree with @timcappalli.
My preference is in the following order -
Option 3 (Most favorable)
Option 1
Option 2 (least)
tulshi commentedon Apr 20, 2024
I agree that option 3 is a good one, although I'd like to call the event "device management status" (IMO we should stop using "change" in event names, because all events indicate some change). I feel the two events "device compliance" and "device management" are different, so having both of them co-exist is fine.
tulshi commentedon Nov 17, 2025
@appsdesh could you please verify if this issue is still current?
appsdesh commentedon Nov 18, 2025
We can close it, I see that most of the device management vendors have onboarded to the compliance change event as compliance policies probably cover the management aspects
ysarig75 commentedon Apr 14, 2026
Reopening the issue per the discussion we had in the 04/14/26 meeting: https://hackmd.io/@oidf-wg-sse/wg-meeting-20260414
martingalloar commentedon May 4, 2026
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:
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.
ysarig75 commentedon May 8, 2026
@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_statusbut it doesn't replace "unmanaged".