139 lines
2.7 KiB
Markdown
139 lines
2.7 KiB
Markdown
|
# ASL/DAP/1 -- Domain Admission Protocol
|
||
|
|
|
||
|
|
Status: Draft
|
||
|
|
Owner: Architecture
|
||
|
|
Version: 0.1.0
|
||
|
|
SoT: No
|
||
|
|
Last Updated: 2025-01-17
|
||
|
|
Tags: [admission, trust, federation]
|
||
|
|
|
||
|
|
**Document ID:** `ASL/DAP/1`
|
||
|
|
**Layer:** L2 -- Admission semantics (no transport)
|
||
|
|
|
||
|
|
**Depends on (normative):**
|
||
|
|
|
||
|
|
* `ASL/DAM/1`
|
||
|
|
* `ASL/POLICY-HASH/1`
|
||
|
|
|
||
|
|
**Informative references:**
|
||
|
|
|
||
|
|
* `ASL/OCS/1` -- offline certificate system
|
||
|
|
* `ASL/OFFLINE-ROOT-TRUST/1`
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 0. Conventions
|
||
|
|
|
||
|
|
The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHOULD**, and **MAY** are to be interpreted as in RFC 2119.
|
||
|
|
|
||
|
|
ASL/DAP/1 defines **admission semantics** for recognizing external domains. It does not define transport.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 1. Purpose
|
||
|
|
|
||
|
|
The Domain Admission Protocol defines how a receiving domain evaluates and admits an applicant domain before any federation or trust is granted.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 2. Actors
|
||
|
|
|
||
|
|
| Actor | Role |
|
||
|
|
| ----- | ---- |
|
||
|
|
| Applicant Domain | Domain requesting admission |
|
||
|
|
| Receiving Domain | Domain evaluating admission |
|
||
|
|
| Operator | Optional human/policy agent |
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 3. Admission Object Model
|
||
|
|
|
||
|
|
An admission request MUST include:
|
||
|
|
|
||
|
|
* Domain Authority Manifest (DAM)
|
||
|
|
* Proof of possession of the DAM root key
|
||
|
|
* Requested admission scope
|
||
|
|
* Optional courtesy lease request
|
||
|
|
|
||
|
|
No artifacts, blocks, or logs are required for admission.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 4. Admission Flow (Normative)
|
||
|
|
|
||
|
|
1. **Submission**
|
||
|
|
|
||
|
|
* Applicant sends DAM and proof of root-key possession.
|
||
|
|
|
||
|
|
2. **Structural validation**
|
||
|
|
|
||
|
|
* Receiving domain verifies DAM schema and signature.
|
||
|
|
* Policy hash integrity MUST be verified.
|
||
|
|
|
||
|
|
3. **Policy compatibility**
|
||
|
|
|
||
|
|
* Receiving domain evaluates requested scope and policy alignment.
|
||
|
|
|
||
|
|
4. **Decision**
|
||
|
|
|
||
|
|
* Outcomes: ACCEPTED, ACCEPTED_LIMITED, DEFERRED, REJECTED.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 5. Admission Guarantees
|
||
|
|
|
||
|
|
If accepted:
|
||
|
|
|
||
|
|
* DomainID is recognized by the receiving domain.
|
||
|
|
* Root key and policy hash are pinned.
|
||
|
|
* Admission scope is enforced for federation.
|
||
|
|
|
||
|
|
Admission does not imply trust in artifacts beyond the granted scope.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 6. Courtesy Lease (Optional)
|
||
|
|
|
||
|
|
A courtesy lease is a **bounded, revocable grant of resources** without semantic trust.
|
||
|
|
|
||
|
|
```text
|
||
|
|
CourtesyLease {
|
||
|
|
lease_id
|
||
|
|
domain_id
|
||
|
|
granted_by_domain
|
||
|
|
|
||
|
|
resources: {
|
||
|
|
storage_bytes
|
||
|
|
block_count
|
||
|
|
snapshot_count
|
||
|
|
}
|
||
|
|
|
||
|
|
duration: {
|
||
|
|
start_time
|
||
|
|
end_time
|
||
|
|
}
|
||
|
|
|
||
|
|
constraints: {
|
||
|
|
encrypted_only: boolean
|
||
|
|
no_federation: boolean
|
||
|
|
no_public_indexing: boolean
|
||
|
|
}
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
Courtesy storage MAY be deleted upon lease expiry. Courtesy does not grant federation or publication rights.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 7. Non-Goals
|
||
|
|
|
||
|
|
* Transport format
|
||
|
|
* PKI integration
|
||
|
|
* Live revocation or liveness checks
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 8. Summary
|
||
|
|
|
||
|
|
ASL/DAP/1 defines a deterministic admission process for domains, with optional courtesy leasing for rescue and bootstrap scenarios.
|