block-beta
block
ActorName space:4 ActorPK
ActorName <-- "TTP" --> ActorPK
end
1 Abstract
Modern multiuser computing systems provide mature abstractions for inter-process communications which enable message-passing among processes. In this article, we introduce two protocols for trustworthy message-passing among intentional actors within an Internet-scale computing environment. One of these protocols is the EAP-MILAN protocol used by actors for initial access to the network, and the other one is the HTTPV (“Verifiable HTTP”) protocol used at the application layer as a drop-in replacement for HTTPS.
Both of the above protocols are carefully designed not to rely on any trusted third party (TTP) or on any blindly trusted statement/context. Due to this design constraint, all statements about the trustworthiness of intentional actors with observable actions are computationally verifiable 1 by each individual actor without relying on anything external to the computing environment observable by the actor.
While assumptions about the trustworthiness of observable actors do not need to be made, they may always be made every now and then by intentional actors, unless logical contradictions due to the use of the trust assumptions are discovered.
2 Background
Mature abstractions for inter-process communications or IPC are present in many modern computing environments supporting time-shared concurrent computations. One such abstraction - the UNIX pipeline - is particularly relevant to the messaging protocols introduced in this article. An important feature of UNIX pipelines is the “hiding of internals” in the context of message-passing among processes. This allows enhanced clarity in the semantics of message-passing. Implementation details such as the buffering of messages are handled by the underlying computing system.
Status-quo messaging protocols over a network typically involve first accessing the network and then using an application layer protocol, such as HTTPS (Rescorla [2000]), to perform message-passing. As shown in Figure 1, for security, Internet messaging protocols typically rely on a trusted third party (TTP) to validate the binding between a cryptographic public key (ActorPK in Figure 1) used for securing the initial access and/or the subsequent application-layer messages, and a real-world identity (ActorName in Figure 1). While the real-world identity cannot typically be used to secure the messaging link, the cryptographic public key can be, using algorithms from asymmetric key cryptography (Housley et al. [2002]). The TTP, such as a Certificate Authority (CA), is responsible for saying the equivalent of, “Yes, this person is who they say they are, and we, the CA, certify that”.
In this article we introduce protocols for initial access and secure application-layer message-passing which do not rely on a TTP. As shown in Figure 2, while these protocols still rely on a cryptographic public key for securing the messaging link, the association of public keys with real-world identities is maintained not by a TTP, but by a multiuser computing environment (CE). This unlocks enhanced observability by every actor into the effects of actions performed by other actors in the shared computing system, which then enables local and independent proofs of statements about the private intentions of the actors behind observable actions. Multiple actors may collaborate on these proofs based on their local observations about their computing environments (CEs). A single real-world actor may have multiple public keys associated with it for use in different problem-solving contexts.
Within the computing environment shown in Figure 2, there is no need for any actor to assume the role of a TTP, even though local conjectures about the trustworthiness of actors may be heuristically introduced every now and then to speed up contradiction-finding computations. All changes in the association between the real-world identity of an actor and its cryptographic public key may be discovered and/or queried using deterministic computational tools available to all the actors within the computing environment (CE).
block-beta
block
ActorName space:4 ActorPK
ActorName <-- "CE" --> ActorPK
end
3 Protocols for initial access and secure message-passing
3.1 Initial access
Prior to exchanging messages, actors need to connect to a network, such as the Internet or a local Intranet, to which other actors are also connected. This is similar to actors logging in as an user to an UNIX-like system, but is different in that actors cannot assume a root of trust, such as a /etc/passwd file. Common standards for networking include Ethernet (IEEE 802.3), WiFi (IEEE 802.11), WiMAX (IEEE 802.16) and LTE (currently 3GPP LTE Rel-19). All of these standards support the EAP framework (Vollbrecht et al. [2004]) for authentication and initial access (either as a required feature of the standard or as an optional feature), so we leverage this framework for an initial access protocol which does not rely on a TTP. We name this protocol EAP-MILAN, Milan being an Indian word for “coming together”.
Unlike many incumbent protocols for initial access, such as EAP-TLS (Simon et al. [2008]), 5G-AKA (3GPP [2025]), and EAP-AKA’ (Arkko et al. [2009]), EAP-MILAN does not rely on any TTP. This enables full computational verifiability of statements by an actor about its initial access to the network and its subsequent use of the network towards message-passing with other actors participating in concurrent computations.
3.2 Secure message-passing
After initial access, messages to actors may be exchanged via secure application layer protocols. An incumbent protocol for secure application-layer message-passing is the Secure HTTP or the HTTPS (Rescorla [2000]) protocol, which relies on a TTP - a trusted Certificate Authority (CA). Since we have the constraint that we cannot rely on a TTP, we develop the Verifiable HTTP or the HTTPV protocol as a drop-in replacement for HTTPS.
Instead of relying on a TTP, the HTTPV protocol relies instead on abstractions provided by a computing environment (CE) accessible to all actors. Some of these abstractions are described in the next section and elaborated on further in future articles.
3.3 Abstractions provided by the CE
The computing environment (CE) provides various abstractions for anchoring trust among actors using the environment so these abstractions are called trust anchors. These anchors, typically expressible as executable code or data structures with precise semantics within the CE, then inform the overall trust invariants offered by the CE without relying on any TTP. If the CE is Linux running on a single physical computer, examples of such trust anchors include the Linux kernel and various runtime in-kernel data structures such as those exposed via the /proc filesystem on Linux. When the CE is a decentralized computing environment such as Solana executing on multiple physical computers (also known as validator nodes), examples of such trust anchors may be smart contracts and various runtime data structures associated with executing these smart contracts on the CE, such as a ledger of transactions representing the output from executing instructions within the smart contract.
Specifics of the trust anchors used in EAP-MILAN and HTTPV will be discussed in future articles. Some design considerations involved with developing these trust anchors are common to all verticals, while some are unique to certain verticals only. These considerations are influenced primarily by the set of possible private intentions among the actors who use these trust anchors.
4 Summary
In this article, we introduced EAP-MILAN - a protocol for trustworthy access to networks by actors, as well as HTTPV - a protocol for secure message-passing among actors within the same network. Unlike many incumbent protocols, these protocols do not rely on a trusted trusted party (TTP), but on trust anchors which have precise semantics with a computing environment (CE). These trust anchors are computer programs or various runtime data structures associated with their execution within a CE.
5 Changelog
This document was first published on December 16, 2025. It was last modified on December 20, 2025.
6 Feedback
The author of this article would love to hear your feedback at hello@milaneum.io. In your message, please consider including the name of the article, the listed identity of the Milaneal author of this article, and the semantic version.
References
3GPP. 2025. Authentication and Key Management for Applications (AKMA) based on 3GPP credentials in the 5G System (5GS). https://www.etsi.org/deliver/etsi_ts/133500_133599/133535/19.00.00_60/ts_133535v190000p.pdf.
Arkko, J., Lehtovirta, V., and Eronen, P. 2009. Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA’). https://www.rfc-editor.org/info/rfc5448.
Housley, R., Polk, T., and III, L.E.B. 2002. Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. https://www.rfc-editor.org/info/rfc3279.
Simon, D., Hurst, R., and Aboba, Dr.B.D. 2008. The EAP-TLS Authentication Protocol. https://www.rfc-editor.org/info/rfc5216.
Vollbrecht, J., Carlson, J.D., Blunk, L., Aboba, Dr.B.D., and Levkowetz, H. 2004. Extensible Authentication Protocol (EAP). https://www.rfc-editor.org/info/rfc3748.
Footnotes
Even though statements may, in theory, be verifiable; in practice the computational cost of some kinds of verification may be too prohibitive unless algorithmic or architectural advances are made.↩︎