scim.cloud

Device Schema

Schema extensions for provisioning devices, not just users.

The SCIM core schema was designed for provisioning users. RFC 9944 adds schemas for provisioning devices, and for carrying the bootstrapping material a device needs to get onto a network. It defines two new resource types plus a family of extensions, one per underlying onboarding system — Wi-Fi Easy Connect, FIDO Device Onboard vouchers, Bluetooth Low Energy pairing, MAC Authenticated Bypass, and Zigbee.

Unlike RFC 9865 and RFC 9967, this document does not update RFC 7643 or RFC 7644. It is purely additive: new resource types and new schema URIs, using the extension model the core schema already provides.

Resource types

Device urn:ietf:params:scim:schemas:core:2.0:Device
A provisionable device. Carries the core attributes below, and one or more bootstrapping extensions describing how the device is onboarded.
EndpointApp urn:ietf:params:scim:schemas:core:2.0:EndpointApp
An application permitted to communicate with devices. Devices reference endpoint applications through the application endpoint extension, which is how a deployment expresses which app may talk to which device.

Core device attributes

Attribute Required Mutability Description
displayName readWrite Human-readable name, suitable for showing to end users. Not case sensitive, no uniqueness constraint.
active readWrite Whether the device is intended to be operational. Attempts to control or reach a device with active false may be rejected.
mudUrl readWrite URL of the device's Manufacturer Usage Description file (RFC 8520). Case sensitive.
groups readOnly Group membership, in the same form as the groups attribute in RFC 7643 §4.1.2.

All four sit alongside the usual common attributes — id, externalId, and meta — described in the object model. A minimal Device resource:

Device resource
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Device"],
  "id": "e9e30dba-f08f-4109-8486-d5c6a3316111",
  "displayName": "BLE Heart Monitor",
  "active": true,
  "meta": {
    "resourceType": "Device",
    "created": "2022-01-23T04:56:22Z",
    "lastModified": "2022-05-13T04:42:34Z",
    "version": "W\/\"a330bc54f0671c9\"",
    "location": "https://example.com/v2/Devices/e9e30dba-f08f-4109-8486-d5c6a3316111"
  }
}

Bootstrapping extensions

Each onboarding system gets its own extension schema, keyed by URI in the resource just like any other SCIM extension. A device lists every schema it conforms to in schemas.

Extension Schema URI
Bluetooth Low Energy …:extension:ble:2.0:Device
Wi-Fi Easy Connect (DPP) …:extension:dpp:2.0:Device
Ethernet MAB …:extension:ethernet-mab:2.0:Device
FIDO Device Onboard …:extension:fido-device-onboard:2.0:Device
Zigbee …:extension:zigbee:2.0:Device
Application endpoints …:extension:endpointAppsExt:2.0:Device

Every URI above is prefixed urn:ietf:params:scim:schemas. BLE additionally defines four pairing-method extensions — pairingJustWorks, pairingPassKey, pairingOOB, and pairingNull — selected according to how the device authenticates during pairing.

A device onboarded with Wi-Fi Easy Connect carries its bootstrapping key, MAC address, and the class/channel pairs it can be reached on:

Device with the Wi-Fi Easy Connect extension
{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:Device",
    "urn:ietf:params:scim:schemas:extension:dpp:2.0:Device"
  ],
  "id": "e9e30dba-f08f-4109-8486-d5c6a3316111",
  "displayName": "WiFi Heart Monitor",
  "active": true,
  "urn:ietf:params:scim:schemas:extension:dpp:2.0:Device": {
    "dppVersion": 2,
    "bootstrappingMethod": ["QR"],
    "bootstrapKey": "MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADURzxmttZoIRIPWGoQMV00XHWCAQIhXruVWOz0NjlkIA=",
    "deviceMacAddress": "2C:54:91:88:C9:F2",
    "classChannel": ["81/1", "115/36"],
    "serialNumber": "4774LH2b4044"
  },
  "meta": {
    "resourceType": "Device",
    "created": "2022-01-23T04:56:22Z",
    "lastModified": "2022-05-13T04:42:34Z",
    "version": "W\/\"a330bc54f0671c9\""
  }
}
Bootstrapping material is sensitive

These extensions carry keys, passcodes, and vouchers. RFC 9944 §8 treats unauthorized device creation as the central threat — a device added by an attacker may be granted network access — and several attributes are defined write-only, never returned in a response, for exactly this reason.