[halJordan]

In general any one can make a passkey app. Keepass chooses to be out of spec. No one is gatekeeping them. If an nginx server receives bad data it spits out a 400 error instead of processing the request. One of the reasons browsers are still effed up is because they refused to be standards compliant and were still paying for quirks mode. I would like to see this article complain about an http server handling a bad actor.

Otherwise, create multiple passkeys. Create a passkey in your ios keychain and in your Keepass app. This walled garden has a gate, walk through it.

[comex]

In the hypothetical scenario where websites block Keepass, Keepass would not be sending “bad data” to the website. Its interaction with the website would not be noncompliant in any way. Rather, the website would be punishing Keepass for a separate interaction between Keepass and the user.

A more apt analogy would be if the http server sent an 400 to all requests from browsers known to support ad blocking.

[paradox460]

Not so hypothetical. PayPal supports passkeys, but does browser sniffing to only enable it in Safari on Mac. I could tell my browser to fake it's UA to use 1password's passkeys, but to what end?

[warkdarrior]

It is potentially bad data, since authentication data is supposed to show that a valid user wants to log in to the service. If the client makes it easy for anyone to pretend to be that user, than the authentication data is bad data.

[AlexandrB]

The better analogy is a web server blocking a web client because, even though it's standards compliant, it does something with that data it receives that the server's owner doesn't like. For example, yt-dlp.

[hooverd]

Really, the example would be refusing to serve browsers that are standards compliant but aren't blessed by some certification authority, kind of like what they tried to pull with WEI. I'm sure FOSS developers will be able to keep up the passkey certification regime as well as the big boys, right?

[varjolintu]

According to this list majority of the clients are out of spec: https://passkeys.dev/docs/reference/known-issues/

[votepaunchy]

The list has been filtered to include only non-compliant clients:

“The following list of passkey providers have not implemented User Verification in a spec-compliant manner.”

[mrled]

I think this is more like a webserver sniffing the user agent and choosing not to serve the request, not like sending a webserver bad data such that it isn't able to serve the request. I'm concerned that passkeys end up in a "This site is best viewed in Internet Explorer" mindset, where passkey providers that would work fine are detected and prohibited because the website operators want them to enforce user behavior.

[hirsin]

In the sense of "I refuse to support browsers that only support tls 1.0", definitely. "Just let the user turn off TLS, why do you hate choice" isn't the instant win you might hope it is.

[miloignis]

No, again, the protocol between the site and the authenticator is unchanged. It's much more like DRM that doesn't let 4K media play on systems that allow the user to do whatever they want, but in this case instead of the DRM preventing the user from copying someone else's copyrighted work, it's preventing the user from copying their own data.

[mrled]

I agree that it's not an unqualified win. If sites block passkey apps that allow exporting unencrypted passkeys, that probably will prevent some accidental passkey leaks.

It's just that it's not an unqualified win to allow sites to block passkey apps either. If we allow that, we can get to a place where sites block apps for the wrong reason, or it becomes more expensive to develop passkey apps so there is less competition for secure passkey apps.

It's not just whether it's a good idea to allow unencrypted exports. It's whether it's a good idea to give websites a say in how we manage credentials.