Open appsdesh opened 6 months ago
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.
I agree with @timcappalli.
My preference is in the following order - Option 3 (Most favorable) Option 1 Option 2 (least)
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.
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
current_status
andprevious_status
as optional to avoid mandating compliance statuscurrent_management_status
andprevious_management_status
as OPTIONAL fields to communicate current and previous management status.Pros -
Cons -
Option 2 - Extend the values of existing keys
current_status
andprevious_status
keys managed not-managedPros -
Cons -
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
andprevious_status
keys and values defined in the Option 2Pros -
Cons -