Intent to Implement: Token Binding
Many web services use bearer tokens (such as cookies, OAuth tokens) for authenticating clients to servers. Attackers gaining possession of a token can reuse it to impersonate the authenticated user. Token Binding attempts to solve this problem by cryptographically binding tokens to the TLS layer. Token Binding is similar to Channel ID in its goal, but has a different implementation.
Token Binding and Channel ID both work by having the client sign part of the TLS handshake with an asymmetric key generated by the client unique for that origin. Channel ID sends its message as part of the TLS handshake, while Token Binding sends it in the application layer (HTTP).
This Intent to Implement does not cover all of the Token Binding specs; it only covers a subset needed to reach feature parity with Channel ID. This includes supporting negotiating token binding with ECDSA keys and sending the Token-Binding HTTP header. This does not include anything from section 3 of “Token Binding over HTTP”. The current implementation of Channel ID is based on a draft spec that expired two years ago. Token Binding will continue to evolve as the replacement for Channel ID.
Low risk. Token Binding includes as part of its protocol negotiation the version of the protocol being used. The client can only negotiate a single version (while the server can support multiple versions). We will switch to supporting the latest version some amount of time after its (draft) spec is published, allowing time for servers that support token binding to update to the latest version.
Microsoft is behind token binding, but their plans for support in IE or Edge are unclear. Mozilla has also chatted about it, but their level of commitment is less clear. There are no signals from Safari or Opera.
Ongoing technical constraints:
Will this feature be supported on all six Blink platforms?