- From: =JeffH via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Feb 2021 19:16:01 +0000
- To: public-webauthn@w3.org
> HSTS adds another property of prohibiting user recourse to invalid certificates. Something to note here: HSTS was always seen by the browser/UA vendors and the websec WG as an _interim_ solution. As the Web moves towards being more fully HTTPS-based, the nominal intention of UAs is to eventually default to trying HTTPS first, instead of insecure HTTP. In fact, we're presently at the beginning of that effort: https://9to5google.com/2021/01/11/google-chrome-address-bar-may-soon-default-to-https/ So the exigent need that underlied the invention of the website-declared HSTS policy is declining, and thus whether "secure" sites will continue to (need to) emit the Strict-Transport-Security header field is uncertain. Thus I would not necessarily base a WebAuthn feature/facet/whatHaveYou on HSTS. An important question is whether the UAs include the "no user recourse" HSTS feature in their HTTPS-first approach. [A quick search seems to indicate that there continues to be controversy over that particular HSTS feature. ](https://www.google.com/search?q=try+https+first++hsts+%22no+user+recourse%22) ISTM that whether or not a UA enforces a "no user recourse" policy in the event of error(s) during TLS establishment is orthogonal to WebAuthn per se. -- GitHub Notification of comment by equalsJeffH Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1554#issuecomment-772752767 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 February 2021 19:16:03 UTC