An open profile for reaching people and businesses.

What the profile describes.

A line publishes a signed manifest at a well-known address. It names who the line represents, what an agent can ask for, the owner’s standing rule for each request, and the ranked ways to reach it, structured paths for machines first.

The manifest describes; it does not grant. Every request is decided when it arrives, under the owner’s rules, and the decision is written to a signed receipt that stays with the owner.

1. Find the manifest: the well-known address, DNS, or the older TXT record.
2. Check its signature and that it came from the line’s own origin over HTTPS.
3. Call a capability over MCP or A2A, optionally signing as an agent platform.
4. Receive Allow, Step up (the owner decides) or Deny, with a receipt.

Built on existing standards.

Discovery

A well-known URI, /.well-known/dmi.json (RFC 8615). An SVCB record at _dmi._mcp._agents.<domain> following the DNS-AID naming convention (specified, not yet published by the reference line). The earlier _qlaas TXT record still works.

Agent protocols

Execution paths point at MCP and A2A endpoints. The profile adds no wire protocol of its own; an A2A agent card, an MCP server card and an RFC 9727 API catalogue can sit alongside.

Decisions

Every request ends in Allow, Step up or Deny. The draft maps these onto the OpenID AuthZEN evaluation request and response, so policy and audit tools need no DMI-specific model.

Operator identity

Agent platforms sign requests with RFC 9421 HTTP Message Signatures as profiled by Web Bot Auth. A valid signature proves the platform, not the person it acts for.

Evidence

The manifest and each receipt are signed with Ed25519 over JCS (RFC 8785) canonical JSON. Each receipt carries the hash of the one before it.

Draft, schemas and vectors.

draft-qlaas-dmi-profile-00

The draft, in Internet-Draft Markdown (kramdown-rfc).

Manifest schema 0.2

JSON Schema for /.well-known/dmi.json, as the reference line emits it today.

Receipt schema 0.1

JSON Schema for one signed, chained receipt.

Test vectors

Two valid signed manifests, ten invalid ones, a valid receipt chain and five broken chains.

Signatures and the receipt chain, in one place:

signing input  = JCS(manifest without "signatures")
signature      = base64url(Ed25519(receipt key, signing input))   86 characters

receipt.signature     = base64url(Ed25519(receipt key, JCS(payload)))
next.payload.prev     = base64url(SHA-256(JCS({ payload, signature, keyId })))
first.payload.prev    = null

Every test vector is signed with the public RFC 8032 test keys. They are for testing only; never trust them in a verifier.

Conformance.

The Agent-Ready Check tests a domain’s dmi.json against each clause below and reports every result. It is informational: it does not change the score, and a pass says nothing about how the line behaves when called. To fix what it finds, publish the discovery records; to check a line's signed receipts, use receipt evidence.

MUST json

The document is a JSON object.

MUST profile

It names the profile worldauth.dmi.communications/0.1.

MUST schema

It is valid against the 0.2 manifest schema.

MUST ranks

Execution paths have distinct ranks of 1 or more.

MUST references

Every capability names a listed execution path.

MUST signature

An Ed25519 signature under the declared receipt key verifies.

SHOULD https

Machine paths use HTTPS.

SHOULD clock

generatedAt is not in the future.

A valid signature proves the file is intact since the key holder signed it. It does not prove who holds the key; that comes from fetching the manifest over HTTPS from the line’s own origin.

Status and licence.

This is an individual draft. It has not been adopted by the IETF or any other standards body, and no third party has implemented or endorsed it. The proposed IETF DAWN working group was not chartered; DNS-AID is now a Linux Foundation project. The profile follows DNS-AID’s naming and will track it.

One reference implementation exists: the qlaas DMI line server. The schema describes what it emits today; where the two disagree, the draft is corrected. Parts marked “not implemented” in the draft, such as the SVCB record, an AuthZEN endpoint and receipt inclusion proofs, are not built.

The draft text is offered under the IETF Trust Legal Provisions. The schemas, vectors and accompanying code are licensed under the Apache License 2.0.