Is it possible to fail the registration ceremony if a certain extension is not present?

[arianvp]

I know we're wary of feature detection without prompting user presence for privacy reasons.

However, I'm in a bit of an annoying situation, and I think it should be solveable without compromising privacy. I was wondering if it's possbile with the current spec but I couldn't figure out why.

My usecase: I'm building a cloud password manager; on top of the prf extension; which I want to use to derive a local key for encryption. This means I do not want people to register with credentials that do not support the extension. I'm also relying on resident credentials for the user to get prompted what authenticator to use.

I want to figure out if people actually have this extension.
Problem now is I set {prf: true} in the create call; but I can only find out if the authenticator supports the extension I want after registration is complete. At which point it is too late. I'd like the registration ceremony to fail if the extension is not there, such that the credential doesn't show up in the resident credential menu later when authenticating.

Then I found out about the exts extension; which should allow for discovering what extensions are supported. But again this doesn't really help as you discover what extensions are present after the credential is created.

Is there any way to assert that certain credentials are present, without polluting the resident credential slots on the authenticator? (which might lead to a lot of user confusion "Why do I have 10 accounts named the same way in my chrome settings tab?")

To provide privacy, the failure should only occur after user presence has been asserted. such that it can not be used for fingerprinting. Is such functionality available in any shape or form?

[arianvp]

I also see now that the exts extension was removed from webauthn Level 2.

[ve7jtb]

The prf extension has been pulled out of level 2, so I recommend lobbying if you really want it.

We do have a enforce credprotect option. where the platform won't make a credential if credprotect is not available on the authenticator.

In principal prf should work for both resident and non resident credentials.

It might not be unreasonable to have a similar flag so resident/discoverable slots are not taken up by credentials that won't be used.

[arianvp]

Ah I see the rationale in #1462 now

Given prf was never part of Webauthn level 1 I guess this issue isn't very actionable then (from standardisation viewpoint)

I guess I should just create the credential without residentKey (make a new credential just for prf extension usage. Where I discard the public key).

[arianvp]

so I recommend lobbying if you really want it.

lobbies

Anyhow; I'll cose this issue now as it doesn't seem actionable. However I'd love to see PRF extenion not get kicked out personally; but there doesn't seem to be clear consensus so it makes sense that people moved along without it...