Due to the Webauthn specification, Passkeys are created against a particular website (e.g., A.xyz) as its “Relying Party ID”. This Passkey will only be able to be prompted during the visit from a browser to this domain. If this domain is no longer available, the Passkey will remain within the device of the user, but it will no longer be able to be prompted by any other website (e.g., B.xyz). Additionally, since only A.xyz was ever able to get the related public key of said Passkey as part of its creation, if the public key of the Passkey was not stored elsewhere, this public key is lost forever, and signatures can not be verified against it.

This architecture poses a critical flaw into applications that do not use the Passkey in the intended Webauthn workflow, such as decentralized applications that only use the Passkey as an authentication mechanism for a smart wallet within the context of web3 (e.g., EIP 4337). However, as a work around, as long as the source code of A.xyz is available, the user can run it locally and trick a device where the Passkey is stored into loading A.xyz in its device instead of via the actual DNS call the domain resolved. This can be easily done in computer devices by updating the local /etc/hosts and using an SSL proxy with a self-signed certificate (e.g., via mkcert), but might pose a harder challenge in a mobile device.