This isn't necessarily the scope of the proposal and I don't know if it should be co-mingled, but I wonder what native apps will do. It's perhaps a different failure mode for native client tokens to be stolen because something like a malicious browser extension probably wouldn't be able to accomplish, but is another situation where session token theft can be a problem and device binding would help mitigate.

If considering attacks beyond a browser it really indicates the OS needing to provide an API for creating keys which userspace software can request operations with (sign/encrypt) but not directly access without elevated OS privileges. I'm not well-versed in the nuances of how this has been implemented.

I'm coming at this from the perspective of a Corpsec Engineer who struggles with consistent revocation of long-lived session tokens in SSO-integrated apps. This proposal doesn't address that problem, but I'm acutely aware of just how many forms sessions tokens take. On a mobile OS (iOS/Android) stealing the session tokens from another application likely implies a level of host compromise that only a TPM/Secure Enclave would mitigate, but on a desktop/laptop OS my impression is that userspace privileges could likely be used to harvest session tokens so device-binding would provide some value.

These thoughts came to reading responses to #13