WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Meet declarative device management

Meet declarative device management

App StoreDistribution & MarketingBusiness & Education
Watch original video

Highlight

Apple has added declarative device management to the existing MDM protocol, allowing users of iOS 15 and iPadOS 15 to register devices to locally determine policies, apply configurations, and proactively report changes to the server through status channels.

Core Content

When large organizations manage equipment, what they fear most is the back-and-forth questions.

The policy of a device has changed, and the server needs to send commands. After the device is executed, the server will continue to query the status. When thousands of devices are updated together, these round-trip requests pile up on the server. Administrators who want to know whether the device has met the password policy can only wait for the next round of polling.

The answer Apple gave in this session is Declarative Device Management. The server no longer splits each operation into commands and issues them, but instead writes the organization’s desired policies into statements and sends them to the device.

After the device obtains the statement, it determines the current status locally. If the status matches, the policy is applied. If the status changes, it is recalculated. The server does not need to keep asking the device, but only subscribes to the status items it cares about.

This change directly addresses two pain points.

First, the policy judgment is close to the device. The device knows its system version, hardware model, whether the statement has been applied, and can handle status changes immediately.

Second, status reports become proactive push. The device reports key changes through the status channel, and the server only receives subscriptions and declares status changes.

Apple does not require MDM vendors to replace the protocol. Declarative capabilities are integrated into the existing MDM protocol and continue to use existing mechanisms such as registration, logout, HTTP transmission, device authentication, and user authentication.

Detailed Content

Statement: Write organizational policies as JSON

(03:16) Declaration represents the policies that the organization wants the device to enforce, such as accounts, settings, and restrictions. Its structure is similar to profile payload, and JSON object is used for network transmission instead of plist.

All declarations have three required attributes:Type、Identifier、ServerToken。PayloadStores data related to the declared type.

{
  "Type": "passcode configuration",
  "Identifier": "4D2A0F90-1E1B-4B73-9B8D-8C4D6D1C0F11",
  "ServerToken": "revision-1",
  "Payload": {
    "Policy": "device passcode restrictions"
  }
}

Key points:

  • TypeDefine which policy this statement represents. Session uses password configuration as an example.
  • IdentifierUniquely identifies this claim among all claims received by the device, usually a UUID string.
  • ServerTokenRepresents a revised version of this statement, the sameIdentifierUse a different value for each revision of .
  • PayloadTo store specific policy data, different declaration types will have different fields.

Statements are divided into four categories: configuration, asset, activation, and management. Together, these four categories form a device-locally executable policy model.

Configuration and resources: Separate public policies from user data

(05:02) Configuration represents the policy to be applied to the device and is similar to the existing MDM profile payload. Accounts, settings, and restrictions can all be made into configuration statements.

Assets represent auxiliary data that need to be referenced for configuration. Large files can be placed behind a URL for devices to download from an MDM server or content delivery network (CDN). User name, email, account password, and certificate can also be independently generated into resource declarations.

{
  "Type": "user identity asset",
  "Identifier": "7B52C2F5-A5D8-46BC-9D31-8C02C4A69A22",
  "ServerToken": "revision-3",
  "Payload": {
    "FullName": "A Managed User",
    "EmailAddress": "[email protected]"
  }
}

Key points:

  • TypeIndicates that this is a user identity resource, and session uses it to describe data such as user contact information.
  • IdentifierAllow configuration to reference this resource.
  • ServerTokenLet the device know if the resource is updated.
  • PayloadSave user-related data to avoid copying each user’s customized data into multiple configurations.

(06:41) Resources and configurations have a one-to-many relationship. A user credentials resource can be referenced by multiple account configurations. When the credentials are updated, only the resource is updated; the configuration that references it remains unchanged. The device updates the policy based on the new resources.

Activation: Let the device atomically apply a set of configurations

(07:38) Activation represents a set of configurations that the device wants to apply atomically. The device only applies the entire group policy when the configuration and reference resources in the group are valid. If any item is invalid, activation fails.

