What the project specified about subscriber identity privacy

The three divide the problem in a way that is still recognisable. One addresses protecting the identity at the point of disclosure, which is the exchange described on the mechanism page. One addresses breaking the association between a device and the identity it presents, which is a different objective: not concealing the identity but making it a poorer handle on the device. The third addresses privacy policy analysis, which is neither of those and belongs to the question of whether a network’s stated handling of subscriber data can be checked against what it actually does.

A fourth item appears in the project’s own privacy cluster and has no specification in this archive. It is listed in the enabler catalogue without a record page, because there is no document to serve. That gap is in the source material.

The project ran while the first 5G security architecture was being written, and neither before nor after it. That places these documents in an unusual position: they describe a problem that was still open, using an architecture that was still moving, and they were contributed into a standardisation process through the partnership the project belonged to, and were not submitted as finished answers.

What was eventually standardised addresses the same disclosure by concealing the permanent identifier before transmission, as the concealment page describes. The resemblance in objective is close. The resemblance in objective is not evidence of derivation: many groups were working on the same problem at the same time, the problem had been publicly understood for years, and convergence on encrypting an identifier to its home network is not a distinctive enough idea to attribute on similarity alone.

So the useful reading of these documents is as a record of the state of the question in the middle of the transition, by a group with access to the architecture as it was being settled. That is a genuine historical value, and it is a smaller claim than the one a reader might expect a research archive to make about its own contents.

The nine pages in this silo are not summaries of the specifications, and they are not presented as project output. They describe where the subject stands, drawing on the documents where the documents are the best available source and on the published standards where those are. The distinction is maintained page by page: statements about what the project specified are attributed to it, and statements about what networks do now are not.

The documents themselves are short by the standards of the collection, which is worth knowing before opening one. They are enabler specifications: each states a problem, describes a design, and defines what an implementation would have to provide, at the length that a project deliverable review requires and no more. Readers arriving from a citation for the project’s broader security position are usually looking for the architecture and risk documents in the deliverables index instead, which are several times longer and carry the reasoning these specifications assume.

The reason for keeping them separate is that the archive’s value depends on it. A reader arriving from a citation wants to know what a 2017 document said, and a reader arriving from a search wants to know how identity exposure works today. Answering the second by quietly rewriting the first would damage the thing that makes this collection worth keeping.