Will using aaguid for platform-identification stop being useful?

[dasali-jenario]

Some (many?) relying parties use the aaguid from passkeys to assess the passkey-sync-fabric and display this information in the settings. How will this be impacted by CXP? Is it correct that the aaguid will remain the same indicating the platform that created it, but not necessarily that's holding it?

[Progdrasil]

Theres work to add the AAGUID to the credprops extension. This could be used to signal that an exchange has taken place. See w3c/webauthn#2157 for more information.

[dasali-jenario]

Thank you. I think the options discussed in the linked discussion are sensible.

My concern is that if relying parties make decisions based on the aaguid, they will be mislead unless the importing sync-fabric updates the id. I would hope that most of these checks are purely cosmetic to display information to the user. Having a passkey with a apple keychain aaguid in a 1password sync-fabric would not make sense. Am I missing something?

[Progdrasil]

So AAGUIDs are bound to the authenticator, they are not transferred over to the importing provider who would have a different AAUID. In the case of synced passkeys, the AAGUID is mostly for UI purposes since it is not bound to any sort of attestation proving management of the passkey itself.

For sure nothing stops a provider to masquerade as a different provider by using that other provider's AAGUID. In the case of an unattested key, the RPs should not necessarily be using the AAGUID as a trust signal. This applies to the current status of webauthn.

With the addition of credential exchange, one could imagine a scenario where the passkey has been exchanged, and the new AAGUID is provided in the assertion response through CredProps. In this case the RP could prompt the user to ask if they would like to update the passkey's name (if they support such a feature) to give the name of the new provider.