Is it accurate that their solution does something like: CloudFlare -> Browser: challenge{...} Browser -> CloudFlare: {sha256((device_public_key)^root_signatur

Is it accurate that their solution does something like: CloudFlare -> Browser: challenge{...} Browser -> CloudFlare: {sha256((device_public_key)^root_signature), (challenge)__device_priv_signature} CloudFlare -> CA: "get signed public key by hash" CA -> CloudFlare: {(device_public_key)^root_signature} CloudFlare -> self: "verifies hash, decrypts returned challenge" CloudFlare -> Browser: "ok" Where "CA" is some source of device public keys, "^" means signed, and "__" means encrypted. I find Alice and Bob stories impenetrable. This is just an HN comment and not a thought through design, but to do the verification, it needs that challenge to bind to the private key on the device, which uniquely identifies it. They need something with more diversification than what I've described to provide privacy and anonymous attestation. The way they would need to do this with any degree of anonymity would be to use a symmetric key on the device that was both a) derived from a vendor/manufacturer key, and b) the response was diversified by both a KDF on the device, and the challenge. I missed this part in their description. The other piece is that I don't know how we verify that FIDO token vendors aggregate their batch keys into cohorts large enough that they provide trustworthy anonymity. Maybe I'm into the weeds without details, but what this post talks about is a non-trivial problem.