Web Authentication works by having devices that provide authentication factors (authenticators), and providing APIs to register some authenticator with a website, or prove presence of a previous authenticator.
The authenticators allow for this registration and proof via generated public key pairs. These key pairs along with other configuration are referred to as Web Authentication Credentials.
There are several modes you can request, such as user verification (perform an additional non-possession factor, such as prompting for a PIN or biometric). You can choose between a model where you challenge authenticators based on previous registration handles, or "ask into the void" if any authenticator thinks there's a valid credential registered for the site. That second mode is called a discoverable credential.
A passkey is a discoverable credentials which supports user verification.
The term isn't trademarked, and just is meant to describe 'a more secure alternative to passwords', but there are a minimal set of features supported. The hope is, like passwords, society will get to a point where we don't have to explain what a passkey is. Support is typically provided by the same software and integration as a password manager.
It doesn't require any capability which was not in Web Authentication Level 2, the prior spec. That said, the platform vendors appear to be taking a much more opinionated idea on how things should be used, and what sort of capabilities (and security posture) should be exposed via the authenticators exposed by their browsers/operating systems.
Most particularly, passkeys are expected to be backup-eligible - e.g. that there is some sort of back-end storage and recovery mechanism. This likely is tied to some sync fabric provided by the platform.
This provides a better user experience in many cases, and reduces the burden on websites to do account recovery (say, if you lose your security key or buy a new cellphone). An authenticator like a Yubikey 5 which supports the other features but does not support backups generates credentials called "single device passkeys" to distinguish this behavior.
Web Authentication Level 3 should eventually expose this backup information to websites, as it is likely a relying party will want to know that the user credential is somewhat 'robust' before they take any sort of migration step like offering to delete any password-based credentials previously used on an account.
In terms of how it is most commonly used - there is significant established usage of WebAuthn, which also supports the functionality of old U2F keys as second factors to a password-based login, such as on sites like Google and Github.
In terms of the 'usernameless and passwordless multi-factor' authentication provided by passkeys, it is expected that the commitment by Apple/Google/Microsoft to support this system will drive adoption, and that it will become the dominant mode of operation. This is all relatively new though - Apple and Google launched toward the end of last year with new backup-capable passkey implementations and new platform-level UX.
That said, the backup eligibility concerns more traditional organizations who are concerned about having Apple/Google/Microsoft clouds as part of their attack surface. The cloud synchronization means that it is debatable whether it meets their needs of considering the phone as a physical factor. And Apple at least offers the ability to 'share' passkeys with contacts over proximity wireless, which interferes with some regulatory requirements. A certain amount of evolution may be needed for them to accept a credential from an authenticator with these characteristics as a sole factor.