Refine federation replay and authority specs
This commit is contained in:
Carl Niklas Rydberg
parent
a5537e13d3
commit
95e030d562
|
|
@ -42,6 +42,7 @@ It binds domain identity to principals, roles, and a policy hash.
|
|||
* **Principal**: a cryptographic public key
|
||||
* **Role**: capability granted to a principal
|
||||
* **Policy hash**: canonical hash binding policy constraints to a domain
|
||||
* **Authority scope**: explicit actions this DAM authorizes within the domain
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -68,6 +69,7 @@ DomainAuthorityManifest {
|
|||
root_key : PublicKey
|
||||
principals[] : PrincipalEntry
|
||||
policy_hash : Hash
|
||||
scope[] : AuthorityScope
|
||||
}
|
||||
|
||||
PrincipalEntry {
|
||||
|
|
@ -79,9 +81,34 @@ PrincipalEntry {
|
|||
|
||||
The DAM is immutable once published. Rotation is performed by publishing a new DAM.
|
||||
|
||||
### 4.1 Authority Scope
|
||||
|
||||
The optional `scope[]` constrains what this DAM authorizes. If omitted, scope is
|
||||
assumed to include all roles defined in this document.
|
||||
|
||||
```text
|
||||
AuthorityScope = {
|
||||
"produce",
|
||||
"execute",
|
||||
"publish",
|
||||
"federate",
|
||||
"audit"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Validation Rules (Normative)
|
||||
## 5. Admission and Pinning (Normative)
|
||||
|
||||
Before a DAM is trusted, a receiving domain MUST:
|
||||
|
||||
1. Admit the domain (see `ASL/DAP/1`).
|
||||
2. Pin the DAM artifact to a snapshot.
|
||||
3. Pin the DAM's `policy_hash` for that snapshot lineage.
|
||||
|
||||
---
|
||||
|
||||
## 6. Validation Rules (Normative)
|
||||
|
||||
A node MUST reject any action unless:
|
||||
|
||||
|
|
@ -90,16 +117,25 @@ A node MUST reject any action unless:
|
|||
3. The action is signed by a principal listed in the DAM.
|
||||
4. The principal has the required role.
|
||||
5. The DAM `root_key` is certified by the offline root trust chain.
|
||||
6. The action is within the DAM's declared `scope[]` (if present).
|
||||
|
||||
---
|
||||
|
||||
## 6. Policy Binding
|
||||
## 7. Policy Binding
|
||||
|
||||
The DAM `policy_hash` binds the domain to a specific policy document. If policy changes, a new DAM MUST be published and referenced by new snapshots.
|
||||
|
||||
---
|
||||
|
||||
## 7. Non-Goals
|
||||
## 8. Idempotency and Rotation
|
||||
|
||||
* Replaying the same snapshot + DAM MUST yield identical authority decisions.
|
||||
* Rotation is done by publishing a new DAM and referencing it in new snapshots.
|
||||
* Old snapshots remain valid with the DAM they reference.
|
||||
|
||||
---
|
||||
|
||||
## 9. Non-Goals
|
||||
|
||||
* Encoding format
|
||||
* Key rotation workflow
|
||||
|
|
@ -107,6 +143,6 @@ The DAM `policy_hash` binds the domain to a specific policy document. If policy
|
|||
|
||||
---
|
||||
|
||||
## 8. Summary
|
||||
## 10. Summary
|
||||
|
||||
ASL/DAM/1 defines the minimal authority document for a domain, binding principals and roles to a policy hash under an offline root trust chain.
|
||||
|
|
|
|||
|
|
@ -59,7 +59,26 @@ No artifacts, blocks, or logs are required for admission.
|
|||
|
||||
---
|
||||
|
||||
## 4. Admission Flow (Normative)
|
||||
## 4. Admission Record (Normative)
|
||||
|
||||
The receiving domain MUST persist an admission record that is snapshot-pinned:
|
||||
|
||||
```text
|
||||
AdmissionRecord {
|
||||
domain_id
|
||||
dam_hash
|
||||
policy_hash
|
||||
admitted_scope[]
|
||||
decision
|
||||
decision_epoch
|
||||
}
|
||||
```
|
||||
|
||||
The `decision_epoch` is a monotonically increasing local counter (not wall time).
|
||||
|
||||
---
|
||||
|
||||
## 5. Admission Flow (Normative)
|
||||
|
||||
1. **Submission**
|
||||
|
||||
|
|
@ -80,7 +99,7 @@ No artifacts, blocks, or logs are required for admission.
|
|||
|
||||
---
|
||||
|
||||
## 5. Admission Guarantees
|
||||
## 6. Admission Guarantees
|
||||
|
||||
If accepted:
|
||||
|
||||
|
|
@ -92,7 +111,15 @@ Admission does not imply trust in artifacts beyond the granted scope.
|
|||
|
||||
---
|
||||
|
||||
## 6. Courtesy Lease (Optional)
|
||||
## 7. Scope Enforcement (Normative)
|
||||
|
||||
* Admission scope MUST gate federation view construction and replay admission.
|
||||
* A receiving domain MUST NOT admit state outside the granted scope.
|
||||
* Scope changes require a new admission decision and updated AdmissionRecord.
|
||||
|
||||
---
|
||||
|
||||
## 8. Courtesy Lease (Optional)
|
||||
|
||||
A courtesy lease is a **bounded, revocable grant of resources** without semantic trust.
|
||||
|
||||
|
|
@ -125,7 +152,7 @@ Courtesy storage MAY be deleted upon lease expiry. Courtesy does not grant feder
|
|||
|
||||
---
|
||||
|
||||
## 7. Non-Goals
|
||||
## 9. Non-Goals
|
||||
|
||||
* Transport format
|
||||
* PKI integration
|
||||
|
|
@ -133,6 +160,6 @@ Courtesy storage MAY be deleted upon lease expiry. Courtesy does not grant feder
|
|||
|
||||
---
|
||||
|
||||
## 8. Summary
|
||||
## 10. Summary
|
||||
|
||||
ASL/DAP/1 defines a deterministic admission process for domains, with optional courtesy leasing for rescue and bootstrap scenarios.
|
||||
|
|
|
|||
|
|
@ -55,6 +55,7 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
|
|||
| Published state | Artifacts/snapshots visible to other domains. |
|
||||
| Federated snapshot | Snapshot with visibility state that may be imported by other domains. |
|
||||
| Cross-domain reference | Reference to a published artifact from another domain. |
|
||||
| Federation view | A deterministic view constructed by combining local internal state with admitted published state from other domains. |
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -75,6 +76,7 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
|
|||
* Only published artifacts MAY be referenced by other domains.
|
||||
* Cross-domain references are read-only and immutable.
|
||||
* The consuming domain indexes imported artifacts using normal ASL index semantics.
|
||||
* Imported entries MUST preserve origin metadata (domain identity and visibility) for deterministic replay.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -83,6 +85,7 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
|
|||
* Snapshot IDs are unique per domain.
|
||||
* Federated snapshot identity is `(DomainID, SnapshotID)`.
|
||||
* A federated snapshot MAY include cross-domain references only to published artifacts.
|
||||
* Replay of federated state MUST be bounded by the source domain's `{SnapshotID, LogPrefix}`.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -102,17 +105,35 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
|
|||
|
||||
---
|
||||
|
||||
## 6. Cross-Domain Operations
|
||||
## 6. Federation View Construction
|
||||
|
||||
To construct a federation view for a domain:
|
||||
|
||||
1. Start with the local domain's internal + published state at `{SnapshotID, LogPrefix}`.
|
||||
2. For each admitted foreign domain, include only published state that is:
|
||||
|
||||
* Visible under that domain's `{SnapshotID, LogPrefix}`, and
|
||||
* Allowed by the receiving domain's admission and policy rules.
|
||||
|
||||
3. Apply normal ASL index shadowing and tombstone rules within each domain's log order.
|
||||
|
||||
Federation MUST NOT bypass ASL/LOG/1 ordering or ASL/1-CORE-INDEX semantics.
|
||||
|
||||
---
|
||||
|
||||
## 7. Cross-Domain Operations
|
||||
|
||||
1. **Import published artifacts**
|
||||
|
||||
* A domain MAY import a published artifact from another domain.
|
||||
* Imported artifacts MUST be treated as immutable.
|
||||
* Import MUST be gated by admission and policy compatibility (see `ASL/DAP/1` and `ASL/POLICY-HASH/1`).
|
||||
|
||||
2. **Export published artifacts**
|
||||
|
||||
* Internal artifacts MAY be promoted to published state.
|
||||
* Promotion MUST be snapshot-bound and log-ordered.
|
||||
* Publication MUST respect the domain's policy hash and DAM roles.
|
||||
|
||||
3. **Federation log propagation**
|
||||
|
||||
|
|
@ -121,7 +142,7 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
|
|||
|
||||
---
|
||||
|
||||
## 7. Provenance and Traceability
|
||||
## 8. Provenance and Traceability
|
||||
|
||||
* Execution receipts MAY include cross-domain inputs.
|
||||
* Provenance MUST preserve origin domain and snapshot identity.
|
||||
|
|
@ -129,7 +150,7 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
|
|||
|
||||
---
|
||||
|
||||
## 8. Normative Invariants
|
||||
## 9. Normative Invariants
|
||||
|
||||
1. **Determinism:** Reconstructing CURRENT in a domain yields the same visible state given the same snapshot and log prefix.
|
||||
2. **Immutability:** Published artifacts and snapshots are immutable.
|
||||
|
|
@ -139,7 +160,7 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
|
|||
|
||||
---
|
||||
|
||||
## 9. Integration with Other Layers
|
||||
## 10. Integration with Other Layers
|
||||
|
||||
| Layer | Role in Federation |
|
||||
| ------------------ | ------------------ |
|
||||
|
|
@ -151,7 +172,7 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
|
|||
|
||||
---
|
||||
|
||||
## 10. Non-Goals
|
||||
## 11. Non-Goals
|
||||
|
||||
* Transport protocols
|
||||
* Network replication
|
||||
|
|
@ -160,6 +181,6 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
|
|||
|
||||
---
|
||||
|
||||
## 11. Summary
|
||||
## 12. Summary
|
||||
|
||||
ASL/FEDERATION/1 defines the semantic rules for multi-domain visibility and cross-domain reference. It keeps federation deterministic, snapshot-safe, and read-only across domain boundaries.
|
||||
|
|
|
|||
|
|
@ -21,6 +21,8 @@ Tags: [federation, replay, determinism, tgk, pel]
|
|||
|
||||
* `ASL/SYSTEM/1` -- unified system view
|
||||
* `ENC-ASL-CORE-INDEX` -- domain metadata
|
||||
* `ASL/DAP/1` -- admission gating
|
||||
* `ASL/POLICY-HASH/1` -- policy compatibility
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -47,22 +49,39 @@ This document defines how artifacts, PERs, and TGK edges are propagated and repl
|
|||
|
||||
---
|
||||
|
||||
## 3. Propagation Rules
|
||||
## 3. Replay Record Requirements
|
||||
|
||||
### 3.1 Artifacts and PERs
|
||||
Each propagated record MUST be replayable without external context. Records MUST carry:
|
||||
|
||||
* `domain_id` (source domain)
|
||||
* `record_type` (artifact, PER, TGK edge, tombstone)
|
||||
* `logseq` (source-domain ordering)
|
||||
* `snapshot_id` and `log_prefix` bounds for which the record is visible
|
||||
* Canonical identity (ArtifactKey or Canonical Edge Key)
|
||||
* Visibility metadata (internal/published, cross-domain source when applicable)
|
||||
|
||||
Records MAY include optional integrity fields (hashes, signatures), but replay MUST
|
||||
remain deterministic without them.
|
||||
|
||||
---
|
||||
|
||||
## 4. Propagation Rules
|
||||
|
||||
### 4.1 Artifacts and PERs
|
||||
|
||||
* Artifacts and PERs are propagated with their `ArtifactKey` and `logseq`.
|
||||
* Only artifacts visible under a published snapshot MAY be propagated.
|
||||
* Duplicate ArtifactKeys MUST be de-duplicated by identity.
|
||||
* Imported entries MUST preserve origin metadata (domain identity and visibility).
|
||||
|
||||
### 3.2 TGK Edges
|
||||
### 4.2 TGK Edges
|
||||
|
||||
* TGK edges are propagated with their canonical edge identity and `logseq`.
|
||||
* Edge propagation MUST preserve the same snapshot/log visibility constraints as artifacts.
|
||||
|
||||
---
|
||||
|
||||
## 4. Deterministic Replay Ordering
|
||||
## 5. Deterministic Replay Ordering
|
||||
|
||||
Replay order MUST be deterministic across nodes:
|
||||
|
||||
|
|
@ -73,14 +92,34 @@ This ordering MUST be applied identically by all receivers.
|
|||
|
||||
---
|
||||
|
||||
## 5. Snapshot Bounds
|
||||
## 6. Snapshot Bounds
|
||||
|
||||
* Replay MUST be bounded by `{SnapshotID, LogPrefix}`.
|
||||
* Records with `logseq` greater than the replay prefix MUST be ignored.
|
||||
* Replay MUST use the source domain's `{SnapshotID, LogPrefix}` as the bound for imported state.
|
||||
|
||||
---
|
||||
|
||||
## 6. Conflict Handling
|
||||
## 7. Federation View Construction
|
||||
|
||||
Receivers construct a federation view by combining:
|
||||
|
||||
1. Local domain state at `{SnapshotID, LogPrefix}`.
|
||||
2. Admitted foreign published state bounded by the source domain's `{SnapshotID, LogPrefix}`.
|
||||
|
||||
Admission and policy compatibility MUST be enforced before any foreign state is admitted.
|
||||
|
||||
---
|
||||
|
||||
## 8. Tombstones and Shadowing
|
||||
|
||||
* Tombstones MUST be replayed in log order and apply only within their source domain.
|
||||
* A tombstone from domain A MUST NOT shadow artifacts from domain B.
|
||||
* Shadowing is resolved per-domain using ASL/LOG/1 order and ASL/1-CORE-INDEX semantics.
|
||||
|
||||
---
|
||||
|
||||
## 9. Conflict Handling
|
||||
|
||||
1. **ArtifactKey collision**
|
||||
|
||||
|
|
@ -97,7 +136,17 @@ This ordering MUST be applied identically by all receivers.
|
|||
|
||||
---
|
||||
|
||||
## 7. Provenance and Audit
|
||||
## 10. Replay State and Idempotency
|
||||
|
||||
Replay MUST be idempotent:
|
||||
|
||||
* Re-applying the same record set MUST NOT change the resulting state.
|
||||
* Receivers SHOULD track `{domain_id, logseq}` high-water marks per peer.
|
||||
* Checkpointing MUST be aligned to `{SnapshotID, LogPrefix}` boundaries.
|
||||
|
||||
---
|
||||
|
||||
## 11. Provenance and Audit
|
||||
|
||||
Receivers SHOULD maintain:
|
||||
|
||||
|
|
@ -108,7 +157,7 @@ This supports deterministic audit and replay verification.
|
|||
|
||||
---
|
||||
|
||||
## 8. Non-Goals
|
||||
## 12. Non-Goals
|
||||
|
||||
* Transport protocol selection
|
||||
* Streaming formats
|
||||
|
|
@ -116,6 +165,6 @@ This supports deterministic audit and replay verification.
|
|||
|
||||
---
|
||||
|
||||
## 9. Summary
|
||||
## 13. Summary
|
||||
|
||||
ASL/FEDERATION-REPLAY/1 defines a deterministic replay ordering and conflict rules to ensure federation is reproducible across nodes and snapshots.
|
||||
|
|
|
|||
|
|
@ -70,6 +70,26 @@ AuthorityCertificate {
|
|||
|
||||
* `domain_root`: certifies a domain root key for DAM issuance.
|
||||
* `principal`: certifies a principal key for roles under a policy hash.
|
||||
* `roles[]` MUST be empty for `domain_root` certificates.
|
||||
* `policy_hash` MUST match the DAM policy hash for the domain when used.
|
||||
|
||||
---
|
||||
|
||||
## 3.3 Authority Request (Normative)
|
||||
|
||||
An authority request is a deterministic, offline-signable object:
|
||||
|
||||
```text
|
||||
AuthorityRequest {
|
||||
subject_type
|
||||
subject_pubkey
|
||||
domain_id
|
||||
roles[]
|
||||
policy_hash
|
||||
}
|
||||
```
|
||||
|
||||
The offline signer MUST validate the request against the offline root trust rules before issuing a certificate.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -83,7 +103,15 @@ No online checks are required after import.
|
|||
|
||||
---
|
||||
|
||||
## 5. DAM Validation Chain
|
||||
## 5. Certificate Visibility and Idempotency
|
||||
|
||||
* AuthorityCertificate artifacts MUST be visible in the snapshot that uses them.
|
||||
* Replaying the same snapshot + certificate set MUST yield identical authority results.
|
||||
* Duplicate certificates for the same subject_id MUST be rejected within a snapshot.
|
||||
|
||||
---
|
||||
|
||||
## 6. DAM Validation Chain
|
||||
|
||||
A DAM is valid iff:
|
||||
|
||||
|
|
@ -93,13 +121,13 @@ A DAM is valid iff:
|
|||
|
||||
---
|
||||
|
||||
## 6. Revocation Model
|
||||
## 7. Revocation Model
|
||||
|
||||
There is no live revocation. Revocation is performed by publishing a new DAM and new certificates, and referencing them in new snapshots.
|
||||
|
||||
---
|
||||
|
||||
## 7. Federation Verification
|
||||
## 8. Federation Verification
|
||||
|
||||
When receiving state from another domain:
|
||||
|
||||
|
|
@ -110,6 +138,6 @@ When receiving state from another domain:
|
|||
|
||||
---
|
||||
|
||||
## 8. Summary
|
||||
## 9. Summary
|
||||
|
||||
ASL/OCS/1 defines immutable authority certificates signed by offline roots and bound to policy hashes, enabling deterministic, offline trust validation.
|
||||
|
|
|
|||
|
|
@ -23,7 +23,10 @@ Tags: [deterministic, federation, pel, tgk, index]
|
|||
* `ASL/INDEX-ACCEL/1`
|
||||
* `TGK/1` — Trace Graph Kernel semantics
|
||||
* PEL draft specs (program DAG, execution receipts)
|
||||
* Federation and domain policy drafts
|
||||
* `ASL/FEDERATION/1` — core federation semantics
|
||||
* `ASL/FEDERATION-REPLAY/1` — cross-node deterministic replay
|
||||
* `ASL/DAP/1` — domain admission
|
||||
* `ASL/POLICY-HASH/1` — policy binding
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -135,6 +138,9 @@ Deterministic replay across nodes MUST respect:
|
|||
Federation does not change PEL semantics. It propagates artifacts and receipts
|
||||
that were already deterministically produced.
|
||||
|
||||
Admission and policy compatibility gate foreign state: only admitted domains and
|
||||
policy-compatible published state may be included in a federation view.
|
||||
|
||||
---
|
||||
|
||||
## 7. Index Alignment
|
||||
|
|
|
|||
Loading…
Reference in a new issue