Skip to content

IdLE.Provider.Intune 1 (read-only) - Device.List capability + normalized device context schema #215

Description

@blindzero

Problem Statement

IdLE must support BYOD scenarios where personal devices are enrolled in Microsoft Intune. For safe policies and human-in-the-loop procedures, workflows/hosts need a reliable way to discover device inventory for an identity.

Today IdLE lacks:

  • an Intune provider implementation
  • a read-only capability to list devices for an identity
  • a normalized, safe, serializable schema for device inventory stored in Request.Context

Without a standardized read-only device inventory capability, BYOD-related orchestration is host-specific, hard to test, and hard to audit.

Proposed Solution

1) Introduce Intune provider module (read-only)

Create provider module:

  • Module: IdLE.Provider.Intune

Implement capability (v1):

  • IdLE.Device.List (read-only)
    • Input: identity keys from request (UPN and/or Entra object id, as available)
    • Output: list of Intune managed devices associated with that identity

The provider MUST remain read-only in this issue (no destructive actions).

2) Define canonical device context snapshot location + schema

Define where and how device inventory is stored:

  • Location: Request.Context.Devices.Intune.ManagedDevices[]

Define and document the normalized schema. Requirements:

  • Safe to store in plan artifacts and logs (no secrets, no tokens, no session data)
  • Serializable and stable
  • Includes enough non-sensitive metadata to help operators identify devices (human-friendly)
  • Size-bounded (avoid unbounded payloads)

Example fields (illustrative; finalize in this issue):

  • Id (provider device id)
  • DisplayName
  • Platform (Android/iOS/Windows/macOS)
  • Model (if available)
  • SerialNumber (if considered acceptable; otherwise omit)
  • LastCheckIn (if available)
  • ComplianceState / ManagementState (if safe and available)

3) Testing strategy

  • Unit tests: mock Intune provider responses; validate normalized output and schema constraints.
  • Provider contract tests: define expected behavior for IdLE.Device.List (inputs, outputs, error behavior).

Alternatives Considered

  1. Host-only device inventory
  • Reduces portability and consistency; duplicates logic across hosts.
  1. Store raw provider objects in context
  • Unsafe (non-serializable, potentially sensitive), not stable for plan export.

Impact

  • Adds a new provider module and documentation footprint.
  • Enables consistent BYOD device discovery and audit-friendly device context.

Dependencies

  • Requires the request schema split: Request.Intent / Request.Context.
  • Requires plan snapshot/export rules that safely include Request.Context.

Definition of Done (Step-0-Ready / Agent-Safe)

Design / Contracts

  • Define capability contract for IdLE.Device.List (inputs, output shape, error behavior).
  • Define and document canonical device context location:
    • Request.Context.Devices.Intune.ManagedDevices[]
  • Define normalized schema and safety rules (no secrets, serializable, size-bounded).

Implementation

  • Implement IdLE.Provider.Intune with capability IdLE.Device.List.
  • Implement normalization mapping to the canonical schema.
  • Ensure output can be safely placed into Request.Context and included in plan snapshots.

Tests (Pester)

  • Unit test: IdLE.Device.List returns normalized device list.
  • Unit test: schema validation rejects unsafe fields/types (per snapshot rules).
  • Contract test: capability is exposed and behaves as specified.

Docs / Examples

  • Provider documentation for IdLE.Provider.Intune (read-only):
    • authentication approach
    • required permissions/scopes
    • usage example for listing devices and populating Request.Context

Non-Goals (explicit)

  • No device retire/wipe actions in this issue.
  • No interactive UI behavior in IdLE.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions