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 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.
Sort of. Passwords themselves are just text, and they can always be copied and pasted no matter what. But you're right that the full vaults themselves aren't standardized, and a requirement in the spec that authenticators just generally support export would be enough for me I think, even if it didn't specify a specific format.
I do think specifying a specific format might be better though -- if we had standardized password vaults more, maybe the LastPass breach wouldn't have happened, and they wouldn't have assumed that encrypting site metadata/urls was optional. But I generally agree, supporting multiple export formats is fine as long as those export formats exist in some form.
> 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.
Well, that's the question though: should it make assumptions about the characteristics of an authenticator? Embedded in that statement is the idea that sites should have more insight into my device than they've ever had in the past. It's a huge expansion of the amount of information that a site has about where a user is logging in from. I don't know that I agree with that, and I think there needs to be more justification that having that information leads to practical increases in security.
There are a lot of advantages to WebAuthn that have nothing to do with verifying the device. The biggest security increase from WebAuthn is the site identifying itself to the authenticator. The site getting information about the hardware is kind of secondary, and I would argue of much more limited value for security (but of high value for DRM/platform restrictions).
Users can already get device-bound credentials without attestation -- they can get a Yubikey. So for users that want that extra security, options exist. But does it add tangible security for the site to be in charge of that? Enough security to justify enabling some really pervasive DRM methods and device lock-down?
> 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.
I don't think I agree with this either. Any restriction Apple puts in front of iCloud recovery can be put in front of an export button. Any information that Apple asks you before syncing to a new iPhone can be asked before providing you with a backup file. And from an attacker's point of view, if I can attack the iCloud export function, I can also buy an iPhone and attack its device recovery process. I'm not sure there is much of a security difference here.
I think that ship has kind of sailed as soon as we start talking about syncing passkeys between devices. I think this argument only makes sense if we get of sync entirely and say, "no, they'll be completely device-bound like a Yubikey." But if Apple is syncing keys between iOS and Mac, if it allows going even further and sharing them using AirDrop, we're well past the point of worrying about whether someone can trick you into exporting your passkeys.
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.
> 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.
I would question whether 100k devices is actually a big enough pool to protect privacy. Regardless, that is "an expansion of information", right? It's a pretty decent fingerprinting vector to start with when combined with other device information.
> 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
At the point where a company is in that position, they should be supplying their own locked down devices. This is an extremely narrow use case, much more narrow than "I'd like to be able to use this on a Linux machine." And the companies that are in that position have much greater resources to solve that problem by issuing dedicated hardware that's locked down in general. It doesn't need to be part of the spec.
In practice, where this will be used most often is with banking apps, which I've argued elsewhere are not nearly responsible enough to be trusted with this extra information and are usually startlingly insecure. They can get on board with basic security techniques that the rest of the industry has already implemented before we discuss giving them more control over my hardware.
People keep billing this as a compromise, but it's not really. The attestation proponents are asking for a capability that doesn't exist, they're asking for a level of insight into my hardware that login methods have never provided before. The status quo is "no, of course you don't get that." If they want to change the status quo, asking for "compromise" isn't the way to do it, providing real proof that it's not going to be abused (which, I'll mention in a second I don't think is safe to assume) and that it'll provide meaningful security increases is where they should start.
> 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.
Also attestation in the form of SafetyNet (https://developer.android.com/training/safetynet/attestation) and the more recent Play Integrity API has been used for DRM in plenty of instances, even for very trivial services like Netflix. So it seems pretty reasonable to extrapolate out that services that already use attestation for DRM today are going to use it when it's available for WebAuthn.
The default assumption ought to be that this is going to be abused. Every instance of attestation in the past has been abused. Why would we just assume that suddenly companies are going to be nice about it?
> However that's the nature of standards and how they come about, there's multiple interests in the working groups.
Right, and the way you force that collaboration is by refusing to go along with standards that are harmful. I'm not part of this standards process, it's their job to build a standard that appeals to me if they want me to use it. If they can't do that, then I won't use it. And I'll advise other people not to use it and I'll tell people (truthfully) that I believe it's a harmful standard. As users/stakeholders, we force collaboration by laying out very clearly where our limits are so we can focus on finding solutions that solve multiple use-cases.
I'm willing to compromise on a lot of stuff. Not this. If the big stakeholders also aren't willing to compromise on it, then we'll stick with passwords. That's fine with me. The FIDO group doesn't have an inherent right to have people pay attention to them. It's their job to come up with a standard that's good enough that people want to pay attention to it.
> 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
Some of us would argue that is also entirely the FIDO Alliance's problem to solve given that they exist to build the FIDO standard and are the most invested party in getting the rest of us to adopt their solution.
Normally when people get together to build Open standards, they start with an Open implementation as a proof of concept. FIDO Alliance seems to be under the impression that it's everyone else's problem that nobody has built an Open implementation of their "Open" spec for them. That's just not how this should work.
> and will have to be primarily OS-vendor-driven
It's a good thing that all of those OS-vendors are part of the FIDO Alliance and are currently involved in a process that provides them with a great opportunity to sit down with each other and hash this out then.
> 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.
That wouldn't solve any of my problems; the sync fabric isn't the important part -- I want to control my own keys. What does an "Open" sync fabric that restricts keys to specific devices even look like? That's certainly not Open in the sense that I control the sync fabric or can compile/change it myself.
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.
> I also don't quite see how merely having attestation in the standard is harmful.
Because having it there makes it an option, and I think that history is pretty clear that if you give the tech industry a bat, they will beat their users with it sooner or later.
> 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 seems like it does though... correct me if I'm wrong, but attestation is how Google knows that it's a Yubikey and that it doesn't have a PIN/biometrics set. And in practice, it's not allowed to be used to provide user verification; there's a restriction on functionality. Yes, you can use it as a Yubikey, but you can't use it for the new passkey system.
> For the "own locked down devices" is that Enterprise Attestation exists, which has management overhead in both its configurations, wheras normal attestation does not.
Good? Attestation should have an overhead. Getting rid of the overhead is exactly what I don't want. You can have attestation today through existing methods, and they're basically sufficient for enterprises that need them. It costs a bit of money, which is good because it'll force enterprises to think about it. And importantly, it doesn't really work for restricting consumer accounts, it's mostly useful for orgs where devices are controlled. Which is again, good, that's the best outcome. Enterprises can restrict their devices, but there are barriers to entry that prevent those restrictions from being applied to general consumers using their own devices.
The other thing you can do if you don't want to go the hardware route is you can have a custom login app for your enterprise. You shouldn't, you should provide users with devices if you're going to restrict those devices -- but there's nothing stopping an org from having a custom authenticator that works outside of the standard.
The only problem they'll have is if they want general users outside of the org to install that app just to log in. Which again, is very good. It's good that you can build a custom solution for within an enterprise, but that there are significant challenges in front of trying to force that solution on regular users.
Heck, you can even use the Play Integrity API to help. Should the Play Integrity API exist? No, probably not. But it does and it's usable for dedicated authenticators, so we certainly don't need another solution on top of it.
This is a rare use-case, and it's probably fine for the orgs that need it to use something other than passkeys. There's no real danger to them of lock-out, they're already doing this today so they can just keep doing what they're already doing.
> I also don't quite see how merely having attestation in the standard is harmful.
Because every single time that we've had attestation in the past -- literally every single time -- it's been used for DRM. Hopefully this conversation doesn't matter because Apple is just blocking attestation, but what do you see in the industry that makes you think this time would be different? Has something radically changed at Netflix over the past couple of years?
When has attestation ever not been abused?
Here's the Chromium team expressing similar fears: https://www.chromium.org/security-keys/ Are those fears unfounded? I don't generally assume that Google is going to be leading the charge on user freedom, and if even they are kind of creeped out about the potential here, then I trust that there's a real risk of abuse.
> 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.
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.
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?
> Also consider that Apple zeroes out attestation for its devices
This may be the saving grace because it may end up being that whether or not attestation is part of the standard doesn't matter because companies won't be able to use it. But it doesn't mean that attestation is harmless, it means that we're very lucky that (for now) Apple is deciding to effectively make it impossible for a commercial service to actually use it reliably.
> It prevents you from using security keys that aren't configured for user verification, and they don't do that through attestation.
Fair point, I don't know that this is actually using attestation and that it's not just the Yubikey reporting back that it doesn't support that field. I do quibble somewhat with "they're not blocking Yubikeys, they're just blocking <description of a Yubikey>." But... yeah, I'll grant you're probably right that this is not using attestation.
> I don't see a world where you can export passkeys from Apple iCloud Keychain and import them into Google Password Manager.
That's exactly what I mean when I say it wouldn't be sufficient. When I talk about syncing, I'm talking about transferring into and out of ecosystems, not just specific devices. What you're describing is a system where I can use the KeePassXC ecosystem to use keys across multiple devices. But I can't transfer those keys out of the KeePassXC ecosystem (unless hopefully other vendors like 1Password add support), and if someone starts using iCloud, they're stuck with same vendor lock-in.
This is effectively saying, "you'll have a closed ecosystem for most people, but people who know enough beforehand to avoid it can somewhat avoid it." We should expect better from a standards body that purports to be building an Open standard.
I really don't see how this is an out-of-scope problem for the FIDO Alliance. They have input from every single major OS. All of the players are in the same space. And their entire job is to dictate how this is going to work. I'm just asking them to do that job. A spec for portability is not that big of an ask compared to everything else they're already working on as part of this.
It's not really that different than a spec for logging in using a standardized QR code, or over Bluetooth -- all of which was considered in-scope for them to to work on. Portability is just part of the general interoperability work that we should be expecting them to do.
> Do you want your browser deciding for you what websites you can log in to?
Of course not; in very typical fashion Google's solution to the problem may be worse than the problem itself. Google is very fond of recognizing that a feature is abusable and saying, "well, how about we prevent that abuse by giving ourselves even more capricious power?"
But I do think it shows I'm not being paranoid, that this is a legitimate worry that even Google recognizes is worth worrying about. Google is part of the FIDO Alliance and it's not looking at attestation as a theoretical risk; it's looking at it as a very plausible risk that it needs to have policies around.
Which I think is pretty reasonable given that every single instance of attestation in the past has been used for DRM, and there's nothing special about attestation in this spec that would stop that from happening. I really do think the burden of proof here is on you to describe why you think Netflix/Banks/etc... are suddenly going to act differently now than they have with every other attestation method they've had access to leading up to now.
The only answer I can think of is, "they'll act differently because Apple is effectively killing attestation for platform keys for everyone." But that's not really a defense of attestation, it's just something to thank Apple for.
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.
> They're blocking authenticators that don't have additional protection other than just presence.
I know this isn't strictly attestation, but this is blocking authentication based on attributes of the device, correct? I'm sort of quibbling over details here I know, but this is basically saying "we are checking for a pin protection or biometric protection and limiting how an authenticator is used based on the presence of that feature."
> 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.
And that is a good reason to reject the standard as harmful.
I'd love to use keys for log-in, it would be a huge boost to security. But if portability between sync fabrics as you call them isn't supported, then we can stick with passwords. I'm fine with that, and I think other people are as well. Ultimately, passkeys have to be better than what we have, and out of luck or history or whatever reason password vaults are extremely portable between different ecosystems. Even ecosystems that try to lock down passwords struggle to do so, because ultimately passwords are text and in the worst case they can be copied and pasted between managers. So if passkeys aren't similarly portable and they become another tool for holding people down into a single OS ecosystem (even if there are options that allow avoiding that), then they're harmful -- the security gains are not worth the downside.
It does not address my concerns to say that a user who knows about the dangers of vendor lock-in in advance can avoid it in some situations.
> 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
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.
It's also relevant to FIDO in the sense that it is a major barrier of entry to getting passkeys to be accepted by the general public. At the end of the day, the highest-level responsibility for FIDO is to figure out a standard that's usable. The lack of portability keeps the standard from being usable. It is the single biggest complaint that people have about passkeys.
Yes, that is a problem they should solve, particularly because everyone who would be required to be in the same room to solve that problem is currently in the same room, and all of them have a vested interest in getting rid of barriers to passkey adoption.
Ultimately, does FIDO want this to be adopted by normal people or not? If the answer is yes, then portability is a problem they need to tackle. Again, every single company required to tackle this problem is currently a member of that alliance.
> Standards simply attempt to provide the bare minimum for interoperability that every party can agree to.
That bare minimum of interoperability should not exist for abusive uses of the technology. Like you said, there are solutions for this today. Companies that are abusing their customers should not get extra support from OSes and standard bodies to help them do it.
Bank of America can already use a Yubikey today. Or they can use a poorly implemented proprietary token. And maybe if that goes badly for them, they'll use an actually more secure option instead of LARPing security.
But look, this is exactly what people said about web video DRM, it's exactly what people say every time these conversations around DRM and fingerprinting come up. Companies are going to fingerprint your device anyway, we might as well give them a device ID for advertising. Companies are going to build weird browser extensions, we might as well get rid of them and make DRM part of the spec. It's really just an excuse, the standards make it easier to do this stuff. They're pursued because they get rid of the inconvenient parts of abusing users. And in doing so, they remove a barrier of entry that should exist.
And integrating this into web browsers on desktop platforms is a huge gift to companies that want to do this. I already can't use my bank's app on a deGoogled phone but at least I can sign in on a web browser, because in the world that currently exists attestation through a general web browser is just difficult and just annoying enough that my bank isn't willing to do it. Please stop trying to change that.
When a company is doing something awful, it should have to leave the beaten path and work outside of the standard to do it. Because that helps us call out that they are doing something awful, and it helps us point to their solution and say, "no, that's not intended."
> 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.
> Do you want to log in to Google with a bearer Yubikey (what do you do when it gets stolen?)
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. I mean, you talk about scope of the standard, a pin is a thing that exists locally on my device that I use to secure my keys. It's a local security measure, not something that's part of credentials for the service.
It's out of scope for Google to know anything about that. The scope of Google's login is the credentials that get submitted to Google. It's not really their business to know how my phone is locked (or by extension, how my passkey vault is locked).
> In the same way that a keyboard dictates how a password is typed
Well, the difference is that keyboards aren't currently blocking adoption of passkeys. Lack of portability is blocking adoption of passkeys. It's the biggest complaint people have.
If keyboards were a huge problem that made it harder to use passkeys, yes, it would be in scope to figure out some kind of solution to mitigate that problem.
> I simply don't see either the value in mandating interoperable sync fabrics
Because until users are confident that interoperability is going to to exist (and not just for one or two solutions, but also for the big environments like iOS/Android), this is going to continue to be a huge barrier to adoption and people are going to continue to warn against the spec.
The value is to address the complaint or people will keep complaining.
> Also remember that the standard doesn't just cater to users, it caters to these vendors implementing it as well, and more so.
Okay, then the users will stick with passwords. This is honestly kind of wild. The point of passkeys ought to be to make a usable solution for users. My heart bleeds for some of the richest companies on the planet, but they joined the FIDO Alliance, they wanted to build a usable standard. They signed up for this.
I have a solution that currently works (password vaults), and they want me to get rid of my solution and use theirs. So convince me. If they don't cater to users, users won't use passkeys, and it'll go the same way that every other key based authentication method for the web has gone. Remember, this is not the first time that companies have tried to get rid of passwords. Building a solution that doesn't have major caveats is really important if they want a different outcome from the previous efforts.
> 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
Only if it doesn't use attestation and doesn't get your device pinned down to X in 100,000. But that's not the important part, the important part is that attestation is literally DRM.
It is DRM to say "you will not be able to log into this service unless you're using a proprietary Apple/Android/Windows OS."
And will companies do that? Well, every single instance of attestation pre-WebAuthn -- literally every single instance -- is being used as DRM today. And you want that in the browser? If my bank is already using this to block me from logging into an app unless I'm on a proprietary OS, then of course they're going to do the same thing with web browsers as soon as they have access to tools to help them do so. You have to understand that, you have to understand that absent some kind of force blocking them from doing so (again, thanks Apple) attestation in the browser is most likely going to mean that I can't log into my bank from a web browser unless I have a proprietary OS to act as the authenticator. That's the world we're talking about.
Why wouldn't they use attestation here the same way as they've used every other attestation mechanism they've ever been handed? What is making you think that won't happen?
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).
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.