Network Working Group                                       Y. Narvaneni
Internet-Draft                                                S. P. Ravi
Intended status: Standards Track                  Independent Researcher
Expires: 23 April 2027                                   20 October 2026


           The agent URI Scheme and Verifiable Agent Identity
                      draft-narvaneni-agent-uri-04

Abstract

   Software agents increasingly act on the Internet on behalf of people
   and organizations: they call APIs, browse websites, and delegate work
   to other agents.  Protocols such as A2A and MCP define how agents
   communicate, but there is no interoperable way to answer a prior
   question: _which agent is this, and how can its claims be verified?_

   This document defines the agent URI scheme as a stable, human-
   readable identifier for an agent, a deterministic mapping from that
   identifier to an HTTPS-hosted Agent Identity Document, anchoring of
   the agent's keys to a web origin or a Decentralized Identifier, and
   signed statements that bind the agent to its protocol metadata.  It
   also defines profiles that let an agent prove its identity on HTTP
   requests, building on HTTP Message Signatures for automated traffic,
   and that let short-lived agent instances act under the agent's
   identity using the WIMSE Workload Identity Token format.  It
   deliberately does not define how agents communicate, describe their
   capabilities, or are invoked.

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 23 April 2027.






Narvaneni & Ravi          Expires 23 April 2027                 [Page 1]

Internet-Draft                  agent-uri                   October 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
     1.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   6
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  The agent URI Scheme  . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Normalization and Comparison  . . . . . . . . . . . . . .   8
     4.3.  Dereferencing . . . . . . . . . . . . . . . . . . . . . .   9
     4.4.  Fragments . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Agent Identity Document . . . . . . . . . . . . . . . . . . .  10
     5.1.  Format  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Key Identifiers . . . . . . . . . . . . . . . . . . . . .  11
     5.3.  Key Purposes  . . . . . . . . . . . . . . . . . . . . . .  12
     5.4.  Links . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     5.5.  Example . . . . . . . . . . . . . . . . . . . . . . . . .  13
     5.6.  Retrieval and Validation  . . . . . . . . . . . . . . . .  14
   6.  Anchoring . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  Origin-Anchored Agents  . . . . . . . . . . . . . . . . .  15
     6.2.  DID-Anchored Agents . . . . . . . . . . . . . . . . . . .  16
     6.3.  Lifecycle, Rotation, and Revocation . . . . . . . . . . .  17
   7.  Agent Statements  . . . . . . . . . . . . . . . . . . . . . .  17
     7.1.  Verification  . . . . . . . . . . . . . . . . . . . . . .  18
   8.  Profile: Request Signing  . . . . . . . . . . . . . . . . . .  19
     8.1.  Signing . . . . . . . . . . . . . . . . . . . . . . . . .  19
     8.2.  Verification  . . . . . . . . . . . . . . . . . . . . . .  20
   9.  Profile: Agent Instances  . . . . . . . . . . . . . . . . . .  21
   10. Profile: Authorization  . . . . . . . . . . . . . . . . . . .  23
     10.1.  The Agent as an OAuth Client . . . . . . . . . . . . . .  23
     10.2.  Delegation . . . . . . . . . . . . . . . . . . . . . . .  25
     10.3.  Protected Resources  . . . . . . . . . . . . . . . . . .  25
   11. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . .  25



Narvaneni & Ravi          Expires 23 April 2027                 [Page 2]

Internet-Draft                  agent-uri                   October 2026


   12. Relationship to Other Protocols . . . . . . . . . . . . . . .  26
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  26
     13.1.  Trust Model  . . . . . . . . . . . . . . . . . . . . . .  26
     13.2.  Handle Reassignment  . . . . . . . . . . . . . . . . . .  27
     13.3.  Operator Claims  . . . . . . . . . . . . . . . . . . . .  27
     13.4.  Verifier-Initiated Fetches . . . . . . . . . . . . . . .  27
     13.5.  Request Content and Replay . . . . . . . . . . . . . . .  28
     13.6.  Key Compromise and Key Separation  . . . . . . . . . . .  28
     13.7.  Cross-Origin Metadata  . . . . . . . . . . . . . . . . .  29
     13.8.  Confusable Names . . . . . . . . . . . . . . . . . . . .  29
   14. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  29
   15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29
     15.1.  URI Scheme Registration  . . . . . . . . . . . . . . . .  29
     15.2.  Well-Known URI Registration  . . . . . . . . . . . . . .  30
     15.3.  Media Types  . . . . . . . . . . . . . . . . . . . . . .  30
     15.4.  Signature-Agent Type . . . . . . . . . . . . . . . . . .  31
     15.5.  Link Relations . . . . . . . . . . . . . . . . . . . . .  31
     15.6.  OAuth Client Metadata  . . . . . . . . . . . . . . . . .  31
     15.7.  JSON Web Key Parameters  . . . . . . . . . . . . . . . .  31
     15.8.  JSON Web Token Claims  . . . . . . . . . . . . . . . . .  31
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  31
     16.2.  Informative References . . . . . . . . . . . . . . . . .  35
   Appendix A.  Test Vectors: Agent URI Processing . . . . . . . . .  36
     A.1.  Parsing and Canonicalization  . . . . . . . . . . . . . .  37
     A.2.  Mapping to AID URLs . . . . . . . . . . . . . . . . . . .  39
     A.3.  Reverse Mapping of Signature-Agent Values . . . . . . . .  39
     A.4.  AID Origin Comparison . . . . . . . . . . . . . . . . . .  40
   Appendix B.  Open Issues  . . . . . . . . . . . . . . . . . . . .  40
   Appendix C.  Changes from draft-narvaneni-agent-uri-03  . . . . .  41
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  42
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  42

1.  Introduction

   Agents are now first-class actors on the Internet.  A single user
   task can cause an agent to call dozens of APIs and other agents, each
   of which needs to decide whether to serve the request.  Today those
   services can see a TLS client, an IP address, perhaps an OAuth access
   token issued to _some_ client, and a User-Agent string that anyone
   can forge.  They cannot reliably tell which agent is calling, or
   whether the protocol metadata it advertises was really published by
   whoever controls it.








Narvaneni & Ravi          Expires 23 April 2027                 [Page 3]