An activation can also contain a predicate. The device uses it to determine whether the activation state is active. session gave two examples: only taking effect on iPad, or only taking effect on specific system versions.

{
  "Type": "simple activation",
  "Identifier": "0DCC1890-93AA-4F99-81D5-0F7B2E056D5D",
  "ServerToken": "revision-1",
  "Payload": {
    "Configurations": [
      "4D2A0F90-1E1B-4B73-9B8D-8C4D6D1C0F11",
      "C4712A8E-03F5-4B28-A7F5-35805E4D2F07"
    ],
    "Predicate": "device type is iPad"
  }
}

Key points:

  • TypeIndicates that this is a simple activation statement.
  • IdentifierIdentifies this activation statement.
  • ConfigurationsSave configuration identifiers to be applied together.
  • PredicateDecentralize business rules to the device, and they will be re-evaluated after the device status changes.

(09:16) When the device status changes, the activation predicate will be re-evaluated without server intervention. New policies will be applied and expired policies will be removed. Without a predicate, the device always processes the configuration referenced by the activation.

Status channel: The device proactively reports changes

(10:23) The declared status and the actual status of the device may be inconsistent. Password policy is a typical scenario: the policy has been issued, but the user has not yet set a new password that meets the requirements.

Status channels are used to fill this visibility gap. The server subscribes to specific status items, and the device first sends an initial report, and then only sends incremental reports when the subscription items change.

{
  "Type": "status subscription configuration",
  "Identifier": "F2E64D28-4553-49E6-9380-8D7B50C4630A",
  "ServerToken": "revision-1",
  "Payload": {
    "StatusItems": [
      "device.operating-system.version",
      "device.model.family",
      "device.model.identifier"
    ]
  }
}

Key points:

  • TypeIndicates that this is a status subscription configuration.
  • StatusItemsList the state key-paths that the server cares about.
  • device.operating-system.versionCorresponding device system version.
  • device.model.familyanddevice.model.identifierCorresponding device type and model.

(11:44) Status reporting is incremental. After a device is upgraded from iOS 14.5 to iOS 15, only the system version change item needs to be reported. State changes that state whether they have been applied are reported automatically and the server does not need to subscribe.

Scalability: Devices and servers declare capabilities to each other

(12:48) Declarative management puts extensibility into the data model. Devices and servers will release supported capabilities to each other, avoiding hard-coded system versions or hardware dependencies on the server.

Server capabilities are sent to devices through administrative claims. Device capabilities are sent to the server through status items, and will be re-reported when capabilities change.

{
  "Type": "server capabilities management",
  "Identifier": "A414E797-2ED0-4E76-9B6A-7F634BA18474",
  "ServerToken": "revision-2",
  "Payload": {
    "SupportedFeatures": [
      "declarative management feature"
    ]
  }
}

Key points:

  • TypeIndicates that this is a server capability management statement.
  • SupportedFeaturesIndicates the protocol capabilities supported by the server.
  • After the server is upgraded, new capabilities will be synchronized to the device just like other claims.
  • Changes in device capabilities are reported to the server as status items.

(13:31) The client also publishes supported payloads, listing the claims and status items it supports. After the server obtains this information, it can immediately use the new features and payload of the device.

MDM integration: launch and sync with existing protocols

(14:17) Declarative management is integrated into existing MDM protocols. Registration, logout, HTTP transmission, device authentication and user authentication continue to use the existing mechanisms. Claims and status channels can coexist with existing MDM commands and profiles.

Starting declarative management requires newDeclarativeManagementMDM command. This command has two functions: activates declarative management on the device; carries a synchronization token and starts the synchronization process when needed.

{
  "Command": {
    "RequestType": "DeclarativeManagement",
    "SynchronizationTokens": {
      "DeclarationsToken": "server-token-value"
    }
  }
}

