I agree with this. One way to keep changes small but still compose them into a coherent PR is to make each commit in the final PR independently meaningful, rather than what actually transpired during local development. TFA touches on this somewhat, contradicting the bit you quoted.
A trivial example would be adding the core logic and associated tests in the first commit, and all the remaining scaffolding and ceremony in subsequent commits. I find this technique especially useful when an otherwise additive change requires refactoring of existing code, since the things I expect will be reviewed in each and the expertise it takes are often very different.
I don't mind squashing the branch before merging after the PR has been approved. The individual commits are only meaningful in the context of the review, but the PR is the unit that I care about preserving in git history.
Counter-anecdotally, I reported two WebAuthn issues to Apple in separate instances and both were immediately fixed in the next patch version of iOS/Mac OS. In both cases first line support had little understanding of the issue but were very good at following process, trusting me, calling me back to keep me updated, and escalating to engineering as necessary.
There's a standard for this using NFC and UWB, Digital Car Key; BMW has support for either 2.0 (NFC) or 3.0 (UWB) across their entire range. The Hyundai Motor Company group (Hyundai/Kia/Genesis) is starting to add support as well. See [1] for exact models (look for the little key icon). Several other makes are members of the Car Connectivity Consortium that standardized this protocol so it's reasonable to expect wider compatibility in the near future. The protocol incorporates significant countermeasures against relay and replay attacks like some that are mentioned in other comments here.
Professor Daniel Abadi makes a similar point in his paper [1], where he improves on CAP with PACELC -- if there is a partition (P) how does the system tradeoff between availability and consistency (A and C); else (E) when the system is running as normal in the absence of partitions, how does the system tradeoff between latency (L) and consistency (C)?. (From his blog here: [2]).
Klepmann makes an interesting critique [3], that neither is particularly useful because both imply that you must either pick linearizability or total availability. When in practice, there have been plenty of successful databases that present neither characteristic, and thus are neither CP nor AP.
Beazley's Concurrency From the Ground Up is one of my favorite tech talks ever: In about 45 minutes he builds an async framework using generators, while live coding in an emacs screen that shows only about 20 lines and without syntax highlighting, and not breaking stride with his commentary and engaging with the audience.
UWB is augmenting Bluetooth for car keys solving this exact issue; The Car Connectivity Consortium came up with the Digital Key 3.0 standard that's available today, as implemented by some makes like BMW and the Hyundai/Kia group and Apple, and resists relay and replay attacks through precise ranging.
I think we both have exhausted our arguments regarding attestation. I understand why you don't want attestation to exist, and I believe you understand why I think it needed to exist in order for WebAuthn itself to exist. Like you, I hope it doesn't turn into a dystopia of every service requesting their own particular devices. So far, it doesn't look like it's going in that direction.
> I'd like to have that choice, yes. I don't think it would be good to act on that choice, but... Google should not be in charge of the device I use to submit a key
It's in Google's best interest to not damage their reputation with repeated break-ins to customer accounts and to reduce the overhead of an account recovery mechanism after an attack. It's the same rationale they use to not allow you to use "password" as a password, or why other services mandate 2FA. And again, Google isn't in control either, the authenticator is. Google (the RP) asks the browser (the client) for a user verification attribute. The authenticator is the one in charge of providing a response that sets that attribute. Without attestation, Google can't know if the authenticator did what it asked it to do.
> I have a solution that currently works (password vaults)
We're already seeing third-party sync fabric that don't use hardware elements without needing standard support. Dashlane already has it, 1Password is releasing it next month, and we're on a thread about initial support for it in KeePassXC. I'm sure soon after we'll see import capabilities for other password managers. Isn't this equivalent to the password manager you want to stick with?
All the extra discussion is around backing those sync fabrics with hardware (which is what I think will exist but outside of FIDO) and mandating implementors to allow exports (which I don't think will ever happen, nor do I personally want it or need it).
> but this is blocking authentication based on attributes of the device, correct?
Not precisely. It's requesting capabilities that the Yubikey is not configured to deliver so the browser doesn't show it as an option. There is no attestation or in fact no signed communication other than the RP requesting it in the registration. I don't understand what your desired behavior is here. Do you want to log in to Google with a bearer Yubikey (what do you do when it gets stolen?). Do you want all FIDO2 keys to require PINs, even if they're being used in a traditional "something you have" 2FA fashion?
> It absolutely does, it dictates how that login information gets shared between devices. As far as I'm concerned it's just another part of transport. (...) The lack of portability keeps the standard from being usable
In the same way that a keyboard dictates how a password is typed. Transport has a very well defined meaning in FIDO and it's not about transporting key material but rather signed challenges and responses.
Remember I'm suggesting a mechanism for open sync fabrics to exist, not the opposite. I simply don't see either the value in mandating interoperable sync fabrics, or for a particular vendor in control of the ecosystem like Apple or Google wanting to weaken the security posture of their keys given how the standard works if they allow them to be exported. Also remember that the standard doesn't just cater to users, it caters to these vendors implementing it as well, and more so.
> it's exactly what people say every time these conversations around DRM and fingerprinting come up
Except Webauthn doesn't have any fingerprinting capabilities beyond those in enterprise attestation (not regular attestation). In fact, it's much more privacy preserving that past alternatives. And fully realized, you wouldn't even need a username as an identifier with an RP that can be used to correlate you across services.
let me restate, they're not "blocking the description of a Yubikey" either. You can register one, and in fact I just did to try it out. The Yubikey needs to be configured with a PIN which you do through Yubikey manager. They're blocking authenticators that don't have additional protection other than just presence.
> That's exactly what I mean when I say it wouldn't be sufficient
I think we're confusing what the role of a standard is, versus what other features can be built around a standard capability. With an open fabric, vendors like KeePassXC can allow exports in formats that can then be imported by other sync fabrics as I described previously. The standard mandating it would be a good reason for vendors not to adopt the standard, or adopt a crippled version. Given the fact that WebAuthn ties capabilites to the authenticator at registration time I think it's understandable that vendors like Apple want give RPs assurance that keys are entirely contained in an ecosystem that guarantees those assertions. You will have options, including not using Apple/Microsoft/Google's sync fabrics, and to move off these sync fabrics if you consider them insufficient, but not by exporting keys directly.
> I really don't see how this is an out-of-scope problem for the FIDO Alliance (...) It's not really that different than a spec for logging in using a standardized QR code
Logging in using a QR code or BLE is part of the hybrid transport in CTAP, which deals with how authenticators communicate with clients. It's very much within FIDO. Establishing trust between devices in different ecosystems to form a circle of trust so that key material can be shared doesn't really have anything to do with logging in to services, so it's not WebAuthn. It also doesn't deal with client to authenticator communication as there's no client. If anything, a standard like TPM (ISO/IEC 11889) is a better fit, but probably too low level for that exact use case.
> Which I think is pretty reasonable given that every single instance of attestation in the past has been used for DRM
Going back to attestation, I don't think that in general it's in the best interest of services to not allow you to log in to them, but I can see a bank in their typical backwards-fashion issuing some branded keys and only letting you use those (Symantec, I'm looking at you). The reality is that standard or not, if RPs want this functionality, it'll be there. Standards simply attempt to provide the bare minimum for interoperability that every party can agree to. The alternative is not an attestation-free world. It's a bank asking you to log in with a flawed key they purchased from an ancient vendor because there's no standard offering that does what they want. I'd much rather have a Bank of America branded Yubikey with enterprise attestation using WebAuthn than some weak and poorly implemented proprietary token like the ones they issue today.
Attestation doesn't carry that information. Also consider that Apple zeroes out attestation for its devices and works just fine with Google as passkeys. What's happening here is that when an RP is registering an authenticator, it can include a property that's called userVerification which in a Yubikey is backed by a PIN, and Google sets it as required. The restriction in functionality that you mention is exactly what Google wants though, but not for malicious purposes. Google doesn't want someone stealing your yubikey and having that suffice to log in to your account. They want user verification so that if that Yubikey is stolen, an attacker also needs to know the PIN, thus providing two factors. Again, Google does not prevent you from using Yubikeys. It prevents you from using security keys that aren't configured for user verification, and they don't do that through attestation.
> Right, but if you're talking about trusted devices, unless that's something the user controls, exporting/importing doesn't matter. The point is that the user should be able to export their key and import it to any authenticator they choose without fear that their authenticator is going to be blocked from logging in to a service.
No, not just physical devices. Anything that represents a device with a wrapping key. That could be a software implementation that's just a file you control. What I'm saying though is that for the general case which is what a standard is concerned with, we won't see the standard-mandated ability to export passkeys across sync fabrics. I don't see a world where you can export passkeys from Apple iCloud Keychain and import them into Google Password Manager. But I do see a world where you create passkeys in your Mac with KeePassXC, and can use an open sync fabric from KeePassXC to sync them to your Android device, and a flat file as well, and I believe this will happen not under the purview of FIDO. Whether those flat files can then hop on to another sync fabric (say, 1Password) to later be imported into hardware devices will definitely not be a part of a standard, but given the analogy to password managers, it doesn't matter; those capabilities can still be built.
As far as the Chromium post, I find that one slightly more dystopic than attestation as a feature. They say If Chrome becomes aware that websites are not meeting these expectations, we may withdraw Security Key privileges from those sites, and similar other warnings. They don't say that they will warn users, they say that they will withdraw privileges. Do you want your browser deciding for you what websites you can log in to?
100k devices is the minimum. Also I already agreed that this is an expansion of information, were it to be requested in practice and the user chose to provide it. And I don't believe the use case for attestation in enterprise settings is narrow. For the "own locked down devices" is that Enterprise Attestation exists, which has management overhead in both its configurations, wheras normal attestation does not.
I can't comment on the intent link, as there's no information. But the "practice" link is simply incorrect. Google does in fact allow a Yubikey to be used as a passkey, I have one configured myself. It shows up as "FIDO2 security key". What I assume is happening in that link you sent is that the user's yubikey does not have a PIN set for the FIDO2 interface, which means that it can't provide user verification and therefore is not a passkey as far as Google is concerned. This is the kind of reasoning about the capabilities of the authenticator that I was talking about, and it doesn't have to do with attestation.
> it's their job to build a standard that appeals to me if they want me to use it
They're appealing to OEMs, vendors and service providers as well. I also don't quite see how merely having attestation in the standard is harmful. RPs and users can chose not to require or provide it. If RPs decided they needed it for malicious purposes, would not having it in the standard suffice for them to be benign?
> That wouldn't solve any of my problems; the sync fabric isn't the important part -- I want to control my own keys.
It would, because then the sync fabric is free to provide you with an exported version that's wrapped in a key of your choosing. It's open in the sense that any one software can import/export keys out of hardware devices that are currently restricted to the hardware vendor.
WebAuthn goes to great lengths to preserve user privacy, much more so than past alternatives, so I don't think there's a expansion of information, especially when the device is probed for capabilities which is extremely pervasive with browsers today. There is some new info with attestation, but other than it not being very widespread in practice, attestation keys are shared by a minimum of 100k devices.
In general, the intent of attestation seems to be enterprise use cases where companies want to issue authenticators that meet certain capabilities, and only allow those capabilities as attested by a trusted party. For instance, a company might mandate Webauthn with user verification for their internal systems, and they don't want an employee using a software based virtual authenticator that fakes UV and keeps key material in plain text, so they issue Yubikeys to their staff and only allow Yubikeys to be used for logging in (issued or otherwise, as the RP can't differentiate them). I have not seen a single instance of attestation being used to gatekeep access to an otherwise public service, but I'd like to see some examples if there are any. Enterprise attestation is a different beast, however, and can uniquely identify an individual security key, but this has significant management overhead and will not be seen outside of enterprise use cases.
Now I understand you personally don't value attestation as highly as some other features of WebAuthn and that's fine, I'm on the same boat. However that's the nature of standards and how they come about, there's multiple interests in the working groups. It's hard to say what's the "biggest" security increase because that's entirely relative to the individual or corporation implementing, consuming, or standarizing the functionality.
As to whether there can be a phishing-resistant trust-establishment mechanism, I absolutely agree that there can be. All I'm saying is that there isn't an interoperable one currently, and that it's hard to establish interoperability across vendors and without an online sync fabric (I'd presume most users would want to export key material to a file or otherwise not rely necesarily on a third party phone-home service to export keys). I also think that it exceeds the scope of FIDO and will have to be primarily OS-vendor-driven. For me, personally, this along with something like the recovery extension that Yubico is promoting is one of the potential future features I'm most excited about.
Related, and for the other reason why import/export is hard, which is the reasoning about the ecosystem, I don't think that even with such a mechanism we'll ever be able to export keys out if iCloud Keychain and into KeePassXC. What will most likely happen is that credentials generated by KeePaasXC and backed by hardware, will be able to be imported/exported in/out of devices in the same trust circle, using a KeePassXC sync fabric as the sync mechanism.
I don't think FIDO saying importing/exporting keys is important and them having to standardize it is the same thing.
The first and most straightforward reason is that we have no standard for importing/exporting passwords in or out of password managers, yet we manage to export them just fine. Each vault has its own proprietary format that's simple enough for others to implement as well.
But more importantly, WebAuthn makes assumptions about the characteristics of an authenticator at registration time. (And establishes continuity of those signals with DPK). Exporting it would be contrary to that.
Instead, with all these password manager vendors not wanting to be left out, and a good portion of the userbase either not being entirely in a single vendor's ecosystem, I can see cross-platform virtual authenticators like KeepassXC here becoming more common, and I don't think it's unlikely that the OSs will offer APIs to back these keys with TPMs/Secure Enclaves, and will allow you to replace the built-in passkey manager with a third-party, much like they do with password managers today.
I see it more in the purview of OS APIs than FIDO itself. The big, nontrivial risk here is that it involves establishing trust between devices across ecosystems so that they can share wrapped key material, and this introduces a vector for attacks. A user could more easily be tricked into trusting a malicious TPM that exfiltrates they passkeys, whereas single vendors like Apple can implement mitigations as long as all the devices are in their own ecosystem and they can use their own services for sync.
The entire sync fabric would become the authenticator. Apple and Google could (but don't currently) issue attestation that the passkey ecosystem you're using is theirs for multi-device passkeys, and continue to use attestation for the specific hardware for DPK and single-device passkeys.
Please read the comment again, because that wasn't the argument I was making.
I'll restate in case I wasn't clear -- the fact that it's wrapped addresses the "just a file"; meaning it's not sufficient to attack the filesystem to steal it, just like a password manager vault is.
As for how it's not a downgrade (or upgrade, mind you), it's domain-bound using standard browser APIs, meaning it's less likely than the comparable autofill used by a password manager to not leak passwords to the wrong site (LastPass suffered this issue in the past, for example). It prevents reuse across sites, it's not vulnerable to a man-in-the-middle in the same way a password or TOTP secret is, and guarantees strong assymetric crypto as opposed to whatever a server decides to do with a password and a secret. Additionally, and especially when compared to password managers, most of them now offer to also store and autofill TOTP secrets leaving us in the same spot were at with virtual authenticator backed passkeys, but with worse cryptography.
It's surprisingly difficult to figure what what a passkey is, precisely. I think there's a bit of a terminology issue.
FIDO marketing materials talk about passkeys in the same way you do, a resident key (now called discoverable credentials). Some other materials say that passkey with no other qualifier is a multi-device passkey, meaning it's backed up by a sync fabric. (e.g. the short version here https://passkeys.dev/docs/reference/terms/#passkey). Others, like Google did in their blogpost last week and the long version of that link, say that a passkey is a multi-device passkey that also has user verification (so it can be used for passwordless and not just 2FA/2SV).
Yeah don't get me wrong, I wasn't disagreeing. I think the lack of interoperability is a major risk to adoption, but I also understand why we don't have interoperability today and why we likely never will.
What I'd like to see password manager vendors like you do, though, is to push FIDO and the OS vendors to have richer APIs for interacting with the hardware components that can back keys. To be clear, I don't want to use Bulwark to manage or export passkeys in my iCloud Keychain (I'm confident that will never happen), but I want Bulwark to be able to create a passkey that is backed by a secure element in Mac OS, and then be able request a wrapped version of that key to be exported, and later imported into a TPM running on a Windows OS.
Passkeys are not quite passwords even if backed by software and stored in the same memory space as other applications running on the OS. They're still asymmetric, cryptographically secure, and domain-bound. It's true that being "just a file on your hard drive" changes the threat model as compared to a hardware security key, but that file is wrapped at rest, potentially with a hardware security key as well.
Whether it's a downgrade or not depends on your specific threat model, and whether it's a downgrade for you or for the userbase at large.
WebAuthn lets RPs reason about the strength and capabilities of the authenticator at registration time. With a mechanism like a shared file format and standard ways of transferring them, those mechanisms would be undermined. With hardware-backed multi-device Passkeys, the entire sync fabric becomes the authenticator. Apple and Google currently zero out attestation data, but you can imagine a scenario where attestation data matching the device is presented for single-device passkeys and DPK, but a different attestation key is used for multi-device passkeys that represents the entire sync fabric.
Instead, with all these password manager vendors not wanting to be left out, and a good portion of the userbase either not being entirely in a single vendor's ecosystem and not wanting to deal with the hassle of QR codes and registering each fabric in each RP, or simply distrusting the big vendors like we see here in this thread, I can see cross-platform virtual authenticators like the one you're working on becoming more common, and I don't think it's unlikely that the OSs will offer APIs to back these keys with TPMs/Secure Enclaves, and will allow you to replacethe built-in passkey manager with a third-party, much like they do with password managers today.
If software-based authenticators want to support import/export capabilities, they don't quite need an open standard, in the same way there isn't one for passwords but you can import/export passwords with any major password manager.
A trivial example would be adding the core logic and associated tests in the first commit, and all the remaining scaffolding and ceremony in subsequent commits. I find this technique especially useful when an otherwise additive change requires refactoring of existing code, since the things I expect will be reviewed in each and the expertise it takes are often very different.
I don't mind squashing the branch before merging after the PR has been approved. The individual commits are only meaningful in the context of the review, but the PR is the unit that I care about preserving in git history.