how-to-fido

Sure, but why not preserve the option for people to use hardware keys? Unfortunately, both the FIDO and WebAuthN working groups seem to be dead-set on making the hardware authenticator use case as painful as possible [1] [2] [3]. I just don't get it. Why even try to pretend that WebAuthN is a single API for both use cases when all stakeholders in charge seem to have given up on one of them? [1] https://github.com/fido-alliance/how-to-fido/issues/16 [2] https://github.com/w3c/webauthn/issues/1612 [3] https://github.com/w3c/webauthn/issues/1822

I don't think discoverable credentials on hardware authenticators are a good default pattern (even though requiring(!) resident/discoverable keys is the suggested behavior [2] by the FIDO alliance!?) They have their uses for special use cases for authentication against local or otherwise non-synchronized relying parties or as a component of authentication protocols that aren't a good fit for native WebaAuthN (like SSH), but a regular old website can just ask me for my user ID (which is my email address in 99% of all cases). Unfortunately, there isn't [1] a way to say (in WebAuthN API terms) something like "give me a discoverable credential if you have unlimited storage, otherwise nevermind", so as far as I understand, a relying party can only say "preferred" (taking up a scarce slot on a HW authenticator) or "discouraged" (making a platfo

I started on the abstraction level with SimpleWebAuthn and implemented a POC to get a sense of the general flow: https://simplewebauthn.dev/docs/simplewebauthn/philosophy Then referenced how to FIDO for more information: https://github.com/fido-alliance/how-to-fido/blob/master/How... hope that helps