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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [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, . [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, . [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, . 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, . [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, . 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]