The spec failing to distinguish between these two cases is a major flaw and completely kills passkey viability for personal accounts until they resolve it.
I'm interested in reading more about this. Do you have some links? I did some quick searching of the terms you mentioned and nothing obvious came up.
Some quick bits and pieces from my own searching just now:
Apple's documentation on Passkey attestation is entirely under "declarative configuration", their terminology for mobile device management (MDM) corporate tools: https://support.apple.com/guide/deployment/passkey-attestati...
It is noticeably absent from, for instance, AuthenticationServices documentation: https://developer.apple.com/documentation/authenticationserv...
On non-attestation Passkey responses intentionally send an empty AAGUID for privacy/Apple's belief in the spec's suggestion to send an empty AAGUID:
> iCloud Keychain is one of the few (maybe the only?) passkey authenticator that currently follows the spec and will use an all-zero AAGUID.
From: https://developer.apple.com/forums/thread/739004
On the technical side of limitations of attestation for consumer Passkeys (due to iCloud Keychain sync):
> Passkeys do not provide an attestation statement, as the attestation model currently defined in WebAuthn wasn't designed with syncing credentials in mind.
> Attestation was designed to attest to a specific device, exclusively at the point of creation, with a specific set of security properties. It doesn't make sense for synced credentials for a number of reasons, including syncing to devices with different security properties, changes in security properties that happen after key creation, security properties of the sync fabric, sharing the passkey, or exporting to other passkey providers. We're working hard with W3C and FIDO to solve these problems.
From: https://developer.apple.com/forums/thread/708982
(I believe some of the problems being solved in that one in 2022 is referring to how we got the "uvi" and "uvm" extensions to Passkeys, neither of which is in attestation data nor attested in any way, and both designed for a general semblance of user privacy: https://www.w3.org/TR/webauthn-1/#sctn-uvi-extension)
I believe the juiciest quotes I'm looking for are buried in WWDC videos and I can't find a transcript search tool just yet.
> Passkeys do not provide an attestation statement, as the attestation model currently defined in WebAuthn wasn't designed with syncing credentials in mind.
On any platform, attestation and "syncing" are effectively opposites. Either you're getting attestation that the auth comes from a secure application and on secure hardware (read: non-exportable in-TPM crypto material), or not.
As usual, it's a tug-of-war between security and convenience.
For example, iOS uses the App Attest service (https://developer.apple.com/documentation/devicecheck/prepar...). On Android, you get it from Google Play Services (https://developer.android.com/google/play/integrity/overview) then the built in key attest service (https://developer.android.com/privacy-and-security/security-...). MS Authenticator does all the legwork and returns the results to you at sign-in time.
On Windows, WHFB has this built in (obviously). On macOS, this comes from Platform SSO (https://support.apple.com/en-ca/guide/deployment/dep7bbb0531...).
From a freedom perspective, I need to ensure that Google has no idea whether my device is an Android phone bought from an officially licensed manufacturer, or Waydroid or android-x86. Compliance is not an issue because I am, ya know, some random guy. The only way I can ensure this happens is by ensuring attestation is not possible.
From a corporate compliance perspective, I need to ensure that employee keys are stored in a FIPS-compliant TPM and unexportable. Key loss is not an issue because we have, ya know, an IT department. The only way I can ensure this happens is by whitelisting AAGUIDs and enforcing attestation.
With these factors I can also get out of the MFA hellhole (because I can prove that whitelisted vendor X already performs MFA on-device without me having to manage it: for example, WHFB requires something you have (keys in your TPM) and either something you are (face scan / fingerprint) or something you know (PIN), without me having to store/verify any of those factors or otherwise manage them). Same goes for passkeys stored in MS Authenticator on iOS/Android.