DNS-based Entity-Level Discovery and End-to-End Connection for AI Agents
draft-ni-agent-entity-discovery-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) | |
|---|---|---|---|
| Authors | Ni Yuan , Peter Chunchi Liu | ||
| Last updated | 2026-07-06 | ||
| 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-ni-agent-entity-discovery-00
Network Working Group Y. Ni
Internet-Draft C. P. Liu
Intended status: Informational Huawei
Expires: 7 January 2027 6 July 2026
DNS-based Entity-Level Discovery and End-to-End Connection for AI Agents
draft-ni-agent-entity-discovery-00
Abstract
This document defines a new DNS resource record type, Agent Entity
Discovery (AED), to publish agent-specific trust anchors or direct
match constraints for verifying an agent's certificate or token.
This enables the cross-domain users or agents to authenticate, and
establish secure, end-to-end connections directly with a private-
domain agent entity.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://NiYuan224.github.io/draft-ni-agent-entity-discovery/draft-ni-
agent-entity-discovery.html. Status information for this document
may be found at https://datatracker.ietf.org/doc/draft-ni-agent-
entity-discovery/.
Source for this draft and an issue tracker can be found at
https://github.com/NiYuan224/draft-ni-agent-entity-discovery.
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 7 January 2027.
Ni & Liu Expires 7 January 2027 [Page 1]
Internet-Draft draft-ni-agent-entity-discovery July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Domain Names for AED RR . . . . . . . . . . . . . . . . . . . 5
5. The AED RR . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. AED RDATA Wire Format . . . . . . . . . . . . . . . . . . 5
5.1.1. The Usage Field . . . . . . . . . . . . . . . . . . . 6
5.1.2. The Selector Field . . . . . . . . . . . . . . . . . 6
5.1.3. The Matching Type Field . . . . . . . . . . . . . . . 7
5.1.4. The Credential Association Data Field . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. DNSSEC Dependency . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
AI agents are evolving from isolated, single-domain components into
collaborative entities interacting across domain boundaries. This
shift requires agent-specific credential associations, such as
private-domain trust anchors, to be securely exchanged or published
for cross-domain authentication. For instance, SPIFFE Federation
allows disparate domains to securely exchange their trust bundles via
the bundle endpoint, enabling agents to cryptographically verify
other agents' credentials. However, such a federation relies on out-
of-band pre-configuration between participating organizations, and is
therefore not suitable for dynamic, internet-scale discovery and
authentication.
Ni & Liu Expires 7 January 2027 [Page 2]
Internet-Draft draft-ni-agent-entity-discovery July 2026
Conversely, existing internet-scale mechanisms such as DNSSEC
[RFC4033] and DANE [RFC6698] only secure identities at the domain
level. Consequently, a client cannot differentiate among multiple
agents that are served from the same domain name, leading to risks of
impersonation and lateral movement.
To bridge this gap, this document introduces a mechanism that re-
anchors trust at the agent entity level rather than at the domain
name level. By extending DNS Resource Records (RRs) to publish
agent-specific credential associations, a cross-domain client can
retrieve these records during the discovery phase and establish an
end-to-end connection directly to the target AI agent, rather than
the domain name that hosts it.
The credential association defined in this mechanism provides two
functions, inheriting the definition of certificate associations of
[RFC6698]: it functions either as a credential trust anchor used to
cryptographically verify the signature of an agent's presented
credential (either via certification path validation or JWT signature
verification), or as a credential constraint used to perform a direct
match against the agent's credential.
2. Conventions and 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.
3. Workflow
This section outlines the workflow for establishing a secure, end-to-
end connection directly with a private-domain agent entity (see
Figure 1).
A private-domain administrator (e.g. a private-domain identity
server) publishes agent-specific AED (Agent Entity Discovery) RRs to
the DNS server. Then, a client can query and parse these records,
and use the retrieved credential associations to verify the target
agent during the connection.
Ni & Liu Expires 7 January 2027 [Page 3]
Internet-Draft draft-ni-agent-entity-discovery July 2026
+--------+ +----------+ +--------+ +--------+
| Client | |DNS Server| | Agent | | Admin |
+--------+ +----------+ +--------+ +--------+
| | | |
| |1. Register AED |
| |<------------------------------|
| | | |
|2.Query AED | | |
|-------------->| | |
| | | |
| Answer AED | | |
|<--------------| | |
| | | |
|3.TLS handshake| | |
|<------------------------------> |
| (Validate X.509/RPK/PSK etc.)| |
| | | |
|4.Application credential validation (Optional) |
|<------------------------------- |
| | | |
| | | |
_Figure 1: Workflow of Agent Entity-Level Discovery and End-to-End
Connection_
1. Registration: The private-domain administrator constructs a
dedicated QNAME (as defined in Section 4) for the internal agent
and publishes its AED RRs (as defined in Section 5) to the DNS
server.
2. Discovery: A client sends a DNS query for the agent's specific
QNAME with the AED QTYPE, and extracts the agent's credential
associations from the recevied AED RRs. The client also obtains
the agent's network location (IP address and port) via A/AAAA or
SRV RRs. Subsequent TLS handshake messages SHOULD be sent to
this obtained address.
3. Connection: The client initiates a direct TLS connection to the
agent. During the handshake, the client validates the credential
presented by the agent against the credential associations.
4. Application credential validation (Optional): If additional
application-layer authentication is required inside the secure
tunnel, the agent presents an application-layer token, then the
client utilizes the credential associations from the AED RR to
verify the token signature.
Ni & Liu Expires 7 January 2027 [Page 4]
Internet-Draft draft-ni-agent-entity-discovery July 2026
4. Domain Names for AED RR
The QNAME for an AED RR is constructed by prepending the agent
identifier (agent_id) as the left-most label to the base domain name,
as shown below:
<agent_id>.<base_domain_name>
_Figure 2: Domain Names for AED_
For example, to request AED RRs for an AI agent identified as "agent-
007" hosted at "www.example.com", the QNAME "agent-
007.www.example.com" is used.
To maintain flexibility, the internal structure and generation
mechanism of the "agent_id" label are left open to deployment-
specific choices or future specifications. However, any abstract
identifier used MUST be mapped to a valid DNS label. Examples of
such identifiers MAY include:
* a WIMSE workload identifier;
* a W3C DID;
* an encoded application-layer path component, etc.
5. The AED RR
This section defines a new DNS RR type: AED, which is used to
associate a set of trust anchors or credential constraints with a
specific AI agent entity, thus enabling a client to authenticate that
AI agent.
5.1. AED RDATA Wire Format
The RDATA for an AED RR consists of a one-octet Usage field, a one-
octet Selector field, a one-octet Matching Type field, and a
variable-length Credential Association Data field.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Usage | Selector | Matching Type| /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ /
/ Credential Association Data (variable) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ni & Liu Expires 7 January 2027 [Page 5]
Internet-Draft draft-ni-agent-entity-discovery July 2026
_Figure 3: AED RDATA Wire Format_
5.1.1. The Usage Field
A one-octet value, called "usage", specifies how the association data
is to be used for agent authentication. The usages defined in this
document are:
0 -- Certificate Trust Anchor: Usage 0 is used to specify a
certificate or public key that MUST serve as a domain-specific trust
anchor for TLS certification path validation of the presented agent
certificate during the TLS handshake.
1 -- JWT Trust Anchor: Usage 1 is used to specify a JSON Web Key
(JWK) that MUST serve as a domain-specific trust anchor to verify the
signature of an application-layer JSON Web Token (JWT) presented by
the agent inside the tunnel.
2 -- Certificate Constraint: Usage 2 is used to specify a certificate
or the public key that MUST directly match the certificate presented
by the agent during the TLS handshake.
3 -- JWT Constraint: Usage 3 is used to specify a JWT that MUST
directly match the JWT presented by the agent inside the tunnel.
4 -- RPK Constraint: Usage 4 is used to specify a raw public key
(RPK) that MUST directly match the RPK presented by the agent during
a TLS handshake [RFC7250] and be used to verify the agent's
possession of the private key via the CertificateVerify signature.
5 -- PSK Constraint: Usage 5 is used to specify a pre-shared key
(PSK) identity. The PSK MUST be pre-established out-of-band and
stored securely by both the client and the agent so that the client
can use the PSK identity to select the correct key during a TLS-PSK
handshake [RFC8446]. The record MUST contain only the identity
string, never the secret key material.
5.1.2. The Selector Field
A one-octet value, called "selector", specifies which part of the
trust anchor or credential is contained in the credential association
data. The selectors defined in this document are:
0 -- Full credential: The full binary or textual structure of the
credential or trust anchor.
* For X.509 certificates (usages 0 and 2): The DER-encoded binary
structure of the full X.509 Certificate [RFC5280].
Ni & Liu Expires 7 January 2027 [Page 6]
Internet-Draft draft-ni-agent-entity-discovery July 2026
* For JWT trust anchors (usage 1): The UTF-8 encoded JSON string of
the JWK [RFC7517].
* For JWT constraints (usage 3): The ASCII string representing the
full JWT compact serialization [RFC7519].
* For PSK constraints (usage 5): The opaque string representing the
PSK identity [RFC8446].
1 -- SubjectPublicKeyInfo: DER-encoded binary structure of the public
key.
* For X.509 certificates (usages 0 and 2): The SubjectPublicKeyInfo
field within the certificate, encoded in DER binary format
[RFC5280].
* For RPK constraints (usage 4): The DER-encoded RPK structure
[RFC7250].
5.1.3. The Matching Type Field
A one-octet value, called "matching type", specifies how the
credential association is presented and matched. The types defined
in this document are the same as Section 2.1.3 of [RFC6698]:
0 -- Exact match on selected content.
1 -- SHA-256 hash of selected content.
2 -- SHA-512 hash of selected content.
The following constraints apply to this document:
For JWT Trust Anchors (Usage 1): Matching type 1 or 2 is NOT
RECOMMENDED unless the companion application protocol explicitly
guarantees that the plain-text JWK is delivered alongside the token.
Without the plain-text JWK, the client cannot obtain the public key
material needed to verify the JWT signature.
For PSK Constraints (Usage 5): The matching type MUST be set to 0.
The client requires the raw, unhashed PSK identity to construct the
TLS ClientHello message.
5.1.4. The Credential Association Data Field
This variable-length field contains the credential association data
to be matched, constructed according to the preceding fields:
Ni & Liu Expires 7 January 2027 [Page 7]
Internet-Draft draft-ni-agent-entity-discovery July 2026
* The Usage field exemplifies the use of the credential association
data.
* The Selector field determines whether the credential association
data contains the full structure or the SubjectPublicKeyInfo of
the credential.
* The Matching Type field determines the data's representation: the
raw data, or its cryptographic hash.
6. Security Considerations
6.1. DNSSEC Dependency
All AED RRs MUST be authenticated via DNSSEC [RFC4033]. Clients MUST
reject AED RRs that do not have a valid DNSSEC validation chain.
7. IANA Considerations
This document has no IANA actions.
8. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/rfc/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.
[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/rfc/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/rfc/rfc4033>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005,
<https://www.rfc-editor.org/rfc/rfc4279>.
Ni & Liu Expires 7 January 2027 [Page 8]
Internet-Draft draft-ni-agent-entity-discovery July 2026
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/rfc/rfc6698>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/rfc/rfc7250>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[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/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Yuan Ni
Huawei
Email: niyuan1@huawei.com
Chunchi Peter Liu
Huawei
Email: liuchunchi@huawei.com
Ni & Liu Expires 7 January 2027 [Page 9]