!!! Overview
[{$pagename}] ([RFC 8471]) is established by the [user-agent] generating a [Private Key]-[Public Key] pair (possibly within a [Hardware Security Module] ([HSM]), or a [TPM]) per target server, and proving possession of the private key on every [TLS] connection to the target server.  [{$pagename}] in the course of a [TLS Handshake], a [client] and [server] can use the [Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation] ([RFC 8472]) to negotiate the [{$pagename}] [version] and the parameters (signature algorithm, length) of the Token Binding [key].  This negotiation does not require additional [Round-trips].[{$pagename}] enables client/server applications to create long-lived, uniquely identifiable [TLS] bindings spanning multiple [TLS] sessions and connections. [Applications] are then enabled to [Cryptographically|Cryptographic] bind [Security Tokens] to the [TLS] layer, preventing [token] export and [Replay attacks].
[{$pagename}] uses [Application-Layer Protocol Negotiation] ([ALPN]) protocol IDs  to negotiate the use of [{$pagename}], in addition to the actual application [protocol].

Unlike TLS client [certificates], the use of Token Binding keys does not require any interaction with the user. This is because:[1]
* it is always clear which Token Binding key to use (so the user doesn't have to be consulted), and
* the [browser] always uses a different key with different [Websites] (so the user doesn't need to give consent to use a Token Binding key).

The [Proof-of-Possession] involves signing the exported keying material [RFC 5705] for the [TLS] connection with the [Private Key]. The corresponding [Public Key] is included in the [Token Binding ID] structure (described in the "[Token Binding ID] Format" section of this [RFC 8471]). Token Bindings are long-lived, i.e. they encompass multiple [TLS] connections and [TLS] sessions between a given client and server.  To protect [privacy], [Token Binding ID]s are __NEVER__ transmitted in [Cleartext] and can be reset by the user at any time, e.g. when clearing browser cookies.

When issuing a [Security Token] to a client that supports [{$pagename}], a server includes the client's [Token Binding ID] in the [token].  Later on, when a client presents a security [token] containing a [Token Binding ID], the server makes sure the ID in the token matches the ID of the Token Binding established with the client.  In the case of a mismatch, the server discards the [token].

[Servers] generate various [Security Tokens] (e.g.  HTTP [cookies], [OAuth] [tokens]) for applications to access [Protected Resources].  Any party in possession of such [token] gains access to the [Protected Resources]. [Attackers] export [Bearer Tokens] from the user's machine, present them to the servers, and impersonate authenticated users.  The idea of [{$pagename}] is to prevent such [attacks] by [cryptographically|Cryptography] binding [Security Tokens|Security Token] to the [TLS] layer.

In order to successfully export and [Replay attack] a bound security token, the [attacker] needs to also be able to export the client's [Private Key], which is hard to do in the case of the key generated in a secure hardware module.

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Token Binding|http://www.browserauth.net/token-binding|target='_blank'] - based on information obtained 2017-03-15