Here is the FB ticket: FB16734033 just for reference. Thank you

During further research,I observed that when generating an attestation for the first time, Apple makes a call to a remote service to obtain a signed attestation. This attestation is then cached and reused for subsequent requests. Any future attestation calls return the cached value. To obtain a new attestation, the device keys need to be reset.

Okay so looks like API request.complete(httpAuthorizationHeaders: ["x-sso-attestation": signedJWT])  is only for credential extensions and not meant for Redirect extension.

If Apple were to rotate or replace the attestation certificate chain (for example, in the event of a compromised root attestation CA), would this automatically trigger a repair / re-enrollment flow on all previously enrolled devices? Or is the repair flow initiated only based on server-side decisions, such as attestation validation failures or explicit policy enforcement?

Thanks for the update. I did some investigation on my end using Charles to inspect the traffic and verify whether any Apple attestation APIs are being called. I can confirm that an attestation API is indeed triggered, but I’m not entirely sure what happens behind the scenes. Any progress on the research at your end ?

Thanks for the reply. I’m currently working on threat modeling for my PSSO extension and trying to understand the different attack scenarios. For example, what if an attacker creates a separate SSO extension to generate a valid attestation, and then somehow replaces or injects a malformed payload from their own device into the registration request of another device, potentially updating the keys? In such cases, what protections does the attestation mechanism provide? Also, is it sufficient to send the attestation payload directly in the request body, or should I add an extra layer of security—such as wrapping the payload in a JWT and signing it using Secure Enclave–backed keys generated during registration—to ensure the payload hasn’t been tampered with? At the same time, I want to avoid overengineering the solution. I’m trying to determine whether these additional measures are necessary or just redundant.

Maybe not on the FileVault unlock screen, but is it possible on the macOS login window? If FDE auto-login is disabled, the user lands on the standard login window after authenticating with FileVault. I can use an authorization plugin on that login window, but is there a way to leverage a persistent token or any other mechanism to enable passwordless authentication at this stage ?

Thanks again for the clarification. With Platform SSO enabled, is it possible to support a fully passwordless experience at the macOS login window and lock screen, without requiring a local account password fallback ?

Any update ?

In this case, the parent process would be the installer, since the plugin runs under the host. While this setup would prevent the process from being launched by any other source, an attacker could still create a malicious installer, embed my program within their plugin, and successfully carry out the attack — correct ?

I was wondering — if I include the child process in my installer plugin, wouldn’t that allow an attacker to extract the executable using pkgutil and then run the child process manually with their own parameters? Are you referring to using a root process, such as an SMJobBless Helper? If so, spawning it from the installer would also require root privileges, which isn’t ideal since I’d prefer not to prompt for elevated permissions twice — once during installation and again when launching the process.

NVM I found the solution. let context = LAContext() context.localizedReason = "Authenticate to sign your transaction" // Main prompt text context.localizedCancelTitle = "Cancel" // Cancel button text context.localizedFallbackTitle = "Use Passcode" // While fetching the private key pass the context let query: [String: Any] = [ kSecClass as String: kSecClassKey, kSecAttrApplicationTag as String: "com.example.key".data(using: .utf8)!, kSecReturnRef as String: true, kSecUseAuthenticationContext as String: context // Associate the context ]

Yes, I am using the -resetPasswordFor command. I also noticed an issue where creating an account via sysadminctl doesn't enable the secure token, while creating an account using dscl does enable it. Example: sudo sysadminctl -addUser testuser -fullName "Test User" -password - -adminUser AdminUser -adminPassword - If I try to manually enable the secure token I get an error: "Operation is not permitted without secure token unlock." Example: sudo sysadminctl -addUser testuser -fullName "Test User" -password - -admin -secureTokenOn AdminUser -passwordFor - Secure token for the current account is already enabled

Thank you so much for your prompt and helpful response! I must admit, I completely overlooked using the - flag to prompt for passwords. It worked perfectly for resetting the password. Here's the output I received: 2025-01-13 10:05:49.547 sysadminctl[41068:1823531] resetting password for TestUser. (Keychain will not be updated!) 2025-01-13 10:05:52.409 sysadminctl[41068:1823531] - Done As you pointed out, it looks like there’s a keychain password sync issue, since the keychain isn't updated along with the system password. Is there a command or method to update the keychain password to match the system password? Also, just a thought—if the sysadminctl reset command is causing this out-of-sync issue, wouldn't it make the command effectively useless? Since the keychain wouldn't be updated, the reset wouldn't actually work as expected, right?

Thanks for your insights I was able to achieve my use case using sysadminctl commands, which worked as expected. The main issue, however, is that this approach requires admin credentials to be passed as a parameter to the command. This, of course, introduces a potential security risk, as some endpoint security solutions might intercept these commands and expose the credentials. Currently, I'm executing the sysadminctl command from a daemon, but I’m wondering if there’s a way to hide or obfuscate the admin credentials passed as parameters to prevent such exposure. Do you have any recommendations for mitigating this risk ?