Key points:

  • RequestTypeuseDeclarativeManagement, corresponding to the new MDM command in the session.
  • The device activates declarative management after receiving the command.
  • It cannot be turned off after activation, but the server can remove all statements so that declarative management no longer produces actual policy effects.
  • SynchronizationTokensCan be used to trigger synchronization processes.

(16:16) The new device will be used when synchronizing claims and sending status reportsDeclarativeManagement CheckIn request type。

{
  "MessageType": "DeclarativeManagement",
  "Endpoint": "declaration-items"
}

Key points:

  • MessageTypeset toDeclarativeManagement。
  • Endpointset todeclaration-items, the device requests a declaration manifest.
  • The server returns a manifest listing all declaredIdentifierandServerToken。
  • For new or changed claims, the device initiates a CheckIn request using the unique resource path to obtain a single claim JSON.

(17:22) Migration can be done gradually. Apple provides a declaration type that installs profiles as configurations. The server can first pass the existing profile to the device through the URL, and let the device install it using a declarative process.

{
  "Type": "profile configuration",
  "Identifier": "2B1B2C10-88D5-4F8B-A2D7-5F5F29D93F31",
  "ServerToken": "revision-1",
  "Payload": {
    "ProfileURL": "https://mdm.example.com/profiles/account.mobileconfig"
  }
}

Key points:

  • TypeIndicates that this is a profile configuration statement.
  • ProfileURLPoint to an existing profile.
  • After activating this configuration, the device obtains the profile from the URL and installs it.
  • This approach allows MDM vendors to migrate policy logic first without having to rewrite the entire profile workflow at once.

iOS 15 first batch of support scope

(19:52) iOS 15 and iPadOS 15 are the first to support declarative management. It only applies to the User Enrollment type, including the new onboarding flow in iOS 15 and the existing flow in iOS 13.

Platform: iOS 15, iPadOS 15
Enrollment: User Enrollment
Configurations: account, passcode, profile, status subscription
Activations: simple activation with optional predicate
Assets: user identity, user credential
Management: organization details, server capabilities
Status: declaration status, device hardware model, operating system

Key points:

  • Account and password configuration cover the corresponding MDM account and passcode profile payload.
  • profile configuration can install the complete set of profiles supported by MDM.
  • The status subscription configuration is used to declare which status items the server wants to receive.
  • Simple activation can apply the configuration list atomically and can bring predicate.
  • Each claim has its own status item, and changes in claim status are automatically reported.

Core Takeaways

  1. What to do: Add a “Status Subscription Template” to the MDM console. Why it’s worth doing: Status channel allows the server to only subscribe to the status items it cares about, reducing polling. How ​​to start: First generate status subscription configuration, subscribedevice.operating-system.version、device.model.family、device.model.identifier, write the device initial report and incremental report to the device details page.

  2. What to do: Migrate password policy from traditional profiles to declarative configuration. Why it’s worth doing: Password policies often require user action, and declaring status lets the server know whether the policy has been applied. How ​​to start: Generate a configuration declaration for the password policy, then use simple activation to reference it and listen for changes in the corresponding declaration status.

  3. What to do: Configure different policy packages for iPad and different system versions. Why it’s worth doing: The activation predicate allows the device to locally determine whether the policy is effective, and the server can issue multiple sets of statements at one time. How ​​to start: Split the policy into multiple configurations, and use activation predicate to express device type or system version conditions.

  4. What to do: Split the user identity and credentials from the account configuration into assets. Why it’s worth doing: An asset can be referenced by multiple configurations. When user information is updated, only the asset is synchronized. How ​​to get started: Create a user identity asset and a user credential asset and let the account configuration reference them by identifier.

  5. What to do: First wrap the existing profile with profile configuration. Why it’s worth it: Profile configuration allows teams to migrate the installation and activation process to declarative management while retaining existing profiles. How ​​to start: Put existing.mobileconfigPut it in the server URL, generate profile configuration, and then use activation to activate it.

Comments

GitHub Issues · utterances