1. Passkeys contain the username and the domain of the service that you have registered with
2. Because passkeys contain the domain, it provides very strong phishing protections, because a look-alike website still has a different domain.
Passkeys are resident keys. They take up storage space, which is a problem for dedicated hardware tokens which usually have limited storage space. A much nicer solution are non-residential keys that get recomputed on the fly based on the domain name that you want to authenticate against.
So is this following the OpenID Connect/JWT type flow?
The site registers itself with your passkey "wallet" (?), and logging in would use a signed request and your wallet provides a shared secured response so you both can confirm who you say you are?
> So is this following the OpenID Connect/JWT type flow?
No. This is orthogonal and can be used in combination with the aforementioned technologies.
Let's assume you want to use OpenID connect and also JWT.
1. You have your own web service that does not implement a login form but relies on OpenID connect.
2. You have an authentication service like GitHub, Facebook, Google, ...
3. Your users have a pre-existing account on GitHub, Facebook, Google, ... They use their passkey/non-resident key/plain old password/... to log into one of these services
4. Your users want to log in to your service. They start the OpenID Connection protocol using the authentication service. If they are not logged in yet, then they have to present their passkey/non-resident key/plain old password/... to get logged in. Once they are logged in, the authentication service can issue a fresh JWT to your user.
5. Your user can then use the JWT to use your service.
1. Passkeys contain the username and the domain of the service that you have registered with
2. Because passkeys contain the domain, it provides very strong phishing protections, because a look-alike website still has a different domain.
Passkeys are resident keys. They take up storage space, which is a problem for dedicated hardware tokens which usually have limited storage space. A much nicer solution are non-residential keys that get recomputed on the fly based on the domain name that you want to authenticate against.