- From: Christoph Braun <braun3@fzi.de>
- Date: Wed, 7 May 2025 15:57:04 +0200
- To: <public-lws-wg@w3.org>
Dear LWS WG, I'd like to follow up on our discussion of server-to-server authentication from the call on 2025-05-06 [1] and add to the discussion around differences between WebID+TLS [2] (and mTLS [3] in general) and HTTP message signatures [4]. In particular, I'd like to highlight conceptual differences between the two: WebID+TLS as a form of mTLS creates an authenticated channel on the transport layer (Layer 4 of the OSI model) where both the client and the server are mutually authenticated. mTLS is an authentication protocol (and so is WebID+TLS). The protocol specifies how client and server prove their identities to each other before any application data is sent. HTTP Message Signatures, by contrast, provide a mechanism to sign specific parts of an HTTP message (e.g., headers, body, or a digest) to ensure integrity and authenticity of those components. In the general case, especially when critical elements like the request target (recipient) or host header (sender) are not included in the signature, message signatures cannot guarantee that the message was received directly from a particular client. They only prove that a given party with access to a private key signed the message at some point. HTTP Message Signatures alone do not constitute an authentication protocol, though they can be used as a building block for one at the application layer (Layer 7 of the OSI model). In that sense, comparing HTTP Message Signatures directly with mTLS, WebID+TLS, or the OAuth 2.0 Client Credentials Grant may be misguided. Instead, we should evaluate complete authentication protocols: mTLS-based approaches, OAuth 2.0 Client Credentials or particular authentication protocols that leverage HTTP Message Signatures. This would allow us to discuss the tradeoffs of specific protocol designs more meaningfully. On the idea of creating an authentication protocol that re-uses different specifcations at different layers: We already examined such attempts from the SSI community - I'd like to promote careful consideration of the resulting protocol's security properties [5]. Looking forward to the discussion. Cheers Christoph [1] https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250505T100000/ [2] https://www.w3.org/2005/Incubator/webid/spec/tls/ [3] https://en.wikipedia.org/wiki/Mutual_authentication#mTLS [4] https://www.rfc-editor.org/rfc/rfc9421.html [5] Christoph H.-J. Braun, Ross Horne, Tobias Käfer, Sjouke Mauw: SSI, from Specifications to Protocol? Formally Verify Security! WWW 2024: 1620-1631 (https://doi.org/10.1145/3589334.3645426, Open Access)
Received on Wednesday, 7 May 2025 13:57:13 UTC