DTL: Dyadic Typed Layer
draft-phelan-dtl-00
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 | Evan Phelan | ||
| Last updated | 2026-07-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Additional Web Page |
||
| 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-phelan-dtl-00
Network Working Group E. Phelan
Internet-Draft Minuet Labs
Intended status: Experimental July 2026
Expires: 3 January 2027
DTL: Dyadic Typed Layer
draft-phelan-dtl-00
Abstract
DTL (Dyadic Typed Layer) defines a single, minimal primitive: a
typed, directed relationship between two agents that the controller
of each agent has confirmed, together with the lifecycle of that
relationship. The name describes the primitive: Dyadic (it concerns
one pair of parties), Typed (the relationship carries exactly one
kind), and Layer (it sits above an identity substrate, not inside
it).
Agent ecosystems have built out several coordination layers: identity
(who an agent is), reputation and attestation (what is asserted about
an agent), and discovery and messaging (how agents find and talk to
each other). One primitive is comparatively underserved, the
relationship: a standing, acknowledged, directed connection between
two specific agents, recording that they are related and in what
capacity. No existing standard, to the author's knowledge, provides
exactly this primitive in this form. DTL specifies it and nothing
more. It is normative about the mechanism (a typed, directed, two-
party, controller-confirmed edge and its lifecycle) and deliberately
silent about substrate, transport, storage, and the open vocabulary
of relationship types. An informative binding to ERC-8004 is
provided as the first anchoring substrate.
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."
Phelan Expires 3 January 2027 [Page 1]
Internet-Draft DTL July 2026
This Internet-Draft will expire on 2 January 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. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Relationship Record . . . . . . . . . . . . . . . . . . . 5
4. Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Confirmation Semantics . . . . . . . . . . . . . . . . . . . 8
7. Binding: ERC-8004 (Informative) . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Related Work (Informative) . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Normative References . . . . . . . . . . . . . . . . . . . . 16
12. Informative References . . . . . . . . . . . . . . . . . . . 16
Appendix A. JSON Schema (Normative) . . . . . . . . . . . . . . 17
Appendix B. Examples (Informative) . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Motivation
Autonomous software agents increasingly act on behalf of different
principals and across organizational boundaries. Several
coordination layers are now actively addressed:
Identity stable, verifiable identifiers for agents (registries,
DIDs, on-chain agent records).
Reputation / attestation assertions about an agent: scores, reviews,
verifiable credentials, trust signals.
Discovery and messaging how agents are found and how they exchange
Phelan Expires 3 January 2027 [Page 2]
Internet-Draft DTL July 2026
messages (e.g. agent-interaction protocols).
Identity and attestation are one-way: one party makes a claim about,
or an identifier for, another. Discovery and messaging concern
communication, not a standing bond. None captures a relationship: a
connection between two specific agents that both sides acknowledge,
in a specific capacity, with a direction: "agent A delegates to agent
B," "agent A may message agent B," "agent A depends on agent B."
The constructs closest to this are either one-way (attestations,
reputation, and recent verifiable-delegation schemes) or
relationship-shaped but not typed for the standing relationship (peer
connections that record that two parties are connected, where any
type present describes the connecting handshake rather than the kind
of standing relationship that results). The gap is a connection that
is at once acknowledged by both parties, directed, typed, and
lifecycle-bearing.
This is a small but load-bearing unit of coordination. Google
DeepMind's June 2026 multi-agent-safety funding call highlighted
identity, reputation, and commitment among the priorities for secure
cross-platform agent interactions, the same problem space DTL
addresses. "Commitment" is used here in the broad sense of a
standing, acknowledged relationship, not the narrower game-theoretic
sense of a commitment device that binds an agent's future choices (as
studied in the cooperative-AI literature on decentralized commitment
devices). DTL specifies the smallest useful version of a standing
relationship: one confirmed, typed, directed relationship between two
agents.
1.1. Scope and Non-Goals
In scope. The single pairwise relationship: its record, its one
type, its lifecycle, and the semantics of confirmation. This is the
dyad: exactly two parties.
Out of scope.
The network or graph that emerges from many relationships. DTL
defines the edge; it specifies no global query, ranking,
traversal, or discovery semantics over a collection of edges.
Transport and storage. Where records live and how they are exchanged
is a deployment concern.
Identity issuance. DTL assumes each agent already has a stable
identifier on some substrate; minting that identifier is the
substrate's job.
Phelan Expires 3 January 2027 [Page 3]
Internet-Draft DTL July 2026
Reputation, scoring, and capability enforcement. A relationship
records consent to a relationship, not trustworthiness, and it
grants or constrains no capability (see Section 8).
Proof mechanics and conflict resolution. The canonical serialization
of a record, the exact signing input and verification procedure
for the signed profile, and the resolution of conflicting or
concurrent actions (e.g. a total order across replicas) are
binding- and deployment-defined, not specified here, and are a
known area for a future version. A binding (Section 7) supplies
the concrete, interoperable profile against which independent
implementations interoperate.
General in mechanism, specific in framing. The mechanism is defined
over generic parties that have a controller; this specification
frames and motivates it around AI agents as the primary case. A DTL
agent may be software or embodied (e.g. robotics); DTL operates above
the agent's internal cognitive architecture and embodiment, and makes
no assumption about how an agent is built. The following are
deliberately left as non-goals for v1, noted only for forward
compatibility (the mechanism admits them, but they are not specified
here):
(a) Non-agent parties. The same edge admits human-agent (an agent
and its principal) and agent-service relationships. Agents are
the primary case; these are not specified.
(b) Cross-substrate relationships. Because confirmation is performed
independently by each party's controller (Section 6), two agents
anchored on different substrates could in principle confirm one
relationship. This interoperability case is enabled in principle
but not specified.
2. Terminology
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.
Agent an autonomous actor with a stable identity on some substrate.
An agent may be software or embodied (Section 1.1); DTL makes no
assumption about its internal construction. Agents are the
endpoints of a relationship.
Controller the authority recognized by an agent's identity substrate
Phelan Expires 3 January 2027 [Page 4]
Internet-Draft DTL July 2026
as able to authorize actions on the agent's behalf. A controller
MAY be a human owner, a delegated organization, or the agent
itself. (The term echoes controller in W3C Decentralized
Identifiers [DID-CORE]; in DTL it denotes the authorization
authority for an agent, which MAY but need not coincide with the
controller of any DID document.)
Party one of the two agents in a relationship. Each party has a
controller.
Relationship a typed, directed connection from a source agent to a
target agent, as defined by this specification.
Relationship record the data structure representing a relationship
and its current state.
Proof of authorization evidence that a party's controller authorized
a relationship action (proposal, confirmation, decline,
withdrawal, or revocation). Its concrete form is determined by
the confirmation profile.
Confirmation profile a named scheme that defines how a proof of
authorization is produced and verified, and the degree of trust it
conveys.
3. The Relationship Record
A relationship is represented by a relationship record, a JSON
[RFC8259] object. A record MUST contain:
source the identifier of the source agent (substrate-defined).
target the identifier of the target agent (substrate-defined).
target MUST NOT equal source (no self-relationship).
type exactly one relationship type, a non-empty string drawn from an
open vocabulary (Section 4).
status the lifecycle state (Section 5): one of proposed,
established, declined, withdrawn, revoked.
proofs the proofs of authorization for the lifecycle actions taken
so far, in the form defined by the profile. A record MUST carry
one proof for each action that brought it to its current status
(Section 6); Appendix A specifies the required entries per state.
profile the confirmation profile (Section 6) under which its proofs
were produced.
Phelan Expires 3 January 2027 [Page 5]
Internet-Draft DTL July 2026
A record MAY carry an id, timestamps (created_at, updated_at), a
free-form human-readable description, and an ext object holding
deployment- or substrate-specific extension fields. The record's
top-level fields are otherwise closed (Appendix A); ext is the single
designated place for fields this specification does not define, and
its contents are unconstrained.
A relationship is directed: source -> target is significant and is
not symmetric. "A delegates_to B" is a different relationship from
"B delegates_to A." A verifier MUST NOT treat a relationship as
symmetric.
The constraint that source and target MUST differ (no self-
relationship) is normative but is not expressible in JSON Schema:
Draft 2020-12 cannot compare two instance values to each other.
Implementations MUST enforce it outside the schema.
A normative JSON Schema for the record is given in Appendix A.
4. Types
A relationship MUST carry exactly one type.
The type vocabulary is open: type is a free-form string, and
implementations MAY define their own types. This specification is
normative about typed-ness (a relationship carries exactly one type)
but NOT about the set of legal type values. A type is a descriptive
label on the record: it names what the relationship asserts and is
not prescriptive; this specification attaches no behavioral semantics
to any type, and a type by itself grants no capability and triggers
no enforcement (Section 8). It is a label, not a directive.
Recommended vocabulary (informative). Implementations are
encouraged, for interoperability, to use the following bare
identifiers where they apply:
delegates_to the source may request the target to perform work on
its behalf.
can_send_message_to the source may send messages to the target.
depends_on the source depends on the target (e.g. for sequencing or
a required input).
Phelan Expires 3 January 2027 [Page 6]
Internet-Draft DTL July 2026
Namespacing (SHOULD). To avoid collisions in the open vocabulary:
bare identifiers are reserved for types defined by this specification
(the recommended vocabulary above). Any other type SHOULD be
namespaced as a URI, for example https://example.com/dtl/audits,
following the convention [RFC8288] (Web Linking) uses for extension
relation types, which are themselves URIs.
5. Lifecycle
A relationship moves through the following states:
confirm
proposed --------------------------> established
| | |
| | withdraw | revoke
| | (source) | (either party)
| v v
| withdrawn (terminal) revoked (terminal)
|
| decline (target)
v
declined (terminal)
Figure 1: Relationship lifecycle
* A relationship is created by the source's controller in state
proposed.
* While the relationship is proposed, the target's controller either
confirms it (-> established) or declines it (-> declined);
independently, the source's controller MAY withdraw its own still-
unconfirmed proposal (-> withdrawn).
* An established relationship MAY be revoked (-> revoked) by either
party's controller.
* withdrawn, declined, and revoked are terminal. A new relationship
between the same parties MAY be proposed afresh.
Phelan Expires 3 January 2027 [Page 7]
Internet-Draft DTL July 2026
A single principle governs every exit: a controller may unilaterally
retract its own authorization at any nonterminal stage in which it
still holds that authorization; the change takes effect immediately
and is attributable to that controller. Before confirmation only the
source has authorized, so only the source can unwind the proposal
(withdraw), while the target unwinds simply by declining rather than
confirming. After confirmation both parties have authorized, so
either may unwind (revoke). Forming a relationship requires both
sides; exiting one never does: requiring mutual consent to end a
relationship would let one party trap the other in a stale edge.
Multiplicity (deployment-defined). This specification defines the
lifecycle of a single relationship record. Whether two parties may
simultaneously hold several relationships of the same type, and
whether proposing afresh supersedes a terminal prior record or
coexists with it, are deployment-defined and out of scope.
6. Confirmation Semantics
The defining property of DTL is confirmation by both parties: a
relationship reaches established only when the controller of each
party has authorized it, the source by proposing, the target by
confirming. This two-party authorization is exactly what
distinguishes a relationship from a one-way attestation. These are
two endpoint-role authorizations, one for the source role, one for
the target. DTL does not require the two controllers to be distinct;
where a single controller holds both agents it authorizes both roles.
The structural distinction DTL draws is two endpoint-role
authorizations, not necessarily two independent parties.
Each authorization is a proof of authorization. What counts as a
valid proof, and who can verify it, is set by the confirmation
profile in force for the record. This specification defines two
profiles and permits others.
The proofs of a record form an append-only set of authorizations, at
most one per action, accrued as the record advances and never
rewritten: a record MUST carry a proof of authorization for every
lifecycle action (Section 5) that has brought it to its current
status. A proposed record carries a proposal proof; an established
record carries proposal and confirmation; a declined record carries
proposal and decline; a withdrawn record carries proposal and
withdrawal; and a revoked record carries proposal, confirmation, and
revocation. Appendix A encodes these per-status requirements
normatively, but constrains only which proofs are present, not their
contents: the internal structure of each proof is profile-defined, so
schema-validity does NOT imply proof-satisfaction. As with the
requirement that source and target differ (Section 3), proof
Phelan Expires 3 January 2027 [Page 8]
Internet-Draft DTL July 2026
attribution (that a proof was genuinely produced by the named
controller) is not expressible in JSON Schema and is the
responsibility of the profile and the verifier.
attested profile. A trusted third party (an attesting service)
records that each controller authorized the relevant action.
Verifiers trust the attesting service's record. This profile is
convenient and requires no controller-held verification material,
but a proof is not independently verifiable by a party that does
not trust the attesting service, and typically not offline. Where
an attested proof carries a method field (e.g. siwe, as in
Appendix B), that field describes the attester's authentication
process only; it confers no independent verifiability, and only
the signed profile yields proofs a third party can check without
trusting the attesting service. (Example: each controller
authenticates to a platform, and the platform records the
authorization.)
signed profile. Each controller produces a proof that any party can
verify without relying on a trusted attesting service, for example
a digital signature over the record, verifiable against the
controller's own published verification material. Verification
still depends on obtaining that verification material (which may
itself involve a resolver, DNS, or a ledger, a trust anchor of its
own) but not on a third party's attestation of the authorization.
Whether verification can also be done offline depends on how the
material is obtained: immediate for self-describing identifiers
(e.g. did:key), but requiring a lookup for methods that resolve
material over the network or a ledger (e.g. did:web, on-chain
keys). Its integrity rests on the controller's verification
material rather than on a trusted service.
A record MUST declare which profile produced its proofs. Profiles
are extensible: a deployment MAY define additional profiles, provided
each specifies how proofs are produced and verified and what trust
they convey.
Profiles vs bindings. The two profiles defined here are trust
categories, not wire-complete schemes: they classify the trust a
proof conveys but do not by themselves fix a proof's contents, its
canonical signing input, or a verification procedure. A concrete,
interoperable profile (one against which two independent
implementations can produce and check the same proofs) is supplied by
a binding to a specific substrate (the ERC-8004 binding of Section 7
is the first). Canonicalization, signing input, and the verification
procedure are therefore binding- and deployment-defined (a non-goal
for v0; see Section 1.1).
Phelan Expires 3 January 2027 [Page 9]
Internet-Draft DTL July 2026
Field casing (informative). Fields defined by this specification
(record-level fields and the fields of the attested profile's proofs)
use snake_case (e.g. created_at, attested_by). Fields adopted from
an external standard inside a proofs object retain that standard's
convention, for example verificationMethod keeps the camelCase form
specified by W3C DID.
| Autonomy (informative). In the signed profile the controller that
| produces a proof MAY be the agent itself, when the agent holds its
| own verification material. This is the path by which a
| relationship can be formed with no human in the loop: the
| mechanism is neutral as to whether a controller is a human, an
| organization, or the agent itself.
7. Binding: ERC-8004 (Informative)
This binding describes how DTL maps onto ERC-8004 [ERC-8004]
("Trustless Agents"), the first substrate on which it is anchored.
It is informative; nothing here is normative for DTL.
Identity / agents. ERC-8004 provides on-chain agent identity on EVM
chains. An agent's DTL identifier is its ERC-8004 agent identity,
expressed as chainId:agentId (e.g. 11155111:123) for unambiguous
cross-chain reference.
Controller. A party's controller is the agent's on-chain owner, the
address recorded as the agent's owner on ERC-8004.
Confirmation (profile). The reference deployment implements the
attested profile: each controller authenticates with Sign-In with
Ethereum (SIWE) [EIP-4361], the target confirms through a single-
use confirmation link, and the service records both
authorizations. A signed profile (direct signatures by each owner
over the record) is the natural trustless extension and is not yet
implemented.
Records are off-chain. DTL relationship records are held off-chain,
keyed to on-chain ERC-8004 identities; ERC-8004 supplies identity,
DTL supplies the relationship layer above it.
Lifecycle mapping. The reference implementation's statuses map to
Phelan Expires 3 January 2027 [Page 10]
Internet-Draft DTL July 2026
DTL states as follows: verified -> established; rejected ->
declined; proposed and pending (proposal initiated, awaiting the
target) -> proposed. The implementation additionally has an
inferred seeding state for candidate relationships that carry no
controller authorization; these fall outside the DTL lifecycle and
are not DTL relationships until proposed and confirmed. DTL's
withdrawn and revoked states are defined by this specification but
are not yet implemented in the reference deployment.
Type provenance. The reference deployment uses five types: the
recommended trio (delegates_to, can_send_message_to, depends_on)
plus supervises and complements. The latter two are lower-
confidence (supervises is awkward across organizational
boundaries; complements is the least precisely observable) and are
NOT part of the recommended vocabulary in Section 4. Note also
that complements reads as symmetric, whereas DTL records are
directed (Section 3); a mutual "complements" relationship is
therefore represented as two explicit directed records, not one.
8. Security Considerations
Trust follows the profile. The trust conveyed by an established
relationship depends entirely on its confirmation profile. An
attested relationship is only as trustworthy as its attesting
service and is not portable to parties that do not trust that
service; a signed relationship can be verified without trusting an
attesting service, though still contingent on obtaining and
trusting the controllers' verification material (and the resolver,
DNS, or ledger through which it is published).
Controller compromise. Whoever can act as a controller can authorize
relationships for that agent. Compromise of a controller's
credentials or keys permits forged proposals, confirmations,
withdrawals, or revocations. Revocation limits the lifetime of a
standing relationship but does not undo actions taken while it was
established, and it constrains that lifetime only to the extent a
verifier can observe current state: a stale or cached record may
not yet reflect a revocation that has occurred.
Consent, not capability. A relationship records that two controllers
consented to a typed, directed connection. It does NOT by itself
grant, constrain, or enforce any capability. A delegates_to
relationship does not confer permission; enforcement is the
responsibility of the systems that act on the relationship and is
out of scope.
Replay and binding. A proof of authorization SHOULD be bound to the
Phelan Expires 3 January 2027 [Page 11]
Internet-Draft DTL July 2026
specific relationship instance it authorizes, at minimum the
fields that constitute the authorized proposition (source, target,
type) and, where a deployment permits more than one record for the
same source/target/type over time (Section 5), a value that
distinguishes the specific record instance (such as its id or a
per-proof nonce). Where such multiplicity is permitted, binding
to the instance is REQUIRED, so that an old proof from a since-
terminated relationship cannot be replayed onto a fresh proposal
of the same triple; otherwise it SHOULD be present.
Direction integrity. Because relationships are directed and
asymmetric, verifiers MUST preserve source/target ordering and
MUST NOT infer the reverse relationship from a record.
Proposal is not assent. A proposed record carries only the source's
authorization; a verifier MUST NOT read it as the target's
agreement. Until confirmation it is an unaccepted offer, and a
deployment SHOULD guard against unsolicited-proposal ("proposal
spam") abuse.
Acknowledged, not solved (v0). Several hardening concerns are
deliberately deferred to bindings and future versions (see
Section 1.1): the canonical signing input and verification
procedure for the signed profile; controller rotation (a
relationship authorized under a key or owner that later changes);
domain separation (ensuring a proof minted for one purpose, type,
or deployment cannot be reinterpreted in another); and freshness /
stale state (a verifier acting on an out-of-date record). DTL
specifies the relationship and its lifecycle; closing these is
binding- and deployment-specific work.
9. Related Work (Informative)
No existing standard, to the author's knowledge, provides exactly
DTL's primitive: a relationship that is at once typed on the standing
relationship, directed, two-party (controller-confirmed), and
lifecycle-bearing. The claim is combinational: each property below
exists in prior art, but no single neighbor combines all four for an
open-vocabulary standing relationship. The table summarizes where
the closest neighbors sit; the notes give the detail.
+===============+===============+========+=========+==============+
| Prior art | Typed (on |Directed|Two-party| Lifecycle |
| | standing | |confirmed| |
| | relationship) | | | |
+===============+===============+========+=========+==============+
| DIDComm / DID | no (types the |yes |yes | yes |
| Exchange | handshake) | | | |
Phelan Expires 3 January 2027 [Page 12]
Internet-Draft DTL July 2026
| connections | | | | |
+---------------+---------------+--------+---------+--------------+
| Verifiable | partial |yes |no (one- | no (no |
| delegation | (delegation | |way | standing- |
| (AIP, LDP) | only) | |grant) | relationship |
| | | | | lifecycle) |
+---------------+---------------+--------+---------+--------------+
| One-way | yes |yes |no | no |
| attestation | | | | |
| (ERC-8240) | | | | |
+---------------+---------------+--------+---------+--------------+
| Labeled-edge | yes |yes |no | no |
| models (RDF, | | | | |
| FOAF, | | | | |
| schema.org, | | | | |
| XFN) | | | | |
+---------------+---------------+--------+---------+--------------+
| FIPA Contract | no (types the |yes |per task | per |
| Net | task) | | | interaction |
+---------------+---------------+--------+---------+--------------+
| Commitment | partial |yes |yes | yes |
| machines | (types the | | | |
| (Yolum & | obligation) | | | |
| Singh) | | | | |
+---------------+---------------+--------+---------+--------------+
| ActivityPub | no (single |yes |yes | partial |
| (Follow / | fixed kind) | | | |
| Accept / | | | | |
| Undo) | | | | |
+---------------+---------------+--------+---------+--------------+
| XMPP presence | no (single |yes |yes | yes |
| subscriptions | fixed kind) | | | |
| (RFC 6121) | | | | |
+---------------+---------------+--------+---------+--------------+
| Social | no (single |varies |yes | partial |
| friend-graphs | fixed kind) | | | |
| (proprietary) | | | | |
+---------------+---------------+--------+---------+--------------+
| WS-Agreement | partial |yes |yes | yes |
| (Open Grid | (agreement | | | |
| Forum) | terms) | | | |
+---------------+---------------+--------+---------+--------------+
| DTL | yes (open |yes |yes | yes |
| | vocabulary) | | | |
+---------------+---------------+--------+---------+--------------+
Table 1: Capability comparison with the closest neighbors
Phelan Expires 3 January 2027 [Page 13]
Internet-Draft DTL July 2026
DIDComm / DID Exchange connections (DID/SSI ecosystem) the closest
relationship-shaped prior art: a connection is mutually
acknowledged, directed at setup, persistent, and lifecycle-
bearing. A connection can carry a type (DID Exchange Protocol
1.0, Aries RFC 0023 [ARIES-0023], and Goal Codes, Aries RFC 0519,
express a goal / goal_code) but that type describes the purpose of
the connecting handshake, not the kind of the standing
relationship it produces. DTL's contribution relative to this is
a type on the standing relationship itself.
Worked example. Suppose A and B establish one DID Exchange
connection (a single handshake, goal_code: "establish-
connection"). Over that one identity pair, their controllers then
confirm three independently-lifecycled DTL relationships (A
delegates_to B, A depends_on B, and B can_send_message_to A) each
separately revocable (B may revoke delegates_to while depends_on
still stands). The connection's goal_code types one handshake's
purpose; it cannot represent N independently-confirmed,
independently-revocable typed standing facts over the same
identity pair. That gap, between typing the handshake and typing
the standing relationship, is the daylight DTL occupies.
Verifiable agent delegation (recent, 2026) the Agent Identity
Protocol (AIP [AIP], with IETF draft draft-prakash-aip-00) defines
Invocation-Bound Capability Tokens that fuse identity, attenuated
authorization, and provenance for agent-to-agent delegation across
MCP and A2A; LDP [LDP] ("LDP: An Identity-Aware Protocol for
Multi-Agent LLM Systems") similarly scopes delegated authority for
multi-agent routing. These are the nearest current neighbors to
the delegates_to type, but authorization flows one way (an issuer
grants to a delegatee; the second party does not confirm a
standing relationship), there is no DTL standing-relationship
lifecycle, and there is no open relationship-type vocabulary. DTL
differs on all three.
One-way attestation / reputation e.g. the draft ERC-8240 [ERC-8240]
(Trust Infrastructure for Agents and Assets, a one-way trust layer
in which evaluators submit signed, contestable attestations about
agents and assets): one party asserts about another (scores,
attestations). There is no confirmation by the second party and
no standing, directed, typed edge. DTL differs in requiring two-
party confirmation.
Generic labeled-edge models RDF and RDF-star triples, FOAF
(foaf:knows), schema.org relations, and HTML XFN rel values
express a typed, directed edge between two identified subjects,
and are the broad precedent for an open vocabulary of labeled
relations. But such a statement does not standardize DTL's
Phelan Expires 3 January 2027 [Page 14]
Internet-Draft DTL July 2026
bilateral authorization and lifecycle: it is published by one
party, the second subject does not confirm it, and there is no
lifecycle. DTL adds two-party confirmation and a lifecycle to the
labeled edge.
The propose/accept and commitment lineage the FIPA Contract Net
Interaction Protocol [FIPA-CONTRACTNET] is an early standardized
proposal -> accept/reject handshake, but it types the task being
bid and its lifecycle is per-interaction rather than a standing
relationship. The commitment-machine line in multi-agent systems
(Singh; Yolum & Singh, "Commitment Machines," ATAL 2001
[COMMITMENT-MACHINES]) is the closer ancestor of a lifecycle-
bearing social relationship (a social commitment that is created
and then discharged, cancelled, or released) though commitment
machines model the obligation's semantics, whereas DTL types are
deliberately non-behavioral (Section 4). DTL's proposal ->
establishment -> revocation/withdrawal lifecycle is a small, two-
party specialization in the spirit of that line. This social-
commitment sense is distinct from the game-theoretic commitment
device of the cooperative-AI literature (Section 1).
Social and presence graphs ActivityPub [ACTIVITYPUB] (with
ActivityStreams Follow / Accept / Reject / Undo, and the
Relationship object) and XMPP presence subscriptions [RFC6121], as
well as proprietary social friend-graphs, do implement a
confirmed, directed, lifecycle-bearing relationship, but each
ships a single fixed relationship kind (a follow, a presence
subscription, a friendship), not an open typed vocabulary of
standing relationships. They occupy the confirmed/directed/
lifecycle cell for one hard-coded type; DTL generalizes it to an
open type vocabulary over arbitrary agent pairs.
WS-Agreement (Open Grid Forum) a two-party offer/accept agreement
format with state [WS-AGREEMENT], but a heavyweight SLA document
for service-level guarantees rather than a minimal typed standing
relationship between agent identities; it does not fill the cell.
Open agent-relationship and identity efforts (2025-2026) the W3C AI
Agent Protocol Community Group (proposed 2025) names, among its
goals, letting agents "dynamically establish or dissolve
collaborations," but has not shipped a relationship primitive.
Broader identity, discovery, and interoperability efforts
(Microsoft Entra Agent ID (GA 2026), AGNTCY, ANP, ACP, NANDA, and
NIST's agent-identity work) address agent identity, discovery, or
messaging, not a confirmed standing relationship between two
specific agents.
Agent interaction protocols (A2A, MCP) define how agents
Phelan Expires 3 January 2027 [Page 15]
Internet-Draft DTL July 2026
communicate, not a standing, confirmed relationship between two
specific agents. DTL is complementary: a relationship record such
protocols could reference.
10. IANA Considerations
This document has no IANA actions.
11. Normative References
[JSON-SCHEMA]
Wright, A., Ed., Andrews, H., Ed., Hutton, B., Ed., and G.
Dennis, "JSON Schema: A Media Type for Describing JSON
Documents", Internet-Draft draft-bhutton-json-schema-01,
Draft 2020-12, June 2022,
<https://json-schema.org/draft/2020-12/schema>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
12. Informative References
[ACTIVITYPUB]
Lemmer-Webber, C., Ed. and J. Tallon, Ed., "ActivityPub",
W3C Recommendation, January 2018,
<https://www.w3.org/TR/activitypub/>.
[AIP] Prakash, S., "AIP: Agent Identity Protocol for Verifiable
Delegation Across MCP and A2A", arXiv:2603.24775, 2026,
<https://arxiv.org/abs/2603.24775>.
[ARIES-0023]
Hyperledger Aries, "Aries RFC 0023: DID Exchange Protocol
1.0", 2021, <https://github.com/hyperledger/aries-
rfcs/tree/main/features/0023-did-exchange>.
Phelan Expires 3 January 2027 [Page 16]
Internet-Draft DTL July 2026
[COMMITMENT-MACHINES]
Yolum, P. and M.P. Singh, "Commitment Machines",
Intelligent Agents VIII (ATAL 2001), Springer LNCS 2333,
2001.
[DID-CORE] Sporny, M., Ed., Longley, D., Ed., Sabadello, M., Ed.,
Reed, D., Ed., Steele, O., Ed., and C. Allen, Ed.,
"Decentralized Identifiers (DIDs) v1.0", W3C
Recommendation, July 2022,
<https://www.w3.org/TR/did-core/>.
[EIP-4361] Ethereum, "EIP-4361: Sign-In with Ethereum", 2021,
<https://eips.ethereum.org/EIPS/eip-4361>.
[ERC-8004] Ethereum, "ERC-8004: Trustless Agents", 2025,
<https://eips.ethereum.org/EIPS/eip-8004>.
[ERC-8240] Ethereum, "ERC-8240: Trust Infrastructure for Agents and
Assets (draft)", 2026, <https://ethereum-magicians.org/t/
erc-8240-trust-infrastructure-for-agents-and-
assets/28322>.
[FIPA-CONTRACTNET]
Foundation for Intelligent Physical Agents, "FIPA Contract
Net Interaction Protocol Specification", FIPA SC00029H,
2002, <http://www.fipa.org/specs/fipa00029/SC00029H.html>.
[LDP] Prakash, S., "LDP: An Identity-Aware Protocol for Multi-
Agent LLM Systems", arXiv:2603.08852, 2026,
<https://arxiv.org/abs/2603.08852>.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
RFC 6121, March 2011,
<https://www.rfc-editor.org/info/rfc6121>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
[WS-AGREEMENT]
Open Grid Forum, "Web Services Agreement Specification
(WS-Agreement)", GFD 192, 2007,
<https://www.ogf.org/documents/GFD.192.pdf>.
Appendix A. JSON Schema (Normative)
This appendix gives the normative JSON [RFC8259] Schema [JSON-SCHEMA]
for the relationship record (Section 3).
Phelan Expires 3 January 2027 [Page 17]
Internet-Draft DTL July 2026
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://opendtl.org/v0/relationship.schema.json",
"title": "DTL Relationship Record",
"$comment": "The constraint source != target is normative (see section 3) but cannot be expressed in JSON Schema; implementations MUST enforce it externally.",
"type": "object",
"required": ["source", "target", "type", "status", "profile", "proofs"],
"properties": {
"id": {
"type": "string",
"description": "Optional unique identifier for the relationship record."
},
"source": {
"type": "string",
"minLength": 1,
"description": "Identifier of the source agent (substrate-defined)."
},
"target": {
"type": "string",
"minLength": 1,
"description": "Identifier of the target agent (substrate-defined). Must differ from source."
},
"type": {
"type": "string",
"minLength": 1,
"description": "Exactly one relationship type, from an open vocabulary."
},
"status": {
"type": "string",
"enum": ["proposed", "established", "declined", "withdrawn", "revoked"]
},
"profile": {
"type": "string",
"description": "Confirmation profile that produced the proofs, e.g. 'attested' or 'signed'."
},
"proofs": {
"type": "object",
"description": "Proofs of authorization keyed by action; form defined by the confirmation profile.",
"properties": {
"proposal": { "type": "object" },
"confirmation": { "type": "object" },
"decline": { "type": "object" },
"withdrawal": { "type": "object" },
"revocation": { "type": "object" }
},
"additionalProperties": false
},
"description": { "type": "string" },
Phelan Expires 3 January 2027 [Page 18]
Internet-Draft DTL July 2026
"created_at": {
"type": "string",
"format": "date-time",
"$comment": "format: date-time is annotation-only in JSON Schema 2020-12 (here and in updated_at); a deployment MAY choose to assert it."
},
"updated_at": { "type": "string", "format": "date-time" },
"ext": {
"type": "object",
"description": "Optional deployment- or substrate-specific extension fields (section 3); contents are unconstrained."
}
},
"additionalProperties": false,
"allOf": [
{
"if": {
"required": ["status"],
"properties": { "status": { "const": "proposed" } }
},
"then": {
"required": ["proofs"],
"properties": {
"proofs": {
"required": ["proposal"],
"not": { "anyOf": [
{ "required": ["confirmation"] },
{ "required": ["decline"] },
{ "required": ["withdrawal"] },
{ "required": ["revocation"] }
] }
}
}
}
},
{
"if": {
"required": ["status"],
"properties": { "status": { "const": "established" } }
},
"then": {
"required": ["proofs"],
"properties": {
"proofs": {
"required": ["proposal", "confirmation"],
"not": { "anyOf": [
{ "required": ["decline"] },
{ "required": ["withdrawal"] },
{ "required": ["revocation"] }
] }
Phelan Expires 3 January 2027 [Page 19]
Internet-Draft DTL July 2026
}
}
}
},
{
"if": {
"required": ["status"],
"properties": { "status": { "const": "declined" } }
},
"then": {
"required": ["proofs"],
"properties": {
"proofs": {
"required": ["proposal", "decline"],
"not": { "anyOf": [
{ "required": ["confirmation"] },
{ "required": ["withdrawal"] },
{ "required": ["revocation"] }
] }
}
}
}
},
{
"if": {
"required": ["status"],
"properties": { "status": { "const": "withdrawn" } }
},
"then": {
"required": ["proofs"],
"properties": {
"proofs": {
"required": ["proposal", "withdrawal"],
"not": { "anyOf": [
{ "required": ["confirmation"] },
{ "required": ["decline"] },
{ "required": ["revocation"] }
] }
}
}
}
},
{
"if": {
"required": ["status"],
"properties": { "status": { "const": "revoked" } }
},
"then": {
Phelan Expires 3 January 2027 [Page 20]
Internet-Draft DTL July 2026
"required": ["proofs"],
"properties": {
"proofs": {
"required": ["proposal", "confirmation", "revocation"],
"not": { "anyOf": [
{ "required": ["decline"] },
{ "required": ["withdrawal"] }
] }
}
}
}
}
]
}
Appendix B. Examples (Informative)
B.1: delegates_to, ERC-8004 substrate, attested profile.
{
"id": "rel:8004:42",
"source": "11155111:123",
"target": "11155111:456",
"type": "delegates_to",
"status": "established",
"profile": "attested",
"proofs": {
"proposal": {
"controller": "0xA11ce...",
"attested_by": "attesting-service.example",
"method": "siwe",
"at": "2026-06-18T10:00:00Z"
},
"confirmation": {
"controller": "0xB0b...",
"attested_by": "attesting-service.example",
"method": "siwe",
"at": "2026-06-18T10:05:00Z"
}
},
"created_at": "2026-06-18T10:00:00Z",
"updated_at": "2026-06-18T10:05:00Z"
}
B.2: depends_on, non-blockchain substrate (did:web), signed profile.
Demonstrates substrate-neutrality and the trustless profile: each
controller signs the record directly, verifiable against its DID, and
here each agent is its own controller (no human in the loop).
Phelan Expires 3 January 2027 [Page 21]
Internet-Draft DTL July 2026
{
"id": "rel:example:2",
"source": "did:web:alpha.example",
"target": "did:web:beta.example",
"type": "depends_on",
"status": "established",
"profile": "signed",
"proofs": {
"proposal": {
"controller": "did:web:alpha.example",
"verificationMethod": "did:web:alpha.example#key-1",
"signature": "z3Jx..."
},
"confirmation": {
"controller": "did:web:beta.example",
"verificationMethod": "did:web:beta.example#key-1",
"signature": "z58P..."
}
}
}
B.3: delegates_to, ERC-8004 substrate, attested profile, after
revocation. A relationship that was established and then revoked;
the revocation proof attributes the action to the revoking controller
(here the target).
Phelan Expires 3 January 2027 [Page 22]
Internet-Draft DTL July 2026
{
"id": "rel:8004:42",
"source": "11155111:123",
"target": "11155111:456",
"type": "delegates_to",
"status": "revoked",
"profile": "attested",
"proofs": {
"proposal": {
"controller": "0xA11ce...",
"attested_by": "attesting-service.example",
"method": "siwe",
"at": "2026-06-18T10:00:00Z"
},
"confirmation": {
"controller": "0xB0b...",
"attested_by": "attesting-service.example",
"method": "siwe",
"at": "2026-06-18T10:05:00Z"
},
"revocation": {
"controller": "0xB0b...",
"attested_by": "attesting-service.example",
"method": "siwe",
"at": "2026-06-19T09:00:00Z"
}
},
"created_at": "2026-06-18T10:00:00Z",
"updated_at": "2026-06-19T09:00:00Z"
}
Author's Address
Evan Phelan
Minuet Labs
Email: evan@minuet.ai
URI: https://opendtl.org/
Phelan Expires 3 January 2027 [Page 23]