Thank you very much for the response! From what we understand, if the discoverable credentials are handled better, then it basically means that passkeys on native are fully supported because that is exactly the same protocol - Kratos just need to expose them in the native flows.
Frankly, if we lie a little bit and pass username to existing WebAuthn implementation in Kratos, then we are able to register/sign user in in an mobile app with the browser flow, so this is basically a matter of exposing the flow for native clients. 🙂 So if you aim for an conformant WebAuthn with discoverable credentials implementation for browsers, then we get native implementation for "free".
There are open question on how we should pass the data to native clients because APIs of each platform is slightly different (Google wants JSON, Apple/MS want parsed object of `PublicKeyCredentialCreationOptions`/`PublicKeyCredentialRequestOptions` ), but that is basically it.
That said, we are willing to contribute the native part (i.e. exposing WebAuthN flow to native clients), but I don't think we (well,
@square-machine-71017, as he's responsible for the contributions to Kratos on our side) will be able to help you with the general architecture as we don't know Kratos internals well enough. And it would be better to do the native part after the web one is (roughly) finished. Nevertheless, if you need some testing (i.e. using the browser implementation on mobile just to validate the ideas), then shoot us - we already have test app for Android (iOS is in the works) ready and are actively running
master
Kratos on our envs. :)