Change:
tokens are an option in GNAP, these types of tokens have their own tradeoffs discussed elsewhere in this section. <del> TLS functions at the socket layer, ensuring that only the parties on either end of that socket connection can read the information passed along that connection.  Each time a new socket connection is made, such as for a new HTTP request, a new trust is re-established that is unrelated to previous connections.  As such, it is not possible with TLS alone to know that the same party is making a set of calls, and therefore TLS alone cannot provide the continuity of security needed for GNAP.  However, mutual TLS (MTLS) does provide such security characteristics through the use of the TLS client certificate, and thus MTLS is acceptable as a key-presentation mechanism when applied as described in mtls. </del> <ins> TLS functions at the transport layer, ensuring that only the parties on either end of that connection can read the information passed along that connection.  Each time a new connection is made, such as for a new HTTP request, a new trust is re-established that is mostly unrelated to previous connections.  While modern TLS does make use of session resumption, this still needs to be augmented with authentication methods to determine the identity of parties on the connections.  In other words, it is not possible with TLS alone to know that the same party is making a set of calls over time, since each time a new TLS connection is established, both the client and the server (or the server only when using mtls) have to validate the other party's identity.  Such a verification can be achieved via methods described in I-D.ietf-uta-6125bis), but these are not enough to establish the identity of the client instance in many cases. To counter this, GNAP defines a set of key binding methods in binding-keys that allow authentication and proof of possession by the caller, which is usually the client instance.  These methods are intended to be used in addition to TLS on all connections. </ins> 12.3.

Discussion:
Built To edit notification comments on pull requests, go to your .
The last paragraph of Sec. 12.2 is a bit off. From an IETF perspective, we should be using "transport layer" (TCP, or OSI layer 4) instead of "socket layer". More importantly, modern TLS uses session resumption heavily, meaning that the trust relationship does not end when the L4 connection ends. Granted that we often need to re-authenticate, but the explanation should be more precise.
If you can, please provide more precise text to help this section out. Thanks!
NAME I cannot agree more on that. The specification may also suggest setting the Connection HTTP header to "close" when it isn't desirable to reuse the same connection.
I tried rewriting the text but then realized that the text is incorrect in a deeper way than I commented on. The current text is: The word "continuity" is misused here. MTLS does provide mutual authentication of the TLS session (a TLS session consists of multiple connections). But it doesn't provide continuity, in the sense that each TLS session is authenticated separately, and there is no session identifier bound to all requests. So we need to figure out if "continuity" is a requirement, if it is, address it, otherwise we shouldn't claim to have it but settle on mere mutual auth.
It seems the initial intent is indeed to go beyond mutual authentication, although the related "discontinuity" risks are not called out. For my understanding, by TLS continuity, do we mean a way to resume sessions ? Like session ID or session tickets or PSK ? Or something else ? In my view (perhaps incorrect, because I'm just a basic user of such systems, not a TLS/mTLS designer) : a big part of the difference between TLS + PSK and mTLS seems related to key management. with PSK a secret key is shared between client and server, so we get back to the discussion on out of band key distribution with PKI, we only need one private key per entity, and possibly the setup is simplified by a trusted certificate chain
I would suggest to drop the "continuity" word, and instead, have a normative statement saying that both client and server (server only when using MTLS) MUST validate the other party's identity (RFC 6125-bis, possibly with our own twist) on each new L4 connection.
Yes, we'll do that.