Linking an Agent's DNS Name to its OAuth Client

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

the caller is agent01.a.example, and
organization A still authorizes agent01.a.example to act.

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

Goals

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.

Non-goals

Authenticating the agent's name. That is the job of the channel or of a sender-constrained token ().
Granting access. The token carries no permissions; the receiver applies its own authorization policy.
Conveying the identity of users on whose behalf the agent acts.

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 when, and only when, they appear in all capitals, as shown here.

Terminology

Agent name:: A DNS name identifying an agent, for example agent01.a.example.
Sender:: The agent that makes a call and presents a link token.
Receiver:: The agent or service that receives the call and verifies the link.
Link record:: The DNS TXT record defined in .
Link token:: An access token as described in .
Linked agent:: An agent name for which a valid link record exists.
Authenticated sender name:: The agent name of the sender as established by the receiver through a mechanism outside this document ().

The sender authenticates to its own authorization server as an OAuth client (for example with the client credentials grant, Section 4.4 of ).
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.

Establishing the Sender's Name 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.

Channel Mode 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).

Sender-Constrained Mode The sender states its agent name in the request, and presents a link token that is sender-constrained, for example with DPoP or mutual-TLS certificate-bound tokens . The receiver verifies the sender-constraint as specified for that mechanism, then verifies the link as described in , 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 (). 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

Location The link record is a DNS TXT record at the underscored name _agent-oauth beneath the agent name :

Syntax A TXT record consisting of several character-strings is concatenated before parsing. Fields:

iss (REQUIRED):: The issuer identifier of the authorization server, exactly as it appears in the iss claim of tokens it issues.
client_id (REQUIRED):: The client identifier of the agent's OAuth client at that issuer.
aud (REQUIRED):: The audience value for which link tokens are issued ().

Receivers MUST ignore unknown keys. TXT records at the same name that do not begin with v=agent-oauth1 MUST be ignored.

Validity 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 (). Publishing an invalid record therefore fails closed. The domain owner SHOULD sign the zone with DNSSEC . Receivers SHOULD validate DNSSEC when it is available.

The Link Token A link token is a JWT access token issued by the authorization server named in iss to the client named in client_id. In addition to the requirements of :

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

Sender Procedure

Obtain a link token from the issuer for the configured audience.
Inspect it as described in ; 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 ().
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.

Receiver Procedure For each incoming call:

Establish the sender's agent name ().
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 .
- Invalid record: refuse.
- Valid record: a link token is REQUIRED; continue.
If no link token is present, refuse.
Obtain the issuer's metadata using or at the iss value from the record, and its JSON Web Key Set . Metadata and keys MAY be cached according to HTTP caching rules.
Verify the token's signature with those keys, and verify that:
- iss equals the record's iss;
- the client identifier equals the record's client_id;
- aud contains the record's aud;
- the token has not expired, and iat is not older than the receiver's maximum age ();
- the token grants nothing ().
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 ().

Any failure MUST result in refusal. A receiver SHOULD record each verification result, including the agent name and client identifier, in its audit log.

Once Linked, Always Linked 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.

Freshness and Revocation 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 ; it only stops new receivers from requiring a token. Disabling the client is the revocation mechanism.

Authorization Policy 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.

Security Considerations

Token Replay 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 ().

Misuse by the Receiver 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 (), 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.

DNS 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; limits this. Receivers SHOULD use a validating resolver and short cache lifetimes.

Authorization Server Compromise A compromised issuer can mint link tokens for its clients. This affects only agents linked to that issuer, which are operated by the same organization that operates the issuer.

Clock Skew Receivers SHOULD allow a small tolerance on exp and iat.

Privacy Considerations 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 Considerations IANA is requested to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry :

RR Type	_NODE NAME	Reference
TXT	_agent-oauth	(this document)

Implementation Status 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 . 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 , "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 Agent

Organization:: HexaEight
Description:: 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.
Differences from this document:: 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.
Maturity:: Implemented. Interoperability testing between independently operated organizations is in progress.
Licensing:: Commercial.
Documentation:: https://www.hexaeight.com/docs/concepts/oauth/

Relationship to Other Work OAuth Identity and Authorization Chaining and 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 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 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 describes building agent authentication on existing OAuth specifications; this document is offered as one such building block for calls across organizations.