amduat-api/ops/ASL-AUTH-HOST v0.1 — Authority Node Profile.md
2026-01-17 09:04:19 +01:00

5.8 KiB
Raw Blame History

Heres a first draft for ASL-AUTH-HOST v0.1 — the profile for an authority node that is structurally similar to a SystemRescue node but configured for offline, auditable domain authority operations.


ASL-AUTH-HOST v0.1 — Authority Node Profile

1. Purpose

Defines the host-level profile for a Domain Authority Node (DAN) in the ASL ecosystem. This profile ensures that the authority node:

  • Operates offline
  • Maintains an internal ASL-HOST store
  • Produces deterministic artifacts and receipts
  • Supports domain admission and certificate management
  • Can bootstrap new personal or group domains

2. Core Principles

  1. All authority state is an artifact: keys, DAM, policies, and environment claims are recorded in ASL.
  2. Offline-first: no network dependency for core operations.
  3. Deterministic snapshots: every operation is captured in a snapshot.
  4. Receipt-oriented: outputs are PER artifacts ready for federation or personal import.
  5. Minimal trusted code: authority functionality is limited to signing, sealing, and packaging artifacts.

3. Required Components

3.1 ASL-HOST Store

/asl-host/
    /domains/
        /<domain-id>/
            /store/          # block store
            /log/            # append-only log
            /snapshots/      # snapshot markers
            /certs/          # locally stored authority certificates
            /policies/       # policy artifacts
            /dam/            # Domain Admission Manifests
  • Supports block and index operations according to ASL-STORE semantics.
  • No external federation by default.

3.2 Authority Keys

  • Root keypair generated locally per domain.

  • Stored as:

    • Public key artifact
    • Private key artifact (encrypted on local storage)
  • Optionally rotated with deterministic PEL DAGs.


3.3 Offline Environment Claim

  • Records:

    • Image hash
    • Boot-time environment
    • Installed tool versions
    • Snapshot of ASL-HOST store
  • Stored as environment claim artifact.


3.4 Domain Admission Manifest (DAM)

  • Stored as an artifact.

  • Includes:

    • Domain ID
    • Root key fingerprint
    • Policy hash
    • Optional courtesy lease references
  • Signed with authority nodes root key.


3.5 PEL Programs

  • Minimal offline PEL DAGs for:

    • Signing DAMs
    • Generating PER receipts
    • Packaging SOPS bundles
  • Executed deterministically from snapshots.


4. Operation Modes

Mode Description
Genesis Create first domain for personal use; generate DAM, root keys, and policy artifacts.
Rescue Accept input artifacts (old data, files, or device images) and produce PER receipts.
Admission Sign DAMs and package SOPS bundles for new nodes entering the ecosystem.
Maintenance Rotate keys, refresh policies, seal snapshots, audit artifacts.

5. Snapshot and Logging

  • Every operation produces:

    • New blocks for artifacts
    • Append-only log entries
    • Snapshot marker capturing CURRENT state
  • Snapshots are immutable and form the basis for deterministic PER generation.


6. Authority-Only Constraints

  • No network communication.
  • No automatic federation.
  • All outputs are artifacts for later import or distribution.
  • Garbage collection is disabled; nothing may be deleted from genesis snapshot onward.

7. Security Considerations

  • Root private keys must remain offline.
  • Environment claim artifacts allow proof of image integrity and operational reproducibility.
  • Courtesy leases (optional) allow temporary storage for new personal domains under common domain supervision.

8. Output Artifacts

Artifact Type Description
Root key artifact Public/private keypair for domain signing.
DAM artifact Domain Admission Manifest, signed.
Policy artifact Hash of accepted policies and operational contracts.
Environment claim artifact Immutable claim of offline environment state.
PER artifact Receipt confirming DAM or policy execution.
SOPS bundle Encrypted and portable bundle for admission or personal archive.

9. Bootstrapping Flow

  1. Boot ASL-AUTH-HOST image offline.
  2. Initialize local ASL-HOST store.
  3. Generate root keypair artifact.
  4. Create DAM artifact, sign with root key.
  5. Produce environment claim artifact.
  6. Seal snapshot (genesis snapshot).
  7. Generate PER receipts for DAM and environment.
  8. Optionally export SOPS bundle for new nodes or personal import.

10. Relationship to SystemRescue Node

  • Uses same OS image base.

  • ASL-HOST store layout is identical.

  • Only differs in:

    • Authority keys presence
    • Offline-only policy
    • Deterministic signing and SOPS bundle generation

This draft defines the authority node as a first-class ASL-HOST, offline, deterministic, and auditable, ready to issue DAMs, PERs, and SOPS bundles for new personal domains or rescue operations.


If you want, I can draft the exact on-disk block layout for ASL-AUTH-HOST, showing directories, artifact blocks, log files, snapshots, DAMs, and policy files, similar to a precise filesystem blueprint for bootstrapping. This would make it fully tangible for your SystemRescue image.

Do you want me to do that next?