AppAttest for MacOS27

Is there a definitive list of which extension types support DCAppAttestService on macOS 27 — and is the credential-provider extension (ASCredentialProviderExtension) among them?

Extensions are not supported on macOS. The supported list of extensions for iOS and the other platforms are listed under here, https://developer.apple.com/documentation/devicecheck/establishing-your-app-s-integrity#Check-for-availability.

I'm thrilled to hear demand for this on macOS already. Please do file a feedback request and the team can take a look, https://developer.apple.com/feedback-assistant/.

If credential-provider extensions are not supported, in an app that ships a credential-provider extension, can I add a separate (e.g. SSO or Action) extension — or use the containing app — to perform App Attest and generate/attest a key, then use that key from the credential-provider extension (e.g. via a shared keychain access group)? Or is the attested key inherently bound to the attesting process and not shareable?

On macOS, you can only generate keys, attest, and assert them from the main app bundle. The attested key is tied to the RP_ID (team identifier + signing identifier) of the process that generates it (i.e., your main app). So I do not think you would be able to proxy keys across your main app to your extension to perform attestation or assertion.

As mentioned above, if extensions are an important part of your developer workflow, do file a feedback request.

Thanks, that's very clear and helpful!

The context for my question is like I'm building a our own credential provider with device/enterprise attestation.

Given App Attest is main-app-only on macOS and keys can't be proxied to the extension, I do have two quick follow-ups:

1. Is it reasonable to use App Attest in the main app at enrollment purely to attest the integrity of the whole app bundle even with other extensions? Is that the intended pattern, or does App Attest's RP_ID binding make the app-level attestation not meaningfully cover the extension?
2. Since we still need attestation, can I use the ManagedApp framework on macOS 27 — provisioning an identity via com.apple.configuration.app.managed → ACME — and would that key be hardware-bound (Secure Enclave)? I also post that question in a different thread earlier: https://developer.apple.com/forums/thread/831160

Thanks!

Is it reasonable to use App Attest in the main app at enrollment purely to attest the integrity of the whole app bundle even with other extensions? Is that the intended pattern, or does App Attest's RP_ID binding make the app-level attestation not meaningfully cover the extension?

Yes, that would be reasonable. The attestation will provide a security posture signal of the app on the user's device. Based on the attestation and it's validity, you can extend that assumption to your extension embedded in your app.

Since we still need attestation, can I use the ManagedApp framework on macOS 27 — provisioning an identity via com.apple.configuration.app.managed → ACME — and would that key be hardware-bound (Secure Enclave)? I also post that question in a different thread earlier: https://developer.apple.com/forums/thread/831160

Please pose this question in the Business and Education QA. The experts there can help with this.