Based on my experience of working with FIDO for nearly a decade, I can tell you that relying upon a DRAFT specification to implement a production application is risky. There is a good chance that the DRAFT will change before it becomes a Recommended standard. In fact, even after it becomes a standard, you may not be able to implement features defined in the Level-3 spec - the history of Transaction Confirmation from the Level-1 spec is a cautionary tale.
Secondly, not all browsers are likely to implement all capabilities of a spec. As you can see, Apple chose to do something completely different from the Level-2 spec that took many years to settle; Mozilla Firefox only recently implemented the UV implementation to prompt for a PIN.
If you are building an application in a regulated industry (banking, healthcare, etc.), then you should technically be depending on Level-2 - it is the current standard on the books. It took many people multiple years to publish a white paper that shows how to implement one of the most stringent fintech regulations in the world: How FIDO Standards Meet PSD2's Regulatory Technical Standards Requirements on Strong Customer Authentication. Unfortunately, the DRAFT Level-3 spec has sown confusion in the market about whether W3C can/will force browsers to preserve Level-2 APIs to support RPs who may have built production applications following such guidance from the FIDO Alliance and the W3C. You can try sending e-mails to the W3C to get an official answer from them, but given what companies have done in the last year (in stark contrast to the existing Level-2 standard), good luck with that!
Arshad Noor
StrongKey
--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/7fd884de-6ddc-4697-8838-4fd4589644b2n%40fidoalliance.org.
Specifically, are the authenticators implemented by those offering passkeys sending the Backup Eligible (BE) and Backup Selected (BS) flags in the authenticator response during attestation or assertion as per the L3 draft spec?
Are counters being sent?
Could I get a lower counter value if the credential is synced to another authenticator?