> 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).
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?