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

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.

AuthorityScope = {
  "produce",
  "execute",
  "publish",
  "federate",
  "audit"
}

5. Admission and Pinning (Normative)

Before a DAM is trusted, a receiving domain MUST:

Admit the domain (see ASL/DAP/1).
Pin the DAM artifact to a snapshot.
Pin the DAM's policy_hash for that snapshot lineage.

6. Validation Rules (Normative)

A node MUST reject any action unless:

The DAM artifact is visible in the relevant snapshot.
The DAM hash matches the snapshot reference (if recorded).
The action is signed by a principal listed in the DAM.
The principal has the required role.
The DAM root_key is certified by the offline root trust chain.
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.

3.5 KiB Raw Blame History