- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Jun 2021 03:46:28 +0000
- To: public-webauthn@w3.org
When I say they are hints, the javascript on the page if compromised or modified can alter the content of this structure before it is sent to the clients navigator.credentials api. From the "output" of the navigator.credentials call it is not possible to assert what was the state of the input that went into that api was, and if it was or was not tampered with, and so it's not possible to know if these requirements were upheld. However, to the RP, the language *looks* like the client *must* enforce these options, even though there is a possibility of alteration. For example, on one IDM as a service site, they incorrectly use a combination of discouraged/preferred UV in registration/login, so your authenticator will request UV even though it is not actually validated, so I have a local js that disables that and sets it to always be "discouraged". Another example could be that page javascript is altered to disable a requirement for platform authenticators, so that an external one can be used, and there would be no way to identify this (without checking attestation and which vendor supplied the authenticator to determine if it is possible for it to be platform/non-platform). -- GitHub Notification of comment by Firstyear Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1618#issuecomment-851783457 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 June 2021 03:46:39 UTC