An Information Model for Minimum Discoverable Information (MDI)

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.¶

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

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 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.¶

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:¶

• 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).¶

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.¶

+--------------+   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? }

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.¶

• 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

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.¶

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