# ASL/DAM/1 -- Domain Authority Manifest

Status: Draft
Owner: Architecture
Version: 0.1.0
SoT: No
Last Updated: 2025-01-17
Tags: [authority, trust, policy, domains]

**Document ID:** `ASL/DAM/1`
**Layer:** L2 -- Authority semantics (no encoding)

**Depends on (normative):**

* `ASL/POLICY-HASH/1`

**Informative references:**

* `ASL/OCS/1` -- offline certificate system
* `ASL/OFFLINE-ROOT-TRUST/1` -- offline root policy
* `PER/SIGNATURE/1` -- PER signature verification

---

## 0. Conventions

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

ASL/DAM/1 defines the **logical structure and semantics** of the Domain Authority Manifest. It does not define an encoding.

---

## 1. Purpose

The Domain Authority Manifest (DAM) defines **who may assert authority** on behalf of a domain.
It binds domain identity to principals, roles, and a policy hash.

---

## 2. Core Concepts

* **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

---

## 3. Roles (Minimal Set)

| Role       | Capability |
| ---------- | ---------- |
| produce    | Create internal artifacts |
| execute    | Emit PERs |
| publish    | Publish artifacts/snapshots |
| federate   | Export published state |
| audit      | Verify only, no mutations |

Roles are **capabilities**, not identities.

---

## 4. Logical Schema

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

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

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. 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:

1. The DAM artifact is visible in the relevant snapshot.
2. The DAM hash matches the snapshot reference (if recorded).
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).

---

## 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.

---

## 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
* Live revocation

---

## 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.