[IgorPartola]

Almost. Cookies are way too permissive and complex. What I am thinking of is essentially a Session: abcdef12345 type of header that would be used for authentication/sessions. This header would be directly tied to the domain I am talking to and should have a simple expiration (or not) policy that the web server may suggest but I can override. No more X-PHP_Session_widget_co-referer: … type crap. No multiple cookies. No large storage. No HTTP vs HTTPS, no HTTP-only, no third party anything. path is the only thing I am somewhat ambivalent about because it does present a certain complication but also allows you to have applications that aren’t at the top of the domain.

Along with this we have a browser API we can call Authentication with something like Authenticate.prompt() and Authenticate.clear(). prompt() would bring up the standard browser UI for logging in and the parameters to it would dictate how the authentication should happen: username and password, 2FA options, private/public key, client certificate, etc. Registration could be handled in the same UI or have a separate API. clear() lets you have an internal logout button or mechanism on the site. The same APIs should be available via HTTP headers for non-JS usage.

As a bonus, we can then develop a mechanism for creating a session ID based on me having a private key that has an associated identity with with. So when I am prompted with a login UI instead of entering usernames and passwords I can simply choose from a drop down which identity I want to use for this site. Of course the problem of syncing private keys across devices is hard, but not any harder than what password managers currently do with my passwords.