The Transparency Stack, and where it sits on the OSI model
Ask an engineer where something happens on the internet and you get a number. Ask where privacy happens and you get an argument. What the OSI reference model settles, and what it does not.
The internet has a reference model. Privacy does not.
Ask an engineer where something happens on the internet and you get a number. Routing is three. Transport is four. The web is seven. The Basic Reference Model for Open Systems Interconnection, ISO/IEC 7498-1, has given that vocabulary to four decades of network engineering, and it works because it is precise. A layer provides a service to the layer above it and to the layers beneath it (clause 5.2.1.5). Entities within the same layer talk to each other by protocol (5.2.1.3). And a layer can be replaced without disturbing the others.
The model is also more modest about itself than its reputation suggests. Clause 6.2.1 sets out eleven principles for deciding what constitutes a layer, and prefaces them: "It may be difficult to prove that any particular layering selected is the best possible solution." Forty years of use has not made that sentence untrue.
Ask where privacy happens and you get an argument.
That is not a small problem. It is why compliance discussions go in circles, why a transparency requirement can be answered with a cookie banner, and why nobody can say whether a given control is in the right place. Without a reference model there is no wrong answer.
What we have been building
The Internet Transparency Code of Practice, and the ISO/IEC work item that profiles it, describe a chain of instruments. Each derives its authority from the one above it and returns evidence to it.
| Level | Instrument | What it settles |
|---|---|---|
| Treaty | Convention 108+ | That transparency and rights are owed |
| Code | Internet Transparency Code of Practice | What an organisation must publish and what a person may check |
| Profile | ISO/IEC work item, SC 44/WG 1 | How the base standards are selected and constrained |
| Practice | The disclosure as actually performed | Whether the code was followed on this occasion |
| Record | ISO/IEC TS 27560:2023 and the notice record extension | The structure of the evidence |
| Registry | Public transparency register | Where controller identification resolves |
It is tempting to call these layers. They are not, and the distinction matters.
A treaty does not provide a service to a code. It confers authority. There are no peer entities exchanging protocol messages at the rank of treaty. And while a record structure can be replaced without disturbing the treaty above it, a treaty cannot be replaced without disturbing everything below.
There is some comfort in the model itself here. Clause 7.1.3.1.3 states that "There exists no Application Layer service in the sense of (N)-layer service in that there is neither a general service provided to an upper layer nor a relation to a service-access-point." OSI's own top rank is an exception to the service property. Not everything useful is a layer, and the people who wrote the model said so first.
So this is a chain rather than a stack. Authority runs downward, evidence runs upward, and neither of those is what a layer boundary does.
Where the OSI mapping is real
The chain is not layered. The artefacts are, and that is where the reference model earns its place.
| Artefact | Where it operates |
|---|---|
| Controller identification record | Rank 7, carried by ranks 1 to 6. The lower ranks provide the capability; they do not perform the retrieval (5.2.1.5) |
| Online notice as presented | Rank 7 |
| Notice receipt | Rank 7 |
| Notice event log | Outside the model. OSI describes communication between open systems, not records retained after an exchange |
| The direct relationship case | The network and the device, ranks 1 to 3 |
One consequence, and it is the reason this note exists.
A central requirement of the code is that a person can inspect a disclosure before being identified. Written as policy, that is a statement of intent and an implementer can argue about it. Written against the reference model it becomes a structural parallel with a clause behind it. The model places identification of the intended communication partners, and agreement on security aspects including authentication and access control, at rank 7 (clauses 7.1.3.2 a) and e)). Identification is therefore a function of the topmost rank, not a precondition of the ones below it.
The parallel has a limit, and it is worth stating plainly rather than glossing. OSI's partners are application-entities, not people. Clause 7.1.2.3 says an application-entity represents one and only one application process, and the word authentication appears exactly once in the whole text. So the model does not tell us anything about identifying human beings, and any argument that claims otherwise is borrowing vocabulary it has not earned.
What it does give is a shape. Identification belongs at the top; retrieval does not require it. A disclosure that must be readable before identification has to be retrievable without an exchange in which identification has occurred, and that is testable. You can check whether a record resolves without a login, without a session and without a contract.
Why the openness conditions are the same conditions
The 0PN Openness Code sets six conditions for a service that claims to be public infrastructure. No fee to read. No login to read. No contract to read. No dependency on a paywalled standard. Machine readable and human readable as peers. No observation of the reader.
Read against the reference model, the second and third are testable as properties of an exchange: no login and no contract means the record is retrievable without the functions the model places at rank 7. The first, no fee, has no analogue in OSI at all, which is worth admitting rather than assimilating.
The fourth is about the specification rather than the record, and it has a pleasing property here. The reference model itself is free. ITU-T Recommendation X.200 carries the identical text to ISO/IEC 7498-1:1994, and it downloads from itu.int over plain HTTPS with no fee, no account and no click-through. Building on it introduces no paywalled dependency, which is the condition we set for ourselves.
A rule the public is expected to rely on has to be readable by the public. That applies to the standards behind the rule as much as to the rule.
What this bridges
Three things, and none of them requires anything new to be invented.
It gives the argument a shared vocabulary with the people who build the internet. Standards bodies, network engineers and supervisory authorities have all been talking past each other about where transparency belongs. A reference model is how that conversation stops being about opinion.
It makes a policy requirement into a conformance test. Before identification stops being a phrase to negotiate and becomes something a conformity assessment body can check.
It shows the work is placement rather than invention. Nothing in this proposal asks for a new mechanism. The record structures exist. The reference model is forty years old and free. What has been missing is the statement of where the transparency artefacts sit, and what has to be true of them at that position.
Privacy has never had a reference model. It has had principles, which are not the same thing, because a principle cannot tell you whether a control is in the right place.
That is worth fixing, and most of the parts are already on the shelf.
TCIEG works on transparency and consent interoperability, and on the Internet Transparency Code of Practice with the Council of Europe. The ISO/IEC work item referenced here was established by resolution at the fifth plenary of ISO/IEC JTC 1/SC 44 in September 2026.
