poztter.org

component · model

Sub-zone Delegation.

All components · Master Zone · Survivorship · Why grant ≠ deny

The Master Zone delegates authority over each sub-zone — Identity, Email, Feed, Auth, Service — to a set of delegation keys. Each delegation key carries two values evaluated independently: grant and deny.

two thresholds, one rule

Both grant and deny follow the same ≥100 summation rule used for master-zone survivorship. To authorize a grant operation (add or modify a sub-zone entry), the signing delegation keys' grant values must sum to ≥100. To authorize a deny operation (revoke or remove an entry), the signing delegation keys' deny values must sum to ≥100. The two are checked independently — the same set of signatures might satisfy one and not the other.

flowchart LR subgraph DK[Delegation keys for Identity Zone] K1["Key A
grant = 50
deny = 100"] K2["Key B (backup device)
grant = 50
deny = 100"] end G[Grant a new identity?
need Σ grant ≥ 100] D[Deny / revoke an identity?
need Σ deny ≥ 100] K1 --> G K2 --> G K1 --> D K2 --> D
fig 01 · a two-key Identity Zone delegation. Either key alone can revoke (deny=100). Both must agree to add (grant 50+50).

why two thresholds

Real-world security policy is asymmetric. The cost of an attacker holding a credential they shouldn't is much higher than the cost of a delay in adding a new one. Splitting grant and deny lets you encode that explicitly:

The protocol-level recommendation is simple: configure higher deny authority than grant authority. It should be easy to lock things down. It should be harder to open them up. Read more on the reasoning →

how sub-zones use delegation

Each delegated zone (Identity, Email, etc.) carries the master's current_master_hash at the time it was authorized, plus the keys that the master delegated to. When a verifier walks the chain — master → authority → zone — it confirms that:

  1. The authority's master_zone_hash matches a real master revision.
  2. The master revision actually delegates to the listed keys for this zone type.
  3. The zone's signatures meet the grant threshold (for new entries) or the deny threshold (for removals).
MASTER ZONE · 0x0001 current_master_hash · 0xae3f…7c signed by master keys (survivorship ≥ 100) delegation · 0x0011 Identity Zone → keys [K1, K2] authority references master_zone_hash IDENTITY AUTHORITY · 0x0010 authority_hash · 0xc1f9…2b master_zone_hash · 0xae3f…7c authorized_keys [K1, K2] · serial · timestamp zone signed by authorized keys (grant/deny ≥ 100) IDENTITY ZONE · 0x0011 identity_zone_hash · 0x4b8c…01 entries[ ] · signatures by K1, K2 verifier walks chain back to master
fig 02 · master → authority → zone. each layer cites the layer above by hash. The verifier walks down from a master they trust; any break invalidates everything below.

constraints

see also