Independent Submission M. L. Macgowan Internet-Draft scadenger.com Intended status: Informational 24 August 2026 Expires: 24 February 2027 Domain Operational Standing Declaration (DOSD) Protocol draft-macgowan-dosd-02 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. This revision adds three optional operational profiles: a Distress Notice profile (DOSD-DN) for time-bounded duress signaling, an Emergency Contact object and De-escalation profile (DOSD-EC) for witness-mediated resolution of an active distress signal, and a Co-signature anchor state (pending_cosign) for instruments requiring two witnesses before publication. 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 24 February 2027. 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. Co-signature Anchor State (pending_cosign) 15. Distress Notice Profile (DOSD-DN) 16. Emergency Contact and De-escalation Profile (DOSD-EC) 17. Security Considerations 18. Privacy Considerations 19. IANA Considerations 20. 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. This revision (draft-macgowan-dosd-02) is backward compatible with draft-macgowan-dosd-01. It adds three optional profiles that nodes MAY implement and that consumers MUST ignore when absent: a Co-signature anchor state for instruments requiring two witnesses (Section 14), a Distress Notice profile for time-bounded duress signaling (Section 15), and an Emergency Contact and De-escalation profile for witness-mediated resolution of an active distress signal (Section 16). These profiles add publication and routing mechanics only. As with all DOSD data structures, they do not determine the truth or legal effect of the underlying assertions. 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. Co-signature State (pending_cosign): An anchor state in which an instrument has received a first witness signature and is awaiting a second before becoming part of the public record. See Section 14. Dead Man Switch: A node-configured time window, measured from a distress notice, after which an unresolved distress signal advances from restricted-audience to broadcast scope. See Section 15. De-escalation Notice: A record, submitted by an emergency contact who received a distress notice, asserting that the participant is observed to be safe. See Section 16. Distress Notice: A time-bounded record signaling that a participant has indicated duress. See Section 15. 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. Emergency Contact: A person designated by a participant to receive a distress notice and authorized to submit a de-escalation notice. See Section 16. 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. Discovery of DOSD documentation by automated and AI-assisted consumers is described in the supporting specification [DOSD-AID]. 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. The federation model is defined in full in the supporting specification [DOSD-FED]. 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. 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. The escalation model governing NCP scope advancement is defined in full in the supporting specification [DOSD-ESC]. 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. Co-signature Anchor State (pending_cosign) 14.1. Purpose Certain DOSD instruments change the public record in ways that SHOULD NOT take effect on a single party's action: corrections to an already-anchored record, declarations concerning a participant who can no longer respond, and successions of standing. For these instruments a node MAY require two distinct witness signatures before the instrument becomes part of the public record. The pending_cosign state is the published representation of "signed once, awaiting the second signature." It is a routing and publication state. It makes no assertion about the merit of the instrument. 14.2. Anchor State Machine A node implementing this profile recognizes the following anchor_status values: Value Meaning -------------- ------------------------------------------------ pending Submitted. First-witness review required. pending_cosign First witness has countersigned. Awaiting the second witness signature. anchored Both witnesses have signed. Public record. rejected A witness declined. The instrument remains on the chain as rejected and is not removed. A record in pending_cosign state: o MUST be visible to the witnesses and to any named party. o MUST NOT be presented to anonymous consumers as part of the public record. o MUST NOT advance NCP state (Section 10). o MUST NOT expire automatically. The transition from pending_cosign to anchored MUST be triggered by the second witness. An implementation MUST NOT allow the first witness to advance an instrument to anchored alone. 14.3. Applicability Instruments for which a node SHOULD require pending_cosign include corrections to anchored records, declarations that a named participant is non-responsive or deceased, and successions of standing from one participant record to another. The specific instrument vocabulary is a node policy matter and is not normative in this document. 15. Distress Notice Profile (DOSD-DN) 15.1. Purpose DOSD-DN provides a node-level mechanism for a participant to place a time-bounded signal on the record indicating duress, and for that signal to advance in publication scope if it is not resolved within a node-configured window. DOSD-DN defines publication, timing, and routing only. A distress notice is not an emergency dispatch service and MUST NOT be represented as one. A node publishing DOSD-DN SHOULD make clear to participants that the profile does not summon emergency responders and is not a substitute for contacting them. 15.2. Distress Notice Record A distress notice is a chain record. The following fields are defined: Field Type Description -------------------- ---------- ---------------------------- participant_ref string Reference to the participant record raising the notice. raised string Timestamp of the signal (RFC 3339). location_hash string OPTIONAL. SHA-256 of location coordinates. Raw coordinates MUST NOT be stored or published. evidence_hash string OPTIONAL. SHA-256 of any client-captured recording. Raw recording data MUST NOT be stored by the node. deadman_deadline string Timestamp at which the notice advances to broadcast scope absent resolution (RFC 3339). A node MUST NOT store raw location coordinates or raw recording data for a distress notice. Only hashes are anchored. See Section 18. 15.3. Dead Man Switch Window A node configures a Dead Man Switch window as a node-level value (for example, a number of hours). The window is the same for all participants on a node; a participant requiring a different window uses a node configured for that window. The deadman_deadline of a distress notice is computed as the "raised" timestamp plus the node's configured window. 15.4. Three-Gate Resolution Model A distress notice has exactly three terminal dispositions. A node implementing DOSD-DN MUST implement all three: Gate 1 - Resolution by witness. Two emergency contacts (Section 16) who received the notice submit de-escalation notices asserting the participant is observed safe. The distress notice is marked resolved. It does not advance in scope. Gate 2 - Resolution by the participant. The participant who raised the notice rescinds it through an authenticated node action. The distress notice is marked resolved. Gate 3 - Expiry without resolution. The deadman_deadline passes with neither Gate 1 nor Gate 2 satisfied. The notice advances in publication scope toward broadcast (Section 11.3), subject to the same white flag constraint that governs any WORLD-scope publication. Advancement under Gate 3 is the only automatic state change in this profile. All other transitions require an explicit, authenticated action by the participant or by an emergency contact. 16. Emergency Contact and De-escalation Profile (DOSD-EC) 16.1. Purpose DOSD-EC defines an emergency contact object associated with a participant and a de-escalation notice that an emergency contact may submit to resolve an active distress notice under Gate 1 of Section 15.4. 16.2. Emergency Contact Object An emergency contact is associated with the participant who designated it. The following fields are defined: Field Type Description ------------- --------- -------------------------------------- owner_ref string Participant who designated the contact. name string Contact display name. email string OPTIONAL. Contact email. phone string OPTIONAL. Contact telephone. relationship string OPTIONAL. e.g. spouse, attorney. linked_ref string OPTIONAL. Reference to the contact's own participant record, if the contact is itself a DOSD participant. Null until established. priority integer Contact order for notification. An emergency contact begins as a plain entry. It MAY later be linked to the contact's own participant record (the "linked_ref" field) by an automatic match on email or telephone, or by an explicit action. Linking is not required for the contact to receive a distress notice or to submit a de-escalation notice. 16.3. Dual-Witness Edit Requirement Because the emergency contact set governs who can resolve a distress notice under Gate 1, a node SHOULD protect edits to that set with two independent confirmations on two channels (for example, an email confirmation and a telephone confirmation) before the edit takes effect. A node MUST NOT allow the emergency contact set to be edited while a distress notice raised by the same participant is unresolved. 16.4. De-escalation Notice A de-escalation notice is a chain record submitted by an emergency contact who received a distress notice. It is a child of the distress notice it resolves. The following fields are defined: Field Type Description --------------- -------- ------------------------------------ distress_ref string The distress notice being resolved. contact_ref string The emergency contact submitting. observed string Assertion of observation, e.g. "participant observed safe". submitted string Timestamp (RFC 3339). Standing to submit a de-escalation notice is conferred by receipt of the distress notice; an emergency contact need not be a DOSD participant to submit one. A node SHOULD verify the submitting contact through the channel on which the distress notice was delivered (for example, telephone verification) before recording the de-escalation notice. When the node's required number of de-escalation notices (two, under Section 15.4 Gate 1) is recorded against a distress notice, the distress notice is marked resolved and does not advance in scope. 16.5. Access Tiers DOSD-EC distinguishes the following access tiers for actions on a node. The tiers are a routing and authorization model; they make no assertion about legal capacity. Action Required basis ------------------------------ ---------------------------- View a record None. The record is public. Respond to a served notice None beyond the served party. Submit a de-escalation notice Receipt of the distress notice plus channel verification. Open a new notice or claim Node-defined attestation and, where applicable, payment. Steward actions Steward authentication. The attestation and payment basis for opening a new notice or claim is a node policy matter. Its purpose in this profile is to distinguish a human-initiated new matter from automated submission; the mechanism is not normative. 17. Security Considerations 17.1. DNS Integrity DOSD discovery relies on DNS. Relying parties SHOULD prefer nodes using DNSSEC when trust decisions depend on DNS authenticity. 17.2. HTTPS Integrity dosd.json and dosd-index.json MUST be fetched over HTTPS. Certificate errors MUST be treated as fetch failures. 17.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. 17.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. 17.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. 17.6. Distress Notice Integrity The advancement of a distress notice under Gate 3 (Section 15.4) is automatic and time-driven. Implementations MUST anchor the deadman_deadline at the time the notice is raised and MUST NOT permit it to be silently extended. A node MUST NOT allow a single unverified de-escalation submission to resolve a distress notice; the node's required number of verified de-escalation notices MUST be met. 17.7. Emergency Contact Set Integrity The emergency contact set determines who may resolve a distress notice under Gate 1. An attacker who can alter that set can suppress a genuine distress signal. Implementations SHOULD protect edits with two independent channel confirmations (Section 16.3) and MUST lock the set against edits while a distress notice from the same participant is unresolved. 17.8. De-escalation Authorization Standing to submit a de-escalation notice derives from receipt of the distress notice. A node SHOULD verify the submitting contact on the same channel by which the distress notice was delivered before recording the de-escalation, to reduce the risk that an unauthorized party resolves a genuine distress signal. 17.9. Co-signature State Integrity A node implementing pending_cosign (Section 14) MUST NOT permit the first witness to advance an instrument to anchored. The second witness signature MUST originate from a distinct authenticated party. 18. 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. A distress notice (Section 15) and the emergency contact set (Section 16) are especially sensitive. Raw location coordinates and raw recording data MUST NOT be stored or published; only SHA-256 hashes are anchored. Emergency contact details (name, email, telephone) SHOULD be treated as private node data and MUST NOT be published in dosd.json or any publicly fetched index. A resolved distress notice remains on the chain as a record of the event; nodes SHOULD ensure that what is retained is the fact of the notice and its resolution, not sensitive personal content. 19. IANA Considerations 19.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. 19.2. Underscored DNS Node Name This document uses the "_dosd" underscored DNS node name. 20. References 20.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. [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [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. 20.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-02 --