WebAuthn credProtect needs a policy at creation and assertion

The WebAuthn credProtect extension lets a relying party ask an authenticator to apply a credential protection policy. It can require user verification before a credential is used, or limit discoverability without user verification. The extension is useful because a passkey can be found before the user is fully verified. It is not a replacement for the relying party's own user-verification policy.

The CTAP specification defines several protection levels. userVerificationOptional is the baseline behavior. userVerificationOptionalWithCredentialIDList allows credential discovery without user verification only when the caller already has a credential ID. userVerificationRequired requires user verification before the credential can be used. The authenticator persists the selected policy with the credential.

An authenticator may also have a default policy higher than the minimum. The request should set enforceCredentialProtectionPolicy when the relying party cannot accept a weaker result. Without enforcement, a platform may create the credential with a policy that does not meet the application's assurance requirement.

Treat creation as a decision

Review the creation options for every sensitive credential. Decide whether the credential may be discoverable before user verification and whether the user interface should reveal account details. The CTAP text warns that personal data in the user entity should use userVerificationRequired and enforcement when the relying party wants that protection.

Set the policy per application and risk level. A shared device used for workforce administration may require a stricter policy than a low-risk consumer account. Record the requested policy and the authenticator's returned extension output. Do not mark a credential as protected just because the request contained the extension name.

Handle unsupported authenticators explicitly. If a client does not support credProtect and the product requires it, registration should fail or move to an approved alternative. A silent downgrade to the default policy creates a credential that looks normal but does not meet the documented assurance level.

Validate the assertion

At assertion time, inspect the authenticated response and the credential record. Confirm that the credential still belongs to the expected relying party and user, and that the ceremony satisfies the policy the application needs. userVerificationRequired is stronger than user presence alone. Do not accept a presence-only result because the browser returned a success response.

Keep the credential policy in the server-side record and bind it to the credential ID. A later policy change should apply to new credentials and have a migration plan for existing ones. Do not rewrite the meaning of an existing credential silently.

Test a credential created with the required policy, one created at the optional level, and one on an authenticator without the extension. Confirm that the server rejects the weaker cases when the account requires protection. Test discoverable and non-discoverable authentication separately.

Operate the trust boundary

The authenticator, browser, platform, and relying party all participate in the decision. The browser can pass extension inputs, but the server decides whether the resulting assurance is acceptable. Log the credential ID, policy, user-verification result, authenticator attachment, and decision. Do not log raw biometric data or private key material.

If an account is recovered or a credential is replaced, apply the same policy review to the new credential. A recovery flow that creates a weaker credential can undo the control without changing the original record.

credProtect gives the relying party a way to express a policy to the authenticator. The server still has to enforce the result, record it, and test the downgrade cases.

References

• W3C Web Authentication Level 3
• FIDO Client to Authenticator Protocol 2.3
• FIDO Authenticator Security Requirements 1.5