Carl Niklas Rydberg 1d552bd46a Added some notes that needs to be analyzed.

2026-01-17 00:19:49 +01:00

4.8 KiB

Raw Blame History

Good — this can be very small and still complete. Below is a minimal, sufficient Domain Authority Manifest (DAM) that fits your ASL / PEL / TGK / federation model without introducing bureaucracy, PKI sprawl, or OS-level users.

This is intentionally boring, deterministic, snapshot-friendly, and artifact-centric.

Domain Authority Manifest (DAM)

Minimal Specification

1. Purpose

The Domain Authority Manifest (DAM) defines who may assert truth on behalf of a domain.

It governs:

Who can produce artifacts
Who can emit PERs
Who can seal and publish snapshots
Who can federate state

It is:

Immutable once sealed
Snapshot-pinned
Deterministic and replayable
Interpreted identically across nodes

2. Location & Storage

The DAM is stored as an ASL artifact and referenced by snapshot.

Canonical location (logical, not filesystem-bound):

ArtifactKey("domain-authority-manifest")

Typical ZFS-backed layout:

/asl/domain/authority.manifest

The manifest itself is content-addressed and immutable.

3. Identity Model

3.1 Principals

A principal is a cryptographic public key.

No usernames. No UIDs. No machines.

PrincipalID = HASH(public_key)

3.2 Roles (Minimal Set)

Role	Capability
`produce`	Create artifacts (internal only)
`execute`	Emit PERs
`publish`	Publish artifacts/snapshots to domain-visible state
`federate`	Export published state to other domains
`audit`	Verify, but never mutate

Roles are capabilities, not permissions.

4. Manifest Format (Minimal)

4.1 Logical Schema

DomainAuthorityManifest {
    domain_id        : DomainID
    version          : u32
    root_key         : PublicKey
    principals[]     : PrincipalEntry
    policy_hash      : Hash
}

4.2 Principal Entry

PrincipalEntry {
    principal_id : Hash
    public_key   : PublicKey
    roles[]      : Role
}

No expiry. No rotation logic in-spec. Rotation is done by publishing a new manifest.

5. Example (Canonical Text Form)

domain_id: "example.org/build"
version: 1

root_key: ed25519:9f2c...a71b

principals:
  - principal_id: 3a91...ff02
    public_key: ed25519:3a91...ff02
    roles: [produce, execute]

  - principal_id: b822...19de
    public_key: ed25519:b822...19de
    roles: [publish, federate]

policy_hash: sha256:4e7b...c912

6. Root Key Semantics

The root key:

May sign new DAM artifacts
May revoke all other principals implicitly
Is not required for day-to-day operation

Think of it as a domain constitution, not an admin account.

7. Policy Hash (Why it Exists)

The policy_hash binds:

Snapshot publication rules
Federation constraints
Visibility guarantees

This allows:

Policy documents to evolve
Manifests to remain small
Deterministic policy verification

If policy changes → new DAM → new snapshot.

8. Validation Rules (Normative)

A node must reject any action unless:

The DAM artifact is visible in the snapshot
The DAM hash matches the snapshot reference
The action is signed by a principal listed in DAM
The principal has the required role
The signature covers:
- artifact/per hash
- logseq
- snapshot ID

9. Interaction with PEL & PERs

PER Certification

A PER is authoritative iff:

PER.signature.principal ∈ DAM
AND role ∈ {execute}
AND snapshot_id matches

The PER signature is stored as an artifact and linked via TGK.

10. Federation Rules

A receiving domain must verify:

Snapshot is published
Publishing principal has publish
Federation principal has federate
DAM artifact is included or referenced

No trust in transport. No trust in machines.

11. Key Rotation & Revocation (Minimal)

Rotation = publish new DAM
Revocation = omit key in new DAM
Old snapshots remain valid
New snapshots use new DAM

No CRLs. No live checks.

12. Why This Is Enough

This manifest:

✔ Anchors authority ✔ Enables certification ✔ Preserves determinism ✔ Survives replay ✔ Works offline ✔ Scales across federation ✔ Avoids OS/user entanglement

13. One-line Summary

The Domain Authority Manifest defines who is allowed to say “this happened” — and makes that statement replayable, verifiable, and permanent.

If you want next, we can:

Specify PER signature layout
Define policy hash contents
Walk through “home directory archived” as a certified execution
Add hardware-backed keys (TPM / HSM) without changing the model

Just say the word.

4.8 KiB Raw Blame History