In my tests Apple refuses to provide attestation. I'm using Resident Key: required, User Verification: required and Authenticator Attachment left empty. With those settings registering a credential fails if I ask for attestation: "indirect" or "direct". Only "none" works.
My theory is that setting Authenticator Attachment to "cross-platform" (yubikeys and such) or "platform" (touch/face ID) might block cloud-synced credentials, in which case perhaps attestation: "indirect" still works. But I'm just guessing, I haven't tried it.
Or perhaps Apple anonymous attestation only works when using webauthn as a second factor (i.e. without Resident Key and/or without User Verification).
> Unfortunately, this also makes it a dealbreaker for me – I want some credentials to be device-bound and non-extractable.
Why do you need attestation to have that? You can still use a Yubikey and the like, if nothing else.
Or do you mean that you want to force the users of your service to only use credentials that are device-bound and non-extractable, I suppose. But then I would ask... why?
As an RP, due to regulatory or security requirements, for example:
Knowing whether I need to worry about my users' iCloud and Google accounts having been taken over or not is important for accurately evaluating the security posture of any service built on Passkeys as an authentication factor.
And as a user, I don’t trust Apple's or Google's sync backends enough to store my most important credentials there. Especially iCloud is frighteningly easy to hijack, even with a recovery code in place (which ironically at the same time increases the chance I’ll lock myself out as the legitimate user).
> And as a user, I don’t trust Apple's or Google's sync backends enough to store my most important credentials there
I'm not sure everyone realizes that you don't get a choice whether or not Apple passkeys are synced to iCloud, you can't create a passkey from Safari unless iCloud syncing is turned on.
Regardless of whether or not there's support for exporting/importing, you should as a user have the option to not send your passkeys to iCloud. That is a completely reasonable ask. There's really no system where synchronizing to the cloud and syncing between devices/ecosystems ought to be required for the user. I want users to have that option and I have some disagreements about whether services should be able to block it, but I do want it to be an option rather than a requirement.
My guess is that Apple is worried people will turn off syncing without knowing the implications, but... it should still be the user's choice. It's completely legitimate for someone to be annoyed about forced sync.
My main issue with attestation is that it's platform controlled instead of user-controlled and that it doesn't just bind a credential to a device, it binds an authentication mechanism to a category/subset of devices.
If the attestation part was separated from the manufacturer and it couldn't be used to identify who made the device or what brand the device was or what OS it was running, and instead was just a completely randomized device key with no other information with only the restriction that it was hardware-bound, would that be enough to meet your use case or would the user being able to update the OS/firmware still be a problem for you?
My problems with attestation in order:
1. Locking down the ability of the user to change the software/firmware.
2. Allowing the website to identify the device/manufacturer (and allowing them to restrict accounts to a subset of devices).
3. Not allowing the user to replicate/change the device/move the key.
But 1 and 2 are the biggest issues I have, if they went away then 3 wouldn't be as big of a deal to me. Not that I would be super-happy about it, I still don't think it would be a good idea, but... it's comparatively less of a problem.
I could imagine a version of this where you get one private key set on firmware/OS load for your device but it's completely random, and if you update the firmware and the integrity check fails the only thing that happens is that key changes to a new one and the old key is erased. So updating the firmware would invalidate the old login keys that were relying on attestation, but it would not make it possible for a site to block an un-Googled Android from making an account or to even know that you were using an Android/iOS device in the first place.
Again, I don't think that would be a good idea, I think it would be introducing a lot of foot-guns that shouldn't be exposed to ordinary users, but I don't think it would be nearly as much of a problem as saying "we guarantee this is one of X devices in this hardware batch, and that the OS hasn't been customized."
This would be great, but as it is, platform authenticators are effectively always a combination of trusted and untrusted hardware/software, since the TEE or Secure Element usually does not have user input/output capabilities and is relying to the application processor OS's integrity to some extent.
Notable exception: Google's Protected Confirmation [1] – the signature format of that is not natively WebAuthN/FIDO compatible, though.
My theory is that setting Authenticator Attachment to "cross-platform" (yubikeys and such) or "platform" (touch/face ID) might block cloud-synced credentials, in which case perhaps attestation: "indirect" still works. But I'm just guessing, I haven't tried it.
Or perhaps Apple anonymous attestation only works when using webauthn as a second factor (i.e. without Resident Key and/or without User Verification).