- From: philomathic_life via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Apr 2024 19:21:11 +0000
- To: public-webauthn@w3.org
zacknewman has just created a new issue for https://github.com/w3c/webauthn: == Clarification on UVM extension == According to the [UVM section in WebAuthn Level 3](https://www.w3.org/TR/webauthn-3/#sctn-uvm-extension), an authenticator is required to have at most three UVM entries; however [user verification methods](https://fidoalliance.org/specs/common-specs/fido-registry-v2.2-rd-20210525.html#user-verification-methods) is a flag that allows authenticators to encode multiple methods as a single value. Does this mean that the array that is sent can have at most three entries, but it is OK for the sum of verification methods to be greater than three? For example an authenticator is allowed to send `[[0x1DFF, 0xA, 0x4]]` even though the first integer in the inner array represents 11 factors—when counting "internal" and "external" methods for the same "factor" as distinct. This means that while an authenticator can send multiple UVM entries to represent multiple factors, they could more easily do the same (with fewer restrictions) by sending a single entry? Related to this, nothing in the FIDO guide strictly forbids seeming contradictory user verification methods; are we to assume that is just an oversight? For example `USER_VERIFY_NONE` seems to contradict all other values, so presumably it should be forbidden for such a value to be combined with the others. The FIDO guide explicitly forbids certain values elsewhere (e.g., `KEY_PROTECTION_TEE` is mutually exclusive with `KEY_PROTECTION_SECURE_ELEMENT` ); so it's at least bizarre to rely on "common sense" in one part and explicit rules in others. Less obvious and not stated, are the `_INTERNAL` methods mutually exclusive with the `_EXTERNAL` methods (e.g., `USER_VERIFY_PASSCODE_INTERNAL` and `USER_VERIFY_PASSCODE_EXTERNAL`)? Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2055 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 4 April 2024 19:21:12 UTC