- From: Rolf Lindemann via GitHub <sysbot+gh@w3.org>
- Date: Thu, 16 Jun 2022 09:12:19 +0000
- To: public-webauthn@w3.org
I wouldn't do the last two steps that you proposed, i.e. "RP rejects registration" and "browser renders error". In the ideal case, the RP receives a DPK extension signed with a (single-device) key that is already known. Essentially the trust level is equivalent to FIDO assertions today (i.e. before Passkeys). Alternatively, the DPK extension could include a new (single-device) key (i.e. first time use of a device). In this case the RP might (or might not if password-only security level is sufficient today) trigger some kind of additional verification. This process is similar to what RPs would do today (i.e. before Passkeys): there is a new device, verify the user through some other method (=not using FIDO platform authenticator on this device) and then trigger registration of a new FIDO credential). The difference is that you do it in the inverse order with Passkeys, i.e. first get the new key through the DPK extension, and then (potentially) trigger additional verification. The case *without* DPK is not as good, as the RP couldn't distinguish first-time use of the credential on a device from subsequent credential usage on a device - losing the ability to detect *strong* (in the sense of FIDO before Passkeys) device binding. --> back to my previous opinion that DPK support would be sufficient for Enterprise RPs. -- GitHub Notification of comment by rlin1 Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1739#issuecomment-1157423850 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 16 June 2022 09:12:20 UTC