An Information Model for Minimum Discoverable Information (MDI)
draft-cui-dawn-mdi-model-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 | Yong Cui | ||
| Last updated | 2026-07-03 | ||
| 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-cui-dawn-mdi-model-00
Network Working Group Y. Cui
Internet-Draft Tsinghua University
Intended status: Informational 3 July 2026
Expires: 4 January 2027
An Information Model for Minimum Discoverable Information (MDI)
draft-cui-dawn-mdi-model-00
Abstract
The Discovery of Agents, Workloads, and Named Entities (DAWN)
terminology document defines Minimum Discoverable Information (MDI)
as the minimum information an entity must provide to be discoverable,
but does not define its field-level content. The DAWN requirements
and problem-statement documents identify the need for a standardized
minimum structure; in its absence, emerging discovery formats risk
each defining its own minimal metadata, with descriptors that do not
interoperate across organizational or protocol boundaries.
This document proposes a small, encoding-neutral information model,
in the sense of RFC 3444, for MDI: three mandatory elements, a short
set of recommended and optional elements, and the minimal constraints
that hold among them. It is a minimum common subset and a mapping
target for richer descriptors -- not a new card format and not a
discovery protocol.
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 4 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Cui Expires 4 January 2027 [Page 1]
Internet-Draft DAWN MDI Information Model July 2026
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 3
4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4
5. MDI Information Model . . . . . . . . . . . . . . . . . . . . 5
5.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Elements . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Minimal Constraints . . . . . . . . . . . . . . . . . . . 8
6. Binding Expectations . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Illustrative JSON Example . . . . . . . . . . . . . 12
Appendix B. Mapping Notes . . . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Distributed systems increasingly compose agents, workloads, and
services that have no pre-configured relationship with one another.
Before any interaction can begin, a discovering party needs a small
amount of information about a remote entity: what it is, what it
does, how to reach it, and what assurances, if any, accompany those
claims. [I-D.farrel-dawn-terminology] names this common header
Minimum Discoverable Information (MDI) but intentionally does not
define its fields; [I-D.king-dawn-requirements] requires that
discovery mechanisms convey base properties, communication
parameters, capability descriptions, and trust-related information,
distinguishing mandatory from optional and static from dynamic;
[I-D.akhavain-moussa-dawn-problem-statement] calls directly for a
standardized structure carrying the minimum information a discovery
response returns; and [I-D.moussa-dawn-gap-analysis] sketches a
Cui Expires 4 January 2027 [Page 2]
Internet-Draft DAWN MDI Information Model July 2026
provisional baseline without normalizing it. No DAWN document
instantiates MDI as a field-level model.
Meanwhile, the gap is being filled independently and incompatibly by
adjacent ecosystems: DNS-based bootstrap
([I-D.mozleywilliams-dnsop-dnsaid]), well-known JSON manifests, agent
cards, and signed capability documents each carry a slightly
different minimal field set with slightly different semantics, each
bound to its own substrate. A descriptor that is minimal and
sufficient in one system is unreadable in another.
This document proposes an information model in the sense of [RFC3444]
-- abstract, protocol- and encoding-neutral, derivable into many
concrete data models -- for MDI: the elements of the common discovery
header and the minimal constraints that hold among them. The
intended division of labor is a three-part stack: terminology says
what MDI is, this document proposes what MDI contains, and specific
discovery mechanisms say how those contents are carried.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
This document uses the terms defined in
[I-D.farrel-dawn-terminology], including Entity, Discovery, Discovery
Information, Discoverable Object, Capability Card, Trust Indicator,
and, centrally, Minimum Discoverable Information (MDI); readers are
assumed to be familiar with that document. The elements defined here
are the normalized slots through which a minimal subset of an
entity's Properties is conveyed as Discovery Information. An MDI
instance -- the collection of element values published or returned
for one entity -- is itself Discovery Information and, where it is
retrievable as a unit, can be regarded as a Discoverable Object. A
Capability Card is a richer Discoverable Object that MDI points to;
it is not part of MDI.
3. Scope and Non-Goals
This document defines the abstract content of the MDI common header,
and nothing else. It does NOT define:
Cui Expires 4 January 2027 [Page 3]
Internet-Draft DAWN MDI Information Model July 2026
* a discovery, query, resolution, or transport protocol, and it does
not bind MDI to DNS or to any other carrier;
* a wire format, serialization, or schema; representations are
illustrative (Appendix A);
* a new capability card, or a replacement for any existing
descriptor;
* identity verification, authentication, authorization, policy
evaluation, or attestation procedures;
* capability exchange, negotiation, selection, registration, or
invocation semantics.
MDI is _advertised_ information, positioned strictly below entity
verification: by itself it asserts nothing a discovering party should
treat as verified. Trust-related elements carry references and hints
only.
4. Design Principles
Encoding-neutral model: Per [RFC3444], one information model can be
carried by many concrete data models -- a JSON object, a CBOR map,
a set of DNS records. Those are carriers; MDI is the shared
meaning they carry.
Thin core, rich references: MDI is a header. Rich or sensitive
structures -- capability cards, proofs, certificates, policy
documents -- are referenced, not embedded, and fetched only when
needed.
Discovery-time only: MDI carries what lets a discovering party
identify an entity, decide whether follow-up is worthwhile, and
dereference the next object safely -- not negotiation state,
selection criteria, or invocation contracts.
Freshness and rate of change matter -- elements are marked static,
mainly-static, or dynamic, and validity information is first-class --
but detailed cache behavior belongs to bindings (Section 6).
Cui Expires 4 January 2027 [Page 4]
Internet-Draft DAWN MDI Information Model July 2026
5. MDI Information Model
An MDI instance is the common header published or returned for one
entity. Only three elements are mandatory -- Entity Identifier,
Entity Type, and Endpoint -- so that an entity can be discoverable
with a very small record; in constrained carriers, a binding may
derive mandatory values from the carrier itself (Section 6).
Everything else is recommended or optional. The element set
instantiates the conveyance requirements of
[I-D.king-dawn-requirements], including the mandatory/optional and
static/dynamic distinctions.
Status key words in this document place obligations on the publishers
and bindings that claim to carry MDI; an abstract model has nothing
that could conform on its own. Status governs whether an element is
conveyed at all; cardinality governs how many values of it may be
carried. Obligations specific to binding documents are collected in
Section 6.
5.1. Structure
Figure 1 shows the elements and their shapes. Composite members
marked "?" are optional, and an element whose members are all
optional (freshness, operational-hint) is present only when at least
one member is present; all other structure is given by the
cardinalities.
+--------------+ describes exactly one
| MDI Instance |---------------------------> Entity
+--------------+
|- entity-identifier (1)
|- entity-type (1)
|- entity-summary (0..n)
|- Endpoint { locator-type, locator,
| protocols (1..n) } (1..n)
|- capability-summary (0..n)
|- capability-reference : Reference (0..n)
|- trust-reference : Reference (0..n)
|- authentication-hint { scheme, metadata? } (0..n)
|- freshness { version?, valid-from?,
| valid-until?, refresh-hint? } (0..1)
|- provenance { publisher,
| responsible-party? } (0..1)
|- scope-hint (0..n)
|- operational-hint { status?, detail? } (0..1)
|- extension { name, value } (0..n)
Reference = { ref-type, locator, digest? }
Cui Expires 4 January 2027 [Page 5]
Internet-Draft DAWN MDI Information Model July 2026
Figure 1: Elements of the MDI model
A Reference is a typed pointer: the ref-type says how to interpret
the locator, and the optional digest is an integrity digest over the
object the locator identifies (Section 5.3).
5.2. Elements
+================+========+===============+======================+
| Element | Status | Class | Purpose |
+================+========+===============+======================+
| Entity | MUST | static | Stable handle within |
| Identifier | | | a publisher scope |
+----------------+--------+---------------+----------------------+
| Entity Type | MUST | static | Coarse type of the |
| | | | entity |
+----------------+--------+---------------+----------------------+
| Endpoint | MUST | mainly-static | Where and by which |
| | | | protocols follow-up |
| | | | proceeds |
+----------------+--------+---------------+----------------------+
| Entity Summary | SHOULD | static | Short human-readable |
| | | | description |
+----------------+--------+---------------+----------------------+
| Capability | SHOULD | mainly-static | Discovery-time |
| Summary | | | triage tags |
+----------------+--------+---------------+----------------------+
| Capability | SHOULD | mainly-static | Pointer to richer |
| Reference | | | capability |
| | | | information |
+----------------+--------+---------------+----------------------+
| Authentication | SHOULD | mainly-static | Hint for follow-up |
| Hint | | | access |
+----------------+--------+---------------+----------------------+
| Trust | SHOULD | mainly-static | Pointer to assurance |
| Reference | | | material |
+----------------+--------+---------------+----------------------+
| Freshness | SHOULD | dynamic | Version or validity |
| | | | information |
+----------------+--------+---------------+----------------------+
| Provenance | SHOULD | static | Publisher or |
| | | | responsible party |
+----------------+--------+---------------+----------------------+
| Scope Hint | MAY | mainly-static | Opaque discovery- |
| | | | scope hint |
+----------------+--------+---------------+----------------------+
| Operational | MAY | dynamic | Coarse availability |
| Hint | | | hint |
Cui Expires 4 January 2027 [Page 6]
Internet-Draft DAWN MDI Information Model July 2026
+----------------+--------+---------------+----------------------+
| Extension | MAY | varies | Type-specific |
| | | | extension |
+----------------+--------+---------------+----------------------+
Table 1
A static value does not change for the lifetime of the Entity
Identifier. A mainly-static value changes only through deliberate
administrative or deployment action. A dynamic value can change in
normal operation and is evaluated together with Freshness.
Entity Identifier: An opaque, stable handle for the entity within a
publisher scope (Section 5.3). It is a name -- not a verified
identity, key, or proof -- and it anchors caching and
deduplication.
Entity Type: The kind of entity (for example agent, workload, or
service); it lets a discovering party triage before fetching
anything. The value space is left to DAWN, bindings, or profiles
to define.
Entity Summary: A short human-readable description with no machine
semantics; language handling, if any, is a binding matter.
Endpoint: A composite of locator-type, locator, and one or more
protocols spoken at that endpoint: where follow-up can proceed and
in which protocol families, not how to speak. An entity whose
endpoints speak different protocols is expressible without loss.
Capability Summary: Coarse, machine-readable capability tags for
discovery-time filtering and triage; they are not sufficient for
selection, negotiation, authorization, or invocation. Full
capability detail lives behind a Capability Reference.
Capability Reference: A Reference to a fuller capability
description, such as a Capability Card, retrieved on demand.
Authentication Hint: The authentication scheme(s) a discovering
party would need for follow-up, optionally with a Reference to
authentication metadata. Never credentials, never authorization
logic.
Trust Reference: A Reference to a trust indicator -- a signature,
certificate, attestation, trust manifest, or key set. A pointer,
not a procedure.
Freshness: Version, validity window, and refresh hint for the
Cui Expires 4 January 2027 [Page 7]
Internet-Draft DAWN MDI Information Model July 2026
instance.
Provenance: Who published this discovery information and,
optionally, the party responsible for the entity -- information-
layer provenance, not verified identity.
Scope Hint: An opaque hint about discovery scope, audience,
jurisdiction, or visibility -- deliberately no more than an
extension point, so as not to pre-empt scope and policy work under
way elsewhere.
Operational Hint: A coarse availability or health class, or a
Reference to richer operational state, or both.
Extension: An extension named by a binding, profile, or future
registry, carrying type-specific or ecosystem-specific
information. An Extension does not alter core element semantics
and does not reintroduce a non-goal of Section 3.
5.3. Minimal Constraints
The following rules are part of the model. A binding MAY tighten
them but MUST NOT relax them.
1. An MDI instance describes exactly one entity. A discovery
response may carry multiple instances; aggregation is a carrier
matter.
2. An Entity Identifier is scoped by a publisher scope. How that
scope is determined and how identifier and token values are
compared are defined by the binding, with exact match as
published as the default. Within one publisher scope, equal
identifiers denote the same entity; inequality does not by itself
imply distinct entities, and across publisher scopes this model
makes no sameness claim. Where a consumer holds multiple
instances for the same identifier, reconciliation is guided by
Freshness and otherwise left to the binding.
3. Protocols attach to endpoints, not to the instance as a whole.
An instance-level protocol list, where a binding offers one, is
derived information -- the union over all endpoints -- and cannot
diverge from them. The model attaches no meaning to the order of
Endpoints; preference and selection are binding or carrier
matters.
Cui Expires 4 January 2027 [Page 8]
Internet-Draft DAWN MDI Information Model July 2026
4. A digest, when present, is a member of the Reference it protects
and covers exactly the object that Reference locates. Integrity
is not trust: a matching digest shows that the bytes are intact,
not that the publisher or the entity should be believed. How a
digest value identifies its algorithm is defined by the binding.
5. A consumer MUST ignore unrecognized Extensions and Scope Hints;
their presence is never an error.
6. Binding Expectations
MDI reaches the wire through bindings: documents that map this model
onto a concrete encoding or discovery mechanism. A binding that
carries MDI MUST specify:
* how each carried element is encoded;
* how mandatory values are derived from the carrier where they are
implicit (for example, an Entity Identifier taken from a DNS owner
name); an implicit value participates in comparison and
constraints exactly as if it were carried explicitly;
* how the publisher scope is determined (for example, from a web
origin);
* how carrier freshness (a DNS TTL, an HTTP cache lifetime)
interacts with the Freshness element, with the earlier applicable
expiry prevailing;
* how unrecognized Extensions are carried and skipped at the
encoding level;
* which value space applies to each element that has one, and
whether it is defined by the binding, a profile, or a future
registry.
A binding MAY tighten Status, cardinality, or constraints, including
per entity type, but MUST NOT relax a MUST element or a rule of
Section 5.3. Existing discovery formats already approximate bindings
of this model (Appendix B); normative bindings are expected in
separate documents.
7. Security Considerations
MDI is advertised information; a consumer MUST treat it as unverified
until corroborated by mechanisms outside this document.
Cui Expires 4 January 2027 [Page 9]
Internet-Draft DAWN MDI Information Model July 2026
* Any element can be forged by whoever publishes it: an Entity
Identifier is not proof of identity, and an Endpoint does not
prove that the reachable party is the intended entity. Acting on
unverified MDI carries the usual risks of contacting an untrusted
endpoint.
* A digest provides integrity for a referenced object, not trust in
the publisher or the entity; a Trust Reference locates assurance
material but confers none until that material is verified by
procedures defined elsewhere.
* Integrity and authenticity of MDI in transit, including protection
against the removal of optional elements, are properties of the
binding and carrier (for example DNSSEC, TLS), not of this model.
A consumer SHOULD NOT draw conclusions from the absence of an
element, and a value derived implicitly from a carrier is exactly
as trustworthy as the carrier mechanism that produced it.
* A Reference locator is supplied by an unverified party; the usual
dereferencing protections apply, such as limits on redirects and
response sizes, and the filtering of locators that resolve to
internal or link-local addresses.
8. Privacy Considerations
Publishing MDI can reveal entity names, endpoints, organizational
structure, capability hints, and scope information. Publishers
SHOULD minimize public MDI to what discovery requires and SHOULD
place sensitive information -- detailed capabilities, policy,
internal topology, operational state -- behind access-controlled
references.
9. IANA Considerations
Future revisions or binding documents may request registries for
selected MDI value spaces, such as entity types or capability tags;
existing registries are to be reused where applicable.
10. References
10.1. Normative References
Cui Expires 4 January 2027 [Page 10]
Internet-Draft DAWN MDI Information Model July 2026
[I-D.farrel-dawn-terminology]
Farrel, A., Yao, K., Schott, R., and N. Williams,
"Terminology for the Discovery of Agents, Workloads, and
Named Entities (DAWN)", Work in Progress, Internet-Draft,
draft-farrel-dawn-terminology-02, 4 June 2026,
<https://datatracker.ietf.org/doc/html/draft-farrel-dawn-
terminology-02>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 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, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References
[I-D.king-dawn-requirements]
King, D. and A. Farrel, "Requirements for the Discovery of
Agents, Workloads, and Named Entities (DAWN)", Work in
Progress, Internet-Draft, draft-king-dawn-requirements-01,
28 April 2026, <https://datatracker.ietf.org/doc/html/
draft-king-dawn-requirements-01>.
[I-D.akhavain-moussa-dawn-problem-statement]
Akhavain, A., Moussa, H., and D. King, "Problem Statement
for the Discovery of Agents, Workloads, and Named Entities
(DAWN)", Work in Progress, Internet-Draft, draft-akhavain-
moussa-dawn-problem-statement-04, 12 June 2026,
<https://datatracker.ietf.org/doc/html/draft-akhavain-
moussa-dawn-problem-statement-04>.
[I-D.moussa-dawn-gap-analysis]
Moussa, H. and A. Akhavain, "Gap Analysis and
Applicability Statement for Discovery Protocols of Agents,
Workloads, and Named Entities (DAWN)", Work in Progress,
Internet-Draft, draft-moussa-dawn-gap-analysis-01, 12 June
2026, <https://datatracker.ietf.org/doc/html/draft-moussa-
dawn-gap-analysis-01>.
[I-D.mozleywilliams-dnsop-dnsaid]
Mozley, J., Williams, N., Sarikaya, B., Schott, R., and J.
Damick, "DNS for AI Discovery", Work in Progress,
Internet-Draft, draft-mozleywilliams-dnsop-dnsaid-02, 27
May 2026, <https://datatracker.ietf.org/doc/html/draft-
mozleywilliams-dnsop-dnsaid-02>.
Cui Expires 4 January 2027 [Page 11]
Internet-Draft DAWN MDI Information Model July 2026
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/info/rfc9460>.
Appendix A. Illustrative JSON Example
This example is illustrative only; no encoding is normative in this
document.
{
"entity_id": "urn:example:agent:invoice-bot",
"entity_type": "agent",
"endpoint": [
{ "locator_type": "uri",
"locator": "https://example.com/agent",
"protocols": [ "a2a" ] }
],
"capability_ref": [
{ "ref_type": "uri",
"locator": "https://example.com/.well-known/agent.json" }
],
"freshness": { "valid_until": "2026-09-01T00:00:00Z" }
}
Appendix B. Mapping Notes
MDI is a common subset of, and a translation target for, existing
discovery formats; it does not replace them. The table sketches
where its mandatory elements and two recurring recommended elements
surface in SVCB-based DNS discovery records ([RFC9460],
[I-D.mozleywilliams-dnsop-dnsaid]) and in the generic well-known-JSON
and agent-card patterns (no single specification is implied). Field
names are indicative; full mappings belong to binding documents.
Cui Expires 4 January 2027 [Page 12]
Internet-Draft DAWN MDI Information Model July 2026
+=============+================+============+===================+
| MDI element | DNS-AID (SVCB) | Well-known | Agent Card |
| | | JSON | |
+=============+================+============+===================+
| Entity | owner name / | identity | agent_id |
| Identifier | target | | |
+-------------+----------------+------------+-------------------+
| Entity Type | (label/ | (metadata) | (metadata) |
| | context) | | |
+-------------+----------------+------------+-------------------+
| Endpoint | TargetName | endpoints | endpoint.url |
| locator | | | |
+-------------+----------------+------------+-------------------+
| Endpoint | alpn | (in | endpoint.protocol |
| protocols | | endpoints) | |
+-------------+----------------+------------+-------------------+
| Capability | cap | descriptor | (the card itself) |
| Reference | | URI | |
+-------------+----------------+------------+-------------------+
| Freshness | DNS TTL | version | version |
+-------------+----------------+------------+-------------------+
Table 2
Each format keeps the protocol attached to the endpoint that speaks
it (alpn per TargetName, endpoint.protocol), an association the
Endpoint composite preserves; carrier-specific selection metadata,
such as SVCB priorities, remains with the carrier.
Acknowledgements
The author thanks Chenguang Du for his valuable contributions to the
design and text of this draft.
This work builds on the DAWN terminology, requirements, problem
statement, and gap-analysis documents.
Author's Address
Yong Cui
Tsinghua University
Beijing, 100084
China
Email: cuiyong@tsinghua.edu.cn
URI: http://www.cuiyong.net/
Cui Expires 4 January 2027 [Page 13]