The general idea is that the Identity Provider will generate an identity assertion that can be submitted by the browser only over a certain HTTPS channel. The Relying Party can then evaluate the identity assertion (making sure that it was, indeed, submitted by the browser over an appropriate HTTPS channel), and set a channel-bound cookie in response.

With Token Binding, the browser will typically use a different key to authenticate to the Relying Party than it uses to authenticate to the Identity Provider. Therefore, in order to create an identity assertion that is bound to the key used with the Relying Party, the Identity Provider needs to know what that key is (sometimes also called a "proof-key"), and needs to be told in a secure manner. For this purpose, Token Binding allows browsers to prove possession of more than one key in the Sec-Token-Binding Header:

In the example above, the Identity Provider receives proofs from the browser that it possesses both K1 and K2. The Relying Party has to signal to the browser that it's ok to reveal a Token Binding key that it's not normally using with the Identity Provider (K2) to that Identity Provider. From a privacy perspective, that's ok because the Identity Provider knows the browser's identity with respect to the Relying Party (in fact, it's its job to establish that identity). 

The Token Binding specs explain how the Relying Party can signal to the browser to include proof of key possession of not one, but two keys to the Identity Provider as shown above. (This happens through a header that is part of an HTTP response redirecting the browser from Relying Party to Identity Provider.)

Once the Identity Provider knows which Token Binding key the browser uses with the Relying Party (in the above example it's K2), it can issue a channel-bound identity assertion to the browser. In the example above, the assertion issued should be bound to K2:

The Proof of Possession for JWT specification describes in detail how a JSON-based identity assertion, such as those used in OpenID Connect, can be bound to a client's public key. This means that if Token Binding is used in conjunction with the Proof of Possession for JWT specification, OpenID Connect can be made secure against man-in-the-middle attacks.

Similar to the protocol outlined above, existing federation protocols such as SAML or OpenID Connect can be hardened by binding their respective identity assertions to the underlying HTTPS channels, using the Token Binding to prove possession of two separate keys to the Identity Provider.