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.<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.
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.<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. 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 = <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. 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,
<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-02 --