]> HexaEight

India sriram.s@hexaeight.com

Security AI agents OAuth DNS workload identity cross-domain 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.

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:

1. the caller is agent01.a.example, and
2. 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 ().

Overview | Receiver | | | agent01... | +----------+ | +------------+ | | | (5) issuer metadata + JWKS (public) | | +---------------------------------------------+ | | DNS: _agent-oauth.agent01.a.example TXT (4) lookup <------+ "v=agent-oauth1; iss=...; client_id=...; aud=..." ]]>

1. The sender authenticates to its own authorization server as an OAuth client (for example with the client credentials grant, Section 4.4 of ).
2. It receives a link token for a dedicated audience.
3. It presents the token with each call to a receiver.
4. The receiver looks up the link record for the sender's agent name.
5. 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 Agent-Link-Name HTTP request header field (), 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. A request in this mode without exactly one Agent-Link-Name field MUST be refused. The field is not signed and does not need to be: a sender that states another agent's name fails the link check, because its token was issued to a client other than the one published for that 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.

The Agent-Link-Name Field In sender-constrained mode the sender states its agent name in the Agent-Link-Name HTTP request header field. Its value is a String Structured Field Item () containing the agent name in its ASCII form (A-labels), without a trailing dot: Receivers compare agent names case-insensitively. The field is not used in channel mode, where the channel establishes the name.

Sender Procedure

1. Obtain a link token from the issuer for the configured audience.
2. Inspect it as described in ; if it grants anything, do not use it and report the misconfiguration to the operator.
3. Cache the token and present it with every call to a receiver, renewing it before it reaches the receiver's maximum age ().
4. 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:

1. Establish the sender's agent name ().
2. 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.
3. If no link token is present, refuse.
4. 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.
5. 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 ().
6. In sender-constrained mode, verify the sender-constraint.
7. Remove the link token from the request before passing it to any other component, log or model.
8. 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)

IANA is requested to add the following entry to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" ():

Field Name:

Agent-Link-Name

Status:

permanent

Structured Type:

Item

Reference:

of 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 Workload Authorization Grant lets a workload obtain access tokens at a third party's authorization server without per-workload registration, once the platform's issuer has been registered there. A link record could serve as one way for a receiver to discover the issuer responsible for an agent name instead of registering it, and names the operating organization's own issuer even when a platform hosts agents for many organizations. DNS-Anchored Durable Identity for AI Agents binds an agent's DNS name to the accountable entity that controls its domain, with a lifecycle history that outlives the agent's keys. The two are complementary: DNSid anchors the agent's durable identity and accountable entity, while the link record ties the same name to a live signal, from the operator's existing OAuth client, that the operator still authorizes the agent. 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.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields. This document obsoletes RFC 8941. Informative References The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. 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. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed. Okta This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. Identity Digital Autonomous software agents are being deployed across enterprise, cloud, and cross-organizational boundaries. These agents negotiate, transact, delegate, and produce work products that persist beyond their own ephemeral runtime. Current standards and initiatives for agent identity collectively address runtime authentication, authorization, lifecycle management, and tool interaction, but a gap remains: a durable, governance-backed identifier that lets a relying party determine and verify the accountable entity behind an agent it encounters, including agents that have since been retired or whose keys have rotated, and attribute past and present work products to that entity. Lifecycle-history verification is governed by the applicable log method and deployment scope. DNSid addresses the accountable layer of identity: the durable ownership anchor that existing agent identity standards do not provide. This document specifies DNSid, a minimal identity primitive that assigns each agent a Fully Qualified Domain Name (FQDN), binds it to an accountable entity identified by a DNS domain under that entity's control, and publishes a structured set of pointers in DNS TXT records to the agent's cryptographic keys, lifecycle log, and operational status. DNSid uses accountable-entity-controlled signatures for record integrity and an abstract append-only lifecycle log for history. It is designed to sit beneath existing identity, authentication, authorization, and agent interaction standards without competing with them. DNSid introduces no new DNS resource record types, opcodes, or response codes, and requires no changes to DNS resolvers, authoritative servers, or the DNS protocol. It applies to any agent that can be assigned an FQDN whose accountable entity can publish verification material; public discoverability of the agent is not required. Anthropic OpenAI Okta Defakto Security Ping Identity This document defines the Workload Authorization Grant (WAG), by which a workload hosted on a platform -- an AI agent is the motivating case -- obtains access tokens from a third party's OAuth authorization server without requiring an administrator to perform a per-workload provisioning step. Each workload is identified by an opaque identifier that is never reassigned. The platform signs a JWT authorization grant ([RFC7523]) that names one workload, and the workload presents it at the token endpoint of an authorization server that has been configured, once, to trust that platform. The authorization server does not reject a workload because it has not seen it before. The workload's access is determined by the authorization server's own policy, which may consult claims the platform asserts about the workload. This document covers workloads acting on their own behalf. Access on behalf of a user or other principal is out of scope, though the grant is intended to compose with delegation mechanisms in which the workload is the actor. OpenID Foundation

Document History RFC Editor: please remove this section before publication. -01:

• Sender-constrained mode: the sender states its agent name in the new Agent-Link-Name HTTP field (); IANA registration added.
• Relationship to Other Work: the Workload Authorization Grant and DNSid.

-00:

• Initial version.