| Internet-Draft | Agent DNS-OAuth Link | October 2026 |
| Shankarlingam | Expires 23 April 2027 | [Page] |
Software agents increasingly call agents and services operated by other organizations. A receiving organization often wants to know two things about any such caller: that it is the agent it claims to be, and that the organization operating it still authorizes it. Existing approaches to the second question require a trust relationship between the two organizations' authorization servers.¶
This document defines a DNS record by which the owner of a domain links an agent's DNS name to the OAuth client that the agent uses at the owner's own authorization server. The sending agent presents a fresh access token for that client; the receiver verifies the token against the record and against the issuer's published keys. No trust relationship, registration or federation between the two organizations is needed, and disabling the client at the sending organization's authorization server stops the agent being accepted by every receiver.¶
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 23 April 2027.¶
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.¶
An agent operated by organization A (for example agent01.a.example) calls an
agent or service operated by organization B. Before answering, B wants
assurance that:¶
Question 1 is answered by whatever mechanism authenticates the caller: an authenticated channel, a client certificate, a sender-constrained token, or an agent identity system. Question 2 is usually answered inside one organization by its authorization server: when an administrator disables a client, that client can no longer obtain tokens.¶
Across organizations, question 2 is harder. OAuth Identity and Authorization Chaining Across Domains [I-D.ietf-oauth-identity-chaining], OpenID Federation [OpenID.Federation] and cloud workload identity federation all work, but each requires the receiving side's authorization server or trust anchor to be configured to trust the sending side's, pair by pair or through a shared anchor. For agents that call many partners, this setup does not scale, and in practice organizations fall back to long-lived API keys that are not disabled when the agent is.¶
This document takes a narrower approach. The sending organization publishes, in DNS under the agent's name, which issuer and client identifier the agent uses. With every call the agent presents a short-lived access token issued to that client. Any receiver can check the token using only public information: the DNS record and the issuer's published signing keys. The receiver does not need to trust the sender's authorization server for anything beyond a signed statement that it recently issued a token to the named client.¶
The token grants nothing. It is issued for a dedicated audience that no resource server accepts, and serves only as evidence that the client is still active. The receiver continues to make its own access decisions.¶
Link an agent's DNS name to an existing OAuth client with no change at any authorization server and no per-partner configuration.¶
Give the operating organization a single control (disabling the client) that takes effect at every receiver.¶
Let any receiver verify the link without prior contact with the sender.¶
Prevent a linked agent from evading the check by omitting the token.¶
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.¶
A DNS name identifying an agent, for example agent01.a.example.¶
The agent that makes a call and presents a link token.¶
The agent or service that receives the call and verifies the link.¶
An agent name for which a valid link record exists.¶
The agent name of the sender as established by the receiver through a mechanism outside this document (Section 3).¶
Organization A Organization B
+---------------+ (1) client credentials
| Authorization |<------------+
| Server (iss) |-----------+ |
+---------------+ (2) token | |
^ v |
| +------------+ (3) call + token +----------+
| | Sender |----------------->| Receiver |
| | agent01... | +----------+
| +------------+ | |
| (5) issuer metadata + JWKS (public) | |
+---------------------------------------------+ |
|
DNS: _agent-oauth.agent01.a.example TXT (4) lookup <------+
"v=agent-oauth1; iss=...; client_id=...; aud=..."
¶
The sender authenticates to its own authorization server as an OAuth client (for example with the client credentials grant, Section 4.4 of [RFC6749]).¶
It receives a link token for a dedicated audience.¶
It presents the token with each call to a receiver.¶
The receiver looks up the link record for the sender's agent name.¶
The receiver verifies the token's signature using the issuer's published keys, and checks that issuer, client identifier and audience match the record.¶
This document links an agent name to an OAuth client. It relies on the receiver already knowing, or being able to establish, the sender's agent name. Two modes are defined.¶
The receiver obtains the authenticated sender name from the channel over which the call arrives. Examples include an end-to-end authenticated and encrypted channel provided by an agent identity system, or mutual TLS with a certificate whose subject alternative name is the agent name.¶
In channel mode, the link token MUST be carried inside the protected channel so that it is not exposed to intermediaries, and the channel MUST bind the token to the authenticated sender name (that is, an intermediary cannot move a token from one sender's messages to another's).¶
The sender states its agent name in the request, and presents a link token that is sender-constrained, for example with DPoP [RFC9449] or mutual-TLS certificate-bound tokens [RFC8705]. The receiver verifies the sender-constraint as specified for that mechanism, then verifies the link as described in Section 7, using the stated agent name.¶
In this mode the agent name is established by the link itself: the receiver learns that the caller holds the key bound to a token issued to the client that the domain owner has published for that name. The strength of the name binding is therefore that of the DNS lookup (Section 8.3). Because a forged DNS answer would let an attacker impersonate the agent entirely, sender-constrained mode SHOULD NOT be used unless the receiver validates the link record with DNSSEC.¶
A receiver MUST NOT accept a link token that is neither carried in channel mode nor sender-constrained, because a bearer token could be replayed by anyone who obtains it.¶
The link record is a DNS TXT record [RFC1035] at the underscored name
_agent-oauth beneath the agent name [RFC8552]:¶
_agent-oauth.agent01.a.example. IN TXT (
"v=agent-oauth1; iss=https://login.a.example/; "
"client_id=7f3c2a90-1b4e-4c55-9d1a-2e6f8b0c4d11; "
"aud=api://agent-proof" )
¶
link-record = version *( ";" *SP field ) [";"] version = "v=agent-oauth1" field = key "=" value key = "iss" / "client_id" / "aud" / ext-key ext-key = 1*( ALPHA / DIGIT / "_" / "-" ) value = 1*( %x21-3A / %x3C-7E ) ; printable, no ";" or space¶
A TXT record consisting of several character-strings is concatenated before parsing. Fields:¶
The issuer identifier of the authorization server, exactly as it appears in
the iss claim of tokens it issues.¶
The client identifier of the agent's OAuth client at that issuer.¶
The audience value for which link tokens are issued (Section 5).¶
Receivers MUST ignore unknown keys. TXT records at the same name that do not
begin with v=agent-oauth1 MUST be ignored.¶
The record is valid if exactly one TXT record at the name begins with
v=agent-oauth1 and it contains each required field exactly once. If more than
one such record exists, or a required field is missing or repeated, the agent
name MUST be treated as linked with an invalid record, and calls from it MUST be
refused (Section 7). Publishing an invalid record therefore fails closed.¶
The domain owner SHOULD sign the zone with DNSSEC [RFC4033]. Receivers SHOULD validate DNSSEC when it is available.¶
A link token is a JWT access token [RFC9068] issued by the authorization
server named in iss to the client named in client_id. In addition to the
requirements of [RFC9068]:¶
The aud claim MUST contain the value published in the record. That audience
MUST be dedicated to this purpose: it MUST NOT be an audience accepted by any
resource server.¶
The token MUST NOT grant anything. It MUST NOT carry roles, permissions or entitlements, and MUST NOT carry scopes other than at most one scope that the issuer defines for this purpose and that no resource server accepts.¶
The token MUST identify the client. [RFC9068] uses the client_id claim,
and receivers MUST use it when it is present. As a compatibility allowance
for widely deployed issuers that do not follow [RFC9068] in this respect,
a receiver MAY instead use another claim that the issuer documents as
identifying the client (for example azp, appid or cid), but only when
client_id is absent and only one such claim is present. Receivers that
differ in which claims they allow may reach different results for the same
token; issuers that conform to [RFC9068] avoid this.¶
The sender MUST inspect each link token before using it and MUST NOT present a token that fails these requirements. This protects the sender's organization if its client is misconfigured: a token that granted access to the sender's own resources would otherwise be handed to every receiver.¶
Obtain a link token from the issuer for the configured audience.¶
Inspect it as described in Section 5; if it grants anything, do not use it and report the misconfiguration to the operator.¶
Cache the token and present it with every call to a receiver, renewing it before it reaches the receiver's maximum age (Section 7.2).¶
A linked agent that cannot obtain a valid link token is in a failed state, and SHOULD report it to its operator. Calling without a link token is not a fallback: receivers that perform the checks in this document refuse such calls. A sender MAY still attempt a call, for example for diagnostics, but it MUST NOT treat calling without a token as an alternative way to operate.¶
A sender MAY be configured not to present link tokens to particular receivers. Receivers that perform the checks in this document will refuse such calls.¶
For each incoming call:¶
Look up the link record for that name.¶
No record: the sender is not linked. The receiver proceeds with its normal policy, except as described in Section 7.1.¶
Invalid record: refuse.¶
Valid record: a link token is REQUIRED; continue.¶
If no link token is present, refuse.¶
Obtain the issuer's metadata using [RFC8414] or [OIDC.Discovery] at the
iss value from the record, and its JSON Web Key Set [RFC7517]. Metadata
and keys MAY be cached according to HTTP caching rules.¶
Verify the token's signature with those keys, and verify that:¶
In sender-constrained mode, verify the sender-constraint.¶
Remove the link token from the request before passing it to any other component, log or model.¶
Apply the receiver's authorization policy (Section 7.3).¶
Any failure MUST result in refusal. A receiver SHOULD record each verification result, including the agent name and client identifier, in its audit log.¶
If an attacker can cause a receiver's DNS lookup to fail, an agent that is normally linked could appear unlinked, and a call without a token could be accepted. A receiver that has once seen a valid link record for an agent name SHOULD continue to require a link token from that name until it observes, through a successful (and, where available, DNSSEC-validated) lookup, that the record has been removed.¶
When the operator disables the client at its authorization server, no new link
tokens are issued, but tokens already issued remain valid until they expire.
Receivers bound this window with a maximum age measured from iat. The
effective revocation delay is at most the smaller of the token lifetime and the
receiver's maximum age, plus the DNS and key caching periods.¶
A maximum age of 120 minutes or less is RECOMMENDED as a general default. Deployments in which an agent's actions take effect quickly, such as payments, trading or automated changes to production systems, SHOULD use a much shorter maximum age (for example 5 to 15 minutes) chosen from their own threat model; senders then renew correspondingly more often, subject to the issuer's rate limits. A receiver MAY apply different maximum ages to different senders or operations.¶
Removing the link record does not revoke the agent at receivers that apply Section 7.1; it only stops new receivers from requiring a token. Disabling the client is the revocation mechanism.¶
Verifying the link establishes that the operator still authorizes the agent. It does not decide what the agent may do. Receivers SHOULD express policy for linked agents in terms of both the agent name and the client identifier, and a policy entry that matches any agent name (a bare wildcard) SHOULD NOT by itself admit a linked agent.¶
A link token is evidence, not a credential, but a stolen token could be replayed to another receiver by an attacker claiming the sender's name. Channel mode prevents this by keeping the token inside a channel bound to the authenticated sender; sender-constrained mode prevents it by binding the token to a key. Bearer link tokens outside either mode MUST NOT be accepted (Section 3).¶
Every receiver sees the sender's link tokens. If the token's audience were a real resource server, each receiver would hold a working credential for it. The requirements that the audience be dedicated and that the token grant nothing (Section 5), and the sender's duty to refuse such tokens, address this. A receiver that forwards a link token to a third party claiming to be the sender fails at the third party: in channel mode the channel authenticates the receiver, not the sender; in sender-constrained mode the receiver lacks the sender's key.¶
The link record is only as trustworthy as the DNS answer. Without DNSSEC, an on-path attacker could forge or suppress the record. Forging it lets the attacker name a client it controls; this matters most in sender-constrained mode, where the record also establishes the name. Suppressing it can downgrade a linked agent to unlinked; Section 7.1 limits this. Receivers SHOULD use a validating resolver and short cache lifetimes.¶
Receivers SHOULD allow a small tolerance on exp and iat.¶
The link record discloses the issuer and client identifier used by an agent. Neither is secret, but together they reveal which authorization server an organization uses. Link tokens may contain other claims about the client; senders SHOULD use clients whose tokens carry no information beyond what this document requires. The mechanism conveys no information about end users.¶
IANA is requested to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]:¶
| RR Type | _NODE NAME | Reference |
|---|---|---|
| TXT | _agent-oauth | (this document) |
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶
HexaEight¶
An agent runtime that implements the link in channel mode. The sender's name is established by the HexaEight agent identity channel, which authenticates and encrypts each message end to end; the link token travels inside the encrypted message. Implements the sender's inspection of tokens that grant anything, the receiver checks, once-linked-always-linked, a configurable maximum age (default 120 minutes), removal of the token before logging, and policy rules naming agent and client identifier.¶
The deployed record uses the prefix hexaeight-oauth=v1 at the agent name
itself rather than v=agent-oauth1 at _agent-oauth. Sender-constrained mode
is not implemented.¶
Implemented. Interoperability testing between independently operated organizations is in progress.¶
Commercial.¶
OAuth Identity and Authorization Chaining [I-D.ietf-oauth-identity-chaining] and OpenID Federation [OpenID.Federation] let a receiving domain issue or accept tokens based on a configured trust relationship with the sending domain. This document needs no such relationship; in exchange, the token it conveys grants nothing and the receiver keeps all access decisions.¶
The OAuth Client ID Metadata Document [I-D.ietf-oauth-client-id-metadata-document] identifies a client by a URL. The two are complementary: this document links an agent name to a client at the agent operator's own issuer.¶
HTTP Message Signatures [RFC9421] and the work built on them for automated clients identify the operator of a client by a key published under its domain. They do not convey whether the operator's own authorization server still authorizes the client.¶
The WIMSE working group's guidance on authenticating AI agents [I-D.ietf-wimse-aims] describes building agent authentication on existing OAuth specifications; this document is offered as one such building block for calls across organizations.¶