Internet-Draft                  agent-uri                   October 2026


   Communication protocols already exist.  [A2A] defines agent-to-agent
   interaction and an Agent Card; [MCP] defines how agents reach tools
   and publishes server metadata; OpenAPI describes HTTP APIs.  Each of
   these describes _how to talk to_ an endpoint.  None of them defines a
   portable answer to _who_ an agent is that works across all of them.

   This document defines that missing identity layer.  Its *core*
   (Section 4 to Section 7) is:

   1.  *A name.* The agent URI (e.g., agent://example.com/planner) is a
       stable, human-readable identifier for an agent (Section 4).

   2.  *A document.* Every agent URI maps deterministically to an HTTPS
       URL that serves an Agent Identity Document listing the agent's
       claimed operator, public keys, and links to its protocol metadata
       (Section 5).

   3.  *An anchor.* The agent's keys are trusted because of where the
       document is served (the origin derived from the agent URI) or
       because of a Decentralized Identifier bound to the agent URI
       (Section 6).

   4.  *Statements.* The agent signs statements binding itself to
       specific protocol metadata, so that metadata can be hosted,
       mirrored, or indexed anywhere (Section 7).

   On top of the core, this document defines *profiles* that are
   deliberately separable and are expected to track related IETF work:

   *  a request-signing profile of [WEB-BOT-AUTH] (Section 8);

   *  an agent-instance profile that reuses the WIMSE Workload Identity
      Token format [WIMSE-CREDS] with AID-based trust (Section 9); and

   *  OAuth 2.0 bindings (Section 10).

1.1.  Design Principles

   *  *Identify, do not invoke.* An agent URI names an agent.  It is not
      a locator for an endpoint and carries no invocation parameters.

   *  *Reuse before invent.* Every mechanism is a profile of an existing
      or in-progress standard: HTTPS and well-known URIs [RFC8615], JWK
      [RFC7517], JWS [RFC7515], HTTP Message Signatures [RFC9421] as
      profiled by [WEB-BOT-AUTH], the WIMSE Workload Identity Token
      format [WIMSE-CREDS], OAuth 2.0, and DIDs [DID-CORE].





Narvaneni & Ravi          Expires 23 April 2027                 [Page 4]

Internet-Draft                  agent-uri                   October 2026


   *  *Anchor trust outside the document being verified.* A key is
      trusted because of the origin or DID it is published under, never
      because a document names it about itself.

   *  *Separate the name from the long-lived identity when needed.*
      Domains change hands; agents get renamed and sold.  The scheme
      supports a stable cryptographic identifier behind the human-
      readable name, with continuity for verifiers that have seen it
      before (Section 6.2).

   *  *Authenticate keys, not claims.* Verification establishes control
      of keys anchored to an agent URI.  Everything else an agent says
      about itself, including who operates it, remains a claim.

   *  *Work for agents that live for seconds.* Most agent executions are
      ephemeral.  Instances act under the identity of their agent
      without being individually published.

1.2.  Non-Goals

   The following are explicitly out of scope:

   *  Communication semantics, message formats, task lifecycles, and
      invocation.  These belong to A2A, MCP, OpenAPI-described APIs, and
      similar protocols.

   *  Capability, skill, or tool description.  Protocol metadata
      documents (for example, an A2A Agent Card or an MCP server card)
      remain authoritative for these.

   *  Transport bindings.

   *  Verification of organizations.  This document does not verify that
      the operator an agent claims is real or actually operates it.

   *  Search, ranking, or registry services.  This document makes
      identity verifiable so that any registry can index agents without
      being trusted.

   *  Reputation, pricing, payments, and service levels.

   *  Authorization policy.  Knowing who an agent is does not grant it
      anything.








Narvaneni & Ravi          Expires 23 April 2027                 [Page 5]

Internet-Draft                  agent-uri                   October 2026


2.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document uses the terms "JSON object", "member", and "string"
   from [RFC8259], and "Dictionary", "Item", and "String" from
   [RFC9651].

   Agent:  A software system that acts autonomously or semi-
      autonomously, typically on behalf of a person or organization.

   Operator:  The person or organization that an agent claims is
      accountable for it.

   Agent URI:  An agent URI as defined in Section 4.  The human-readable
      name of an agent.

   Agent Identity Document (AID):  A JSON document, retrieved by
      dereferencing an agent URI, that lists the agent's claimed
      operator, keys, and links (Section 5).

   AID URL:  The HTTPS URL that an agent URI maps to (Section 4.3).

   AID Origin:  The tuple ("https", canonical host, effective port) of
      the AID URL, where the effective port is 443 when no port is
      present.

   Agent Key:  A public key anchored to an agent (Section 6).

   Key Identifier:  The JWK SHA-256 Thumbprint of an Agent Key
      (Section 5.2).

   Instance:  A running, typically short-lived execution of an agent
      that holds its own key pair and acts under the agent's identity
      (Section 9).

   Verifier:  Any party that checks an agent's identity: a website or
      API receiving requests, an authorization server, a registry, or
      another agent.

3.  Overview






Narvaneni & Ravi          Expires 23 April 2027                 [Page 6]

Internet-Draft                  agent-uri                   October 2026


                       agent://example.com/planner           (name)
                                  |
                                  | deterministic mapping
                                  v
        https://example.com/.well-known/agent/planner        (AID URL)
                                  |
             +--------------------+---------------------+
             |                    |                     |
        operator (claim)     keys (JWK Set)        links (rel, href)
                                  |                     |
        origin-anchored: trusted via HTTPS        A2A Agent Card,
        DID-anchored: keys from DID document      MCP server card,
                                                  OAuth client metadata

              Figure 1: From agent URI to verifiable identity

   A typical verification, for a request received by an API:

   1.  The request carries an HTTP message signature and a Signature-
       Agent member whose value is the AID URL of agent://example.com/
       planner.

   2.  The verifier derives the agent URI from the AID URL and retrieves
       the AID (or uses a cached copy).

   3.  The verifier finds the anchored key identified by the signature
       and verifies the signature and the request content.

   4.  The verifier now knows that the request was made by a holder of a
       key anchored to agent://example.com/planner.  It also has the
       operator the agent _claims_, which it must not treat as verified
       (Section 13.3).  Whether to serve the request remains a policy
       decision.

4.  The agent URI Scheme

4.1.  Syntax

   The following ABNF [RFC5234] uses fragment from [RFC3986] and ALPHA
   and DIGIT from [RFC5234].











Narvaneni & Ravi          Expires 23 April 2027                 [Page 7]

Internet-Draft                  agent-uri                   October 2026


   agent-uri    = "agent://" agent-host [ name-path ] [ "#" fragment ]

   agent-host   = dns-name [ ":" port ]
   dns-name     = label 1*( "." label )
   label        = let-dig [ *61( let-dig / "-" ) let-dig ]
   let-dig      = ALPHA / DIGIT
   port         = %x31-39 *4DIGIT         ; 1-65535, no leading zero

   name-path    = 1*8( "/" name-segment )
   name-segment = lc-let-dig [ *61( lc-let-dig / "-" ) lc-let-dig ]
   lc-let-dig   = %x61-7A / DIGIT        ; a-z, 0-9

                      Figure 2: ABNF for the agent URI

   Additional constraints:

   *  dns-name MUST contain at least two labels (as required by the
      ABNF), MUST NOT exceed 253 octets, and its final label MUST
      contain at least one ALPHA character.  This excludes IPv4
      addresses in dotted-decimal form and single-label names such as
      localhost.

   *  Internationalized domain names MUST be represented as A-labels
      [RFC5890] [RFC5891].  IP literals and userinfo are not permitted.

   *  port MUST NOT exceed 65535.

   *  An agent URI MUST NOT contain a query component.

   *  An agent URI with an empty name-path (e.g.,
      agent://planner.example.com) identifies the domain's root agent.

   Examples:

   *  agent://example.com/planner

   *  agent://planner.example.com

   *  agent://example.com/acme/billing-assistant

   *  agent://example.com/
      planner#kPrK_qmxVWaYVA9wwBF6Iuo3vVzz7TxHCTwXBygrS4k (a reference
      to one of the agent's keys; see Section 4.4)

4.2.  Normalization and Comparison

   The canonical form of an agent URI is produced by:




Narvaneni & Ravi          Expires 23 April 2027                 [Page 8]

Internet-Draft                  agent-uri                   October 2026


   1.  Lowercasing the scheme and dns-name.

   2.  Converting any U-labels to A-labels.

   3.  Removing a port equal to 443, and removing a ":" followed by an
       empty port.

   4.  Removing a single trailing "/" if present.

   Parsers MAY accept input that differs from the ABNF only by the
   deviations corrected above, and MUST normalize it.  Any other
   deviation (uppercase in name-path, percent-encoding, dot-segments, a
   query, a trailing "." on the host) MUST be rejected.

   Two agent URIs identify the same agent if and only if their canonical
   forms, with any fragment removed, are identical octet strings.  In
   particular, agent://example.com/planner and
   agent://planner.example.com are different agents, even if the same
   operator runs both.

   Agent URIs in AIDs, statements, credentials, and tokens MUST be in
   canonical form and MUST NOT contain a fragment, unless a fragment is
   explicitly permitted.

4.3.  Dereferencing

   An agent URI is dereferenced by mapping it to its AID URL:

   https://<agent-host>/.well-known/agent<name-path>      (named agent)
   https://<agent-host>/.well-known/agent/_                (root agent)

   For example:



















Narvaneni & Ravi          Expires 23 April 2027                 [Page 9]

Internet-Draft                  agent-uri                   October 2026


   +=============================+====================================+
   | Agent URI                   | AID URL                            |
   +=============================+====================================+
   | agent://example.com/planner | https://example.com/.well-         |
   |                             | known/agent/planner                |
   +-----------------------------+------------------------------------+
   | agent://example.com/acme/   | https://example.com/.well-         |
   | billing-assistant           | known/agent/acme/billing-assistant |
   +-----------------------------+------------------------------------+
   | agent://planner.example.com | https://planner.example.com/.well- |
   |                             | known/agent/_                      |
   +-----------------------------+------------------------------------+
   | agent://example.com:8443/   | https://example.com:8443/.well-    |
   | planner                     | known/agent/planner                |
   +-----------------------------+------------------------------------+

                  Table 1: Agent URI to AID URL mapping

   The root agent uses the reserved segment _, which cannot appear in a
   name-segment.  This allows the root AID and named AIDs to coexist on
   static file hosting.

   The mapping is purely syntactic and is reversible: an HTTPS URL is an
   AID URL if and only if it has no query or fragment and applying the
   reverse mapping yields an agent URI that is valid and canonical.  No
   registry or index needs to be fetched to dereference an agent URI.

4.4.  Fragments

   A fragment in an agent URI identifies an Agent Key by its Key
   Identifier (Section 5.2).  No other fragment semantics are defined.

5.  Agent Identity Document

5.1.  Format

   An AID is a JSON object [RFC8259] served with media type application/
   agent-id+json (Section 15.3).  It has the following members:

   id:  REQUIRED.  String.  The canonical agent URI that this document
      describes.

   operator:  REQUIRED.  Object stating who the agent claims is
      accountable for it, with members name (REQUIRED, string) and url
      (OPTIONAL, string, HTTPS URL).  These values are self-asserted
      (Section 13.3).

   keys:  REQUIRED for origin-anchored agents; MUST be absent for DID-



Narvaneni & Ravi          Expires 23 April 2027                [Page 10]

Internet-Draft                  agent-uri                   October 2026


      anchored agents.  A JWK Set [RFC7517] containing the agent's
      public keys (Section 6.1).

   did:  OPTIONAL.  String.  A DID [DID-CORE] whose DID document is the
      anchor for this agent's keys (Section 6.2).

   name:  OPTIONAL.  String.  A display name for people.  It has no
      identity semantics.

   status:  OPTIONAL.  String.  One of "active" (default), "suspended",
      or "retired" (Section 6.3).

   links:  OPTIONAL.  Array of link objects (Section 5.4).

   updated:  OPTIONAL.  String.  The time the document was last changed,
      as an RFC 3339 [RFC3339] timestamp.

   Members not defined here MUST be ignored by verifiers that do not
   understand them.  Extension member names SHOULD be namespaced (e.g.,
   "acme_tier") to avoid collision with future versions of this
   document.

   An AID MUST NOT exceed 64 KiB.

5.2.  Key Identifiers

   Every Agent Key is identified by its *Key Identifier*: the base64url-
   encoded JWK SHA-256 Thumbprint [RFC7638] of the key, computed as
   specified in [RFC7638] for EC keys and in Appendix A.3 of [RFC8037]
   for OKP keys.  This is the same identifier [WEB-BOT-AUTH] uses for
   keyid.

   Key Identifiers are used everywhere a key is named in this document:
   in the kid of JWKs in an AID, in agent URI fragments, in the JWS kid
   header of statements and Workload Identity Tokens, and in the keyid
   signature parameter of request signatures.

   Verifiers MUST compute the thumbprint of each candidate key
   themselves and select keys by comparing it with the presented Key
   Identifier.  They MUST NOT rely on an operator-supplied kid or DID
   verification method id to select a key.

   For DID-anchored agents, each verification method is converted to a
   JWK before the thumbprint is computed:

   *  a publicKeyJwk value is used as-is (private members MUST NOT be
      present);




Narvaneni & Ravi          Expires 23 April 2027                [Page 11]

Internet-Draft                  agent-uri                   October 2026


   *  a publicKeyMultibase value that is a Multikey encoding of an
      Ed25519 public key (base58btc with the 0xed01 header, as defined
      in [CID]) is converted to an OKP JWK with "crv": "Ed25519"; and

   *  verification methods in any other representation MAY be supported;
      those a verifier cannot convert are ignored.

5.3.  Key Purposes

   Agent Keys are used for two purposes:

   Assertion:  Signing Agent Statements (Section 7) and Workload
      Identity Tokens for instances (Section 9).

   Authentication:  Signing HTTP requests directly as the agent
      (Section 8).

   For DID-anchored agents, a key is usable for assertion only if it is
   referenced from the DID document's assertionMethod relationship, and
   for authentication only if it is referenced from authentication
   [DID-CORE].  Verifiers MUST enforce these relationships.

   For origin-anchored agents, a JWK in keys MAY carry an agent_use
   member (Section 15.7): an array containing one or both of the strings
   "assertion" and "authentication".  A key is usable only for the
   purposes listed; a key without agent_use is usable for both.
   Verifiers MUST enforce agent_use.  A key whose agent_use is not an
   array of strings (for example, a bare string), or contains no
   recognized value, MUST be ignored; it is never treated as
   unrestricted.  An AID in which two JWKs have the same Key Identifier
   MUST be rejected, so that purposes cannot be combined across entries
   for the same key material.  Operators SHOULD give every key a single
   purpose, so that a key held by a running agent for request signing
   cannot mint Workload Identity Tokens or sign statements
   (Section 13.6).

5.4.  Links

   Each link object has the following members, with the semantics of Web
   Linking [RFC8288]:

   rel:  REQUIRED.  String.  A registered link relation type or a URI.

   href:  REQUIRED.  String.  An absolute HTTPS URL.

   type:  OPTIONAL.  String.  The media type of the target.

   statement:  OPTIONAL.  String.  An Agent Statement (Section 7) about



Narvaneni & Ravi          Expires 23 April 2027                [Page 12]

Internet-Draft                  agent-uri                   October 2026


      the target.

   Link relations expected to be common include:

       +=======================+===================================+
       | Relation              | Target                            |
       +=======================+===================================+
       | agent-card            | The agent's [A2A] Agent Card      |
       +-----------------------+-----------------------------------+
       | mcp-server-card       | The agent's [MCP] server metadata |
       +-----------------------+-----------------------------------+
       | service-desc          | An OpenAPI or other API           |
       |                       | description [RFC9727]             |
       +-----------------------+-----------------------------------+
       | oauth-client-metadata | The agent's OAuth Client ID       |
       |                       | Metadata Document (Section 10.1)  |
       +-----------------------+-----------------------------------+

                       Table 2: Common link relations

   A link whose href has the *same origin as the AID Origin* is trusted
   to the same degree as the AID itself.  To compare, the verifier
   lowercases the href host, converts it to A-labels, and uses port 443
   if none is present; the result must equal the AID Origin exactly
   (Appendix A.4).  No other normalization is applied; in particular, a
   trailing "." is not removed from the host.  A link to any other
   origin MUST carry a statement, and verifiers MUST ignore cross-origin
   links without a valid statement (Section 7.1).  Because verifier-
   initiated fetches never follow redirects (Section 13.4), a same-
   origin href cannot acquire the same-origin exemption for content
   served from another origin.

   For DID-anchored agents the same-origin exemption does not apply:
   every link MUST carry a statement signed with a key from the DID
   document's assertionMethod, and verifiers MUST ignore links without
   one.  Otherwise whoever controls the origin could replace linked
   metadata, such as an OAuth client metadata document containing client
   keys, without holding any key authorized by the DID (Section 13.1).

5.5.  Example











Narvaneni & Ravi          Expires 23 April 2027                [Page 13]

Internet-Draft                  agent-uri                   October 2026


   {
     "id": "agent://example.com/planner",
     "name": "Example Trip Planner",
     "operator": {
       "name": "Example Travel Ltd",
       "url": "https://example.com"
     },
     "keys": {
       "keys": [
         {
           "kty": "OKP",
           "crv": "Ed25519",
           "x": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo",
           "kid": "kPrK_qmxVWaYVA9wwBF6Iuo3vVzz7TxHCTwXBygrS4k",
           "alg": "EdDSA",
           "use": "sig"
         }
       ]
     },
     "links": [
       {
         "rel": "agent-card",
         "href": "https://example.com/planner/agent-card.json",
         "type": "application/json"
       },
       {
         "rel": "mcp-server-card",
         "href": "https://cdn.example.net/planner/server.json",
         "statement": "eyJ0eXAiOiJhZ2VudC1zdGF0ZW1lbnQrand0Ii..."
       },
       {
         "rel": "oauth-client-metadata",
         "href": "https://example.com/planner/oauth-client.json"
       }
     ],
     "updated": "2026-10-20T09:00:00Z"
   }

        Figure 3: Example Agent Identity Document (origin-anchored)

5.6.  Retrieval and Validation

   To obtain the AID for an agent URI, a verifier:

   1.  Parses and canonicalizes the agent URI (Section 4.2), rejecting
       it on failure.

   2.  Constructs the AID URL (Section 4.3).



Narvaneni & Ravi          Expires 23 April 2027                [Page 14]

Internet-Draft                  agent-uri                   October 2026


   3.  Applies the fetch policy of Section 13.4.

   4.  Sends an HTTPS GET with Accept: application/agent-id+json,
       validating the server certificate for dns-name.

   5.  Treats any status code other than 200 (OK) [RFC9110], and other
       than 304 (Not Modified) received in response to a conditional
       request revalidating a cached copy [RFC9111], as a retrieval
       failure.  Redirects are always failures.

   6.  Rejects responses larger than 64 KiB, or that are not valid JSON
       objects.  Verifiers MUST NOT reject a response solely because its
       media type is application/json (to support static hosting) but
       MUST reject any other media type.

   7.  Rejects the document unless its id member is identical to the
       canonical agent URI.

   8.  Performs the anchoring checks of Section 6, including the DID
       binding and pinning checks of Section 6.2 when applicable.

   Verifiers SHOULD cache AIDs according to HTTP caching [RFC9111].
   Operators SHOULD NOT set a freshness lifetime longer than 24 hours,
   so that key removal takes effect promptly (Section 6.3).  Verifiers
   SHOULD cache failures for a short period to limit repeated fetches.

6.  Anchoring

   An Agent Key is _anchored_ when the verifier has established that
   whoever controls the agent URI published it.  This document defines
   two anchoring modes.  An AID uses exactly one.

6.1.  Origin-Anchored Agents

   The AID contains keys and no did.  The keys are anchored by the HTTPS
   retrieval of Section 5.6: control of the AID Origin is control of the
   agent's identity.

   Each JWK in keys MUST:

   *  contain only public key parameters;

   *  have a kid equal to its Key Identifier (Section 5.2);

   *  have an alg member; and

   *  be usable for signatures ("use": "sig", or a key_ops containing
      "verify").



Narvaneni & Ravi          Expires 23 April 2027                [Page 15]

Internet-Draft                  agent-uri                   October 2026


   Implementations MUST support EdDSA (Ed25519) and ES256.  Algorithms
   MUST be restricted as described in [RFC8725]; in particular, none and
   symmetric algorithms MUST NOT be accepted.

   This mode needs nothing beyond a web server.  Its weakness is that
   identity is exactly as durable as control of the domain
   (Section 13.2).

6.2.  DID-Anchored Agents

   The AID contains a did member and no keys.  The agent's keys are the
   verification methods of the DID document, with the purposes defined
   in Section 5.3.

   The binding between the agent URI and the DID MUST be bidirectional:

   *  the AID retrieved for the agent URI names the DID in did; and

   *  the DID document lists the canonical agent URI in its alsoKnownAs
      property [DID-CORE].

   Verifiers MUST check both directions and MUST treat the agent as
   unverified if either is missing.

   *Pinning.* A verifier that has previously verified an agent URI as
   DID-anchored and recorded its DID MUST NOT attribute a later AID for
   that agent URI to the same agent unless it names the same DID.  An
   AID that is origin-anchored or names a different DID MUST be treated
   as a different identity (for example, by rejecting it, or by treating
   it as a new agent with no history), not as a key rotation.  Verifiers
   that record identities SHOULD record the DID.

   *Continuity and its limits.* For a verifier that has pinned the DID,
   DID anchoring preserves identity across a rename or domain move: the
   operator publishes an AID under the new agent URI and adds that URI
   to alsoKnownAs.  For a verifier with no prior state, DID anchoring
   gives no more assurance than origin anchoring, because whoever
   controls the agent URI's origin can publish an origin-anchored AID
   instead (Section 13.1).












Narvaneni & Ravi          Expires 23 April 2027                [Page 16]

Internet-Draft                  agent-uri                   October 2026


   *DID methods.* A DID whose resolution depends on the same host as the
   agent URI (for example, did:web on that host) adds no independence
   from the origin.  Operators SHOULD NOT use such a DID for DID
   anchoring, and verifiers MUST NOT treat it as providing assurance
   beyond origin anchoring.  DID methods that support verifiable key-
   rotation history (for example, [DID-WEBVH] hosted independently of
   the agent URI's host) are RECOMMENDED.  Verifiers MUST maintain an
   allowlist of DID methods they support and MUST reject any other
   method.  Network requests made by DID resolvers are subject to
   Section 13.4.

6.3.  Lifecycle, Rotation, and Revocation

   Removing a key from the AID (or DID document) revokes it: every
   statement and Workload Identity Token it signed stops verifying once
   verifiers' cached copies expire.  Rotation and revocation are
   therefore the same operation, and operators rotate as follows:

   1.  Publish the new key alongside the old one.

   2.  Re-issue all statements and credentials signed by the old key,
       including statements carried in AIDs copied by mirrors and
       registries.

   3.  Remove the old key once re-issued statements have propagated.

   Statements about metadata that changes SHOULD carry an exp so that
   copies held by third parties are refreshed regularly.

   If status is "suspended" or "retired", verifiers MUST treat all
   signatures, statements, and credentials from the agent as invalid.  A
   retired agent URI SHOULD NOT be reassigned to a different agent.

   Operators that need auditable key history MAY additionally record
   their AIDs and statements in a transparency service [RFC9943].  This
   document does not require it.

7.  Agent Statements

   An Agent Statement is a JWS [RFC7515] in compact serialization,
   signed with an Agent Key usable for assertion, that binds the agent
   to a specific version of a resource such as an Agent Card.  It allows
   protocol metadata to be served from any origin, mirrored, or included
   in registries without losing its link to the agent.

   The JWS Protected Header MUST contain:

   *  typ: "agent-statement+jwt";



Narvaneni & Ravi          Expires 23 April 2027                [Page 17]

Internet-Draft                  agent-uri                   October 2026


   *  alg: the algorithm of the signing key;

   *  kid: the Key Identifier of the signing key (Section 5.2).

   The payload is a JWT Claims Set [RFC7519] with:

   iss:  REQUIRED.  The canonical agent URI, without a fragment.

   sub:  REQUIRED.  The URL of the resource the statement is about.

   resource_digest:  REQUIRED.  An object with members alg ("sha-256"),
      canon ("jcs" or "none"), and value (the base64url-encoded digest).
      With "jcs", the digest is computed over the resource canonicalized
      per [RFC8785]; with "none", over the exact bytes of the
      representation.

   iat:  REQUIRED.  Issue time.

   exp:  OPTIONAL.  Expiry time.

7.1.  Verification

   To verify a statement carried in a link of an AID, a verifier:

   1.  Checks that typ is "agent-statement+jwt".

   2.  Checks that iss is identical to the AID's id, and checks the
       AID's status (Section 6.3).

   3.  Checks that sub is identical to the link's href.  A statement
       whose sub differs MUST be rejected, even if it is otherwise
       valid.

   4.  Selects an anchored key usable for assertion whose Key Identifier
       equals kid, and verifies the signature.

   5.  Checks iat and, if present, exp.

   6.  Obtains the resource at sub, either by fetching it under the
       policy of Section 13.4 or by using a copy, and compares its
       digest with resource_digest.

   Statements obtained other than through an AID link (for example, from
   a registry) are verified in the same way, except that step 2 uses the
   AID retrieved for iss and step 3 compares sub with the URL the
   verifier intends to use.





Narvaneni & Ravi          Expires 23 April 2027                [Page 18]

Internet-Draft                  agent-uri                   October 2026


   A statement protects only the bytes of the resource it names.  It
   does not extend to other resources that resource refers to, such as a
   jwks_uri in OAuth client metadata: each such resource needs its own
   statement before it can be relied on with the same assurance.

   Protocol metadata documents that support extension fields SHOULD
   include a reference back to the agent URI, so that a client starting
   from the metadata can find the identity.  How that reference is
   expressed is defined by each protocol (see Appendix B).

8.  Profile: Request Signing

8.1.  Signing

   An agent proves its identity on an HTTP request by signing it as
   specified in [WEB-BOT-AUTH], with the additional requirements in this
   section.  A request signed this way is a conforming [WEB-BOT-AUTH]
   request; this profile adds a new Signature-Agent member type and
   constrains the signature further.

   The request MUST include a Signature-Agent Dictionary member, keyed
   by the signature label, whose value is the AID URL derived from the
   agent's canonical agent URI (Section 4.3) and which carries the
   parameter type=agent-id:

   Signature-Agent: sig1="https://example.com/.well-known/agent/planner"
       ;type=agent-id

       Figure 4: Signature-Agent member (line break for display only)

   The signature MUST:

   *  cover @method, @authority, @target-uri, and "signature-
      agent";key="<label>";

   *  cover content-digest [RFC9530] when the request has content;

   *  cover workload-identity-token when that field is present
      (Section 9);

   *  include the created and expires parameters, with expires no more
      than 300 seconds after created;

   *  include a keyid parameter whose value is the Key Identifier of the
      signing key; and

   *  include the parameter tag="web-bot-auth".




Narvaneni & Ravi          Expires 23 April 2027                [Page 19]

Internet-Draft                  agent-uri                   October 2026


   A nonce parameter SHOULD be included where the verifier is expected
   to detect replay.

   Example:

   POST /v1/bookings HTTP/1.1
   Host: api.example.net
   Content-Type: application/json
   Content-Digest: sha-256=:...:
   Signature-Agent: sig1="https://example.com/.well-known/agent/planner"
       ;type=agent-id
   Signature-Input: sig1=("@method" "@authority" "@target-uri"
       "signature-agent";key="sig1" "content-digest");
       created=1792486800;expires=1792486860;
       keyid="kPrK_qmxVWaYVA9wwBF6Iuo3vVzz7TxHCTwXBygrS4k";
       tag="web-bot-auth"
   Signature: sig1=:...:

         Figure 5: A signed request (line breaks for display only)

8.2.  Verification

   A verifier MUST perform all of the following steps, and MUST NOT rely
   on a generic HTTP Message Signatures implementation to enforce them:

   1.  Select the signature with tag="web-bot-auth" whose label has a
       Signature-Agent member with type=agent-id.  If there is none, the
       request does not carry an agent identity under this profile.

   2.  Check that the member value is an AID URL and derive the agent
       URI from it (Section 4.3).  Verifiers MUST NOT normalize the
       value before applying the reverse mapping; a value that is not
       exactly the AID URL of a canonical agent URI is rejected.

   3.  Check that the covered components include every component
       required by Section 8.1, and that expires is no more than 300
       seconds after created and the current time is between them,
       allowing for modest clock skew.

   4.  Retrieve the AID (Section 5.6) and check status (Section 6.3).

   5.  If a Workload-Identity-Token field is present, validate it as
       described in Section 9; the verification key is then the key in
       its cnf claim, and keyid MUST equal that key's Key Identifier.
       Otherwise, select an anchored key usable for authentication whose
       Key Identifier equals keyid.  Key lookup is keyed on the pair
       (agent URI, keyid), as required by [WEB-BOT-AUTH].




Narvaneni & Ravi          Expires 23 April 2027                [Page 20]

Internet-Draft                  agent-uri                   October 2026


   6.  Verify the signature as specified in [RFC9421].

   7.  If the request has content, recompute the digest of the received
       content for a supported algorithm as specified in [RFC9530] and
       compare it with the covered Content-Digest value.  A request with
       content and a missing, unsupported, or mismatched Content-Digest
       MUST be rejected.  A valid signature over Content-Digest does not
       by itself authenticate the content (Section 7.2.8 of [RFC9421]).

   On success, the verifier has established that the request, including
   its content, was made by a holder of a key anchored to the agent URI
   (directly, or through an instance credential).  On failure, the
   verifier MUST NOT treat the request as coming from the named agent;
   it MAY process it as an unauthenticated request.

   A [WEB-BOT-AUTH] verifier that does not support type=agent-id ignores
   the member, as that specification requires, and so treats the request
   as not signed by a known agent rather than failing.

9.  Profile: Agent Instances

   Agents frequently run as many short-lived instances, for example one
   per task.  Publishing a key for each instance in the AID does not
   scale, and placing the agent's long-term private keys in every
   instance is unsafe.

   Instead, the agent's controlling infrastructure issues each instance
   a token in the WIMSE Workload Identity Token (WIT) format
   [WIMSE-CREDS] that binds the instance's key to the agent.

   This profile reuses the WIT format and header field but not the WIMSE
   trust model.  Section 3 of [WIMSE-CREDS] requires verifiers to bind
   each trust domain to issuers and trust anchors provisioned out of
   band.  This profile replaces that requirement: the only authorized
   issuers of a WIT whose sub is an agent URI are the assertion keys
   anchored to _exactly that agent URI_ (Section 6), discovered from its
   AID.  Verifiers that also implement WIMSE MUST NOT treat these keys
   as trust anchors for any other workload identifier, in the same trust
   domain or otherwise, and MUST NOT accept such a WIT under WIMSE
   trust-domain configuration alone.

   This profile applies only to agent URIs without a port, because WIMSE
   workload identifiers cannot contain one.  An agent whose URI has a
   port MUST NOT issue WITs under this profile, and verifiers MUST
   reject a WIT whose sub has a port.  A port MUST NOT be removed to
   make a URI fit, since that names a different agent.





Narvaneni & Ravi          Expires 23 April 2027                [Page 21]

Internet-Draft                  agent-uri                   October 2026


   The WIT MUST conform to the format and claim requirements of
   Section 5.1 of [WIMSE-CREDS] and additionally:

   *  is signed with an Agent Key usable for assertion, with the JWS kid
      header set to that key's Key Identifier;

   *  has a cnf claim [RFC7800] containing the instance's public key as
      a jwk, as required by [WIMSE-CREDS];

   *  has sub set to the canonical agent URI;

   *  has iss, if present, set to the canonical agent URI;

   *  has a jti claim, which MUST be generated at random and not reused
      (Section 14);

   *  has an iat claim that is not in the future; and

   *  has an exp later than iat and no more than one hour after it.

   The instance signs requests with its own key as in Section 8.1, with
   keyid set to the Key Identifier of the key in the WIT's cnf.jwk, and
   sends the WIT in the Workload-Identity-Token field defined by
   [WIMSE-CREDS], which the signature covers.

   To validate the WIT, the verifier:

   1.  Validates the WIT's format and claims as specified in Section 5.1
       of [WIMSE-CREDS] and the additional requirements above.  The
       verifier MUST reject the WIT if iat is missing; if iat is later
       than the current time plus the allowed clock skew; unless 0 < exp
       - iat <= 3600; if exp has passed; if nbf is present and has not
       yet been reached; or if sub has a port.  These checks MUST be
       performed explicitly, because [RFC7519] does not require JWT
       libraries to reject a future iat.

   2.  Checks that sub is identical to the agent URI derived from
       Signature-Agent, and retrieves its AID; trust-anchor provisioning
       is replaced as described above.

   3.  Selects an anchored key usable for assertion whose Key Identifier
       equals the WIT's kid, and verifies the WIT signature.

   4.  Checks that the request signature's keyid equals the Key
       Identifier of cnf.jwk, and verifies the request signature with
       that key using the algorithm in cnf.jwk.alg.





Narvaneni & Ravi          Expires 23 April 2027                [Page 22]

Internet-Draft                  agent-uri                   October 2026


   This profile does not use the WIMSE HTTP signature profile
   [WIMSE-HTTPSIG], whose tag and covered components differ; see
   Appendix B.

10.  Profile: Authorization

   Identity is not authorization.  This section connects agent identity
   to OAuth 2.0 without defining new token formats.

10.1.  The Agent as an OAuth Client

   An agent that obtains OAuth tokens SHOULD use a Client ID Metadata
   Document [OAUTH-CIMD] as its client identifier and link to it from
   its AID with rel="oauth-client-metadata".  The client metadata
   document SHOULD include the agent_uri client metadata parameter
   (Section 15.6) containing the canonical agent URI.

   The agent_uri value is a claim made by whoever publishes the client
   metadata document.  Ordinary client authentication [OAUTH-CIMD] does
   not authenticate it: anyone can publish client metadata that names
   someone else's agent URI and then authenticate correctly as that
   client.

   *Association check.* The association between a client_id and an agent
   is verified by retrieving the AID for the claimed agent URI
   (Section 5.6), including all anchoring and status checks, and
   confirming that the AID has an oauth-client-metadata link whose href
   is identical to the client_id, with any statement that link requires
   (Section 5.4).  An authorization server that does not attribute agent
   identity MAY skip this check.  On its own, the check does not show
   that the party making the current request controls the agent, because
   a public client_id can be used by anyone.

   *Agent attribution.* An authorization server MUST NOT treat the
   current caller as an authenticated agent unless one of the following
   holds:

   *  the association check succeeds for the exact client_id, *and* the
      client authenticates with private_key_jwt in the current exchange
      using qualifying client keys (below); or

   *  a request signature for the agent URI is verified under Section 8
      in the current exchange.

   A valid client assertion without a successful association check
   leaves the agent identity unverified.





Narvaneni & Ravi          Expires 23 April 2027                [Page 23]

Internet-Draft                  agent-uri                   October 2026


   *Qualifying client keys.* A statement protects only the bytes it
   names (Section 7), so a statement over the client metadata document
   protects a jwks_uri value but not the keys served there.  For the
   private_key_jwt route, client keys qualify only if they are:

   *  embedded in the client metadata document's jwks, where that
      document is served from the AID Origin (origin-anchored agents
      only) or is covered by a valid statement (Section 5.4); or

   *  served from a jwks_uri whose origin, compared as in Section 5.4,
      equals the AID Origin (origin-anchored agents only).

   For DID-anchored agents, only embedded jwks in a statement-covered
   client metadata document qualify; no jwks_uri qualifies, even on the
   AID Origin.  Agents whose client keys do not qualify MUST use request
   signatures for agent attribution.

   *Which agent is attributed.* The attributed agent is the one whose
   identity was verified: for the private_key_jwt route, the agent URI
   that passed the association check; for the request-signature route,
   the agent URI derived from Signature-Agent.  If the client metadata
   document's agent_uri is absent or names a different agent, the
   authorization server MUST NOT display or record that value as the
   agent's identity, and MAY reject the request.

   *Consent.* In flows where the user's browser reaches the
   authorization endpoint through a front-channel redirect, the agent
   cannot sign that request, and the token request happens only after
   consent.  A consent screen can therefore show a verified agent
   identity only if attribution succeeded on a back-channel request made
   for the same authorization request before consent.  Agents that want
   verified identity shown at consent SHOULD use Pushed Authorization
   Requests [RFC9126], with the pushed request either signed under
   Section 8 or authenticated with private_key_jwt satisfying the
   attribution rule above.  Authorization servers SHOULD support this.

   Otherwise, the authorization server MUST handle the client as it
   would any client using that client_id, and MUST NOT present it to
   users as a verified agent identity.  When a verified identity is
   shown, consent screens SHOULD display the attributed agent URI or its
   DID and MUST present the operator name as claimed by the agent
   (Section 13.3).









Narvaneni & Ravi          Expires 23 April 2027                [Page 24]

Internet-Draft                  agent-uri                   October 2026


10.2.  Delegation

   When an agent acts on behalf of a user or another agent, the
   delegation SHOULD be expressed with OAuth 2.0 Token Exchange
   [RFC8693], with the agent identified in the act claim by "sub" set to
   its canonical agent URI.  As required by [RFC8693], only the current
   actor is relevant to access-control decisions; nested actors are
   informational.

   Access tokens used by agents SHOULD be sender-constrained, for
   example with DPoP [RFC9449].  The DPoP key SHOULD be an instance key
   (Section 9) or a key dedicated to DPoP.  Agent Keys used for
   assertion MUST NOT be used as DPoP keys, both to keep long-term keys
   out of running agents (Section 13.6) and to avoid using one key
   across JWS statements, HTTP message signatures, and DPoP proofs.
   Within a single trust domain, [TXN-TOKENS] can carry the agent
   identity and call context between services.

10.3.  Protected Resources

   Resource servers advertise their requirements using OAuth 2.0
   Protected Resource Metadata [RFC9728].  A resource server MAY require
   a valid agent signature (Section 8) in addition to an access token,
   and MAY apply policy based on the agent URI or its DID.

11.  Discovery

   Dereferencing a known agent URI requires no discovery.  To let others
   find which agents a domain operates, a domain MAY list them in an API
   catalog [RFC9727] (a linkset [RFC9264]) at /.well-known/api-catalog,
   using the agent URI as the link context and agent-identity links to
   the AIDs:

   {
     "linkset": [
       {
         "anchor": "agent://example.com/planner",
         "agent-identity": [
           { "href": "https://example.com/.well-known/agent/planner",
             "type": "application/agent-id+json" }
         ]
       }
     ]
   }

                 Figure 6: Listing agents in an API catalog





Narvaneni & Ravi          Expires 23 April 2027                [Page 25]

Internet-Draft                  agent-uri                   October 2026


   Publishing a catalog is optional (Section 14).  Registries and search
   services that index agents SHOULD verify AIDs and statements
   themselves rather than asking clients to trust the index.

12.  Relationship to Other Protocols

   A2A:  An Agent Card describes how to communicate with an agent.  The
      AID links to it with rel="agent-card".  A2A clients can verify a
      card by checking the agent's statement about it.

   MCP:  MCP server metadata describes tools and how to reach them.  The
      AID links to it with rel="mcp-server-card".  MCP clients can
      identify the calling agent to MCP servers using request
      signatures.

   OpenAPI:  The AID links to API descriptions with rel="service-desc"
      [RFC9727].

   Web Bot Auth:  [WEB-BOT-AUTH] lets automated clients sign requests
      and resolve keys from an HTTPS URL.  Section 8 is a profile of it
      that adds a Signature-Agent type resolving to an AID, which gives
      the signer a stable agent name, purpose-scoped keys, and an
      optional DID anchor.

   WIMSE:  [WIMSE-CREDS] defines workload credentials.  Section 9 reuses
      the WIMSE Workload Identity Token format, with the agent URI as
      the workload identifier and the AID, rather than out-of-band trust
      anchors, as the source of the issuer's keys.

13.  Security Considerations

13.1.  Trust Model

   For origin-anchored agents, the trust anchors are DNS and the Web
   PKI: anyone who can obtain a certificate for the agent URI's host and
   serve content there can impersonate the agent.  This is the same
   trust model as the web itself and is appropriate for most agents.

   DID anchoring reduces this dependency only for verifiers that have
   pinned the agent's DID (Section 6.2).  On first contact, a verifier
   cannot tell a legitimate origin-anchored agent from an attacker who
   has taken over the domain and replaced a DID-anchored AID with an
   origin-anchored one.  Even for a pinned DID, assurance holds only if
   verifiers rely solely on DID-authorized keys and on metadata covered
   by statements made with them (Section 5.4).






Narvaneni & Ravi          Expires 23 April 2027                [Page 26]

Internet-Draft                  agent-uri                   October 2026


13.2.  Handle Reassignment

   If a domain lapses and is registered by someone else, the new holder
   can publish an AID for the same agent URIs.  Verifiers that record
   identities for audit or reputation SHOULD record the Key Identifiers
   (and DID, when present) alongside the agent URI, and SHOULD treat a
   change of all keys for an agent as a significant event.

13.3.  Operator Claims

   Verification establishes possession of a key anchored to an agent URI
   or DID.  It does not establish who operates the agent: operator.name
   and operator.url are supplied by the same party that publishes the
   AID.  The owner of attacker.example can claim "Example Travel Ltd" as
   operator and point operator.url at the real company's website.

   User interfaces and logs MUST NOT present an operator name as
   verified unless it has been confirmed by a separate mechanism trusted
   by the verifier, which this document does not define.  They SHOULD
   display the authenticated agent URI host (in A-label form) or DID
   alongside any operator name.

13.4.  Verifier-Initiated Fetches

   Verification causes network requests to destinations chosen by
   untrusted parties: AID URLs from Signature-Agent values, statement
   subjects and link targets, and requests made by DID resolvers.  Each
   of these can be used for server-side request forgery or denial of
   service.  The following policy applies to *every* fetch made in the
   course of verification:

   *  Only HTTPS URLs are fetched, with certificate validation.

   *  Destinations whose host is, or resolves to, an address that the
      IANA IPv4 or IPv6 Special-Purpose Address Registries [RFC6890]
      mark as not globally reachable MUST NOT be fetched.  Hosts that
      are special-use names that do not resolve in the global DNS (for
      example, localhost or names under local or internal) MUST NOT be
      fetched.  Administrators MAY configure explicit exceptions for
      private deployments.

   *  The resolved address MUST be checked and then used for the
      connection (pinned), so that DNS changes cannot redirect the
      request after the check.

   *  HTTP redirects MUST NOT be followed, as in [WEB-BOT-AUTH].  Any
      status other than 200, and other than 304 received in response to
      a conditional revalidation request, is a failure.



Narvaneni & Ravi          Expires 23 April 2027                [Page 27]

Internet-Draft                  agent-uri                   October 2026


   *  Verifiers MUST enforce connection and response timeouts, and MUST
      bound response sizes: 64 KiB for AIDs and a locally configured
      limit for other resources.

   *  Verifiers MUST bound the number of fetches per verification.  A
      limit of 4 (for example, the AID, a DID resolution, and a
      statement subject) is RECOMMENDED.  A DID resolution counts as one
      fetch toward this limit; verifiers MUST separately bound the
      requests a DID resolver makes, by configuration for each allowed
      DID method.  Verifiers MUST NOT recursively follow links or
      depends-style references from fetched documents.

   *  Verifiers MUST rate-limit fetches per host and cache results,
      including failures.

   A statement whose signature is valid does not make its sub safe to
   fetch: an attacker can publish a legitimate AID under its own domain
   and sign a statement whose sub names an internal address.

13.5.  Request Content and Replay

   HTTP message signatures authenticate header values, not content.
   Verifiers MUST recompute Content-Digest over received content
   (Section 8.2); otherwise an attacker can change the content of a
   signed request while keeping the signed digest.

   Signatures cover the method, target URI, and authority, which
   prevents replay against a different resource or service.  The short
   created-expires window limits replay against the same resource;
   verifiers for non-idempotent operations SHOULD require and track
   nonce values.

13.6.  Key Compromise and Key Separation

   Compromise of an Agent Key lets the attacker act as the agent until
   the key is removed and caches expire.  Operators SHOULD keep Agent
   Keys in hardware or a key management service and use instance
   credentials (Section 9) so that long-term keys are never present in
   running agents.  Workload Identity Tokens SHOULD be short-lived,
   because they cannot be individually revoked.

   Operators SHOULD use different keys for assertion and authentication,
   using agent_use for origin-anchored keys and DID verification
   relationships for DID-anchored keys (Section 5.3), and MUST NOT use
   Agent Keys as DPoP keys (Section 10.2).






Narvaneni & Ravi          Expires 23 April 2027                [Page 28]

Internet-Draft                  agent-uri                   October 2026


13.7.  Cross-Origin Metadata

   Requiring statements bound to the exact href for cross-origin links
   (Section 5.4, Section 7.1) prevents a compromised or malicious third-
   party host, mirror, or registry from attaching metadata to an agent's
   identity or redirecting a valid statement to other content.  A
   statement only proves that the agent published the resource; it does
   not vouch for the truth of the resource's contents.

13.8.  Confusable Names

   Agent URIs can be visually similar (e.g., agent://examp1e.example/
   planner and agent://example.example/planner).  User interfaces that
   display agent identities SHOULD display the A-label form of the host,
   and SHOULD warn when an agent URI or DID is new to the user.

14.  Privacy Considerations

   The considerations of [RFC6973] apply.

   *  *Linkability is the point, for agents.* Request signatures make an
      agent's traffic attributable and linkable across services.  That
      is intended for the agent; it must not extend to the people it
      acts for.  Agent URIs, WIT jti values, and Signature-Agent values
      MUST NOT encode user identifiers.  WIT jti values MUST be random
      and not reused across users.

   *  *Per-user agents.* Deployments that create one agent per end user
      (e.g., agent://example.com/u/alice) make that user's activity
      linkable across all services the agent visits.  Such deployments
      SHOULD use a shared agent identity and convey user context only
      through authorization tokens sent to parties entitled to it.

   *  *Enumeration.* API catalogs (Section 11) let anyone list a
      domain's agents.  Domains that do not want their agents to be
      enumerable should not publish them in a catalog; AIDs remain
      retrievable by those who already know the agent URI.

   *  *Verifier fetches.* Fetching an AID reveals to the operator that a
      verifier has seen the agent.  Caching reduces this signal.

15.  IANA Considerations

15.1.  URI Scheme Registration

   This document requests registration of the agent URI scheme in the
   "Uniform Resource Identifier (URI) Schemes" registry per [RFC7595]:




Narvaneni & Ravi          Expires 23 April 2027                [Page 29]

Internet-Draft                  agent-uri                   October 2026


   *  Scheme name: agent

   *  Status: Permanent

   *  Applications/protocols that use this scheme name: Identification
      of software agents and retrieval of their Agent Identity
      Documents.

   *  Contact: The authors.

   *  Change controller: IETF.

   *  Reference: Section 4 of this document.

   This document does not define or request registration of
   agent+<suffix> schemes.

15.2.  Well-Known URI Registration

   This document requests registration in the "Well-Known URIs" registry
   [RFC8615]:

   *  URI suffix: agent

   *  Change controller: IETF

   *  Specification document: Section 4.3 of this document

   *  Status: permanent

   *  Related information: Sub-paths are used; see Section 4.3.

15.3.  Media Types

   This document requests registration of the following media types per
   [RFC6838]:

   *  application/agent-id+json, for Agent Identity Documents
      (Section 5).

   *  application/agent-statement+jwt, for Agent Statements (Section 7).
      The +jwt structured syntax suffix is registered by [RFC8417].

   Full registration templates will be provided in a future revision.







Narvaneni & Ravi          Expires 23 April 2027                [Page 30]

Internet-Draft                  agent-uri                   October 2026


15.4.  Signature-Agent Type

   Section 8 uses the Signature-Agent member parameter value type=agent-
   id.  [WEB-BOT-AUTH] does not currently establish a registry of type
   values.  This document asks that such a registry be created and that
   agent-id be registered in it, referencing Section 8 of this document
   (see Appendix B).

   This document does not register any HTTP field names.

15.5.  Link Relations

   This document requests registration of agent-identity in the "Link
   Relation Types" registry [RFC8288], with description "Refers to the
   Agent Identity Document of the link context."  Registration of agent-
   card, mcp-server-card, and oauth-client-metadata is an open issue
   (Appendix B).

15.6.  OAuth Client Metadata

   This document requests registration of agent_uri in the "OAuth
   Dynamic Client Registration Metadata" registry [RFC7591], with
   description "Canonical agent URI of the client".

15.7.  JSON Web Key Parameters

   This document requests registration of agent_use in the "JSON Web Key
   Parameters" registry [RFC7517], with description "Purposes for which
   an Agent Key may be used", parameter information class "Public", used
   with all key types, referencing Section 5.3 of this document.

15.8.  JSON Web Token Claims

   This document requests registration of resource_digest in the "JSON
   Web Token Claims" registry [RFC7519], with description "Digest of the
   resource identified by the sub claim", referencing Section 7 of this
   document.

16.  References

16.1.  Normative References

   [CID]      Sporny, M. and M. Jones, "Controlled Identifiers v1.0",
              W3C Recommendation, May 2025,
              <https://www.w3.org/TR/cid-1.0/>.






Narvaneni & Ravi          Expires 23 April 2027                [Page 31]

Internet-Draft                  agent-uri                   October 2026


   [DID-CORE] Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele,
              O., and C. Allen, "Decentralized Identifiers (DIDs) v1.0",
              W3C Recommendation, July 2022,
              <https://www.w3.org/TR/did-core/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/rfc/rfc3339>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/rfc/rfc3986>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/rfc/rfc5234>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/rfc/rfc5890>.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891,
              DOI 10.17487/RFC5891, August 2010,
              <https://www.rfc-editor.org/rfc/rfc5891>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/rfc/rfc6838>.

   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
              "Special-Purpose IP Address Registries", BCP 153,
              RFC 6890, DOI 10.17487/RFC6890, April 2013,
              <https://www.rfc-editor.org/rfc/rfc6890>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/rfc/rfc7515>.




Narvaneni & Ravi          Expires 23 April 2027                [Page 32]

Internet-Draft                  agent-uri                   October 2026


   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7517>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7519>.

   [RFC7591]  Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
              P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
              RFC 7591, DOI 10.17487/RFC7591, July 2015,
              <https://www.rfc-editor.org/rfc/rfc7591>.

   [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
              and Registration Procedures for URI Schemes", BCP 35,
              RFC 7595, DOI 10.17487/RFC7595, June 2015,
              <https://www.rfc-editor.org/rfc/rfc7595>.

   [RFC7638]  Jones, M. and N. Sakimura, "JSON Web Key (JWK)
              Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
              2015, <https://www.rfc-editor.org/rfc/rfc7638>.

   [RFC7800]  Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
              Possession Key Semantics for JSON Web Tokens (JWTs)",
              RFC 7800, DOI 10.17487/RFC7800, April 2016,
              <https://www.rfc-editor.org/rfc/rfc7800>.

   [RFC8037]  Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
              and Signatures in JSON Object Signing and Encryption
              (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
              <https://www.rfc-editor.org/rfc/rfc8037>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8259>.

   [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
              DOI 10.17487/RFC8288, October 2017,
              <https://www.rfc-editor.org/rfc/rfc8288>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/rfc/rfc8615>.



Narvaneni & Ravi          Expires 23 April 2027                [Page 33]

Internet-Draft                  agent-uri                   October 2026


   [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
              and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
              DOI 10.17487/RFC8693, January 2020,
              <https://www.rfc-editor.org/rfc/rfc8693>.

   [RFC8725]  Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
              Current Practices", BCP 225, RFC 8725,
              DOI 10.17487/RFC8725, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8725>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8785>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [RFC9111]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Caching", STD 98, RFC 9111,
              DOI 10.17487/RFC9111, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9111>.

   [RFC9421]  Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
              Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
              February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

   [RFC9530]  Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
              DOI 10.17487/RFC9530, February 2024,
              <https://www.rfc-editor.org/rfc/rfc9530>.

   [RFC9651]  Nottingham, M. and P. Kamp, "Structured Field Values for
              HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
              <https://www.rfc-editor.org/rfc/rfc9651>.

   [WEB-BOT-AUTH]
              Meunier, T. and S. Major, "HTTP Message Signatures for
              automated traffic", Work in Progress, Internet-Draft,
              draft-ietf-webbotauth-httpsig-protocol-00, 1 September
              2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
              webbotauth-httpsig-protocol-00>.

   [WIMSE-CREDS]
              Campbell, B., Salowey, J. A., Schwenkschuster, A.,
              Sheffer, Y., and Y. Rosomakho, "WIMSE Workload
              Credentials", Work in Progress, Internet-Draft, draft-



Narvaneni & Ravi          Expires 23 April 2027                [Page 34]

Internet-Draft                  agent-uri                   October 2026


              ietf-wimse-workload-creds-02, 2 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              workload-creds-02>.

16.2.  Informative References

   [A2A]      A2A Project, Linux Foundation, "Agent2Agent (A2A) Protocol
              Specification", 2025,
              <https://a2a-protocol.org/latest/specification/>.

   [DID-WEBVH]
              Decentralized Identity Foundation, "The did:webvh DID
              Method", 2025, <https://identity.foundation/didwebvh/>.

   [MCP]      Model Context Protocol Project, "Model Context Protocol
              Specification", 2025,
              <https://modelcontextprotocol.io/specification/>.

   [OAUTH-CIMD]
              Parecki, A. and E. Smith, "OAuth Client ID Metadata
              Document", Work in Progress, Internet-Draft, draft-ietf-
              oauth-client-id-metadata-document-02, 6 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              client-id-metadata-document-02>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <https://www.rfc-editor.org/rfc/rfc6973>.

   [RFC8417]  Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari,
              "Security Event Token (SET)", RFC 8417,
              DOI 10.17487/RFC8417, July 2018,
              <https://www.rfc-editor.org/rfc/rfc8417>.

   [RFC9126]  Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
              and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
              RFC 9126, DOI 10.17487/RFC9126, September 2021,
              <https://www.rfc-editor.org/rfc/rfc9126>.

   [RFC9264]  Wilde, E. and H. Van de Sompel, "Linkset: Media Types and
              a Link Relation Type for Link Sets", RFC 9264,
              DOI 10.17487/RFC9264, July 2022,
              <https://www.rfc-editor.org/rfc/rfc9264>.






Narvaneni & Ravi          Expires 23 April 2027                [Page 35]

Internet-Draft                  agent-uri                   October 2026


   [RFC9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
              Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
              Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
              September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

   [RFC9727]  Smith, K., "api-catalog: A Well-Known URI and Link
              Relation to Help Discovery of APIs", RFC 9727,
              DOI 10.17487/RFC9727, June 2025,
              <https://www.rfc-editor.org/rfc/rfc9727>.

   [RFC9728]  Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0
              Protected Resource Metadata", RFC 9728,
              DOI 10.17487/RFC9728, April 2025,
              <https://www.rfc-editor.org/rfc/rfc9728>.

   [RFC9943]  Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
              Y., and S. Lasker, "An Architecture for Trustworthy and
              Transparent Digital Supply Chains", RFC 9943,
              DOI 10.17487/RFC9943, June 2026,
              <https://www.rfc-editor.org/rfc/rfc9943>.

   [TXN-TOKENS]
              Tulshibagwale, A., Fletcher, G., and P. Kasselman,
              "Transaction Tokens", Work in Progress, Internet-Draft,
              draft-ietf-oauth-transaction-tokens-11, 30 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              transaction-tokens-11>.

   [WIMSE-HTTPSIG]
              Salowey, J. A. and Y. Sheffer, "WIMSE Workload-to-Workload
              Authentication with HTTP Signatures", Work in Progress,
              Internet-Draft, draft-ietf-wimse-http-signature-08, 20
              October 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-wimse-http-signature-08>.

Appendix A.  Test Vectors: Agent URI Processing

   This appendix is informative.  It gives expected results for the
   syntactic processing defined in Section 4 and Section 5.4, so that
   independent implementations can check that they agree.  Vectors for
   statements, request signatures, and Workload Identity Tokens will be
   added once an implementation can produce and cross-check them
   (Appendix B).








Narvaneni & Ravi          Expires 23 April 2027                [Page 36]

Internet-Draft                  agent-uri                   October 2026


A.1.  Parsing and Canonicalization

   Each vector shows an input, then its result. "valid" inputs are
   canonical. "normalized" inputs differ from the ABNF only by
   deviations listed in Section 4.2; parsers MAY accept them and, if
   they do, MUST produce the canonical form shown. "reject" inputs MUST
   be rejected. <U+00FC> denotes the single character LATIN SMALL LETTER
   U WITH DIAERESIS.











































Narvaneni & Ravi          Expires 23 April 2027                [Page 37]

Internet-Draft                  agent-uri                   October 2026


   agent://example.com/planner
       valid       agent://example.com/planner
   agent://planner.example.com
       valid       agent://planner.example.com    (root agent)
   agent://example.com:8443/planner
       valid       agent://example.com:8443/planner
   agent://example.com/acme/billing-assistant
       valid       agent://example.com/acme/billing-assistant
   agent://123.example/planner
       valid       agent://123.example/planner
   agent://example.com/p#kPrK_qmxVWaYVA9wwBF6Iuo3vVzz7TxHCTwXBygrS4k
       valid       agent://example.com/p          (plus key fragment)

   AGENT://Example.COM/planner
       normalized  agent://example.com/planner
   agent://example.com:443/planner
       normalized  agent://example.com/planner
   agent://example.com:/planner
       normalized  agent://example.com/planner
   agent://example.com/planner/
       normalized  agent://example.com/planner
   agent://planner.example.com/
       normalized  agent://planner.example.com
   agent://b<U+00FC>cher.example/planner
       normalized  agent://xn--bcher-kva.example/planner

   agent://192.168.0.1/planner             reject  all-digit final label
   agent://localhost/planner               reject  single-label host
   agent://[::1]/planner                   reject  IP literal
   agent://user@example.com/planner        reject  userinfo
   agent://example.com./planner            reject  trailing "." on host
   agent://example.com:0443/planner        reject  leading zero in port
   agent://example.com:65536/planner       reject  port out of range
   agent://example.com/planner?task=1      reject  query
   agent://example.com/Planner             reject  uppercase name-path
   agent://example.com/plan%6Eer           reject  percent-encoding
   agent://example.com/a/../planner        reject  dot-segment
   agent://example.com//planner            reject  empty segment
   agent://example.com/-planner            reject  leading "-"
   agent://example.com/_                   reject  reserved segment
   agent://example.com/a/b/c/d/e/f/g/h/i   reject  more than 8 segments
   agent+https://example.com/planner       reject  not the agent scheme

               Figure 7: Parsing and canonicalization vectors

   agent://example.com/p with and without the key fragment identify the
   same agent (Section 4.2).




Narvaneni & Ravi          Expires 23 April 2027                [Page 38]

Internet-Draft                  agent-uri                   October 2026


A.2.  Mapping to AID URLs

   agent://example.com/planner
       https://example.com/.well-known/agent/planner
   agent://planner.example.com
       https://planner.example.com/.well-known/agent/_
   agent://example.com:8443/planner
       https://example.com:8443/.well-known/agent/planner
   agent://example.com/acme/billing-assistant
       https://example.com/.well-known/agent/acme/billing-assistant
   agent://xn--bcher-kva.example/planner
       https://xn--bcher-kva.example/.well-known/agent/planner

                   Figure 8: Agent URI to AID URL vectors

A.3.  Reverse Mapping of Signature-Agent Values

   Values are compared exactly, without normalization (Section 8.2).

   https://example.com/.well-known/agent/planner
       agent://example.com/planner
   https://planner.example.com/.well-known/agent/_
       agent://planner.example.com
   https://example.com:8443/.well-known/agent/planner
       agent://example.com:8443/planner
   https://Example.com/.well-known/agent/planner
       reject  not canonical (host case)
   https://example.com:443/.well-known/agent/planner
       reject  not canonical (default port)
   https://example.com/.well-known/agent/planner/
       reject  not canonical (trailing "/")
   https://example.com/.well-known/agent/planner?v=1
       reject  query
   http://example.com/.well-known/agent/planner
       reject  not HTTPS
   https://example.com/.well-known/agent
       reject  neither a name-path nor the reserved segment
   https://example.com/.well-known/agent/_/planner
       reject  reserved segment inside a name-path
   https://example.com/.well-known/agent/Planner
       reject  invalid name-path
   https://example.com/.well-known/agent/planner#k
       reject  fragment
   https://b<U+00FC>cher.example/.well-known/agent/planner
       reject  not canonical (U-label host)

                     Figure 9: Reverse mapping vectors




Narvaneni & Ravi          Expires 23 April 2027                [Page 39]

Internet-Draft                  agent-uri                   October 2026


A.4.  AID Origin Comparison

   For agent://example.com/planner, the AID Origin is ("https",
   "example.com", 443).  Link targets compare as follows (Section 5.4):

   https://example.com/planner/agent-card.json         same origin
   https://example.com:443/planner/agent-card.json     same origin
   https://EXAMPLE.com/planner/agent-card.json         same origin
   https://planner.example.com/agent-card.json         different host
   https://example.com:8443/planner/agent-card.json    different port
   https://example.com./planner/agent-card.json        different host
   http://example.com/planner/agent-card.json          invalid href

                  Figure 10: AID Origin comparison vectors

   A link whose href is not an HTTPS URL is invalid regardless of
   origin, and a statement cannot make it valid (Section 5.4).

Appendix B.  Open Issues

   This appendix will be removed before publication.

   1.  *Signature-Agent type registry.* [WEB-BOT-AUTH] has no registry
       for type values.  Work with the webbotauth WG to create one, or
       to define agent-id there.  Until then, verifiers that only
       implement [WEB-BOT-AUTH] ignore agent identities.

   2.  *WIMSE alignment.* Discuss with the WIMSE WG whether port-free
       agent URIs are acceptable workload identifiers (their authority
       fits the trust domain shape of WIMSE identifiers), whether AID-
       based issuer discovery can become a recognized alternative to
       out-of-band trust-anchor provisioning, and whether instances
       should also be able to use the WIMSE HTTP signature profile
       [WIMSE-HTTPSIG].

   3.  *Back-references from protocol metadata.* Agree with the A2A and
       MCP projects on how an Agent Card or MCP server card names its
       agent URI, and who registers the agent-card and mcp-server-card
       link relations.

   4.  *Retired keys.* Consider an optional list of retired keys with
       retirement times, so that statements issued before a planned
       rotation remain verifiable without re-issuance, while compromised
       keys are still removed.

   5.  *Reserved root segment.* /.well-known/agent/_ is chosen to work
       on static hosting.  Alternatives (a separate well-known suffix
       for the root agent) should be evaluated.



Narvaneni & Ravi          Expires 23 April 2027                [Page 40]

Internet-Draft                  agent-uri                   October 2026


   6.  *Name path depth and character set.* Lowercase LDH segments, at
       most 8, are chosen for unambiguous comparison.  Confirm this is
       sufficient for multi-tenant platforms.

   7.  *DNS-based verification.* Consider an alternative proof of
       control via a DNS TXT record, for operators that cannot serve
       well-known paths.

   8.  *Port.* Confirm that non-default ports should be permitted in
       agent identities at all, given they complicate certificate and
       policy handling and are excluded from the agent-instance profile
       (Section 9).

   9.  *Cryptographic test vectors.* Appendix A covers URI processing.
       Once an implementation can produce and cross-check them, add
       vectors for: statement iss/sub binding; DID key conversion and
       per-purpose selection; agent_use enforcement, including duplicate
       key material and malformed values; a preserved DID with
       substituted same-origin client metadata keys; a DID-anchored
       client using jwks_uri with private_key_jwt (not attributed); an
       origin-anchored client whose statement-covered metadata points to
       a jwks_uri off the AID Origin (not attributed); an attacker-owned
       client metadata document claiming an unrelated origin-anchored
       agent's agent_uri, both with only a client assertion (not
       attributed) and with a request signed by the attacker's own agent
       (attributed to the attacker's agent, never the claimed one); a
       WIT whose sub has a port; a WIT with a future iat; content
       tampering with a valid signature; fetches to forbidden
       destinations; and expired credentials.  Two independent verifiers
       should reach the same decision for each.

Appendix C.  Changes from draft-narvaneni-agent-uri-03

   This revision changes the scope of the document from "addressing and
   discovery" to "identity".

   Removed:

   *  agent+<protocol> transport-binding schemes and the Transport
      Bindings registry.

   *  Invocation semantics (GET/POST rules, fallback behaviour), query
      parameters in agent URIs, and conformance levels.

   *  The /.well-known/agents.json registry, replaced by the
      deterministic mapping of Section 4.3 and optional RFC 9727
      catalogs.




Narvaneni & Ravi          Expires 23 April 2027                [Page 41]

Internet-Draft                  agent-uri                   October 2026


   *  The agent descriptor's capability fields (skills, transport,
      interactionModel, versioning, content negotiation).  Protocol
      metadata documents are linked instead.

   *  DID authorities in agent URIs, replaced by DID anchoring
      (Section 6.2).

   *  Cross-cutting conventions (tracing, idempotency, rate limits,
      health) and the Interaction Models registry.

   *  The monotonic scope narrowing rule, which conflicted with
      [RFC8693].

   Added:

   *  Strict URI syntax, normalization, comparison, and reverse-mapping
      rules.

   *  The Agent Identity Document, a single Key Identifier scheme, key
      purposes (including agent_use for origin-anchored keys), and
      origin and DID anchoring with DID pinning.

   *  Agent Statements bound to the links that carry them.

   *  A request-signing profile of [WEB-BOT-AUTH], and an agent-instance
      profile reusing the WIMSE Workload Identity Token format with AID-
      based trust.

   *  OAuth bindings that separate metadata association from agent
      attribution, define which client keys qualify, and describe
      verified identity at consent using Pushed Authorization Requests.

   *  Security and privacy considerations specific to agent identity,
      including a fetch policy covering every verifier-initiated
      request.

   *  Test vectors for URI processing (Appendix A).

Acknowledgments

   The authors thank the reviewers of earlier revisions, whose feedback
   led to the change of scope in this revision.

Authors' Addresses







Narvaneni & Ravi          Expires 23 April 2027                [Page 42]

Internet-Draft                  agent-uri                   October 2026


   Yaswanth Narvaneni
   Independent Researcher
   London
   United Kingdom
   Email: yaswanth+ietf@gmail.com


   Sai Purnima Ravi
   Independent Researcher
   Email: r.sai.purnima+ietf@gmail.com









































Narvaneni & Ravi          Expires 23 April 2027                [Page 43]