Re: [webauthn] Discussing mechanisms for enterprise RP's to enforce bound properties of credentials (#1739)

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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Thursday, 16 June 2022 09:12:20 UTC