I'm curious about suggested workflows for a 3rd party ACME server handling a request for a managed device. Specifically, when the MDM server does not control the ACME server like it likely would when using the ACME payload for the MDM client identity. i.e., an organization with a CA that can distribute client identities using ACME; how should ACME servers validate the request is authorized? The server, of course, would be able to validate that the attestation is valid from Apple, but how would an ACME server validate that the request is authorized for a device? I would assume that the ACME server would use the ClientIdentifier key similarly to a SCEP challenge. And that identifier should be populated in MDM either as a static challenge or dynamically fetched by MDM from the ACME service? Or possibly that the ACME service would need a connection (i.e., through a restful API) to the MDM server to validate it is a device under management and fetch the generated client identifier and therefore determine that the device is authorized to request certs from the enterprise CA? It would be great if the device could attest that it is under management and have an OID for the check-in URL or the APNS topic is registered against. This might eliminate the ACME server's need to authorize a request against the MDM server or help improves the validation of the request etc. In any case, I'm curious on folks' thoughts around this in general :)

Hi Folks, In order to facilitate users enrolling their BYOD devices via the new account-driven user enrollment flow, is there a way of deep-linking into the settings app, specifically the VPN & Device Management pane? Specifically from a webpage? Or will organizations need to instruct users which areas within settings to dig into in order to sign in and enroll?

Hi All! I absolutely love the changes this year around user enrollment. It seems this flow will be much easier for a user to enroll their device However, I am curious about the design decisions around the new account driver user enrollment flow. From a vendor perspective, it seems like it could potentially be improved further for sake of the end-user experience. For a cloud-hosted MDM provider, the MDM provider would need to instruct customers to place a file within their web host "/.well-known/com.apple.remotemanagement". I'm curious since a user has to authenticate with a Managed Apple ID anyway during the process, why not have that part done first, and associate a "dep profile" with a Managed Apple ID. Similar to how we associate a "dep profile" with a device available for automated device enrollment. That way, the discovery is all done on Apple's end, and potentially only a single authentication is required unless the MDM inserts an authentication webview into the process the same way it can optionally be done for ADE/DEP enrollments. i.e. User attempts sign in with Managed Apple ID -> Apple performs discovery for enrollment profile based on MAID -> user is prompted to enroll to sign in -> mdm optionally displays a webview (similar to ade/dep -> session token granted -> user enrolls It seems like it would be easier for the end user if we could reduce the number of sign-ins required during an enrollment process. I would love to hear others' thoughts on the new process and user enrollment in general.

If an App is removed from the app store, such as this app: https://apps.apple.com/us/app/office-hand-meetings/id835895780 I assume that the expected behavior is that InstallApplication commands would not work since the app is no longer available. Even though the asset data is still returned in the getAssets call. It also appears that authenticated lookups still allow us to pull the asset metadata for a removed app. Is there a way of knowing that an app is no longer available in the app store, so that we prevent additional InstallApplication commands from being initiated and so that we can make the item visible but "inactive" to the customer on our side?