Internet Engineering Task Force S. D. Park Internet-Draft Samsung Electronics Intended status: Informational 14 August 2026 Expires: 15 February 2027 Architectural Requirements for Supporting AI Agents on the Internet draft-daniel-ai-agent-internet-architecture-00 Abstract Autonomous AI agents are evolving from interactive assistants into networked software workloads that discover services, invoke tools, delegate authority, transact, communicate with other agents, and act asynchronously on behalf of humans and organizations. Existing Internet protocols provide strong foundations, but agent autonomy, dynamic delegation, machine-speed execution, and cross-domain interaction create requirements that span multiple protocol families. This document describes architectural requirements for supporting AI agents on the Internet across naming and discovery, HTTP, authentication, authorization and delegation, TLS and workload identity, asynchronous messaging, capability and intent-based resolution, payments, provenance, auditability, revocation, security, and privacy. It favors profiling and extending existing Internet protocols over defining a monolithic new agent protocol, and identifies the need for IETF-wide architectural coordination. 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 15 February 2027. Park Expires 15 February 2027 [Page 1] Internet-Draft AI Agent Internet Architecture August 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 5. Architectural Principles . . . . . . . . . . . . . . . . . . 5 6. Reference Interaction Model . . . . . . . . . . . . . . . . . 5 7. Naming and Discovery Requirements . . . . . . . . . . . . . . 6 8. HTTP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 9. Authentication, Authorization, and Delegation . . . . . . . . 7 10. TLS, PKI, Workload Identity, and Trust . . . . . . . . . . . 8 11. Asynchronous Agent Communication . . . . . . . . . . . . . . 8 12. Capability and Intent-Based Resolution . . . . . . . . . . . 9 13. Payment and Economic Interaction . . . . . . . . . . . . . . 9 14. Provenance, Auditability, and Accountability . . . . . . . . 10 15. Revocation, Suspension, and Emergency Control . . . . . . . . 10 16. Relationship to Existing Agent Protocols . . . . . . . . . . 11 17. Candidate IETF Work Items . . . . . . . . . . . . . . . . . . 11 18. Current IETF Work Landscape and Coordination Gap . . . . . . 11 19. Recommendation for IETF-Wide Coordination of AI Agent Protocol Work . . . . . . . . . . . . . . . . . . . . . . . . . . 12 20. Security Considerations . . . . . . . . . . . . . . . . . . . 13 21. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 22. Operational Considerations . . . . . . . . . . . . . . . . . 14 23. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 24. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 25. Normative References . . . . . . . . . . . . . . . . . . . . 15 26. Informative References . . . . . . . . . . . . . . . . . . . 15 Appendix A. Document History . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Park Expires 15 February 2027 [Page 2] Internet-Draft AI Agent Internet Architecture August 2026 1. Introduction AI agents are becoming autonomous Internet participants rather than merely user-interface features. An agent can interpret a goal, discover remote services, acquire or present delegated authority, select another agent, invoke tools, initiate payments, maintain state, and continue work without a human being present for each network transaction. Application protocols and frameworks can address important agent interaction patterns, but they do not by themselves solve Internet- wide problems of naming, discovery, identity, delegated authorization, trust, payment negotiation, asynchronous delivery, provenance, and accountability across administrative domains. AI-agent-related Internet-Drafts are already emerging across authentication and authorization, discovery, agent-to-agent and agent-to-tool communication, transport, and related areas. This breadth indicates that supporting AI agents is not a single application-protocol problem. It also creates a coordination risk if common concepts such as agent identity, capability, delegation, discovery metadata, intent, and transaction context are defined independently. This document defines architectural requirements for supporting AI agents on the Internet. It does not define a separate Internet, a new network layer, or a universal agent protocol. The preferred direction is coordinated evolution of existing Internet mechanisms and new mechanisms only where demonstrated gaps remain. 2. Terminology and Conventions 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. Agent: An autonomous or semi-autonomous software entity that can take network actions based on goals, policies, delegated authority, and contextual state. Principal: A human, organization, workload, service, or agent whose identity or authority is relevant to an action. Delegation: A grant of authority from one principal to another, including scope, time, value, context, or re-delegation constraints. Park Expires 15 February 2027 [Page 3] Internet-Draft AI Agent Internet Architecture August 2026 Capability: A machine-readable description of an operation or service that an agent can provide. Intent: The desired outcome or declared purpose associated with an agent action. Intent is not, by itself, an authorization signal. Agent Descriptor: Machine-readable metadata describing an agent's identity, capabilities, endpoints, protocols, security requirements, and related operational properties. AI Agent Internet Architecture: The set of Internet protocol mechanisms and coordinated extensions needed to support autonomous AI agents across administrative and trust boundaries. This term does not imply replacement of the existing Internet architecture. 3. Scope and Non-Goals This document focuses on protocol-layer interoperability across independently administered Internet domains. It covers discovery, identity, authorization and delegation, trust establishment, HTTP interaction, payment negotiation, asynchronous communication, capability resolution, provenance, auditability, revocation, and privacy. This document does not standardize model behavior, prompt formats, reasoning traces, agent planning algorithms, model evaluation, or a universal agent runtime. It does not select a single application framework as the interaction protocol for all agents. 4. Problem Statement Existing Internet protocols can transport agent traffic, but they do not consistently expose the semantics required when autonomous software acts as a principal. A server can authenticate a TLS peer or validate an OAuth access token without necessarily knowing which agent is acting, which human or organization delegated the action, whether re-delegation was permitted, or whether the transaction remains within a spending or operational limit. DNS can locate hosts and services, but Internet-wide agent discovery can require resolution by organization, agent name, capability, supported protocol, security profile, or intent. Long-running agent tasks can also require asynchronous delivery and correlation beyond a single synchronous request/response exchange. An interoperable architecture therefore needs machine-processable answers to: who is acting; who operates the agent; on whose behalf it acts; what it is authorized to do; whether that authority may be Park Expires 15 February 2027 [Page 4] Internet-Draft AI Agent Internet Architecture August 2026 delegated; what the counterparty can do; how the counterparty is discovered and authenticated; what protocol and security profile to use; what payment is required; and what evidence remains after the action. 5. Architectural Principles Evolution Before Replacement: Agent-related mechanisms SHOULD reuse deployed Internet protocols and registries where practical. A new protocol SHOULD be introduced only when existing mechanisms cannot provide the required semantics, security properties, deployment model, or scale. Separation of Concerns: Identity, authentication, authorization, delegation, capability, intent, trust, payment, and audit are distinct concepts and MUST NOT be implicitly conflated. Cross-Domain Operation: Mechanisms MUST assume that agents, principals, authorization services, resource servers, and discovery infrastructure can belong to different administrative domains. Least Authority: Delegated authority SHOULD be narrowly scoped by operation, audience, resource, time, value, and context. Re- delegation SHOULD be explicit rather than assumed. Human and Organizational Accountability: When an agent acts for a human or organization, protocols SHOULD preserve sufficient verifiable evidence to identify the accountable principal without exposing unnecessary personal data. Decentralized Deployability: The architecture SHOULD NOT require a single global agent registry, identity provider, payment provider, or trust-score operator. 6. Reference Interaction Model A representative transaction can involve a User Principal, a User Agent, one or more Specialist Agents, an Agent Service, an Authorization Server, a Discovery Service, and a Resource Server. These roles can be co-located or distributed across domains. Park Expires 15 February 2027 [Page 5] Internet-Draft AI Agent Internet Architecture August 2026 A typical sequence is: the principal delegates a constrained task; the agent discovers candidate services or agents; discovery returns endpoints, capabilities, supported protocols, and security metadata; the agent authenticates and presents delegated authority; a specialist agent may receive a bounded re-delegation; a resource may advertise payment or policy requirements; the agent verifies those requirements against its authority; the action is completed; and material authorization, payment, and provenance evidence is retained for audit. 7. Naming and Discovery Requirements DNS is a natural component of agent discovery because it provides globally delegated naming, caching, service discovery, and security extensions. DNS for AI Discovery (DNS-AID) is one example of current IETF work in this space. REQ-DISC-1: An agent discovery mechanism MUST support discovery when an organization and agent identifier are known. REQ-DISC-2: It SHOULD support discovery when the organization is known but the specific agent is not, using capability or service metadata. REQ-DISC-3: The architecture SHOULD define how capability-only or intent-assisted discovery can be federated without requiring a mandatory centralized registry. REQ-DISC-4: Discovery results SHOULD be able to express endpoint, protocol, protocol version, capability identifiers, authentication requirements, authorization metadata, payment support, and relevant trust material. REQ-DISC-5: Discovery metadata MUST have a mechanism for authenticity and integrity protection. REQ-DISC-6: Discovery mechanisms SHOULD define caching, freshness, negative caching, key rotation, endpoint mobility, and downgrade behavior. 8. HTTP Requirements HTTP is expected to remain a primary substrate for agent interactions. Agent requirements should preferentially use existing HTTP extensibility mechanisms, including status codes, fields, authentication schemes, content negotiation, HTTP Message Signatures, and Well-Known URIs. Park Expires 15 February 2027 [Page 6] Internet-Draft AI Agent Internet Architecture August 2026 Programmatic Payment: HTTP 402 Payment Required and x402-style flows demonstrate a machine-operable payment challenge model. Generic standardization should remain independent of a particular currency, ledger, wallet, or settlement provider. REQ-HTTP-1: A payment challenge SHOULD identify the payment scheme, amount or pricing rule, asset or unit, recipient, expiration, replay constraints, and verification method in machine-readable form. REQ-HTTP-2: Payment authorization SHOULD be bindable to the agent's delegated spending authority, request target, and transaction context. REQ-HTTP-3: Payment mechanisms SHOULD support receipts and SHOULD define failure, retry, duplicate-payment, cancellation, and refund semantics. Agent Authentication: HTTP Message Signatures provide a relevant primitive for cryptographically authenticating selected message components. REQ-HTTP-4: An agent authentication profile SHOULD define how an agent identifier, signing key, operator identity, request freshness, and key-discovery mechanism are bound to a signed request. Intent and Policy Signaling: Any standardized intent or purpose signal MUST be treated as a declaration rather than proof of authorization, and SHOULD be cryptographically bound to the authenticated request when relied upon for policy. Capability Negotiation: HTTP-based agent protocols SHOULD reuse standard content negotiation and extensibility patterns rather than creating incompatible negotiation mechanisms for every framework. 9. Authentication, Authorization, and Delegation Authorization is a central gap for AI-agent use cases. Current IETF work on AI Agent Authentication and Authorization applies workload identity and the OAuth 2.0 family to agent interactions and seeks to identify gaps before defining unnecessary new protocols. REQ-AUTH-1: The architecture MUST distinguish agent identity from the identity of the human or organization on whose behalf the agent acts. REQ-AUTH-2: Authorization evidence MUST be audience-restricted and SHOULD be narrowly scoped to resources and operations. Park Expires 15 February 2027 [Page 7] Internet-Draft AI Agent Internet Architecture August 2026 REQ-AUTH-3: Multi-hop delegation SHOULD preserve the original principal and each authorized delegation step in verifiable form, while allowing privacy-preserving disclosure where intermediaries do not require the full chain. REQ-AUTH-4: Delegation SHOULD express time limits, transaction or value limits, context constraints, and whether re-delegation is permitted. REQ-AUTH-5: A resource server MUST be able to determine the effective authority applicable to the current request without trusting unauthenticated claims from an intermediary agent. REQ-AUTH-6: Delegated authority MUST be revocable or naturally short- lived, and revocation semantics SHOULD address active multi-agent chains. 10. TLS, PKI, Workload Identity, and Trust TLS protects channels and authenticates endpoints, but an agentic system can require additional bindings among endpoint identity, workload identity, agent identity, operator, and delegating principal. REQ-ID-1: Agent identity SHOULD be verifiably bound to a key or workload identity that supports rotation and short lifetimes. REQ-ID-2: The architecture SHOULD support proof that an agent is authorized to represent a domain or organization. REQ-ID-3: Endpoint authentication and agent authentication SHOULD be independently verifiable where they represent different principals. REQ-ID-4: Trust decisions MUST NOT be inferred solely from successful authentication. REQ-ID-5: Designs SHOULD avoid globally stable identifiers when a scoped or pairwise identifier can satisfy the use case. 11. Asynchronous Agent Communication Long-running research, procurement, orchestration, and offline workflows do not always fit synchronous HTTP request/response. Current individual proposals explore asynchronous store-and-forward semantics for agents. Park Expires 15 February 2027 [Page 8] Internet-Draft AI Agent Internet Architecture August 2026 REQ-MSG-1: An asynchronous agent messaging mechanism SHOULD support globally unique message identifiers, correlation identifiers, expiration, retry, delivery status, and duplicate detection. REQ-MSG-2: It SHOULD provide end-to-end integrity and SHOULD allow confidentiality independent of relay hops. REQ-MSG-3: Relay infrastructure MUST be able to apply abuse controls without requiring access to unnecessary private task content. REQ-MSG-4: The mechanism SHOULD define how authorization and delegation evidence is carried or referenced across delayed delivery. REQ-MSG-5: The IETF should first evaluate whether profiles of existing HTTP, messaging, event, or mail technologies can meet these requirements before defining a new transport. 12. Capability and Intent-Based Resolution AI-agent systems add a resolution problem above IP routing: selecting a service or agent because it can satisfy a requested capability under policy constraints. This is service selection and resolution at a higher layer, not a replacement for IP routing. REQ-CAP-1: Capability identifiers SHOULD have stable semantics independent of a single vendor or agent framework. REQ-CAP-2: Capability descriptions SHOULD be separable from endpoint location. REQ-CAP-3: Query and matching mechanisms SHOULD support constraints such as language, protocol, security profile, jurisdiction, price, latency, and policy. REQ-CAP-4: Ranking and reputation information MUST NOT be treated as authoritative identity or authorization evidence. REQ-CAP-5: Intent-based discovery SHOULD minimize disclosure because the query itself can reveal sensitive user goals. 13. Payment and Economic Interaction Autonomous agents can purchase API calls, data, compute, content, reservations, or other services. Payment must compose with discovery, authorization, spending policy, identity, and audit rather than exist as an isolated wallet operation. Park Expires 15 February 2027 [Page 9] Internet-Draft AI Agent Internet Architecture August 2026 REQ-PAY-1: A principal MUST be able to constrain an agent's spending by amount, currency or asset class, recipient or category, time, and transaction type. REQ-PAY-2: A payment proof SHOULD be bound to the resource request sufficiently to prevent replay for a different resource or amount. REQ-PAY-3: The protocol architecture SHOULD permit multiple payment schemes and SHOULD NOT require a particular blockchain or settlement network. REQ-PAY-4: Services SHOULD provide machine-readable receipts that can be correlated with authorization and audit records. 14. Provenance, Auditability, and Accountability Agent actions can have financial, operational, legal, or security consequences. Protocols should preserve evidence of consequential actions without requiring disclosure of model chain-of-thought or unnecessary private content. REQ-AUD-1: Audit evidence SHOULD support correlation of agent identity, operator or accountable principal, authorization context, request identifier, timestamp, material policy constraints, result status, and payment reference when applicable. REQ-AUD-2: Audit evidence SHOULD be tamper-evident and SHOULD support selective disclosure. REQ-AUD-3: Protocols MUST NOT require collection of private reasoning traces as a condition of accountability. REQ-AUD-4: Audit identifiers SHOULD be scoped to reduce cross-service tracking. 15. Revocation, Suspension, and Emergency Control Autonomy and machine-speed execution make revocation a first-order protocol requirement. REQ-REV-1: Credentials and delegated authority SHOULD support short validity periods and explicit revocation where risk requires it. REQ-REV-2: Revocation of a parent delegation SHOULD invalidate or constrain dependent re-delegations according to explicit semantics. Park Expires 15 February 2027 [Page 10] Internet-Draft AI Agent Internet Architecture August 2026 REQ-REV-3: Services SHOULD support rapid suspension of compromised agents or keys without requiring deletion of historical audit evidence. REQ-REV-4: Emergency controls SHOULD be fail-safe and SHOULD avoid a single globally privileged kill switch. 16. Relationship to Existing Agent Protocols Application-layer agent protocols and frameworks are complementary to the Internet mechanisms described here. They can benefit from standardized discovery, authentication, delegated authorization, payment, and trust mechanisms. The architectural objective is composability: discovery identifies a candidate endpoint; identity authenticates it; authorization determines permitted actions; an interaction protocol carries the task; payment settles economic requirements; and provenance or audit mechanisms retain evidence. No single layer should be expected to solve all of these functions. 17. Candidate IETF Work Items Candidate cross-area work includes an agent identity profile; an OAuth-compatible multi-hop delegation profile; DNS and Well-Known based agent discovery profiles; a framework-neutral capability vocabulary and discovery metadata model; an HTTP Message Signatures profile for agents; authenticated intent and policy metadata; generic HTTP payment negotiation and receipt semantics; asynchronous agent messaging requirements; privacy-preserving provenance and audit evidence; and revocation semantics for delegation chains. Protocol-specific wire work should remain with established expert Working Groups where appropriate. Cross-area work is needed for common terminology, architecture, gap analysis, and composability. 18. Current IETF Work Landscape and Coordination Gap As of August 2026, AI-agent-related Internet-Drafts span several protocol domains. Examples include DNS for AI Discovery (DNS-AID); AI Agent Authentication and Authorization; Agentic AI Use Cases and Requirements; and individual proposals addressing agent discovery, invocation, transport, and authorization. Park Expires 15 February 2027 [Page 11] Internet-Draft AI Agent Internet Architecture August 2026 This activity is evidence of a broad protocol problem, but it also exposes a coordination gap. The drafts do not necessarily share a common model for agent identity, operator identity, capability identifiers, delegation, discovery metadata, intent, transaction context, or trust. Similar functions can therefore be specified independently at different layers or by different communities. The architectural requirement is not that every proposal use the same wire protocol. It is that common concepts have clear ownership and composable semantics. Discovery should be able to reference an authorization profile without redefining authorization; payment should be bindable to delegated authority without defining a new identity system; and agent interaction protocols should be able to consume common discovery and security metadata. A cross-IETF gap analysis and terminology effort is therefore needed before multiple overlapping mechanisms become widely deployed. 19. Recommendation for IETF-Wide Coordination of AI Agent Protocol Work The requirements in this document cut across several existing IETF Areas and protocol families. Naming and discovery touch DNS and Internet-area work; authentication, authorization, delegation, and provenance touch Security and OAuth or workload-identity work; HTTP semantics and messaging touch Applications and Real-Time and transport-related communities; and deployment and lifecycle management touch Operations and Management. Without explicit coordination, independently developed solutions risk duplicating functions, defining incompatible identity or capability models, creating overlapping discovery mechanisms, and placing agent- specific semantics at inconsistent layers of the Internet architecture. This document RECOMMENDS that the IETF initiate a community-wide discussion on a dedicated coordination structure for AI-agent-related Internet protocol work. If the scope, volume, and persistence of the work justify Area-level organization, the IETF should consider a new AI Agents Area. The purpose would not be to standardize AI models or relocate every AI-related specification. Its purpose would be to coordinate Internet protocol evolution required to support autonomous AI agents and maintain architectural consistency across affected protocol families. A dedicated coordination structure could cover agent naming and discovery; agent and operator identity; authentication; delegated and multi-hop authorization; capability and intent representation; agent- to-agent and asynchronous communication; HTTP agent semantics; Park Expires 15 February 2027 [Page 12] Internet-Draft AI Agent Internet Architecture August 2026 payment negotiation; provenance and auditability; revocation and lifecycle management; privacy; abuse prevention; and interoperability with application-layer agent protocols. The coordination structure SHOULD follow an extend-before-invent principle. Work should remain in an established Working Group when an existing protocol clearly owns the mechanism and the required expertise exists there. As an incremental path, the IETF could first convene a BOF or other community discussion, establish a directorate or cross-area design team, publish an architectural gap analysis, and then determine whether a permanent Area and one or more Working Groups are justified. The success criterion is not creation of a new Area itself. The success criterion is that Internet standards for autonomous agents evolve as a coherent architecture: reusable across vendors and agent frameworks, decentralized where appropriate, secure by design, and compatible with the existing Internet. 20. Security Considerations AI-agent protocols amplify existing Internet threats because actions can be chained and executed at machine speed. Threats include agent impersonation, compromised credentials, confused-deputy behavior, malicious or poisoned discovery metadata, unauthorized re-delegation, replay of payment or authorization proofs, prompt- or tool-induced privilege escalation, downgrade attacks, trust manipulation, denial- of-wallet attacks, recursive agent loops, and automated abuse. Implementations MUST apply least privilege, audience restriction, freshness and replay defenses, secure key management, explicit re- delegation policy, and strong separation between untrusted content and authorization decisions. Discovery results SHOULD be authenticated where feasible. High-impact actions SHOULD support policy-enforced limits and, where appropriate, explicit human approval. Agent descriptors and capability advertisements are untrusted input until authenticated and authorized. Authenticated descriptive text still MUST NOT be interpreted as executable authorization policy. Park Expires 15 February 2027 [Page 13] Internet-Draft AI Agent Internet Architecture August 2026 21. Privacy Considerations Agent identity, discovery queries, capability requirements, delegation chains, payment metadata, and audit records can reveal sensitive behavior and relationships. Designs SHOULD minimize globally visible metadata, support selective disclosure, and avoid stable cross-context identifiers where unnecessary. Capability-only and intent-based discovery deserves particular scrutiny because a query can reveal user goals. Personal-agent presence SHOULD NOT be made globally discoverable by default. Multi-hop delegation SHOULD permit a resource server to verify sufficient authority without automatically learning every upstream intermediary or unrelated user attribute. 22. Operational Considerations Agent discovery and authorization infrastructure will be highly dynamic. Specifications should define cache lifetimes, stale-data behavior, key rotation, clock-skew tolerance, endpoint migration, retry policy, rate limits, and failure modes. Interoperability profiles should support incremental deployment. A conventional API client should remain able to use a service when optional agent metadata is absent, unless the service explicitly requires an agent-specific security profile. Operators should be able to distinguish protocol failures from policy denials and from agent-level task failures without exposing sensitive internal policy details. 23. IANA Considerations This document requests no IANA actions. Future specifications may require registrations for HTTP fields, Well-Known URI suffixes, OAuth metadata, DNS service labels or SVCB parameters, media types, capability namespaces, or agent messaging parameters. 24. Open Issues Open issues include whether an agent should become a distinct Internet security principal or remain a workload or application identity profile; whether capability-only discovery can be decentralized at Internet scale; how much of a delegation chain a resource server must see; where generic agent semantics belong relative to application-layer frameworks; whether a dedicated asynchronous transport is justified; how payment authorization should Park Expires 15 February 2027 [Page 14] Internet-Draft AI Agent Internet Architecture August 2026 bind to delegated authority; and what minimum audit evidence provides accountability without enabling pervasive tracking. 25. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017, . [RFC9421] al., A. B. E., "HTTP Message Signatures", RFC 9421, February 2024, . [RFC9728] al., M. J. E., "OAuth 2.0 Protected Resource Metadata", RFC 9728, April 2025, . [RFC8414] al., M. J. E., "OAuth 2.0 Authorization Server Metadata", RFC 8414, June 2018, . [RFC6763] Krochmal, S. C. A. M., "DNS-Based Service Discovery", RFC 6763, February 2013, . [RFC9460] al., B. S. E., "Service Binding and Parameter Specification via the DNS", RFC 9460, November 2023, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, May 2019, . 26. Informative References [DNS-AID] al., J. M. E., "DNS for AI Discovery", Work in Progress, Internet-Draft, draft-mozleywilliams-dnsop-dnsaid-02, May 2026, . [AI-AUTH] al., P. K. E., "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft- klrc-aiagent-auth-02, June 2026, . Park Expires 15 February 2027 [Page 15] Internet-Draft AI Agent Internet Architecture August 2026 [AGENTIC-UCREQ] al., T. R. E., "Agentic AI Use Cases and Requirements", Work in Progress, Internet-Draft, draft-agentic-ai- usecases-requirements-00, May 2026, . [AI-AUTH-REQ] Su, M. C. A. L., "New requirements for Authentication and Authorization in the AI Agents era", Work in Progress, Internet-Draft, draft-chen-ai-agent-auth-new-requirements- 00, January 2026, . [AIDIP] al., Y. C. E., "AI Agent Discovery and Invocation Protocol", Work in Progress, Internet-Draft, draft-cui-ai- agent-discovery-invocation-01, February 2026, . [ADP] Lian, H., "Agent Discovery Protocol (ADP)", Work in Progress, Internet-Draft, draft-pro-adp-agent-discovery- 00, June 2026, . [RFC3710] Alvestrand, H., "An IESG Charter", RFC 3710, February 2004, . Appendix A. Document History This is the initial -00 submission. Earlier working copies were not submitted to the IETF. Author's Address Soohong Daniel Park Samsung Electronics Open Source Group Republic of Korea Email: soohongp@gmail.com Park Expires 15 February 2027 [Page 16]