The authoritative deny
A grant is only as good as the revoke behind it. In the data platform there is one canonical governance edge, and a revoke on it is the authoritative deny at every serving face, the Data Exchange marketplace, the Delta Sharing protocol, and the Iceberg REST catalog alike. Withdraw access once, and serving actually stops everywhere.
One edge, three faces
The platform serves the same governed data through three faces:
| Serving face | What it serves |
|---|---|
| Marketplace | Cross-organization offer listings in the Data Exchange. |
| Delta Sharing | The open Delta Sharing protocol for any consumer. |
| Iceberg REST catalog | Iceberg-native consumers over the open REST catalog. |
All three read authorization from the same canonical edge. That edge is a
grant recorded as a (principal, privilege, securable) row in one canonical
access-control plane, the catalog access-control list. ("Edge" here is a grant
edge in that graph; it is unrelated to the edge deployment.) There is no
per-face copy of the grant to fall out of sync, so a revoke cannot succeed on one
face and quietly leave another serving.
A single access-lifecycle service is the one orchestration point for
request, approve, deny, revoke, and resolve across every sharing path,
so the historically divergent flows share one contract and one record of truth.
Figure C9: one edge, three faces. The same canonical governance edge (green) authorizes all three serving faces, the marketplace, Delta Sharing, and the Iceberg REST catalog. A single revoke on that edge (red, dashed) is the authoritative deny at all three faces at once: there is no per-face copy of the grant to fall out of sync, so serving actually stops everywhere. An ungoverned asset is deny-closed, refused, not open by default. This holds identically single-cell and multi-cell, sovereign and cloud.
Table equivalent
| From | Relationship | To | State (meaning) |
|---|---|---|---|
| Canonical governance edge | authorizes | Marketplace (Data Exchange) | verified (green) |
| Canonical governance edge | authorizes | Delta Sharing protocol | verified (green) |
| Canonical governance edge | authorizes | Iceberg REST catalog | verified (green) |
| One revoke on the edge | denies the next read at | All three faces at once | deny (red, dashed) |
Deny-closed by default
An ungoverned asset is refused, not open by default. The absence of a grant is a denial, not a gap that defaults to access. That is the same principle the Security governance plane applies at the action boundary: the gate can say no, and silence means no.
What a revoke does
- Removes the grant on the canonical edge.
- Denies the next read at all three serving faces.
- Tears down the provider and stamps the originating request revoked with a signed, hash-chained decommission receipt, a revoke always de-provisions, so there is no "approved-but-still-serving" limbo behind it.
- On the sharing paths, a revoked recipient's filtered snapshots are dropped and are excluded from disaster-recovery replication, so a revoked recipient does not read from a stale copy.
Deny-authoritative today
The canonical edge is currently authoritative in the deny direction: an explicit deny edge, or a revoked-grant tombstone with no live grant behind it, denies, while the mere absence of an edge does not yet deny on its own, so the canonical check composes safely on top of the legacy path (deny if either says no). Making the edge the sole positive authority, where an absent edge means deny and the legacy store is retired, is the next contract step, and a few direct-admin and tool-grant paths that still dual-write the edge are recorded as owed work rather than narrowed.
Across the deployment matrix
- Single-cell: the canonical edge is local; a revoke denies immediately on the cell.
- Multi-cell: each cell runs the lifecycle against its own stores and the deny authority holds across the cells that serve a workspace's data; the records converge across cells rather than blocking on a coordinator.
- Sovereign / air-gapped: the deny is enforced by the cell, with no external authorization service to reach; an offline verifier fails closed on anything it cannot check (see offline verification). A grant or revoke made on one cell is not visible on a peer until they reconcile, that cross-cell visibility gap is a property of the air gap, raised as a known limit rather than narrowed silently.
- Cloud-enabled: identical behavior across the same three faces.