With passwords, the "proof" or "attestation" is that nobody knows my secret password. In practice this tends to be weak. Some reasons this is so includes:

- the password is low-entropy/complexity, so it is guessable or brute-forcible. - the password is typed into the system, so keyloggers might observe it - the password might be stored insecurity by the server - the password is transmitted over the network and might be intercepted - the password is transmitted over the network, possibly to unintended recipients (like a phishing site) and thus is intercepted.

One alternative is employing public-key/private-key crypto. The server sends some random data to the user. The user signs that data with their private key (this is the attestation part). Only the signed data, which is generated for this single authentication attempt is transmitted. And during registration only the public key is transmitted. The public key is used by the service to verify the attested data. The private key remains secret the entire time. Likely it remains secret even to the user's machine because it lives in separate hardware, such as a yubikey or secure-enclave. The key is also something that isn't going to be guessed because we are using modern algos with large bit-sizes.

Sure but how is that different from JUST logging in with touchID or faceID? Without attestation?

There is no mechanism for that. The biometric hardware is local to your machine. I suppose the hardware could emit a "biometric fingerprint" that is transmitted to the server. And if anyone acquired your fingerprint they could unlock any site. Ok, so you could add some site specific salt to the process before sending the data. This is pretty close to just having a local password manager where the master key is biometric rather than a password.

But touch/faceID aren't implemented that way. They intentionally don't expose the biometric profile, that is kept local to the secure enclave. They instead just give you access to the secure enclaves keystore. Rather than signing data you could just use uniquely generated public keys like a password, or do something like signing a websites name with a private key to generate a password.

However, these approaches don't really make sense. The advantage of public-key cryptography is that you prove who you are WITHOUT SHARING the private/secret key. This is much more secure, because it prevents threat actors that don't have access to the private key from replicating the "proof" or signing process. This is what attestation is about. You can design alternative attestation schemes, but webauthn is pretty simple.

If you don't have attestation, then I can write some JavaScript code that "return true" for the authentication callback, and log into any and every account.

The attestation is a signed (digital) document saying basically "We are $manufacturer and we made this $product and we promise it has these desirable security properties".

In WebAuthn the design is that a batch of (at least 1000 but usually far more) authenticator products should have such a document which Javascript can optionally request (together with proof they didn't just knock it off from another authenticator) when using the authenticator.

If you demand multi-factor and aren't willing to take my word (as the user) that I'm using it, you could insist upon seeing the attestation and reject authenticators unless you can see the attestation and you like it. For example maybe Great American Bank accepts Yubikeys, but rejects the Apple iPhone because they believe Steve Jobs was Satan.

Most sites should not use attestation at all. Firefox in particular can tell a site to fuck off when it asks for attestation. I'm happy to use high security WebAuthn but I don't want to have to tell you which products I use to do it. If your site does not require WebAuthn for every user then almost by definition it makes no sense to demand attestation from users who choose to enable it.

The use of "batches" is a privacy safeguard. If you permit attestation a site might know you have a Mattel Barbie Authenticator, but it won't know which one. If Mattel aren't selling many they probably put the same batch on the Buzz Lightyear Authenticator so a site can't even tell if you've got a Barbie or Buzz Lightyear.

According to this video apparently (?) Apple thought that wasn't safe enough and so it has decided to do something else weird instead, but not yet. Whatever, for almost all web sites you should refuse attestation if given the option. Maybe my bank needs to know I'm doing MFA with a high quality product but there's no reason Facebook or GMail or anybody like that should ask.

The point of the video was that when using the device as the authenticator, attestation reveals details of the phone (such as the unique private key used to prove the phone is valid to a manufacturer). The anonymous attestation authority here allows Apple to be assert to the qualities of the device without the device having to reveal identifiers externally.

This is akin to a batch of identifiers the size of all Apple products, while still allowing the device owner (or Apple) to disavow a particular device if it is lost or stolen.

The implementation also ensures that the same device creating multiple identities for the same website will have no signing characteristics linking one account to the other.

It doesn't reveal "the unique private key" that would be crazy, the revealed key is a public key. And mostly sites should not ask for attestation and users should refuse to grant it if asked (Firefox asks, you can just say "No" but I'd be comfortable with clients just always saying "No" on my behalf instead)

There are already designs if you are quite sure you must have attestation and yet you don't want device identification. You can do blinded attestation and agl has written up a much fancier approach on his blog too.

But again, Don't Ask, Don't Tell. The video shows this silly demo "Shiny picture" site asking for attestation and that's a bad idea you should not replicate, write "none" instead of "direct" and then the problem goes away for your site.