amduat-api/tier1/asl-dam-1.md
2026-01-17 08:58:56 +01:00

149 lines
3.5 KiB
Markdown

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