Domain Operational Standing Declaration (DOSD) Protocol
draft-macgowan-dosd-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Michael Leigh Macgowan | ||
| Last updated | 2026-06-16 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-macgowan-dosd-01
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.<domain>" 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.<domain>".
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://<domain>/.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://<domain>/.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 = <domain name as defined in [RFC1034],
Section 3.5>
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,
<https://scadenger.com/.well-known/specs/
DOSD_AI_DISCOVERY_v1.0.md>.
[DOSD-ID] Macgowan, M., "DOSD Identifier Scheme",
DOSD_URN_SPEC_v1.0, June 2026,
<https://scadenger.com/.well-known/specs/
DOSD_URN_SPEC_v1.0.md>.
[DOSD-FED] Macgowan, M., "DOSD Federation Model",
DOSD_FEDERATION_MODEL_v1.0, June 2026,
<https://scadenger.com/.well-known/specs/
DOSD_FEDERATION_MODEL_v1.0.md>.
[DOSD-ESC] Macgowan, M., "DOSD Escalation Model",
DOSD_ESCALATION_MODEL_v1.0, June 2026,
<https://scadenger.com/.well-known/specs/
DOSD_ESCALATION_MODEL_v1.0.md>.
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 --