Here’s 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 node’s 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?