Oliver Hamlet

> Which opens the possibility that any fraudulent browser extension could do the same. True, at least macOS apparently has APIs for integrating third-party passkey providers, and according to passkeys.dev...

> I think you fundamentally misunderstand the role of the browser extension. It is NOT the client in the spec, that is actually the browser itself. I had a read...

@droidmonkey I feel like we're completely talking past each other at this point. > No, that is the role of the authenticator. I think I was unclear, when I was...

> The whole idea is to perform everything possible in KeePassXC's side. So KeePassXC itself will work as a client and an authenticator. The extension just passes the information and...

> Again: because we want the extension side to be very simple. One reason for this is that any 3rd party client a developer wants to use with KeePassXC via...

> It is unclear to me if we must implement the privacy timeout rules or if the browser does that on the backend regardless of what the overriding client does....

I've started to read through the implementation, and I'm very concerned that it appears to be noncompliant with the WebAuthn Level 1 spec in ways that I believe could cause...

> @Ortham your claims are probably valid, but they are also rather exceptional. I would initially push back to say... if it is "that easy to get it so wrong"...

This seems like a good idea. People face a similar problem when merging plugins, and I think the two problems can be solved with a more general form of aliasing....

I think that's out of scope for this feature, two-way aliasing is way more complicated, and as you've pointed out, solves different problems.