Enrollment (device) API

[jessepeterson]

What should the device API look like?

Some things I'd like to ask of my enrollments:

• "Last seen" time
• Very few details, really (just enrollment ID & serial, really)
• Queryable by serial?
• Support for user enrollments
• Unlock Token request
• Device certificate request (i.e. to later encrypt profiles to device)
• Multiple device query at a time

[w0de]

To be honest we've been quite fine so far without an extended device API. Treating nanomdm as a "dumb" pipe to the MDM protocol - and being diligent about receiving, parsing, and storing webhook'd results - has worked splendidly. The absence of abstraction means our nanomdm client can accurately and easily report on actual status from webhooks alone.

So: I advocate for a very limited API that does not attempt to abstract information that should be properly queried directly from the device. Ie, I agree with "very few details, really."

I don't think the API should abstract workflows that can be handled nanomdm's client + pure MDM. Eg, "device certificate request" - imo the nanomdm client should handle sending the appropriate SCEP payload or already-issued certificate payload, and nanomdm should report (via webhook) accurate command results + accurate results for QueryCertificates (as it does). Same for "last seen:" the client should handle keeping track of this value based on webhooks received.

imo API improvements could be focused on:

• Making the existing endpoints returns more detailed status codes, as we've discussed
• Adding features that allow for querying detailed command status for device(s), and re-sending historical webhooks for same
• Generally improving the webhook experience. Guiding users towards integrating primarily with MDM commands + webhooks in place of abstracted API calls

Also, would love to hear more about what "support for user enrollments" entails

[groob]

Adding features that allow for querying detailed command status for device(s), and re-sending historical webhooks for same

This is something I've wanted to build in MicroMDM as well, so I'll +1
We could have /commands/{id} which returns the status of a specific command and/or /clients/{id}/commands which returns a list of commands for the device.

[jessepeterson]

Also, would love to hear more about what "support for user enrollments" entails

Apologies for the late reply! This is just the notion that Apple MDM 'v1' has two 'styles' of enrollment: device and user with user enrollments dependent on device enrollments. So this was just acknowledging that the API probably needs to reflect the difference between, or perhaps the relationship of, those different enrollments.