# ASL/AUTH-HOST/1 - Authority Node Profile

Status: Draft
Owner: Architecture
Version: 0.1.0
SoT: No
Last Updated: 2026-01-17
Tags: [ops, authority, offline]

**Document ID:** `ASL/AUTH-HOST/1`
**Layer:** O2 - Authority host profile

**Depends on (normative):**

* `ASL/HOST/1`
* `ASL/DAM/1`
* `ASL/DAP/1`
* `ASL/POLICY-HASH/1`
* `ASL/OFFLINE-ROOT-TRUST/1`
* `ASL/OCS/1`

**Informative references:**

* `PEL/1-CORE`
* `PEL/1-SURF`
* `ENC-ASL-AUTH-HOST/1`
* `ASL/RESCUE-NODE/1`
* `ASL/SOPS-BUNDLE/1`
* `ASL/DOMAIN-MODEL/1`

---

## 0. Conventions

The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHOULD**, and **MAY** are to be
interpreted as in RFC 2119.

ASL/AUTH-HOST/1 defines an operational profile. It does not define cryptography
or artifact semantics.

---

## 1. Purpose and Scope

ASL/AUTH-HOST/1 defines the profile for an offline authority node that mints
and signs domain admission artifacts. The host:

* Operates offline by default
* Maintains a local ASL/HOST store
* Produces deterministic artifacts and receipts
* Issues DAM artifacts for new domains

---

## 2. Core Principles (Normative)

1. Authority state is stored as artifacts.
2. Operations are deterministic and snapshot-bound.
3. The host remains offline during authority operations.
4. Outputs are immutable artifacts suitable for later transfer.
5. Authority functionality is limited to signing, sealing, and packaging
   artifacts.
6. Receipts (PERs) are primary outputs for auditing and later federation.

---

## 3. Required Components

An authority host MUST provide:

* ASL/HOST store for authority and domain artifacts
* Root authority key material (offline)
* PEL execution environment for deterministic receipts
* Policy hash verification for admission

---

## 4. Operation Modes

The host MAY operate in the following modes:

* `GENESIS` - mint initial domain and keys
* `RESCUE` - ingest external artifacts and produce receipts
* `ADMISSION` - sign DAMs and policy artifacts
* `MAINTENANCE` - rotate keys, seal snapshots, audit state

---

## 5. Authority Host States (Normative)

An authority host is in exactly one state:

* **Virgin:** no root keys or trusted domains exist.
* **Rooted:** root keys exist but no admission has occurred.
* **Operational:** normal admission, signing, and verification are enabled.

State transitions MUST be explicit and recorded as artifacts or snapshots.

---

## 6. Presented Domain Classification (Normative)

When removable media or an external store is presented, the host MUST classify
it as one of:

* **Virgin:** no certificates or DAM present.
* **Self-asserting:** contains unsigned claims only.
* **Admitted:** has a valid DAM and policy hash.
* **Known foreign:** previously pinned domain and policy.

Classification MUST be derived from artifacts and certificates, not filesystem
heuristics.

Presented domains are treated as temporary, read-only domains:

* Derived `domain_id` (for example, hash of media fingerprint).
* No sealing or GC permitted.
* No snapshots persisted.
* Visibility limited to the current session.

---

## 7. Output Artifacts

The host MUST be able to produce:

* Root key artifacts (public, encrypted private)
* DAM artifacts and signatures
* Policy hash artifacts
* Environment claim artifacts
* PER receipts and associated TGK edges

---

## 8. Snapshot Discipline

Each authority operation MUST:

1. Append log entries for new artifacts
2. Seal relevant segments
3. Create a snapshot marker capturing CURRENT state

Snapshots MUST be immutable once sealed.

---

## 9. Offline Constraints

* Network interfaces SHOULD be disabled.
* External input and output MUST occur via explicit operator action.
* No background services SHOULD alter authority state.
* Garbage collection SHOULD be disabled for authority domains.

---

## 10. Security Considerations

* Private keys MUST remain offline and encrypted at rest.
* Only signed outputs may leave the host.
* Operator presence is required for authority operations.

---

## 11. Versioning

Backward-incompatible profile changes MUST bump the major version.