I'm definitely going to keep track of this standard, but as I understand it no browser has released it yet?

Edit: I didn't properly read your reply, so disregard everything after "quite cool". :)

Web authentication is indeed quite cool. You can also drop passwords altogether and just rely on the token and the username (caveat: someone knows your username and physically steals your token is a threat) or even drop usernames at all! As U2F tokens generate new keypair per origin you'd only need the token to authorize. Of course if someone steals it and tries to login to your site... It's like physical key.

This feature adds a set of restrictions upon the names which may be used for cookies with specific properties. These restrictions enable user agents to smuggle cookie state to the server within the confines of the existing "Cookie" request header syntax, and limits the ways in which cookies may be abused. In a nutshell: `__Secure-` cookies have to have the `Secure` flag, and `__Host-` cookies have to have `Path=/`, can't have `Domain`, and might require `Secure` (depending on the setter).

From: https://www.sjoerdlangkemper.nl/2017/02/09/cookie-prefixes/

Cookie prefixes make it possible to flag your cookies to have different behavior, in a backward compatible way. It uses a dirty trick to put a flag in the name of the cookie. When a cookie name starts with this flag, it triggers additional browser policy on the cookie in supporting browsers.

The __Secure- prefix makes a cookie accessible from HTTPS sites only. A HTTP site can not read or update a cookie if the name starts with __Secure-. This protects against the attack we earlier described, where an attacker uses a forged insecure site to overwrite a secure cookie.

What legitimate use is there for overwriting a secure cookie with a non secure one?