component · 0x0010 / 0x0011

Identity Zone.

All components · Master Zone · Delegation

The Identity Zone is where your POZ record says: "this handle on this provider is mine." Each entry is independently attested by the provider; the zone as a whole is signed by you, asserting you assembled and accepted this set.

what an entry looks like

Each identity entry binds four things together: an authority (who is attesting), a path (optional sub-namespace within the authority), a user handle, and a hash of your POZ record. The authority signs the binding with its delegation key.

identity_type      = 0x01 (POZ)
authority_hash     = <authority's original_master_hash>
authority_domain   = "twitter.com"
path               = []                    ← optional segments
user_handle        = "alice"
user_poz_hash      = <your original_master_hash>
authority_signature = <signed by authority's delegation key>

Because the authority binds your handle to your permanent POZ identity (original_master_hash, set at genesis and never changed), the binding survives every subsequent revision of your Master Zone. Adding new master keys, or rotating delegation keys, doesn't invalidate existing identity entries.

two layers of signatures

Per-entry authority signature. Each authority independently signs its own entry. A single Identity Zone can carry entries from many authorities, each verifiable on its own.
Zone-level user signature. You sign the full zone — including every authority signature — so anyone can confirm you assembled and accepted this exact set of identities. A provider can't add an entry to your zone behind your back.

two-phase activation

Identity entries are issued through a two-phase commit so that an authority's attestation and the user's acceptance are both required, and neither is a single-step takeover risk.

sequenceDiagram autonumber participant U as User participant A as Authority U->>A: SUBMIT_REQUEST (handle + POZ hash + proof signature) A->>A: Verify proof, check policy A-->>U: signed identity entry (PENDING on authority) U->>U: Collect entries from all authorities U->>U: Assemble + sign Identity Zone U->>A: SUBMIT_SIGNED (full zone) A->>A: Verify all signatures A-->>U: ACCEPTED (handle activated)

fig 01 · two-phase activation — authority signs, user assembles, authority confirms.

Until the final signed zone is submitted, the previous Identity Zone remains live. A partially signed zone is never served. Updates are atomic from the outside.

fig 02 · two layers of signatures: each entry signed by its provider (verifiable on its own), and the whole zone signed by the user (proving she assembled and accepted them).

what the authority verifies

The protocol leaves the actual identity check up to the authority — OAuth, email challenge, manual review, knowledge-of-existing-account, whatever the provider already does. POZ doesn't try to dictate how identity verification works; it just provides a signed, portable record of the result.

path segments

The optional path field is for authorities that have internal namespaces (a company that issues identities for multiple sub-products, for example). Most simple cases leave it empty.