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.
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?