W3C home > Mailing lists > Public > public-webauthn@w3.org > February 2021

Re: [webauthn] Adding info about HSTS for the RPID to client Data. (#1554)

From: =JeffH via GitHub <sysbot+gh@w3.org>
Date: Wed, 03 Feb 2021 19:16:01 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-772752767-1612379760-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Wednesday, 3 February 2021 19:16:04 UTC