OpenSK VS webauthn

https://github.com/google/OpenSK works, it runs on something like this $15 board. Could do with a case though.

https://www.nordicsemi.com/About-us/BuyOnline?search_token=n...

There are a huge number of other vendors supporting Webauthn apart from Yubikey. (From the top of my head Nitrokey, Solo, Tomu, Mooltipass, Ledger, Trezor, Google Titan, OnlyKey, Token2).

You could also use the system TPM (https://github.com/psanford/tpm-fido).

A brief search didn't yield any FIDO2 software-only solutions for Linux, but I see no reason why in principle you couldn't implement it (perhaps interfacing https://github.com/google/OpenSK through hidg - similar projects do exist for U2F).

Cloudflare does, using a security key not found in the FIDO Metadata Service will unfortunately not work. This precludes the use of any hacker-friendly solution (making your own).

> Supported: All security keys found in the FIDO Metadata Service 3.0, unless they have been revoked for security reasons.

https://support.cloudflare.com/hc/en-us/articles/44068890480...

Attestation keys, as they're currently used, aren't very "privacy friendly" and it's much worse for those who wish to create their own key.

> Usually, the attestation private key is shared between a batch of at least 100,000 security keys of the same model. If you build your own OpenSK, your private key is unique to you. This makes you identifiable across registrations: Two websites could collaborate to track if registrations were attested with the same key material. If you use OpenSK beyond experimentation, please consider carefully if you want to take this privacy risk.

https://github.com/google/OpenSK/blob/f2496a8e6d71a4e8388849...

There are a number of FOSS solutions.

- https://github.com/google/OpenSK <- DIY solution

- https://solokeys.com/

- https://www.nitrokey.com/

The issue with any FOSS solution is that FIDO requires an attestation private key which is shared between a batch of at least 100,000 security keys. Using a DIY or cli app (application running on the host) solution will likely mean you'll be generating that private key yourself, this makes you identifiable across registrations.

I'm not sure what you're replying to--this scheme is much closer to self-signed X509 client certs, not FIDO. But regarding FIDO, it does not prevent user-controlled hardware; it's up to RPs to choose if they require specific device manufacturers or not.

In my experience, the vast majority of (consumer) RPs do not require specific batch attestation, which is why you can make your own FIDO key: https://github.com/google/OpenSK.

I am under the impression support for attestation was controversial in FIDO--it's clearly useful for enterprise scenarios (e.g. where an enterprise requires some silly certification like FIPS: https://support.yubico.com/hc/en-us/articles/360016614760-Ac...), but there's always the risk that consumer-facing RPs require it for no good reason.

My employer requires FIPS certification due to FedRAMP; I'd be interested in how you would propose to change FIDO such that--as now--I can use a single key for work and for all my consumer needs while eliminating attestation.

These crop up every now and again but they never address my biggest concern, which how we (the users) can prevent abuse of https://w3c.github.io/webauthn/#attestation-object such that only those of us with approved devices are allowed to authenticate.

It's not hard to imagine Google and Apple and a few others finding ways to pressure authenticators into blocking access to users of devices that cannot prove that they're running firmware which bellyfeels ingsoc.

Sure, but why not preserve the option for people to use hardware keys?

Unfortunately, both the FIDO and WebAuthN working groups seem to be dead-set on making the hardware authenticator use case as painful as possible [1] [2] [3].

I just don't get it. Why even try to pretend that WebAuthN is a single API for both use cases when all stakeholders in charge seem to have given up on one of them?

[1] https://github.com/fido-alliance/how-to-fido/issues/16

[2] https://github.com/w3c/webauthn/issues/1612

[3] https://github.com/w3c/webauthn/issues/1822

I'm not trying to do callout posts or anything here, I know that the people involved are genuinely trying to do their best. I'm grateful that Bitwarden is involved with passkeys. But, for all of that gratitude, I still have to say: Bitwarden got a huge amount of attention for being the Open Source implementation of this, and Bitwarden and 1Password were both used as examples that shut down criticisms about portability, and lack of communication and clarity is a big part of how Bitwarden/1Password got used to spread what I would genuinely consider to be misinformation about the current state of the passkey ecosystem.

It's not just that export wasn't supported, it's that this giant limitation that was in many ways the reason why people were so excited about Open implementations in the first place was quietly left unsaid.

I really genuinely do appreciate the work everyone is doing. But at no point when Bitwarden was writing posts and releases about passkey support did anyone writing that stuff think, "people will think this means export is supported, we should clarify that."?

It's so hard not to look at this communication and not think that these kinds of details were deliberately omitted. I'm sure they weren't! I know that emotions are wrong and that everyone involved means the best. But crud, that is how it feels.

How many people who got excited about Bitwarden's implementation even know that they still can't export and import their passkeys? Maybe that'll be a fun surprise for them next time they try to do an import into a new account. Bitwarden's announcements didn't mention this limitation, and as a result no press coverage of Bitwarden mentioned this, and any casual observer who didn't know to go read the documentation and deliberately ask about it would come away from this coverage thinking that export was supported -- and in fact I would argue people did. People think the portability problem is solved because Bitwarden and 1Password exist.

Needing to double-check this kind of stuff, not having transparency or open conversations about any of it is part of the regular frustration of trying to learn about the passkey ecosystem. Very often when I talk to people in industry about passkeys, I will get answers that really sound like they are addressing people's concerns. And then you dig into them, and... they don't. But that's never communicated unless you do the research. So much of the advocacy is saying stuff that is technically true, but has huge unmentioned caveats or that doesn't actually when you dig into it address the concerns that people have or is using some weird definition that isn't what most people would use.

"Passkeys are portable now!"

"So I can export them?"

"Well, that depends on what your definition of portable is."

Bitwarden never technically said that it supported export, but I'm going to go out on a limb and say that a lot of casual observers reading about portability and sync and OS-independence think that Bitwarden does support export, and Bitwarden really isn't going out of its way to avoid that impression. I mean, props for having it in the user docs, that is better than 1Password. +1 for Open Source being more transparent than proprietary software, genuinely I appreciate it. But the only reason I know that Bitwarden doesn't currently support export... is because I knew that I couldn't assume it and I knew that I needed to check the docs. It's not something that's communicated in the announcement, it's not something that's communicated in the FAQ, it's not something that's communicated in any press coverage, it's not something that's communicated unless you know what to Google search.

----

> The best place to argue this “in the open” is by raising issues in the w3c/webauthn repo, or meetings, which is open.

Here are the open issues about portability: https://github.com/w3c/webauthn/issues?q=portability

Maybe I'm searching wrong? Here's migration: https://github.com/w3c/webauthn/issues?q=migration

What am I missing here? I apologize if there's some thread that I just haven't been able to find, but... if this is an open process, where is the conversation happening? I don't want to be a jerk about this; should I be showing up at w3c meetings and complaining about other meetings that aren't happening there? That doesn't seem helpful to anyone, I don't see how that would be productive. But if this is genuinely happening as part of the w3c/webauthn space, then where in that space are the conversations about portability and export? What issues should I be following?

Is the problem that nobody has raised an issue in that space? Because that's a very weird thing if true; I've been told for nearly a year that work is ongoing on migration/export. In all that time, none of that conversation ended up on the webauthn repo, the ostensibly official place for the spec to be discussed?

This just feels like a dismissal; if the webauthn repository is where these conversation should be happening, then why aren't they happening there? This isn't Bitwarden's fault, I'm speaking broadly to anyone involved in this process -- this is a multi-company process that has been happening for months and months and months and I would love to know where those industry-spanning conversations actually exist, so that I can stay up to date on what's going on without needing to search for crumbs of developer updates on Reddit, Mastodon, and Twitter.

I agree, FIDO and webauthn. As for implementing, here's the API GitHub link .

https://github.com/w3c/webauthn/issues/1667

If you're doing something like passwordless and usernameless, then your locally stored credential has an ID that was generated during registration. This is sent as part of the authentication request, and the relying party has a way of association which credential ID's are linked to which user accounts. The credential portion is talked about in section 5.1 of the https://w3c.github.io/webauthn docs.

> Apple's passkeys do not provide attestation

Apple has their own anonymous attestation format[1] that some (unclear which?) of their WebAuthn authenticators support.

In principle the relying party could use this to verify the authenticity of the authenticator back up to Apple's WebAuthn root CA[2]. In practice, I'm not sure if that attestation is included by default (or whether significant portions of users opt out of it, when prompted by their browser).

[1]: https://github.com/w3c/webauthn/pull/1491

[2]: https://www.apple.com/certificateauthority/Apple_WebAuthn_Ro...

There is a great comment thread in the WC3/WebAuthn Github Issues (January 2022) that was pre-publication of the Multi-Device FIDO white paper that prompted all the Passkey stuff (March 2022). https://github.com/w3c/webauthn/issues/1691 The OP of this issue is rightly pointing out that Passkey/MD FIDO is somewhat broken without enforcing the devicePubKey extension. The detractors in the thread are pointing out that it's not something they can enforce.

The idea of authenticator hardware is inherently hostile to DIY and open source because you cannot produce or extract a keypair to generate valid attestation statements. Unless you are part of the cartel of course.

https://w3c.github.io/webauthn/#attestation-statement

Given the Webauthn standard, there could be more than one answer to this question, so here is a list of relevant information: