I'm fuzzy on token binding versus channel ID, the preceding (and, to my eyes, more useful) extension. In neither case do I anticipate widespread use. But it's good to know that it's there.
Token binding changed a few things as it evolved from origin bound certificates, notably:
* moving from using client certs to signing exported keying material[0] to prove key possession
* adding support for RSA keys
* adding support for multiple token bindings on a single connection (see referred token binding)
Fundamentally the two are very similar. I'm curious as to why you think origin bound certificates are more useful.
> In neither case do I anticipate widespread use
For the browser case:
* 0-RTT in TLS 1.3 (and resumption in general) negate a lot of the benefits of token binding. Big players aren't going to give this up (see QUIC).
* Hardware bound keys are interesting, but if crypto oracles are available on consumer machines, they are often far to
slow to be used practically.
* Many compromises happen in the browser so token binding only marginally improves the security of cookies.
I think it will fall out of favor there. The service to service use case is an interesting one. If you turn off 0-RTT and session resumption, and bind tokens to hardware, the security properties start to look a lot like hardware bound mTLS. If the tooling ever gets developed, it might turn out to be a leaner alternative to a full blown PKI.
* moving from using client certs to signing exported keying material[0] to prove key possession
* adding support for RSA keys
* adding support for multiple token bindings on a single connection (see referred token binding)
Fundamentally the two are very similar. I'm curious as to why you think origin bound certificates are more useful.
> In neither case do I anticipate widespread use
For the browser case:
* 0-RTT in TLS 1.3 (and resumption in general) negate a lot of the benefits of token binding. Big players aren't going to give this up (see QUIC).
* Hardware bound keys are interesting, but if crypto oracles are available on consumer machines, they are often far to slow to be used practically.
* Many compromises happen in the browser so token binding only marginally improves the security of cookies.
I think it will fall out of favor there. The service to service use case is an interesting one. If you turn off 0-RTT and session resumption, and bind tokens to hardware, the security properties start to look a lot like hardware bound mTLS. If the tooling ever gets developed, it might turn out to be a leaner alternative to a full blown PKI.
[0]: https://tools.ietf.org/html/rfc5705