Independent Submission M. L. Macgowan Internet-Draft scadenger.com Intended status: Informational 16 June 2026 Expires: 08 December 2026 Domain Operational Standing Declaration (DOSD) Protocol draft-macgowan-dosd-01 Abstract This document describes the Domain Operational Standing Declaration (DOSD) protocol, a voluntary DNS-based mechanism by which domain owners may publish operational declarations, stewardship status, provenance references, documentation indexes, and mediation routing information in a machine-discoverable way. DOSD uses DNS TXT records for discovery, a well-known JSON file for canonical node metadata, and an optional well-known documentation index for discovering protocol drafts, supporting specifications, implementation documents, and historical records. DOSD does not determine legal validity, jurisdiction, sovereignty, standing, or dispute outcomes. It provides discoverable publication infrastructure only. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 08 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 2. Requirements Language 3. Terminology 4. Protocol Scope 5. DNS Discovery Layer 6. Well-Known Metadata (dosd.json) 7. Documentation Discovery (dosd-index.json) 8. DOSD Identifier Scheme 9. Federation and Relay 10. Notice and Commerce Protocol (NCP) 11. White Flag Protocol (DOSD-WF) 12. Deadman Stewardship Extension (DOSD-DMS) 13. Identity Token (DOSD-IT) 14. Security Considerations 15. Privacy Considerations 16. IANA Considerations 17. References Author's Address 1. Introduction Domain owners have no standardized mechanism for publishing operational declarations, active stewardship status, provenance references, supporting documentation, or mediation routing preferences in a machine-discoverable way. DNS provides an existing globally deployed discovery mechanism tied to domain identity, and HTTPS provides a widely deployed transport for retrieving canonical metadata. DOSD proposes a minimal architecture: o A DNS TXT record at "_dosd." for discovery and level signaling. o A well-known JSON file at "/.well-known/dosd.json" for canonical node metadata. o An optional well-known documentation index at "/.well-known/dosd-index.json" for discovering protocol drafts, supporting specifications, implementation documents, and historical records. DOSD is voluntary. Participation does not confer or imply legal status. Absence of a DOSD record has no defined meaning. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. 3. Terminology Canonical URI: The HTTPS URI at which a node's dosd.json file is authoritatively served. DMS: Deadman Stewardship Extension, an optional stewardship-absent signaling profile. Documentation Index: A machine-readable JSON document that lists protocol drafts, supporting specifications, implementation documents, and historical records associated with a node. DOSD Identifier: A compact identifier beginning with "dosd:" that combines an interest code, optional node domain, and optional record reference. Escalation Scope: One of three publication scopes distinguished by capitalization: "world" (geographic scope), "World" (interest- cluster scope), or "WORLD" (full federation broadcast). The capitalization is meaningful and MUST be preserved in all implementations, log entries, JSON field values, and displays. Interest Cluster Node: A DOSD node that declares a primary interest code from the DOSD taxonomy. Interest cluster nodes drive topical escalation routing at the World (capital W) scope. Any node declaring an "interest" block in its dosd.json participates as an interest cluster node for its declared primary code. NCP: Notice and Commerce Protocol, an optional notice-state profile. Node: A single DOSD deployment on a domain. Steward: The natural person or legal entity responsible for maintaining the DOSD metadata for a domain. Stewardship-Absent State (dosd-0): A published node state indicating that the steward has not confirmed active stewardship within the configured check-in window. The chain remains intact in dosd-0 state. No new escalation steps may be taken until stewardship is restored. Terra Firma Node: A DOSD node whose primary function is anchoring a geographic jurisdiction in the federation tree. Terra firma nodes drive geographic escalation routing at the world (lowercase) scope. White Flag: A signal requesting peaceful communication, clarification, review, or mediation. 4. Protocol Scope DOSD defines discovery, publication, transport, and retrieval mechanisms for operational declarations and associated metadata. DOSD does not determine truth, jurisdiction, standing, sovereignty, legal validity, ownership, agency, trusteeship, or dispute outcomes. Relying parties remain responsible for interpreting DOSD records under their own policies and applicable law. DOSD data structures may carry declarations, record references, notice states, white flag status, documentation references, and federation links. The protocol defines how those objects are published and discovered, not whether the underlying assertions are valid. 5. DNS Discovery Layer A DOSD-participating domain publishes a DNS TXT record at "_dosd.". Example: _dosd.example.org. IN TXT "v=dosd1; level=1; uri=https://example.org/.well-known/dosd.json" The "v" field identifies the protocol version. The "level" field declares a node level. The "uri" field identifies the canonical dosd.json URI and MUST use HTTPS. Implementations MUST ignore unrecognized key/value pairs. 6. Well-Known Metadata (dosd.json) The canonical metadata file SHOULD be served at: https:///.well-known/dosd.json The file MUST be publicly accessible over HTTPS. The dosd.json object defines the node's domain, level, stewardship_status, steward object, governance object, provenance references, white_flag object, ncp object, dms object, federation links, and optional documentation block. 6.1. Documentation Block A node MAY publish a top-level "documentation" object: { "documentation": { "index_uri": "https://example.org/.well-known/dosd-index.json", "index_version": "1.0", "index_updated": "2026-06-08" } } The "index_uri" field identifies the documentation index for the node. The "index_version" field identifies the documentation index schema version. The "index_updated" field records the date the index was last updated. A node without a documentation block remains a valid DOSD node. 7. Documentation Discovery (dosd-index.json) A node MAY publish a documentation index at: https:///.well-known/dosd-index.json The documentation index is a JSON document that allows humans, software agents, AI systems, DOSD viewers, and federated nodes to discover the node's protocol documents. The index SHOULD contain schema, node_domain, node_uri, generated, genesis_node, and documents. Each document object SHOULD contain layer, layer_label, title, doc_type, status, version, uri, local_uri, published, supersedes, superseded_by, authoritative, and sha256. The four documentation layers are Protocol Drafts, Supporting Specifications, Implementation Documents, and Historical Record. Consumers SHOULD prefer authoritative Layer 1 documents over other layers when resolving conflicts. 8. DOSD Identifier Scheme DOSD identifiers use the "dosd:" prefix. They do not use the "urn:dosd:" syntax. The grammar uses ABNF notation as defined in [RFC5234]: dosd-urn = "dosd:" interest-code "@" node-domain "!" record-ref / "dosd:" interest-code "@" node-domain / "dosd:" interest-code interest-code = 1*DIGIT *( "." 1*DIGIT ) node-domain = record-ref = 1*( ALPHA / DIGIT / "-" / "_" / "." ) Example of a full record-form identifier: dosd:3.0@scadenger.com!CO23-2026-010826-Xa8D2 The "@" character separates the interest code from the node domain. The "!" character separates the node domain from the record reference. All three forms are valid standalone addresses. A consumer MAY resolve any form by fetching the node domain's dosd.json and, where a record-ref is present, querying the node's public search endpoint. The DOSD identifier scheme is defined in full in the supporting specification [DOSD-ID]. 9. Federation and Relay 9.1. Node Types The DOSD federation defines structural node roles and routing roles. A node's structural role is declared in the "node_type" field of dosd.json. Interest cluster participation is a routing role declared separately through the "interest" block and does not require a distinct node_type value. Genesis: The root of a DOSD tree. A genesis node has no parent; its "parent_domain" field is null. The genesis node's hash chain is the anchor to which all descendant nodes trace their lineage. A genesis node carries the full physical provenance record establishing the steward's standing. Genesis nodes are named in the foundational provenance records of any sibling genesis nodes. Sibling: A genesis-level node with full independent provenance standing that operates alongside the primary genesis node. Sibling nodes are co-equal at the root level; they are not subordinate to one another. Each sibling node's dosd.json names the other via the "sibling_of" array. Branch: Any DOSD domain that joins the tree from a genesis or sibling node. A branch node declares "parent_domain" pointing to its parent and maintains its own independent chain. Participants on a branch node receive DOSD-IT tokens issued by that branch's domain, verifiable by any other node by fetching the issuing domain's dosd.json. Satellite: A node that participates in DOSD but relays notice delivery through a parent node rather than operating its own communication infrastructure. A satellite node maintains its own dosd.json and hash chain. Terra Firma: A node whose primary function is anchoring a geographic jurisdiction in the federation tree. Terra firma nodes are seeded when participants declare physical jurisdiction bases and drive geographic escalation routing at the "world" (lowercase) scope. Interest Cluster: A routing role rather than a node_type value. Any node declaring an "interest" block in its dosd.json participates in interest cluster routing for its declared primary code, driving topical escalation at the "World" (capital W) scope. This role is additive: a branch node that declares an interest block holds both a structural role (branch) and a routing role (interest cluster). The following dosd.json fields carry federation relationship data: Field Type Description ----------------- ---------------- ---------------------------- domain string DNS domain of this node. parent_domain string or null Parent. Null for genesis and sibling nodes. and sibling nodes. node_type string One of the types above. sibling_of array of strings Co-equal genesis domains. satellite_domains array of strings Domains this node lists as branch or satellite nodes. relay.is_relay boolean True if this node relays for satellite nodes. relay.relay_for array of strings Satellite domains served. interest object Interest cluster declaration. terra_firma object Geographic jurisdiction data. 9.2. Tree Traversal The DOSD federation tree is traversable by any consumer with DNS and HTTPS access. No authentication is required. Downward traversal proceeds from a genesis node's dosd.json by reading "satellite_domains", fetching each listed domain's dosd.json, and repeating for each node that lists further satellite_domains. Upward traversal proceeds from any node's dosd.json by reading "parent_domain", fetching the parent's dosd.json, and repeating until "parent_domain" is null, indicating the genesis node has been reached. A consumer verifying a federation relationship SHOULD confirm that the branch node's "parent_domain" matches the claimed parent and that the parent node's "satellite_domains" lists the branch domain. Both nodes' dosd.json files MUST be served over HTTPS with valid certificates. Inconsistency between a node's self-declaration and its parent's declaration is a matter for the verifying party to assess; the protocol does not resolve it. 9.3. Relay A relay node sets "relay.is_relay" to true and lists the satellite domains it serves in "relay.relay_for". A satellite node sets "relay.is_relay" to false. The relay relationship SHOULD be declared by both nodes. A relay declaration by the parent that is not reflected in the satellite's dosd.json, or vice versa, SHOULD be treated as unverified by consuming parties. 10. Notice and Commerce Protocol (NCP) NCP is an optional notice-state profile. Nodes MAY publish NCP state for operational routing and public record-keeping. NCP state does not create legal admission and does not determine the validity of any underlying assertion. 10.1. NCP State Definitions The following states are defined: State Label Description ----------- ---------------------- ---------------------------- none No active notice Default. No matter is active. nrp-1 First Notice Initial notice. Response window open. nrp-2 Second Notice First notice unresponded. Second notice issued. nrp-3 Third Notice Second notice unresponded. Third notice issued. nrp-world Geographic escalation world scope active. nrp-World Interest escalation World scope active. nrp-WORLD Full broadcast WORLD scope. White flag required. See Section 11.3. nrp-R Response Path Respondent has entered a response. Matter in dialogue. acquiesced Acquiesced Window elapsed without rebuttal. Matter closed by non-response. rebutted Rebutted Rebuttal on record. 10.2. State Transitions NCP state advances forward on missed response windows and advances to "nrp-R" or "rebutted" on respondent action. The following transitions are defined: none -> nrp-1 Steward issues first notice. nrp-1 -> nrp-2 Response window elapsed. No response. nrp-2 -> nrp-3 Response window elapsed. No response. nrp-3 -> nrp-world Steward elects geographic escalation. nrp-world -> nrp-World Steward elects interest escalation. nrp-World -> nrp-WORLD Steward elects full broadcast. any -> nrp-R Respondent enters response path. nrp-R -> acquiesced Response window elapsed. No rebuttal. nrp-R -> rebutted Rebuttal received and recorded. Automatic advancement MUST NOT proceed past nrp-3. Advancement from nrp-3 to nrp-world requires explicit steward action. Advancement to nrp-WORLD MUST require explicit deliberate steward action regardless of prior state. nrp-WORLD MUST NOT be reachable by automatic escalation, timer expiry, or steward absence. 10.3. Response Window The default response window for nrp-1, nrp-2, and nrp-3 is 72 hours from confirmed notice delivery. Confirmed delivery means bounce-free email delivery on the digital track or postal delivery confirmation on the physical track. Advancement from nrp-3 onward requires steward judgment; no automatic timer applies beyond nrp-3. 11. White Flag Protocol (DOSD-WF) 11.1. Civil Peace State In normal operation a DOSD node is in civil peace state. The "white_flag.status" field in dosd.json is "none". This signals that the node is operating in good faith and that no matter requiring notice is active. 11.2. White Flag Raised When a steward raises the white flag, "white_flag.status" is set to "raised". This signals a request for peaceful communication, clarification, or mediation. It does not indicate surrender, agreement, legal proceeding, or admission of any kind. The white_flag object in dosd.json takes the following form when raised: { "white_flag": { "status": "raised", "raised": "2026-06-08T00:00:00-06:00", "uri": "https://example.org/dosd/white-flag-notice/" } } The "raised" field records the timestamp at which the white flag was raised. The "uri" field MAY point to a publicly accessible notice document describing the matter for which communication is requested. 11.3. Mandatory White Flag at WORLD Scope A node MUST NOT publish nrp-WORLD NCP state unless "white_flag.status" is simultaneously "raised". Implementations MUST enforce this constraint at the API level before recording a WORLD state transition. A WORLD-scope notice without an active white flag MUST be rejected by the node's own implementation. 12. Deadman Stewardship Extension (DOSD-DMS) 12.1. Purpose DOSD-DMS prevents steward absence from silently removing the node's peace signal from the public record. Without this extension, a node whose steward is incapacitated or unreachable would go dark without any published indication of why. DOSD-DMS ensures that the absence itself is recorded and published, so that participants and relying parties are notified rather than left without explanation. 12.2. Operation When DOSD-DMS is enabled, the steward configures a check-in interval in days via the "dosd_dms.checkin_interval_days" field. Any authenticated steward action on the node resets the check-in timer. If the timer expires without a check-in: 1. The node sets "dosd_dms.warn_sent" to true and delivers a warning to the steward's registered contact address. 2. If a second configured window elapses without a steward response, the node sets "stewardship_status" to "dosd-0" in dosd.json. This state is publicly visible to all consumers fetching the node's dosd.json. The dosd_dms object in dosd.json takes the following form: { "dosd_dms": { "enabled": true, "checkin_interval_days": 30, "last_checkin": "2026-06-08T00:00:00-06:00", "warn_sent": false } } 12.3. Restoration When the steward returns to active status and performs an authenticated action, the node exits dosd-0 state and "stewardship_status" returns to "active". The dosd-0 period is recorded as a chain entry. It does not break the chain; it is part of the record. 12.4. Effect on Escalation A node in dosd-0 state MUST NOT advance NCP state or issue new white flag notices. Existing published state, including any active white flag status and current NCP tier, remains on the public record. Only new escalation steps are blocked until stewardship is restored. 13. Identity Token (DOSD-IT) DOSD-IT is an optional signed token profile for participant attestation. Acceptance of a DOSD-IT is at the relying node's discretion. 14. Security Considerations 14.1. DNS Integrity DOSD discovery relies on DNS. Relying parties SHOULD prefer nodes using DNSSEC when trust decisions depend on DNS authenticity. 14.2. HTTPS Integrity dosd.json and dosd-index.json MUST be fetched over HTTPS. Certificate errors MUST be treated as fetch failures. 14.3. Documentation Discovery Integrity Consumers SHOULD verify that the documentation index is referenced from the node's dosd.json, served over HTTPS, and consistent with the node domain. Documents with published SHA-256 hashes SHOULD be verified before being treated as authoritative local copies. 14.4. Identifier Spoofing A DOSD identifier is only a string. Consumers MUST verify that the referenced node actually publishes the referenced record before relying on it. 14.5. Escalation Scope Integrity The three escalation scope values "world", "World", and "WORLD" are distinguished solely by capitalization. Implementations MUST preserve this capitalization exactly in all storage, display, API responses, and log entries. Case normalization of these values MUST NOT be performed, as it would change the semantic meaning of the scope declaration. 15. Privacy Considerations DOSD metadata is public. Stewards SHOULD avoid publishing personal information, private contact details, or sensitive record contents unless disclosure is intended. Documentation indexes may reveal project structure, implementation details, and historical records. Nodes SHOULD publish only documents intended for public discovery. 16. IANA Considerations 16.1. Well-Known URI Registration This document requests registration of the following URIs in the Well-Known URIs registry established by [RFC8615]. URI suffix: dosd.json Change controller: IETF Specification document(s): This document, Section 6 Related information: None. URI suffix: dosd-index.json Change controller: IETF Specification document(s): This document, Section 7 Related information: The dosd-index.json file provides a machine-readable documentation index for DOSD nodes, enabling discovery of protocol drafts, supporting specifications, implementation documents, and historical records associated with a node. 16.2. Underscored DNS Node Name This document uses the "_dosd" underscored DNS node name. 17. References 17.1. Normative References [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, May 2019. 17.2. Informative References [DOSD-AID] Macgowan, M., "DOSD AI Discovery Model", DOSD_AI_DISCOVERY_v1.0, June 2026, . [DOSD-ID] Macgowan, M., "DOSD Identifier Scheme", DOSD_URN_SPEC_v1.0, June 2026, . [DOSD-FED] Macgowan, M., "DOSD Federation Model", DOSD_FEDERATION_MODEL_v1.0, June 2026, . [DOSD-ESC] Macgowan, M., "DOSD Escalation Model", DOSD_ESCALATION_MODEL_v1.0, June 2026, . Author's Address Michael Leigh Macgowan scadenger.com Florence, Colorado United States Email: dosdnotices@scadenger.com URI: https://scadenger.com/.well-known/dosd.json -- End of draft-macgowan-dosd-01 --