It seems the answer to Q#1 is "No" (which suggests I would need to look for some other solution, which is something I can do on my own, please don't spend time making suggestions for that) and that makes Q#2 the thing I'm still seeking information about.
The functionality in question seems sufficiently useful, and is sufficiently obvious, that it's omission suggests to me that there may be something interesting going on that prevents it from being offered. If anyone knows that why, I'd like to find out about it. (Unless it's "politics", in which case I have no interest in knowing any more than that.)
- Is there a way to do "this thing I want to do"?
- If not, why not?
- Is there some subtle security issue with it?
- Is it too easy to abuse?
- Are there better alternatives for client tracking?
- Are the benefits over existing options not enough to warrant the effort of adding it to the relevant standards?
"This thing I want to do":
TLS provides the ability for the client to authenticate itself via a certificate signed by a CA that the server claims to trust. This seems like it would be a rather robust way to implement client/session identification (as distinct from user identification) that could then be used as a basis for application logins and what not. This could have very similar semantics to cookies, but would be strictly better because the sensitive values are never available without access beyond what the browser normally gives.
Some initial research seems to suggest there isn't a way to do this without some degree of user interaction, furthermore, it seems a lot of the moving bits that would be involved have been changed so as to go out of their way to make it impossible.
What I'm thinking I'd like to see is a process where a unknown, un-trusted, never before seen client contacts a server and before the first page finishes loading (and without user interaction) constructs and installs a client side x.509 certificate with an opaque identity (e.g. some random number or fingerprint; the server may not know who you are, but it can know it's the same anonymous someone) that any further HTTPS request will include. From there any future authentication/access control steps can be pinned to that cert rendering it them non-transferable.
It looks like there used to be a
<keygen /> tag in HTML5, but it was deprecated/unimplemented/removed and all the proposed alternatives seem to require user interaction. For example depending on the OS cert-instillation process, expecting the user to provide a password for the public key, installing a plug-in or extension, having a hardware token, etc.
The goal isn't anonymity but rather something that can be setup with minimal prerequisites that gives an "identity" that can't be faked without a general compromise of the client. ("Already being on the other side of the airtight hatchway.") MITI proxies mandated by pointy-haired-IT, third party JS, overly permissive ACL's on the server side DB, full plain-text transcripts of all the network traffic ... even with any or all of those, an attacker shouldn't be able to impersonate the "identity".
Also, the question of "who is this identity really?" and "what should this identity be allowed to do?" are different questions that would/could be addressed later via traditional logins, some kind of SSO, MFA, bootstrapping to another cert with more fields, signed-cookies-binding-the-cert-to-a-grants-list, ... whatever.