Independent Submission M. L. Macgowan Internet-Draft scadenger.com Intended status: Informational 06 June 2026 Expires: 06 December 2026 Domain Operational Standing Declaration (DOSD) Protocol draft-macgowan-dosd-00 Abstract This document describes the Domain Operational Standing Declaration (DOSD) protocol, a voluntary DNS-based mechanism by which domain owners may publish governance declarations, stewardship status, provenance chains, and mediation routing information. DOSD uses DNS TXT records for discovery and a well-known JSON file for canonical metadata. The protocol defines a Notice and Commerce Protocol (NCP) state machine for escalating notice tiers, a white flag signaling mechanism for requesting peaceful mediation, a Deadman Stewardship Extension (DOSD-DMS) for signaling stewardship- absent states, and a portable identity token format (DOSD-IT) for participant attestation. DOSD does not determine legal validity or sovereignty. It provides discoverable, tamper-evident, publicly verifiable infrastructure for notice, declaration, and mediation routing. 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 06 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. DNS Discovery Layer 4.1. TXT Record Format 4.2. Field Definitions 4.3. Discovery Procedure 5. Well-Known Metadata (dosd.json) 5.1. File Location 5.2. Top-Level Fields 5.3. Steward Object 5.4. Governance Object 5.5. Linktree Array 5.6. Linktree Node Fields 5.7. White Flag Object 5.8. NCP Object 5.9. DMS Object 6. Notice and Commerce Protocol (NCP) 6.1. State Definitions 6.2. State Transitions 6.3. Timing Requirements 6.4. Acquiescence 7. White Flag Protocol (DOSD-WF) 8. Deadman Stewardship Extension (DOSD-DMS) 9. Identity Token (DOSD-IT) 9.1. Token Structure 9.2. Token Verification 10. Federation and Relay 10.1. Satellite Nodes 10.2. Relay Requirements 11. Dual-Track Notice 11.1. Digital Track 11.2. Physical Track (UPU) 12. Security Considerations 13. Privacy Considerations 14. IANA Considerations 14.1. Well-Known URI Registration 14.2. DNS TXT Record Key Registration 15. References 15.1. Normative References 15.2. Informative References Author's Address 1. Introduction Domain owners have no standardized mechanism for publishing governance declarations, active stewardship status, or mediation routing preferences in a machine-discoverable way. DNS provides an existing, globally distributed, authenticated publication mechanism that is tied to domain identity. DOSD (Domain Operational Standing Declaration) proposes a minimal two-layer 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 metadata including declarations, provenance chains, stewardship status, and mediation routing. DOSD is voluntary. Participation does not confer or imply any legal status. DOSD does not determine truth, sovereignty, or legal legitimacy. It provides discoverable, tamper-evident infrastructure for notice, declaration, and mediation routing that any domain owner may choose to publish. The protocol is designed to be: o Implementable with DNS access and a static file host only o Extensible through optional layers (NCP, DMS, federation relay) o Compatible with any governance framework a steward attaches o Auditable by any party with DNS and HTTP access 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, as shown here. 3. Terminology Steward: The natural person or legal entity responsible for maintaining the DOSD record for a domain. Node: A single DOSD deployment on a domain. Each node has one canonical dosd.json file. Linktree: The ordered array of chained hash entries in dosd.json forming a tamper-evident provenance record. Canonical URI: The HTTPS URI at which dosd.json is authoritatively served for a given domain. Satellite: A node that relays NCP through a parent node and links to the parent as canonical record. NCP: Notice and Commerce Protocol -- the tiered escalation state machine defined in Section 6. NRP-N: Notice Routing Protocol tier N (1 through 4) within the NCP state machine. White Flag: A signal indicating a request for peaceful communication or mediation. See Section 7. DOSD-DMS: Deadman Stewardship Extension. See Section 8. DOSD-IT: DOSD Identity Token. See Section 9. DOSD-0: Stewardship-absent state activated by DOSD-DMS. SHA-256: The SHA-256 cryptographic hash function [RFC6234]. UPU: Universal Postal Union -- the international postal authority. Used here for physical dual-track notice. 4. DNS Discovery Layer 4.1. TXT Record Format A DOSD-participating domain MUST publish a DNS TXT record at the name "_dosd." with the following format: _dosd.example.org. IN TXT "v=dosd1; level=; uri=" Multiple space-separated key=value pairs MAY appear in any order after the version tag. 4.2. Field Definitions v (REQUIRED): MUST be "dosd1". Identifies the DOSD protocol version. level (REQUIRED): An integer from 0 to 9 indicating the steward's declared participation level. Level 0 indicates DOSD-0 (stewardship- absent). Level definitions are out of scope for this document and are expected to be defined in a future revision. uri (REQUIRED): The HTTPS URI of the canonical dosd.json file. MUST use the "https" scheme. MUST NOT redirect to an HTTP URI. Additional key=value pairs are reserved for future use. Implementations MUST ignore unrecognized keys. 4.3. Discovery Procedure A relying party that wishes to discover DOSD metadata for a domain performs the following steps: 1. Query DNS for TXT records at "_dosd.". 2. If no record is found, the domain has no DOSD declaration. The relying party SHOULD NOT infer any meaning from absence. 3. If a record is found, parse the key=value pairs. Verify that "v=dosd1" is present. If not, the record is not a valid DOSD declaration. 4. Fetch the JSON document at the "uri" value over HTTPS. The request MUST use a TLS connection. Certificate errors MUST be treated as fetch failures. 5. Parse the fetched document per Section 5. 5. Well-Known Metadata (dosd.json) 5.1. File Location The canonical dosd.json file SHOULD be served at: https:///.well-known/dosd.json The URI in the DNS TXT record is authoritative. If a node uses a non-standard path, the DNS TXT "uri" field governs. The file MUST be served with Content-Type "application/json". The file MUST be accessible without authentication. 5.2. Top-Level Fields The dosd.json file is a JSON object. The following top-level fields are defined: dosd_version (string, REQUIRED): The DOSD protocol version. MUST be "1.0" for this revision. schema (string, REQUIRED): Schema identifier. MUST be "dosd-json-1.0-draft" for this revision. domain (string, REQUIRED): The fully qualified domain name of this node. level (integer, REQUIRED): The steward's participation level. MUST match the "level" value in the DNS TXT record. canonical_uri (string, REQUIRED): The canonical HTTPS URI of this file. stewardship_status (string, REQUIRED): One of: "active", "dosd-0". "dosd-0" indicates stewardship- absent state. steward (object, REQUIRED): See Section 5.3. governance (object, OPTIONAL): See Section 5.4. linktree (array, REQUIRED): See Section 5.5. white_flag (object, REQUIRED): See Section 5.7. ncp (object, REQUIRED): See Section 5.8. dosd_dms (object, OPTIONAL): See Section 5.9. created (string, REQUIRED): ISO 8601 datetime of initial node creation. updated (string, REQUIRED): ISO 8601 datetime of most recent update. 5.3. Steward Object name (string, REQUIRED): The steward's name or identifying designation. style (string, OPTIONAL): The steward's self-declared style (e.g., "living man", "Lawful Woman", "TRADENAME"). rights (string, OPTIONAL): Rights reservation statement. affirmed_date (string, OPTIONAL): ISO 8601 date of initial affirmation. 5.4. Governance Object foundation (string, OPTIONAL): The foundational standard or maxims the steward declares. standard (string, OPTIONAL): The standard of conduct the steward applies. jurisdiction_trees (array of objects, OPTIONAL): Each object represents a jurisdiction or governance tree to which the steward attaches. Fields: name (string, REQUIRED): Name of the jurisdiction or assembly. basis (string, REQUIRED): Basis for attachment (e.g., "domicile", "nativity", "contract"). 5.5. Linktree Array The linktree is an ordered array of node objects. Nodes MUST appear in chronological order. Each node represents a discrete declaration, document anchor, or state change. The first node's "prev_hash" field SHOULD be the SHA-256 hash of a genesis string defined by the steward or a null-equivalent sentinel. 5.6. Linktree Node Fields node (integer, REQUIRED): Sequential node number starting at 1. type (string, REQUIRED): One of: "genesis", "declaration", "satellite", "document", "notice", "response". domain (string, REQUIRED): The domain to which this node belongs. created (string, REQUIRED): ISO 8601 datetime of node creation. prev_hash (string, REQUIRED): SHA-256 hash of the previous node's canonical representation. For the first node, this is the genesis hash or a defined sentinel value. record_ref (string, OPTIONAL): External record reference identifier. declaration_uri (string, OPTIONAL): URI of the public declaration or record page. document_hash (string, OPTIONAL): SHA-256 hash of the primary document associated with this node. ncp_state (string, REQUIRED): Current NCP state for this node. See Section 6.1. white_flag (string, REQUIRED): Current white flag status. One of: "none", "raised". node_hash (string, REQUIRED): SHA-256 hash of this node's canonical representation. Computed after all other fields are set. 5.7. White Flag Object status (string, REQUIRED): One of: "none", "raised". raised (string or null, REQUIRED): ISO 8601 datetime when the white flag was raised, or null. uri (string or null, OPTIONAL): URI of the white flag notice document. 5.8. NCP Object tier (string, REQUIRED): Current NCP tier. See Section 6.1. last_advanced (string or null, REQUIRED): ISO 8601 datetime of last tier advancement, or null. notices (array, REQUIRED): Array of notice objects. Each notice object SHOULD include: tier (string), sent_at (ISO 8601 string), delivery_ref (string). 5.9. DMS Object enabled (boolean, REQUIRED): Whether DOSD-DMS is active for this node. checkin_interval_days (integer or null, REQUIRED): Required steward checkin interval in days. last_checkin (string or null, REQUIRED): ISO 8601 datetime of last steward checkin. warn_sent (boolean, REQUIRED): Whether a DMS warning notice has been sent this interval. 6. Notice and Commerce Protocol (NCP) 6.1. State Definitions The NCP defines the following states: none: No active NCP proceeding. nrp1: First notice sent. Response window open. nrp2: Second notice sent. Response window open. nrp3: Third notice sent. Response window open. nrp4: Propagation notice sent. nrp_r: Response received. Under review. acquiesced: No rebuttal received within the response window. The claims stand unrebutted on the record. rebutted: A rebuttal was received and is on record. closed: The proceeding has been closed. 6.2. State Transitions The following transitions are defined: none --> nrp1 (steward initiates first notice) nrp1 --> nrp2 (72-hour window expires, no response) nrp2 --> nrp3 (72-hour window expires, no response) nrp3 --> nrp4 (72-hour window expires, no response) nrp4 --> acquiesced (propagation window expires, no response) any --> nrp_r (response received at any tier) nrp_r --> rebutted (steward records rebuttal) nrp_r --> acquiesced (response reviewed, claims upheld) any --> closed (steward closes proceeding) Transitions are automated by the NCP cron process. Manual override by the steward is permitted at any state. 6.3. Timing Requirements Each NRP-1 through NRP-3 tier has a MINIMUM response window of 72 hours from the time the notice is delivered. Stewards SHOULD NOT advance the state machine before the window expires. The NRP-4 propagation tier has no fixed window. The steward defines the propagation window. 6.4. Acquiescence Acquiescence is recorded when no rebuttal is received within the applicable window after NRP-4. Acquiescence means the claims stand unrebutted on the public record. It does not constitute legal admission in any jurisdiction. It is a record-keeping state. 7. White Flag Protocol (DOSD-WF) The white flag signal indicates a request for communication, peaceful review, or mediation. It does not indicate surrender, agreement, or waiver. A steward raises the white flag by: 1. Setting white_flag.status to "raised" in dosd.json. 2. Setting white_flag.raised to the current ISO 8601 datetime. 3. Optionally providing white_flag.uri pointing to a notice. 4. Notifying connected participants via NCP notice machinery. The white flag MAY be raised at any NCP tier. Raising the white flag does not stop NCP advancement unless the parties reach an agreement recorded in the ncp object. Relying parties SHOULD treat a raised white flag as a signal to prefer mediation channels over adversarial ones. 8. Deadman Stewardship Extension (DOSD-DMS) DOSD-DMS enables transparent signaling of stewardship-absent states. When enabled, a cron process checks for steward checkins at the configured interval. If no checkin is recorded within (checkin_interval_days + grace_days) days, the following occurs: 1. A warning notice is sent to the steward's contact address. 2. If no checkin follows within grace_days, DOSD-0 state activates. 3. The stewardship_status field in dosd.json is set to "dosd-0". 4. The DNS TXT record level field SHOULD be updated to 0 to reflect the absent state. 5. All active NCP declarations remain in their current state. They are not closed or altered by DMS activation. Stewardship is restored by the steward performing a checkin. The checkin MUST be an authenticated action (e.g., an API call with a valid steward credential). 9. Identity Token (DOSD-IT) 9.1. Token Structure A DOSD Identity Token (DOSD-IT) is a signed JSON Web Token (JWT) [RFC7519] with the following DOSD-specific header fields: alg: "HS256" typ: "DOSD-IT" ver: "1.0" The payload MUST include: sub: Participant node ID (e.g., "PART-XXXXXXXX") iss: Issuing domain (e.g., "scadenger.com") iat: Issued-at timestamp (Unix epoch integer) dom: Origin domain jur: Jurisdiction basis string dh: Declaration hash (SHA-256 hex string) The token is signed with the issuing node's DOSD_IDENTITY_KEY secret using HMAC-SHA256. 9.2. Token Verification A relying node verifies a DOSD-IT by: 1. Decoding the JWT header and confirming typ="DOSD-IT". 2. Fetching the issuing node's dosd.json to confirm stewardship_status is "active". 3. Verifying the JWT signature using the issuing node's published key or a pre-shared secret. 4. Confirming the "dh" (declaration hash) matches a record in the issuing node's participant registry. 5. Confirming the token has not expired per local policy. Nodes MAY accept DOSD-ITs from other nodes as portable proof of standing. Acceptance policy is at the relying node's discretion. 10. Federation and Relay 10.1. Satellite Nodes A satellite node is a domain that participates in DOSD but relays its NCP through a parent node. A satellite node: o Maintains its own dosd.json at its own domain. o Sets its linktree node type to "satellite". o Includes parent_domain and parent_canonical_uri fields in its linktree node. o Uses the parent node's SMTP infrastructure for NCP notice delivery (relay_via field in the ncp object). The parent node is the canonical record for federation purposes. The satellite's dosd.json links to the parent. 10.2. Relay Requirements A relay node MUST: o Maintain an active DOSD declaration. o Accept relay requests only from domains it has explicitly authorized. o Record relay relationships in its satellite_domains array. o Process NCP notices on behalf of satellite domains and record delivery in its own notice audit log. 11. Dual-Track Notice 11.1. Digital Track The digital track consists of: o Email delivery of the notice to the respondent. o Recording of the delivery timestamp in the dosd_notices table. o SHA-256 hash of the notice document recorded in the linktree. The digital track provides immediate, auditable delivery evidence. 11.2. Physical Track (UPU) For notices where physical delivery evidence is desired, the steward MAY send a physical copy via UPU/USPS postal service. The UPU tracking number is recorded as upu_ref in the linktree node and in the dosd_declarations record. When delivery is confirmed, upu_confirmed is set to true and upu_confirmed_at is recorded. Physical delivery via UPU provides a delivery record that is independent of the digital infrastructure and cannot be disputed by claims of non-receipt of email. 12. Security Considerations 12.1. DNS Integrity DOSD discovery relies on DNS TXT records. DNS is subject to spoofing in the absence of DNSSEC. Relying parties SHOULD prefer domains that have deployed DNSSEC when making trust decisions based on DOSD data. 12.2. HTTPS and TLS The dosd.json file MUST be fetched over HTTPS. Certificate errors MUST be treated as fetch failures. A valid TLS certificate for the serving domain provides authenticated transport. 12.3. Hash Integrity Linktree node hashes are computed using SHA-256. The chain structure means that tampering with any node invalidates all subsequent node hashes. Relying parties SHOULD verify the hash chain when auditing a linktree. 12.4. Identity Token Secret The DOSD_IDENTITY_KEY used to sign DOSD-ITs MUST be kept confidential. Exposure of the key allows forgery of identity tokens. Keys SHOULD be rotated periodically. Rotated keys invalidate existing tokens signed with the old key. 12.5. No Legal Effect DOSD does not create legal obligations, enforceable rights, or admissible evidence in any jurisdiction. Parties relying on DOSD records for legal purposes do so at their own risk and should seek qualified legal counsel. 13. Privacy Considerations 13.1. Public Disclosure dosd.json files are publicly accessible. Stewards SHOULD NOT include personally identifiable information beyond what they intend to disclose publicly. 13.2. Participant Data Participant registries (name + node ID) that are published in the public viewer expose the participant's name and participation to anyone who fetches the page. Participants SHOULD be informed of this disclosure at signup. 13.3. Email Addresses Email addresses of participants and respondents MUST NOT be included in public-facing records. Internal records (steward- only access) MAY store email addresses for operational purposes. 14. IANA Considerations 14.1. Well-Known URI Registration This document requests registration of the following Well-Known URI in the "Well-Known URIs" registry as defined by [RFC8615]: URI Suffix: dosd.json Change Controller: The author of this document Reference: This document Status: Permanent Related Information: DOSD protocol 14.2. DNS TXT Record Key Registration This document uses the label "_dosd" as a DNS underscore name per [RFC8552]. Registration of "_dosd" in the "Underscored and Globally Scoped DNS Node Names" registry is requested. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through 'Underscored' Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . 15.2. Informative References [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [UPU] Universal Postal Union, . Author's Address Michael Leigh Macgowan scadenger.com Florence, Colorado United States Email: mmacgowa@yahoo.com URI: https://scadenger.com/.well-known/dosd.json -- End of draft-macgowan-dosd-00 --