0PN · Openness Code of Practice

Openness before identification

The 0PN Online Openness Code of Practice sets six conditions for the public read side of the 0PN Directory. Together they keep published controller records, notices, receipts, logs and index information freely inspectable by people and machines. It is expressed as testable conditions, not general intentions: if any condition fails, the service is not open under the code.

Version 0.3 · effective 30 August 2026 · 0PN-v0.3 (supersedes 0PN-v0.2, which remains readable)
Counterpart to the ITCoP

What this code is

This code is the counterpart of the Internet Transparency Code of Practice. The ITCoP specifies what controllers publish about themselves; the Openness Code binds the operator of the service that publishes it, to the 0PN transparency signal. The rules are stated as testable conditions rather than intentions, so a claim to serve under 0PN can be checked rather than merely trusted.

The commitment

The six conditions

All six hold together. Any one of them failing makes the service closed, whatever the marketing says. Each is numbered so a record, the licence, or the constitution can cite a specific article.

0PN-1

No fee to read

Public transparency information is available without payment. Not a free tier. No read path metered by identity or by volume in a way that functions as a price.

0PN-2

No login to read

A person does not identify themselves before inspecting a published record. Authentication on a read is identification before inspection, the posture this service exists to reverse.

0PN-3

No contract to read

No click-through terms, no API key, no acceptable-use agreement between a person and a published record.

0PN-4

No dependency on a paywalled standard

Everything published can be parsed and checked using only freely available specifications. Alignment with a paid standard must not make buying it a condition of inspection.

0PN-5

Machine-readable and human-readable as peers

Both forms are published as equals. Neither is delayed, restricted, or offered only as a paid upgrade of the other.

0PN-6

No observation of the reader

No analytics on read paths, and no record of who inspected which controller beyond a minimal operational floor. Never used to profile inspectors or to tell a controller it was inspected.

Governance

Who the code binds

0PN is a registry brand operating a two-node Directory service.

  • The UK node, uk1.0pn.org, is operated by and accountable to Global Privacy Rights (GPR) during the interim period.
  • 0PN UK CIC, currently in incorporation, is the named successor UK registrar, authority and accountable operator. The role transfers when the CIC incorporates and accepts it.
  • The Canada node, ca1.0pn.org, is operated by GPR.
  • GPR is also the global badge issuing and credential attribution party. In that role it does not act as controller or processor of the published records.
  • TCIEG UK is a consulting party and registrant number one. It is not the Directory service operator.

UK-node records are held in the United Kingdom under UK GDPR. The UK service does not depend on Canadian adequacy and does not require a UK Article 27 representative.

Coverage

What the code covers

The code covers anything people can read publicly, including web pages and API endpoints that publish:

  • Controller Identification Records
  • notices and transparency policies
  • Notice Receipts
  • Notice Event Logs
  • public index information

The code does not make private administration or write functions public. Registration, record changes and other write operations stay behind authentication and security controls.

Checking a record

A free validation path

Although the record structure aligns with ISO/IEC TS 27560:2023, checking a published 0PN record must not require purchase of the standard. The free validation path uses the ANCR TS 27560 extension, the Kantara ANCR Working Group Consent DPV vocabulary, and Convention 108+ as the legal anchor. A public 0PN JSON schema for machine validation is pending publication.

Reads during alpha

Public reads while the directory is in alpha

Published records require no login to read. Registration and write operations remain permission-gated. During alpha the public index is served only partially: this is a named, dated, temporary exception, not a standing authentication requirement on reads. Full public read access to every published record remains the launch target.

Mirrors

Mirrors and stable addresses

The published read side is meant to be copyable and independently verifiable, subject to the licence being finalised. A mirror should state when it last synchronised and must not present itself as the origin. Because the Notice Event Log is hash-chained, a mirror is checkable rather than merely trusted. Published addresses stay stable; if a rename cannot be avoided, the previous address redirects permanently.

Change control

How the code changes

Changes are versioned and dated, and previous versions remain readable. Any change that narrows one of the six conditions is a breach of the commitment. Version 0.3 supersedes version 0.2 only in relation to operator identification; the six openness conditions are unchanged.

Current position

Where the implementation stands

Conditions 0PN-3, 0PN-4 and 0PN-5 are still in progress, and the record licence is being finalised. These items are stated openly rather than presented as complete. Global Privacy Rights supports this commitment as evidence of control: an individual should be able to verify who is accountable before any identification is demanded. It is not a general claim of legal compliance, certification, or universal trust.