poztter.org / what is POZ

What is POZ?

Overview · Philosophy · Components · FAQ

POZ — Portable Ownership Zone — is a collection of open standards: a binary file format, a network protocol, and a set of cryptographic operations. A POZ record is a self-contained, signed identity that you can hand to anyone, anywhere, and they can verify without trusting the server it came from.

the problem POZ solves

Online identity today is a pile of accounts, each one owned by the platform that issued it. You have no portable proof of ownership that survives the failure or malice of any single provider — and the existing decentralized alternatives (PGP web of trust, blockchain DIDs) either don't address how most people are actually discovered and contacted, or pile on costs and complexity that keep them niche.

POZ takes the opposite path: centralized providers continue to exist and continue to be where people are discovered. POZ just changes who owns the relationship. You hold the record. The provider attests to a binding. Trust the provider, you transitively trust the binding.

the file

A POZ record starts with the bytes POZ, a version, and a length. What follows is a table of contents pointing at typed sections — keys, the master zone, zone authorities, and zone data.

POZ │ v0 │ size           ← 8-byte file header
TOC entries → offsets
┌────────────────────────────────┐
│ 0x0000  Public Key Map         │  required
│ 0x0001  Master Zone            │  required — root of authority
├────────────────────────────────┤
│ 0x0010  Identity Authority     │
│ 0x0011  Identity Zone          │  ← who you are on which platform
│ 0x0030  Email Authority        │
│ 0x0031  Email Zone             │  ← inboxes, addressed by GUID
│ 0x0040  Auth Authority         │
│ 0x0041  Auth Zone              │  ← trust groups for login
│ 0x0050  Service Authority      │
│ 0x0051  Service Zone           │  ← where to find your servers
├────────────────────────────────┤
│ 0x8002  Private Key Map        │  optional, encrypted at rest
│ 0x8003  Zone History           │  optional
│ 0x8004  Key Names              │  optional
└────────────────────────────────┘

the master zone

The master zone is the root of all authority in a POZ record. It says which keys control the record itself, and which keys are delegated authority over each sub-zone. Every revision is hash-chained to the previous one and signed by enough authorizing keys to clear a threshold.

One key is enough in the simplest case. For higher assurance, ownership is distributed across several keys — so the loss or compromise of any single one doesn't take the record down. The same model scales from an individual all the way to critical infrastructure.

survivorship — built for compromise

The master zone uses a threshold model. Each key has a value; authorization requires a set of signing keys whose values sum to at least 100. With one key at 100, you get sole ownership. With three keys at 34/33/33, you require all three to act. With a hardware key at 100 plus a separate recovery group, you get a daily-use path and a backup path that don't share dependencies.

The point isn't the specific numbers. The point is that POZ treats key compromise as something to be planned for, not avoided. Every cryptographic key will eventually be broken. A protocol that doesn't account for it is one good incident from disaster.

grant and deny — asymmetric authority

When the master zone delegates to a sub-zone (Identity, Email, Feed, Auth, Service), it gives each delegation key two independent values: a grant value (authority to add or modify entries) and a deny value (authority to revoke or remove them). Both follow the same threshold rule, but they're evaluated separately.

This makes a useful pattern natural: configure two devices, each with grant=50, deny=100. Either device alone can revoke a compromised credential (fast incident response). Both devices must agree to add a new credential (deliberate authorization). Locking down is unilateral; opening up is consensual.

identity — bindings to the world

The master zone's hash uniquely identifies the record but tells a human nothing. The Identity Zone is where the record connects to names that humans actually use.

An identity entry is a signed link from one record (the provider) to another (the user). The provider uses its own signing keys to attest the binding. Concrete cases:

• Trust a social media company? You can trust the handle they issued.
• Trust a domain registrar? You can trust the domain they sold.
• Trust a phone carrier? You can trust the number they assigned. The same applies to postal addresses.

The result is a web of attestations. To impersonate someone, you would need to forge not one binding but every binding in the chain — every provider, all at once.

the network

POZ records are distributed over a small purpose-built TCP protocol — not HTTP, not a blockchain. Three ports do all of it:

Discovery uses what already works: a _poz._tcp DNS SRV record points to servers, a _poz TXT record binds the domain to a specific master hash, and an HTTPS /.well-known/poz file is the fallback. Cross-validating multiple paths is the whole point — compromising the binding requires compromising DNS and PKI and the POZ chain.

what POZ is not

• Not a blockchain. No global consensus, no token, no mining. Every POZ record is its own little signed chain.
• Not a replacement for DNS or TLS today. POZ uses both during the transition. The ambition is independence; the design is cohabitation.
• Not a single product. POZ is a format and a protocol. The Poztter project provides a reference library and tools; anyone can implement against the specs.

read next