# drafts

name: draft-nelson-agent-delegation-receipts
rev: 08
title: Delegation Receipt Protocol for AI Agent Authorization
time: 2026-05-19T22:37:58Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-20T22:37:58Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "Human-agent interaction"]
tags: []
fetched_at: 2026-05-22T09:24:41.698374+00:00
source: ietf
abstract:
  This document defines the Delegation Receipt Protocol (DRP), a
     cryptographic authorization primitive for AI agent deployments.
     Before any agent action executes, the authorizing user signs an
     Authorization Object containing scope boundaries, time window,
     operator instruction hash, and model state commitment.  This signed
     receipt is published to an append-only log before the agent runtime
     receives control.  The protocol removes the operator as a trusted
     third party by making the user's private key the sole signing
     authority over the delegation record.

full_text:
  Network Working Group                                          R. Nelson
  Internet-Draft                                                 Authproof
  Intended status: Informational                               19 May 2026
  Expires: 20 November 2026


           Delegation Receipt Protocol for AI Agent Authorization
                 draft-nelson-agent-delegation-receipts-08

  Abstract

     This document defines the Delegation Receipt Protocol (DRP), a
     cryptographic authorization primitive for AI agent deployments.
     Before any agent action executes, the authorizing user signs an
     Authorization Object containing scope boundaries, time window,
     operator instruction hash, and model state commitment.  This signed
     receipt is published to an append-only log before the agent runtime
     receives control.  The protocol removes the operator as a trusted
     third party by making the user's private key the sole signing
     authority over the delegation record.

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



  Nelson                  Expires 20 November 2026                [Page 1]


  Internet-Draft          Agent Delegation Receipts               May 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Novel Contributions . . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  The Agentic Delegation Chain  . . . . . . . . . . . . . .   6
       3.2.  The Missing Cryptographic Anchor  . . . . . . . . . . . .   6
       3.3.  IETF Framework Analysis . . . . . . . . . . . . . . . . .   7
     4.  The Delegation Receipt  . . . . . . . . . . . . . . . . . . .   8
       4.1.  Receipt Structure . . . . . . . . . . . . . . . . . . . .   8
       4.2.  Canonical Serialization . . . . . . . . . . . . . . . . .   9
       4.3.  Signing Procedure . . . . . . . . . . . . . . . . . . . .  10
     5.  The Append-Only Log . . . . . . . . . . . . . . . . . . . . .  10
       5.1.  Log Entry Structure . . . . . . . . . . . . . . . . . . .  10
       5.2.  Chain Linking . . . . . . . . . . . . . . . . . . . . . .  11
       5.3.  Timestamp Authority . . . . . . . . . . . . . . . . . . .  11
       5.4.  Denied Call Logging . . . . . . . . . . . . . . . . . . .  12
     6.  Pre-Execution Verification  . . . . . . . . . . . . . . . . .  12
       6.1.  Verification Checks . . . . . . . . . . . . . . . . . . .  12
       6.2.  Check Ordering  . . . . . . . . . . . . . . . . . . . . .  13
       6.3.  Failure Handling  . . . . . . . . . . . . . . . . . . . .  15
       6.4.  Verification Algorithm  . . . . . . . . . . . . . . . . .  15
       6.5.  Denial Reason Codes . . . . . . . . . . . . . . . . . . .  17
     7.  Model State Attestation . . . . . . . . . . . . . . . . . . .  19
       7.1.  Commitment Binding  . . . . . . . . . . . . . . . . . . .  19
       7.2.  Provider Update Handling  . . . . . . . . . . . . . . . .  21
       7.3.  Malicious Substitution Detection  . . . . . . . . . . . .  22
     8.  Scope Discovery Protocol  . . . . . . . . . . . . . . . . . .  23
     9.  Session State and Adaptive Authorization  . . . . . . . . . .  25
     10. Multi-Agent Delegation Chains . . . . . . . . . . . . . . . .  29
       10.1.  Scope Attenuation  . . . . . . . . . . . . . . . . . . .  29
       10.2.  Cascade Revocation . . . . . . . . . . . . . . . . . . .  30
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  30
       11.1.  Threat Model . . . . . . . . . . . . . . . . . . . . . .  30
       11.2.  Semantic Gap . . . . . . . . . . . . . . . . . . . . . .  34
       11.3.  TEE Enforcement  . . . . . . . . . . . . . . . . . . . .  35
       11.4.  Degraded Operation . . . . . . . . . . . . . . . . . . .  36
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  37
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  37
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  37
       13.2.  Informative References . . . . . . . . . . . . . . . . .  37
     Appendix A.  JSON Schema Definitions  . . . . . . . . . . . . . .  38
       A.1.  Delegation Receipt Schema . . . . . . . . . . . . . . . .  38
       A.2.  Action Log Entry Schema . . . . . . . . . . . . . . . . .  42
       A.3.  Session State Schema  . . . . . . . . . . . . . . . . . .  43
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  45
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  45



  Nelson                  Expires 20 November 2026                [Page 2]


  Internet-Draft          Agent Delegation Receipts               May 2026


  1.  Introduction

     Agentic AI systems execute actions on behalf of human principals
     using natural language instructions as their primary authorization
     artifact.  This creates a structural gap between the authorization a
     user believes they granted and the instructions an operator delivers
     to the agent at runtime.  No existing cryptographic mechanism makes
     that gap detectable.

     This document specifies the Delegation Receipt Protocol (DRP), a
     cryptographic authorization primitive that addresses this gap.  DRP
     requires every agent action to be preceded by a user-signed
     Authorization Object -- the Delegation Receipt -- anchored to a
     tamper-evident append-only log.  The receipt commits the user's
     authorized scope, operational boundaries, validity window, and a
     cryptographic hash of the operator's stated instructions.  Any
     deviation by the operator from those instructions is provable from
     the public log without additional trust assumptions.

     DRP is not a replacement for existing IETF agent authorization work.
     WIMSE, AIP, and OAuth 2.0 Token Exchange [RFC8693] address service-
     to-agent trust.  DRP addresses the upstream layer: user-to-operator
     trust.  In a complete agentic trust stack, these layers are
     complementary.

     A reference implementation of this protocol is available as an open-
     source SDK at https://github.com/Commonguy25/authproof-sdk under the
     MIT License.  A hosted service implementing the protocol is available
     at https://cloud.authproof.dev with a free tier requiring no credit
     card.

  1.1.  Novel Contributions

     This document introduces three cryptographic primitives that do not
     appear in existing agent authorization frameworks or IETF drafts:

     *Model State Attestation (Section 7):*

     The delegation receipt is bound to a cryptographic measurement of the
     model state at authorization time.  If the operator substitutes a
     different model after the user signs the receipt, the measurement
     changes and execution is blocked.  This closes the operator model
     substitution attack vector that existing frameworks do not address.
     The protocol distinguishes between malicious substitution (always
     blocked) and provider updates (requires reauthorization) using the
     ProviderUpdate vs MaliciousSubstitution classification defined in
     Section 7.3.




  Nelson                  Expires 20 November 2026                [Page 3]


  Internet-Draft          Agent Delegation Receipts               May 2026


     *Scope Discovery Protocol (Section 8):*

     Before authorization, the agent runs in a sandboxed observation mode
     with no real resource access.  It simulates the intended task and
     records every resource it attempts to access.  This produces a draft
     ScopeSchema grounded in actual agent behavior rather than operator-
     specified assumptions.  The user reviews a plain-language summary and
     signs only what they explicitly approve.  This closes the upstream
     design-time gap where users cannot accurately specify scope before
     understanding agent behavior.

     *Session State and Adaptive Authorization (Section 9):*

     A continuously updated trust score tracks behavioral anomalies across
     the session lifetime.  Trust decays on anomaly detection and recovers
     slowly on clean behavior.  Decision thresholds tighten automatically
     as trust degrades.  Sessions suspend when trust falls below a
     configurable floor, requiring explicit user reauthorization.  This
     extends the static pre-execution authorization model to cover dynamic
     session-level risk that cannot be captured at delegation time.

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

     The following terms are used throughout this document:

     Delegation Receipt:
        A signed Authorization Object produced by the User prior to any
        agent action.  Contains scope, boundaries, time window, and
        operator instruction hash.  *MUST* be anchored to an append-only
        log before the agent runtime receives control.

     Authorization Object:
        The canonical JSON body that is signed to produce a Delegation
        Receipt.  The receipt ID is the SHA-256 hash of this body in its
        canonical serialization.

     User:
        The human principal whose resources and authority are being
        delegated.  The User's private key is the sole signing authority
        for Delegation Receipts.





  Nelson                  Expires 20 November 2026                [Page 4]


  Internet-Draft          Agent Delegation Receipts               May 2026


     Operator:
        The developer or organization that builds and deploys the agent.
        The Operator provides instructions to the agent and is bound by
        the instruction hash committed in the receipt.

     Agent:
        The AI system taking actions on behalf of the User.  The Agent
        *MUST* verify a valid Delegation Receipt before executing any
        action.

     Append-Only Log:
        A tamper-evident ledger to which Delegation Receipts are anchored
        prior to execution.  Implementations *SHOULD* use a decentralized
        transparency log following the Certificate Transparency model.

     Log Anchor:
        An inclusion proof returned by the append-only log after a receipt
        is submitted.  The log anchor establishes the authoritative
        issuance timestamp.

     Scope:
        An explicit allowlist of permitted operations embedded in a
        Delegation Receipt.  Operations are classified as reads, writes,
        deletes, or executes.  All operations not listed are denied by
        default.

     Boundaries:
        Explicit prohibitions embedded in a Delegation Receipt that
        survive any subsequent Operator instruction.  Boundaries *MUST
        NOT* be waived or overridden by the Operator.

     Instruction Hash:
        The SHA-256 hash of the Operator's stated instructions at
        delegation time.  Any change to the Operator's instructions after
        receipt issuance is detectable by recomputing this hash.

     Micro-Receipt:
        A minimal Delegation Receipt covering a single action not included
        in the parent receipt's scope.  *MUST* reference the parent
        receipt hash.

     Model State Commitment:
        A cryptographic measurement binding a specific model identity,
        version, system prompt hash, and runtime configuration hash to a
        Delegation Receipt.






  Nelson                  Expires 20 November 2026                [Page 5]


  Internet-Draft          Agent Delegation Receipts               May 2026


     Scope Discovery:
        A protocol that derives authorized scope from sandboxed
        observation of agent behavior rather than upfront user
        specification.

     Session State:
        A live, stateful risk evaluation layer that tracks trust decay,
        sensitivity classification, and behavioral anomalies across the
        lifetime of an agent session.

  3.  Problem Statement

  3.1.  The Agentic Delegation Chain

     Agentic AI systems involve at minimum three principals:

     *  User -- the human whose resources and authority are delegated.

     *  Operator -- the developer or company that builds and deploys the
        agent.

     *  Agent -- the AI system taking actions on the User's behalf.

     The delegation chain is:

        User --> Operator --> Agent --> Services

     The User grants authority to the Operator.  The Operator translates
     that authority into instructions for the Agent.  The Agent acts on
     downstream services.  At each step, fidelity to the User's original
     intent depends entirely on the honesty and competence of the
     intermediate party.

  3.2.  The Missing Cryptographic Anchor

     In current agentic deployments, the User's authorization is captured
     in natural language -- a chat message, a consent checkbox, a terms-
     of-service agreement.  None of these produce a cryptographically
     verifiable record of what the User actually authorized at the moment
     of delegation.

     This creates three compounding problems:

     The repudiation problem:
        If an agent takes an action the User did not authorize, there is
        no cryptographic evidence of what the User did authorize.  The
        Operator's account of the authorization is the only record, and it
        is unverifiable.



  Nelson                  Expires 20 November 2026                [Page 6]


  Internet-Draft          Agent Delegation Receipts               May 2026


     The drift problem:
        Operators may update system prompts, change agent behavior, or
        respond to external pressure in ways that diverge from the User's
        original authorization.  Nothing in the current architecture makes
        this divergence detectable.

     The audit problem:
        Regulators auditing agentic behavior have no evidence chain
        connecting agent actions to original user consent.  The Operator's
        logs are the only source of truth, controlled by the party whose
        conduct is under scrutiny.

  3.3.  IETF Framework Analysis

     Several IETF working groups have produced or are producing
     specifications for agent identity and authorization.  Each addresses
     a different trust boundary; none addresses user-to-operator trust.

     WIMSE (Workload Identity in Multi-System Environments) addresses
     service-to-service authentication: can service B verify that a
     request came from legitimate workload A?  It does not address whether
     the workload was authorized by the User to make that request in the
     first place.

     AIP (Agent Identity Protocol) defines credential structures for agent
     principals and addresses how agents present identity to services they
     call.  Like WIMSE, its trust model is downstream of the Operator --
     it assumes the Operator has correctly represented the User's
     authorization.

     draft-klrc-aiagent-auth addresses OAuth-style authorization flows for
     AI agents, allowing agents to obtain access tokens for downstream
     APIs.  It solves the service authorization problem -- whether the
     agent can call an API -- but not the delegation integrity problem --
     whether the Operator's instructions faithfully represent the User's
     authorization.

     OAuth 2.0 Token Exchange [RFC8693] and Rich Authorization Requests
     [RFC9396] provide mechanisms for scoped token issuance and delegation
     chains between services but operate at the service layer.  The User's
     intent is represented by the OAuth grant, which is under Operator
     control.

     The gap is consistent across all existing frameworks: user-to-
     operator trust is taken as a precondition.  DRP addresses that
     precondition directly.





  Nelson                  Expires 20 November 2026                [Page 7]


  Internet-Draft          Agent Delegation Receipts               May 2026


  4.  The Delegation Receipt

  4.1.  Receipt Structure

     A Delegation Receipt is a JSON object with the following *REQUIRED*
     fields:

     delegationId:
        The SHA-256 hash of the canonical serialization of the
        Authorization Object body (all fields except delegationId and
        signature).  Encoded as the string "sha256:" followed by the
        lowercase hex digest.

     version:
        Protocol version string.  This document defines version "1".

     scope:
        An object with four keys: "reads", "writes", "deletes", and
        "executes", each containing an array of permitted
        resource:operation strings.  The "executes" array *MUST* contain
        SHA-256 hashes of the static capability DAG of each authorized
        program; program names or URIs *MUST NOT* be used in the
        "executes" array.  Natural language *MUST NOT* appear in any scope
        field.

     boundaries:
        An array of prohibition strings that *MUST* be enforced regardless
        of Operator instruction.  The array *MUST NOT* be empty;
        implementations with no explicit prohibitions *SHOULD* populate a
        conservative default.

     timeWindow:
        An object with "notBefore" and "notAfter" fields, each an ISO 8601
        timestamp.  The authoritative time reference is the log timestamp
        (see Section 5.3), not the client clock.

     instructionHash:
        The SHA-256 hash of the Operator's stated instructions at
        delegation time, encoded as "sha256:" followed by the lowercase
        hex digest.

     operatorInstructions:
        The plaintext instruction string whose SHA-256 hash is recorded in
        instructionHash.







  Nelson                  Expires 20 November 2026                [Page 8]


  Internet-Draft          Agent Delegation Receipts               May 2026


     signerPublicKey:
        The User's public key as a JSON Web Key [RFC7517].
        Implementations *SHOULD* use ECDSA P-256 (crv: "P-256") [RFC7518]
        keys.

     signature:
        The ECDSA P-256 signature over the canonical serialization of the
        Authorization Object body, encoded as base64url.

     The following *OPTIONAL* fields are defined by this document:

     teeMeasurement:
        Model state commitment object binding the receipt to a specific
        TEE enclave measurement.  See Section 7.

     scopeSchema:
        Machine-readable structured allowlist and denylist derived from
        the Scope Discovery Protocol.  See Section 8.

     The complete structure is illustrated below:

     {
       "delegationId":  "<sha256-of-canonical-body>",
       "version":       "1",
       "scope": {
         "reads":    ["<resource>:<operation>"],
         "writes":   ["<resource>:<operation>"],
         "deletes":  ["<resource>:<operation>"],
         "executes": ["sha256:<capability-dag-hash>"]
       },
       "boundaries": ["<prohibition-string>"],
       "timeWindow": {
         "notBefore": "<ISO-8601-timestamp>",
         "notAfter":  "<ISO-8601-timestamp>"
       },
       "instructionHash":      "sha256:<hex-digest>",
       "operatorInstructions": "<operator-instruction-text>",
       "signerPublicKey":      { "<JWK per RFC 7517>" },
       "signature":            "<base64url-ecdsa-p256-signature>"
     }

  4.2.  Canonical Serialization

     The canonical serialization of a receipt body is defined as follows:

     1.  Serialize the Authorization Object as JSON with keys sorted in
         lexicographic ascending order at every nesting level.




  Nelson                  Expires 20 November 2026                [Page 9]


  Internet-Draft          Agent Delegation Receipts               May 2026


     2.  Remove all insignificant whitespace (no spaces, no newlines
         outside of string values).

     3.  Encode the result as UTF-8.

     The delegationId is computed as:

     delegationId = "sha256:" ||
                    lowercase_hex(SHA-256(canonical_body))

     Implementations *MUST* compute the delegationId over the body before
     the signature field is added.  The signature field *MUST NOT* be
     included in the data that is signed.

  4.3.  Signing Procedure

     Receipt issuance *MUST* follow this sequence:

     1.  The Operator presents their intended instructions to the User,
         along with the proposed scope, boundaries, and time window.

     2.  The User reviews the scope, boundaries, time window, and Operator
         instructions.

     3.  The User signs the canonical Authorization Object body using
         their private key via the WebAuthn/FIDO2 API [W3C-WebAuthn]
         [FIDO2].  Hardware key custody (Trusted Platform Module or device
         secure enclave) is *RECOMMENDED*.

     4.  The signed receipt is submitted to a decentralized append-only
         log.

     5.  The log assigns a timestamp and returns a log anchor (inclusion
         proof).

     6.  No agent action *MAY* begin until the log anchor is confirmed.

     The log timestamp established in step 5 is the authoritative issuance
     time.  Client clocks *MUST NOT* be used as the time reference for
     receipt validation.

  5.  The Append-Only Log

  5.1.  Log Entry Structure

     Each entry in the append-only log *MUST* contain:

     *  The Delegation Receipt hash (delegationId).



  Nelson                  Expires 20 November 2026               [Page 10]


  Internet-Draft          Agent Delegation Receipts               May 2026


     *  The SHA-256 hash of the preceding log entry (for chain linking;
        see Section 5.2).

     *  A trusted timestamp conforming to [RFC3161].

     *  The submitter's public key hash.

     *  A monotonically increasing entry sequence number.

     Implementations *SHOULD* use a log format compatible with Certificate
     Transparency [RFC6962] to enable standard log consistency
     verification.

     Action log entries produced during agent execution follow the same
     structure.  Each action log entry *MUST* include:

     *  The receipt hash authorizing the action.

     *  The action type, payload hash, and destination.

     *  The SHA-256 hash of the preceding action log entry.

     *  An RFC 3161 timestamp and the agent's ECDSA P-256 signature over
        the entry body.

  5.2.  Chain Linking

     Each log entry *MUST* include the SHA-256 hash of the immediately
     preceding entry.  This chain structure guarantees:

     1.  Log entries cannot be inserted retroactively without producing a
         detectable chain break.

     2.  Log entries cannot be deleted without invalidating the chain hash
         of the subsequent entry.

     3.  Any two parties holding the same entry hash can verify
         independently that they share the same log view up to that entry.

     The chain structure makes it impossible to insert or delete
     individual action records without producing a detectable
     inconsistency that any log monitor can identify.

  5.3.  Timestamp Authority

     Implementations *MUST* use an RFC 3161 [RFC3161] Time-Stamp Authority
     (TSA) to produce the authoritative timestamp for each Delegation
     Receipt anchored to the log.  The TSA timestamp:



  Nelson                  Expires 20 November 2026               [Page 11]


  Internet-Draft          Agent Delegation Receipts               May 2026


     1.  Establishes the authoritative notBefore time for the associated
         Delegation Receipt.

     2.  Is used in lieu of the client clock for all time window
         validation (see Section 6.1).

     3.  Is included in the log anchor returned to the submitter.

     If the TSA is unreachable, implementations *MAY* record a local-clock
     timestamp marked "UNVERIFIED_TIMESTAMP".  An agent verifier *MUST*
     treat UNVERIFIED_TIMESTAMP as insufficient evidence of authorization
     time in production deployments.

  5.4.  Denied Call Logging

     Implementations *MUST* log all verification decisions including those
     that result in a DENY outcome.  Logging only PERMIT decisions creates
     a blind spot for detecting prompt injection and model drift.

     The distribution of denied calls over time is a leading indicator of
     adversarial activity.  A model being prompt- injected will generate
     denied calls with novel action classes and scope edge probing that
     differs detectably from normal operation.  Post-hoc analysis of the
     deny path is the primary forensic signal for incident reconstruction.

     Denied call log entries *MUST* include the full call context, the
     specific denial reason code, and the session risk score at the time
     of denial.  Implementations *SHOULD* expose denied call distribution
     analytics to enable real-time anomaly detection.

  6.  Pre-Execution Verification

  6.1.  Verification Checks

     Before executing any action, the Agent *MUST* perform all of the
     following checks in order.  All checks *MUST* pass; any single
     failure *MUST* abort the action without partial execution.

     The complete verification procedure is:












  Nelson                  Expires 20 November 2026               [Page 12]


  Internet-Draft          Agent Delegation Receipts               May 2026


     Verify(receipt, action):
       (1) if Revoked(receipt.delegationId)
                                           -> fail
       (2) if not VerifySig(receipt.signature,
                            canonical(receipt.body),
                            receipt.signerPublicKey)
                                           -> fail
       (3) if not InTimeWindow(receipt.timeWindow,
                               logTimestamp)
                                           -> fail
       (4) if not InScope(action, receipt.scope)
                                           -> fail
       (5) if ViolatesBoundary(action, receipt.boundaries)
                                           -> fail
       (6) if action.type == EXECUTE and
              Hash(SafescriptDAG(program))
              != receipt.scope.executes[n]
                                           -> fail
       (7) if Hash(currentOperatorInstructions)
              != receipt.instructionHash
                                           -> fail
       (8) if receipt.toolSchemaHash PRESENT and
              SHA-256(canonical(currentToolSchema))
              != receipt.toolSchemaHash
                                           -> fail
       (9) if receipt.toolOutputHash PRESENT and
              action.toolOutput PRESENT and
              SHA-256(action.toolOutput)
              != receipt.toolOutputHash
                                           -> fail
       (10) if receipt.trustedSources PRESENT and
               action.instructionSource PRESENT and
               action.instructionSource NOT IN receipt.trustedSources
                                           -> fail
       return true

     The revocation pre-check (step 1) *MUST* be performed before any
     other check.  A revoked receipt *MUST* fail immediately regardless of
     whether other checks would pass.

  6.2.  Check Ordering

     The check ordering reflects distinct security properties; each step
     eliminates a distinct attack surface.







  Nelson                  Expires 20 November 2026               [Page 13]


  Internet-Draft          Agent Delegation Receipts               May 2026


     Revocation check (1):
        Ensures a receipt explicitly invalidated by the User cannot
        authorize further actions, regardless of its cryptographic
        validity.

     Signature check (2):
        Confirms the receipt was signed by the holder of the User's
        private key and has not been altered since signing.  Any tampering
        with the receipt body invalidates the signature under ECDSA P-256.

     Time window check (3):
        Validates the action against the log-assigned TSA timestamp, not
        the client clock.  Prevents time manipulation attacks in which an
        agent extends its own authorization window by adjusting local
        time.

     Scope check (4):
        Enforces the deny-by-default allowlist.  If the action is not
        explicitly listed, it *MUST* fail regardless of Operator
        instruction.

     Boundary check (5):
        Enforces the User's hard limits, which survive any subsequent
        Operator instruction or override.

     Execution hash check (6):
        Computes the static capability signature of the actual program the
        agent has been given and compares it to the hash committed in the
        "executes" scope field.  Substituting a different program after
        the receipt is signed is detectable without runtime introspection.

     Instruction hash check (7):
        Compares the SHA-256 hash of the Operator's current instructions
        against the hash committed at delegation time.  If the Operator
        has changed its instructions since the receipt was issued, the
        mismatch is immediately detectable from the log entry, with no
        reliance on the Operator's own account.

     Tool output hash check (9):
        When the receipt contains a toolOutputHash field, the verifier
        computes the SHA-256 hash of the tool output that triggered the
        action and compares it to the committed value.  A mismatch
        indicates that the tool output was altered between delegation time
        and execution time.  Returns TOOL_OUTPUT_TAMPERED on failure.

     Instruction provenance check (10):
        When the receipt contains a trustedSources field, the verifier
        inspects the instructionSource field of the action.  If the source



  Nelson                  Expires 20 November 2026               [Page 14]


  Internet-Draft          Agent Delegation Receipts               May 2026


        is not in the trustedSources list, the action is denied.  This
        check is the primary defense against prompt injection attacks in
        which a poisoned document or untrusted tool output manipulates the
        agent into requesting an in-scope action for malicious purposes.
        Returns UNTRUSTED_INSTRUCTION_SOURCE on failure.

  6.3.  Failure Handling

     When any verification check fails, the Agent *MUST*:

     1.  Abort the action immediately.  No partial execution is permitted.

     2.  Record the failure in the action log, including the specific
         check that failed and the reason string.

     3.  Not fall back to Operator instruction.  A failed verification
         check *MUST NOT* be overridden by any runtime parameter,
         environment variable, or Operator-supplied flag.

     4.  Surface the failure to the User when the failing check is one of:
         revocation (1), instruction hash mismatch (7), or execution hash
         mismatch (6).  These failures indicate possible Operator
         deviation from the committed authorization and *SHOULD* be
         escalated.

     When a scope check (4) fails because an action is outside the current
     receipt's scope, the Agent *MAY* pause execution and request a Micro-
     Receipt from the User covering the specific action.  The Micro-
     Receipt *MUST* reference the parent receipt hash and *MUST* be
     anchored to the append-only log before the action is attempted.

     Implementations *MUST* always make a safe fallback action available
     when execution is blocked.  The designated safe fallback action is
     NO_OP_WITH_LOG: it performs no operation and writes a full audit log
     entry containing the denial reason, a snapshot of the session state
     at the time of denial, and a timestamp.  NO_OP_WITH_LOG is
     unconditionally available regardless of verification state or session
     trust level.  Every DENY decision returned by the gate *MUST* include
     a safeAlternative field set to NO_OP_WITH_LOG, providing callers with
     a guaranteed safe path that preserves the audit record without
     executing any agent action.

  6.4.  Verification Algorithm

     The following pseudocode specifies the complete seven-check
     verification algorithm as a formal function:





  Nelson                  Expires 20 November 2026               [Page 15]


  Internet-Draft          Agent Delegation Receipts               May 2026


     FUNCTION VerifyReceipt(receipt, action, operatorInstructions,
                            sessionState):

       INPUT:
         receipt             : signed delegation receipt object
         action              : the agent action being requested
         operatorInstructions: current operator instruction string
         sessionState        : current session state object (optional)

       OUTPUT:
         PERMIT or DENY with reason code

       CHECK 1: Signature Verification
         IF NOT VerifySignature(receipt.signature,
                                receipt.canonicalPayload,
                                receipt.publicKey) THEN
           RETURN DENY, "INVALID_SIGNATURE"

       CHECK 2: Revocation Status
         IF revocationRegistry.isRevoked(receipt.receiptId) THEN
           RETURN DENY, "RECEIPT_REVOKED"

       CHECK 3: Time Window
         IF receipt.expiresAt < NOW() THEN
           RETURN DENY, "RECEIPT_EXPIRED"
         IF receipt.createdAt > NOW() THEN
           RETURN DENY, "RECEIPT_NOT_YET_VALID"

       CHECK 4: Scope Validation
         IF action.operation NOT IN receipt.scope.allowedActions THEN
           RETURN DENY, "ACTION_NOT_IN_SCOPE"
         IF action.operation IN receipt.scope.deniedActions THEN
           RETURN DENY, "ACTION_EXPLICITLY_DENIED"

       CHECK 5: Operator Instruction Hash
         currentHash = SHA-256(canonicalize(operatorInstructions))
         IF currentHash != receipt.operatorInstructionsHash THEN
           RETURN DENY, "OPERATOR_INSTRUCTIONS_MISMATCH"

       CHECK 6: Model State Attestation
         IF receipt.modelCommitment IS PRESENT THEN
           currentMeasurement = measureModelState()
           IF currentMeasurement != receipt.modelCommitment THEN
             IF modelSubstitutionDetected(receipt,
                                          currentMeasurement) THEN
               RETURN DENY, "MALICIOUS_MODEL_SUBSTITUTION"
             ELSE
               RETURN DENY, "PROVIDER_UPDATE_REQUIRES_REAUTH"



  Nelson                  Expires 20 November 2026               [Page 16]


  Internet-Draft          Agent Delegation Receipts               May 2026


       CHECK 7: Session Risk Evaluation (if sessionState present)
         IF sessionState IS PRESENT THEN
           riskResult = evaluateSessionRisk(action, sessionState)
           IF riskResult.decision == "BLOCK" THEN
             RETURN DENY, "SESSION_RISK_THRESHOLD_EXCEEDED"
           IF riskResult.decision == "REQUIRE_APPROVAL" THEN
             RETURN REQUIRE_APPROVAL, riskResult.reasons

       CHECK 8: Tool Schema Integrity (if toolSchemaHash present)
         IF receipt.toolSchemaHash IS PRESENT THEN
           currentHash = SHA-256(canonicalize(currentToolSchema))
           IF currentHash != receipt.toolSchemaHash THEN
             RETURN DENY, "TOOL_SCHEMA_DRIFT"

       CHECK 9: Tool Output Hash Binding
         IF receipt.toolOutputHash IS PRESENT AND
            action.toolOutput IS PRESENT THEN
           currentHash = "sha256:" || SHA-256(action.toolOutput)
           IF currentHash != receipt.toolOutputHash THEN
             RETURN DENY, "TOOL_OUTPUT_TAMPERED"

       CHECK 10: Instruction Provenance
         IF receipt.trustedSources IS PRESENT AND
            action.instructionSource IS PRESENT THEN
           IF action.instructionSource NOT IN receipt.trustedSources THEN
             RETURN DENY, "UNTRUSTED_INSTRUCTION_SOURCE"

       RETURN PERMIT

     END FUNCTION

  6.5.  Denial Reason Codes

     When VerifyReceipt returns DENY, implementations *MUST* include one
     of the following reason codes in the structured failure response:

     +=================================+================================+
     | Reason Code                     | Description                    |
     +=================================+================================+
     | INVALID_SIGNATURE               | Receipt signature verification |
     |                                 | failed                         |
     +---------------------------------+--------------------------------+
     | RECEIPT_REVOKED                 | Receipt has been explicitly    |
     |                                 | revoked                        |
     +---------------------------------+--------------------------------+
     | RECEIPT_EXPIRED                 | Receipt time window has        |
     |                                 | elapsed                        |
     +---------------------------------+--------------------------------+



  Nelson                  Expires 20 November 2026               [Page 17]


  Internet-Draft          Agent Delegation Receipts               May 2026


     | RECEIPT_NOT_YET_VALID           | Receipt creation time is in    |
     |                                 | the future                     |
     +---------------------------------+--------------------------------+
     | ACTION_NOT_IN_SCOPE             | Requested action not in allow  |
     |                                 | list                           |
     +---------------------------------+--------------------------------+
     | ACTION_EXPLICITLY_DENIED        | Requested action in deny list  |
     +---------------------------------+--------------------------------+
     | OPERATOR_INSTRUCTIONS_MISMATCH  | Operator instructions hash     |
     |                                 | does not match receipt         |
     |                                 | commitment                     |
     +---------------------------------+--------------------------------+
     | MALICIOUS_MODEL_SUBSTITUTION    | Model identity changed after   |
     |                                 | receipt was signed             |
     +---------------------------------+--------------------------------+
     | PROVIDER_UPDATE_REQUIRES_REAUTH | Model version updated by       |
     |                                 | provider; reauthorization      |
     |                                 | required                       |
     +---------------------------------+--------------------------------+
     | SESSION_RISK_THRESHOLD_EXCEEDED | Session trust score below      |
     |                                 | block threshold                |
     +---------------------------------+--------------------------------+
     | REPLAY_DETECTED                 | Receipt presented more than    |
     |                                 | once concurrently              |
     +---------------------------------+--------------------------------+
     | TOOL_SCHEMA_DRIFT               | Tool schema hash at execution  |
     |                                 | time does not match hash       |
     |                                 | committed at receipt issuance  |
     |                                 | time.  Tool specification has  |
     |                                 | changed since authorization    |
     |                                 | was granted.                   |
     +---------------------------------+--------------------------------+
     | TOOL_OUTPUT_TAMPERED            | The hash of the tool output    |
     |                                 | that triggered the action does |
     |                                 | not match the hash committed   |
     |                                 | in the receipt at delegation   |
     |                                 | time.  The tool output may     |
     |                                 | have been modified between     |
     |                                 | delegation and execution.      |
     +---------------------------------+--------------------------------+
     | UNTRUSTED_INSTRUCTION_SOURCE    | The instruction that triggered |
     |                                 | the action originated from a   |
     |                                 | source not listed in the       |
     |                                 | receipt's trustedSources       |
     |                                 | field.  The instruction source |
     |                                 | may have been manipulated by a |
     |                                 | prompt injection attack        |
     |                                 | delivered through an untrusted |



  Nelson                  Expires 20 November 2026               [Page 18]


  Internet-Draft          Agent Delegation Receipts               May 2026


     |                                 | input channel such as a        |
     |                                 | retrieved document or external |
     |                                 | tool output.                   |
     +---------------------------------+--------------------------------+
     | TAU_SESSION_EXHAUSTED           | Session anomaly capacity       |
     |                                 | exhausted: tauSession has      |
     |                                 | fallen to or below tauMin.     |
     |                                 | Execution blocked regardless   |
     |                                 | of trustScore.  Not resettable |
     |                                 | by reauthorization.            |
     +---------------------------------+--------------------------------+

                                   Table 1

  7.  Model State Attestation

  7.1.  Commitment Binding

     A valid Delegation Receipt proves that a User authorized an Agent to
     act within defined scope.  It does not prove that the model executing
     the receipt is the model the User authorized.  An Operator could
     silently substitute a fine-tuned model variant after the receipt is
     signed; all verification checks would pass because the receipt itself
     is genuine.

     Model State Attestation closes this gap with a two-phase
     cryptographic protocol that binds the receipt to a measurement of
     model state at both delegation time and execution time.

     *Phase 1 -- Commitment (at delegation time):*

     The Operator commits to the exact model state that will execute.  The
     commitment is a SHA-256 measurement of five components concatenated
     in canonical order:

     modelMeasurement = SHA-256(
       normalize(modelId)       ||
       normalize(modelVersion)  ||
       systemPromptHash         ||
       runtimeConfigHash        ||
       receiptHash
     )

     Including receiptHash as the fifth component binds the model
     measurement to the specific delegation.  The same model with the same
     system prompt but a different receipt produces a different
     measurement.  A commitment *MUST NOT* be reused across delegations.




  Nelson                  Expires 20 November 2026               [Page 19]


  Internet-Draft          Agent Delegation Receipts               May 2026


     The commitment is signed by the Operator's ECDSA P-256 key and
     attested by the TEE runtime, producing a sealed artifact that
     includes modelId, modelVersion, systemPromptHash, runtimeConfigHash,
     committedAt, the Operator's signature, and a TEE attestation quote.

     *Phase 2 -- Verification (at execution time):*

     Immediately before the agent function executes, the current model
     state is measured using the same five-component computation.  The
     resulting measurement *MUST* equal the committed measurement.  If the
     two measurements differ for any reason, execution *MUST* be blocked
     with a ModelDriftDetected error identifying exactly which components
     changed.

     With Model State Attestation in place, the complete verifiable chain
     of accountability is:

        +---------------------------+
        |    Delegation Receipt     |  <-- User signed
        +---------------------------+
                   |
        +---------------------------+
        |  Model State Commitment   |  <-- Hardware measured
        +---------------------------+
                   |
        +---------------------------+
        |  Execution Attestation    |  <-- TEE verified
        +---------------------------+
                   |
        +---------------------------+
        |     Action Log Entry      |  <-- Chain linked
        +---------------------------+
                   |
        +---------------------------+
        |    Data Flow Receipt      |  <-- Output policy
        +---------------------------+

     An auditor presented with a chain proof can verify each layer
     independently and confirm that a logged action was taken by the model
     the User authorized, acting within the defined scope, under
     conditions unaltered since authorization was granted.










  Nelson                  Expires 20 November 2026               [Page 20]


  Internet-Draft          Agent Delegation Receipts               May 2026


  7.2.  Provider Update Handling

     Hosted model providers may silently update the underlying model
     behind a versioned alias without Operator action.  Treating this
     identically to a deliberate substitution attack is too blunt: it
     would block legitimate executions whenever a provider retires a model
     version, forcing operators to recommit on every provider maintenance
     cycle.

     Model State Attestation distinguishes two categories of measurement
     mismatch:

     MaliciousSubstitution:
        The Operator explicitly changed the model identifier, system
        prompt, or runtime configuration after the commitment was signed.
        This *MUST* always be a hard block.  Indicators are any of:

        *  currentModelId != committedModelId, OR

        *  currentSystemPromptHash != committedSystemPromptHash, OR

        *  currentRuntimeConfigHash != committedRuntimeConfigHash

     ProviderUpdate:
        The model version changed, but the Operator's configured modelId
        is unchanged.  The provider updated the model behind a stable
        alias.  Indicators are all of:

        *  currentModelId == committedModelId, AND

        *  currentModelVersion != committedModelVersion

     Operators declare how provider updates are handled at construction
     time via the providerUpdatePolicy field:

     "block":
        Treat provider updates identically to MaliciousSubstitution.  Any
        version change *MUST* block execution immediately.  *RECOMMENDED*
        when strict model pinning is required.

     "reauthorize" (default):
        When a provider update is detected, return { allowed: false,
        reason: "PROVIDER_UPDATE_DETECTED", requiresReauthorization: true
        } and block all subsequent executions under this attestation
        instance until the User explicitly acknowledges the change.






  Nelson                  Expires 20 November 2026               [Page 21]


  Internet-Draft          Agent Delegation Receipts               May 2026


     The "reauthorize" policy preserves a recovery path.  The provider
     update is flagged and the system halts, but the cause is identified
     as a non-malicious provider action.  A human *MUST* explicitly invoke
     reauthorize() with userApproval: true before execution resumes.  This
     is an explicit human-in-the-loop checkpoint; the system *MUST NOT*
     silently resume execution after a provider update.

  7.3.  Malicious Substitution Detection

     The per-component comparison in the Phase 2 verification identifies
     exactly which aspects of model state changed: model identity,
     version, system prompt, or runtime configuration.  This enables
     forensic analysis of how an unauthorized execution occurred.

     The full SHA-256 measurement comparison is performed in addition to
     per-component comparison.  This is redundant given the component
     checks but provides a cryptographic guarantee: even if the component
     comparison logic contains a bug, the measurement comparison will
     detect any state change.

     Model State Attestation proves:

     1.  Model identity at commitment time.  The Operator committed to a
         specific (modelId, modelVersion, systemPromptHash,
         runtimeConfigHash) tuple before execution began.  The ECDSA
         signature and TEE attestation prove this commitment was made
         inside a trusted environment and has not been altered.

     2.  Model state at execution time.  The TEE verification attestation
         proves the measurement was recomputed inside the enclave
         immediately before execution, and that the recomputed measurement
         matched the committed measurement.

     3.  Delegation binding.  The receiptHash component ensures the
         commitment is irrevocably bound to the specific delegation.  A
         commitment made under receipt A *MUST NOT* be presented as valid
         under receipt B.

     Model State Attestation does not prove that the committed model is
     safe, aligned, or correctly configured.  It does not inspect the
     content of the system prompt.  In simulation mode (the default for
     testing), attestations are signed with a software ECDSA key rather
     than produced by real TEE hardware.  Production deployments *SHOULD*
     use Intel SGX, Intel TDX, or ARM TrustZone attestation.







  Nelson                  Expires 20 November 2026               [Page 22]


  Internet-Draft          Agent Delegation Receipts               May 2026


  8.  Scope Discovery Protocol

     The Scope Discovery Protocol addresses the upstream authorization
     gap: a User cannot correctly define agent scope before observing
     agent behavior.  Asking users to define scope upfront produces one of
     two failure modes:

     Over-authorization:
        The User grants broad permissions to avoid blocking the agent.
        The agent is then authorized to perform operations the User never
        intended to permit.

     Under-authorization:
        The User grants narrow permissions and the agent fails mid-task,
        requiring repeated round-trips to expand scope.  Users respond by
        granting progressively wider permissions under frustration.

     Neither outcome produces a receipt that reflects the User's actual
     intent.  The scope field becomes a legal fiction rather than a
     genuine authorization boundary.

     The Scope Discovery Protocol inverts the authorization sequence.
     Instead of asking Users to define scope before running the agent, it
     runs the agent first in a sandboxed simulation and uses the observed
     behavior to derive the scope definition.

     The protocol proceeds in four stages:

     Stage 1 -- Sandboxed observation:
        The agent function is wrapped with transparent proxies for every
        supported resource type (email, calendar, payment, files,
        database, network).  Every operation call is intercepted,
        timestamped, and appended to an observation log.  Mock data
        matching the expected structure is returned so the agent proceeds
        normally.  No real I/O occurs; no side effects are produced.

     Stage 2 -- Scope generation:
        The observation log is analyzed to produce:

        a.  A draftScope with an allowedActions list (de-duplicated
            observed operations) and conservative deniedActions defaults
            for delete, execute, and payment operations.

        b.  A plainSummary in non-technical language suitable for end-user
            review.






  Nelson                  Expires 20 November 2026               [Page 23]


  Internet-Draft          Agent Delegation Receipts               May 2026


        c.  riskFlags for: delete operations, execute operations, payment
            operations, external send and write operations, and any
            operation called more than 50 times in the observation
            session.

        d.  suggestedDenials for dangerous operations the agent did not
            use, with per-entry explanations.

     Stage 3 -- Plain language review:
        The Operator or User reviews the plain summary, risk flags, and
        suggested denials before approving.  An approve() call accepts
        "remove" and "add" arrays for surgical modification of the draft
        scope.  This is the moment of genuine human authorization,
        grounded in observed behavior rather than speculation.

     Stage 4 -- Cryptographic commitment:
        The approved scope is embedded into a Delegation Receipt using the
        standard signing procedure (Section 4.3).  The receipt includes a
        scopeSchema field with the structured allowedActions and
        deniedActions lists, and a discoveryMetadata field recording
        observation count, any timeout abort, and the risk flags at
        generation time.

     The receipt produced by Scope Discovery is structurally identical to
     one produced by direct issuance.  It carries all standard fields and
     *MUST* be verifiable by the standard Verify procedure (Section 6.1)
     without modification.

     The critical property of observation-based scope generation is
     grounding: every entry in allowedActions corresponds to an operation
     the agent actually performed during a representative run.  This is a
     structural record of what the agent did, not a user estimate of what
     it might need.

     Grounding has three practical consequences:

     Precision:
        The allowedActions list contains exactly the resource/ operation
        pairs observed.  An agent that reads email but never writes it
        receives a receipt authorizing read on email, not write.

     Defensibility:
        The discoveryMetadata.observationCount and riskFlags fields
        provide evidence that scope was derived from observation.  The
        audit trail runs from observation to draft to approval to receipt.






  Nelson                  Expires 20 November 2026               [Page 24]


  Internet-Draft          Agent Delegation Receipts               May 2026


     Ratcheting:
        Each time the agent's behavior changes, a new observation session
        produces a new draft.  If the agent begins calling a new operation
        class in a new version, that operation surfaces in the risk flags
        before any receipt is issued for the updated agent.  Drift in
        agent behavior is detectable before it is authorized.

     For operators who trust their agent's observed behavior and do not
     require manual review, a guided mode provides a single-call end-to-
     end flow that runs observe, generate, approve, and finalize
     automatically.  The returned riskFlags allow operators to inspect
     what was flagged even when they choose not to gate on it.

  9.  Session State and Adaptive Authorization

     A Delegation Receipt is a static artifact.  It answers one question
     at one moment in time: did this User authorize this Agent to perform
     this class of actions?  It cannot answer whether a specific action is
     safe to take right now, given everything that has happened in this
     session.

     Static receipts have three blind spots for long-running sessions:

     The drift problem:
        A receipt issued for "manage my calendar" remains technically
        valid after the agent has sent 400 emails and received a prompt
        injection payload.  The receipt scope string has not changed and
        cannot reflect runtime events.

     The escalation problem:
        A receipt with a generous scope becomes progressively more
        dangerous as the agent accumulates sensitive data and accesses
        external services.  Risk is not static -- it depends on what came
        before.

     The injection problem:
        A receipt cannot detect that the agent's input pipeline has been
        compromised mid-session by a prompt injection attack embedded in
        retrieved content.  The receipt was signed before the session
        began; it has no knowledge of runtime inputs.

     SessionState closes these gaps by maintaining a live, stateful view
     of each session that evolves with every action.  It tracks a
     trustScore for each session, initialized at 100 and bounded between 0
     and 100.

     Three formally distinct quantities govern session risk evaluation.
     Implementations *MUST* maintain all three:



  Nelson                  Expires 20 November 2026               [Page 25]


  Internet-Draft          Agent Delegation Receipts               May 2026


     trustScore:
        A Lyapunov-style bounded recoverable budget.  Initialized at 100,
        bounded in [0, 100].  Decremented by anomaly.severity *
        trustDecayRate on each anomaly event; incremented by
        trustRecoveryRate on each clean action.  The recovery property is
        definitional: trustScore is not monotone and is not a load
        functional.  It models a resilience budget that is restored by
        sustained clean behavior.

     cumulativeAnomalyMass:
        A monotone, non-decreasing quantity tracking the total structural
        burden accumulated over the session lifetime.
        cumulativeAnomalyMass has two components:

        Active (anomaly-driven):
           Incremented by anomaly.severity on each detected anomaly event.
           Records the discrete burden contributed by individual anomaly
           detections.

        Passive (time-driven):
           Incremented by passivePressureRate * elapsedSeconds on each
           call to the session risk evaluator, where elapsedSeconds is the
           time elapsed since the previous evaluation.  The default
           passivePressureRate is 0.001 per second, yielding 3.6 units of
           passive burden per session- hour and 36 units per ten session-
           hours, even with zero detected anomalies.

        cumulativeAnomalyMass is never decremented.  It provides a
        permanent session-level record of total anomaly exposure that is
        not erased by subsequent clean behavior and is available for post-
        session forensic analysis independently of the final trustScore
        value.

     tauSession:
        A strictly decreasing capacity gate derived from
        cumulativeAnomalyMass:

           tauSession = sessionCapacity - cumulativeAnomalyMass

        Initialized to sessionCapacity (default: 100).  Never recovered.
        When tauSession <= tauMin (default: 10), the gate condition fails
        and execution *MUST NOT* proceed regardless of trustScore.  The
        gate condition is checked before all trustScore-derived checks in
        dynamic_admissible:

           if tauSession <= tauMin: DENY TAU_SESSION_EXHAUSTED





  Nelson                  Expires 20 November 2026               [Page 26]


  Internet-Draft          Agent Delegation Receipts               May 2026


        tauSession provides a hard lifetime cap on cumulative anomaly
        exposure that is not resettable by reauthorization.  Once a
        session's anomaly capacity is exhausted, the session is
        permanently closed to further execution.

     Trust decays when anomalies are detected:

     trustScore -= anomaly.severity * trustDecayRate

     Anomaly severity levels are defined as:

     Prompt injection detected        : severity 5
     Sensitive data in external dest. : severity 4
     Frequency spike                  : severity 3
     Scope edge usage                 : severity 2
     First-time action                : severity 1

     Trust recovers slightly on each clean action:

     trustScore += trustRecoveryRate  (default: 0.01)

     Session status is driven by trust score thresholds:

     trustScore >= 30 : ACTIVE    -- normal operation
     trustScore <  30 : DEGRADED  -- risk scores amplified
     trustScore <  10 : SUSPENDED -- all actions blocked

     The DEGRADED state does not block operations directly.  Instead, it
     causes the risk scorer to apply a multiplier to every score, making
     previously marginal decisions tip into REQUIRE_APPROVAL or BLOCK
     territory.

     Before each action, every payload is classified into one of four
     sensitivity levels:

     RESTRICTED   : SSN, credit card, medical identifiers, API keys
     CONFIDENTIAL : Internal email addresses, system prompts,
                    database schemas, config files
     INTERNAL     : Company domain references, internal project
                    names, user IDs
     PUBLIC       : Everything else

     Each level modifies the block and approval thresholds:

     RESTRICTED   : Block threshold drops to at most 60
     CONFIDENTIAL : Approval threshold drops to at most 40
     INTERNAL     : No change
     PUBLIC       : All thresholds relax by +10



  Nelson                  Expires 20 November 2026               [Page 27]


  Internet-Draft          Agent Delegation Receipts               May 2026


     The complete decision engine evaluates five risk checks and maps the
     final score to one of three outcomes:

     Check 1 -- Sensitive data scan:
       SSN pattern              +35
       Credit card pattern      +35
       API key pattern          +30
       High-entropy string      +20
       Prompt injection pattern +40
       Password keyword         +25

     Check 2 -- External exfiltration:
       External domain + sensitive data  +30
       First-time external domain        +15

     Check 3 -- Frequency anomaly:
       Same action type >10x in 60s  +25
       >50 total actions in session  +15

     Check 4 -- Scope edge usage:
       New permission class   +10
       At scope boundary      +10

     Check 5 -- Trust multiplier:
       finalScore = rawScore * (1 + (100 - trust) / 100)

     if session.status == SUSPENDED       --> BLOCK
     if finalScore >= blockThreshold      --> BLOCK
     if finalScore >= approvalThreshold   --> REQUIRE_APPROVAL
     else                                 --> ALLOW

     The checks are deterministic and ordered.  The same action, payload,
     and session state always produce the same score.  Every BLOCK or
     REQUIRE_APPROVAL decision *SHOULD* be accompanied by a structured
     reason object identifying which specific checks contributed to the
     score.

     SessionState *MUST* be integrated with the PreExecutionVerifier as a
     final check, running after all static receipt checks pass (see
     Section 6.1).  An action that passes all cryptographic checks but
     produces a BLOCK outcome from session risk evaluation *MUST NOT*
     execute.

     The architectural insight is that authorization is not binary.  A
     valid receipt is a necessary condition for execution, not a
     sufficient one.  Real-world safety requires a live, stateful layer
     that observes behavior and adapts its decisions based on the full
     session context.



  Nelson                  Expires 20 November 2026               [Page 28]


  Internet-Draft          Agent Delegation Receipts               May 2026


     The complete executability predicate is formally:

        executable(a, R, session, t) =
          Verify(R, a) AND dynamic_admissible(session, a, t)

     where Verify(R, a) establishes static receipt admissibility (the
     complete set of pre(R) and admissible(a, R) checks defined in
     Section 11) and dynamic_admissible(session, a, t) establishes runtime
     session admissibility.  dynamic_admissible evaluates checks in the
     following order: (1) tauSession gate -- if session.tauSession <=
     tauMin, DENY TAU_SESSION_EXHAUSTED immediately; (2) trust score
     threshold check; (3) sensitivity classification; (4) risk score
     evaluation at time t.  Both the tauSession gate and the trustScore
     threshold must pass independently.  Execution requires both
     predicates to hold simultaneously.  A receipt that passes Verify is a
     necessary but not sufficient condition for execution.

  10.  Multi-Agent Delegation Chains

     When a delegated Agent needs to hand off a subtask to another Agent,
     the chain of authority *MUST* remain auditable and bounded.  DRP
     enforces three invariants at every delegation hop.

  10.1.  Scope Attenuation

     Each delegation step *MUST* produce a strict proper subset of the
     parent's authorized scope.  Specifically:

     1.  Every action the child Agent is permitted *MUST* already appear
         in the parent's allowedActions list.  An Agent *MUST NOT* grant
         permissions it was not itself given.

     2.  The child *MUST* have strictly fewer permitted actions than the
         parent.  Equal scope *MUST* be rejected.

     3.  Every action explicitly denied by the parent in deniedActions
         *MUST* be carried forward to the child.  A child *MAY* add new
         denied actions but *MUST NOT* remove any denial that the parent
         established.

     The receipt chain *MUST* track delegation depth.  The root receipt,
     signed directly by the User, is at depth 0.  Each delegation
     increments depth by 1.  When a delegation would produce a receipt at
     depth >= maxDepth, the implementation *MUST* raise a MaxDepthExceeded
     error before creating the receipt.  The default maxDepth is 3,
     meaning at most three levels of agent-to-agent hand-off before the
     chain *MUST* be re-anchored at the User level.




  Nelson                  Expires 20 November 2026               [Page 29]


  Internet-Draft          Agent Delegation Receipts               May 2026


     The root receipt *MUST* carry a valid ECDSA P-256 signature from the
     User's key.  If the root could be generated by an Agent or Operator
     without User involvement, the entire chain could be bootstrapped
     unilaterally, defeating the protocol.  Any downstream Agent that
     wants to prove its authority can walk the chain to the root and
     demonstrate a continuous path of scope-narrowing receipts.

  10.2.  Cascade Revocation

     Revocation of a receipt in a multi-agent chain *MAY* or may not
     cascade to child receipts, depending on the revocation call.

     When cascadeToChildren is true:
        A breadth-first traversal of all descendants *MUST* be performed
        and each descendant marked revoked.  The cascade *SHOULD* be
        anchored to the append-only log before agents are notified, to
        prevent a race condition where a child Agent completes an action
        between the parent revocation and cascade propagation.

     When cascadeToChildren is false:
        Only the named receipt is invalidated.  Its children remain valid
        until explicitly revoked.  This allows surgical removal of one
        Agent from a chain without disrupting sibling branches.

     Cascade revocation entries *MUST* be signed by the User's private key
     and anchored to the append-only log with the same requirements as the
     original revocation procedure (see Section 11.1).

  11.  Security Considerations

  11.1.  Threat Model

     DRP considers the following adversaries and mitigations:

     Compromised Operator:
        An attacker who gains control of the Operator's systems can alter
        the instructions delivered to the Agent.  Under DRP, any
        instruction diverging from the hash committed in the Delegation
        Receipt is immediately detectable at step (7) of Verify.  The
        attacker cannot issue instructions that pass hash verification
        without the User's private key.










  Nelson                  Expires 20 November 2026               [Page 30]


  Internet-Draft          Agent Delegation Receipts               May 2026


     Malicious Operator:
        An Operator who intentionally instructs the Agent to exceed the
        User's authorization -- under commercial pressure, legal
        compulsion, or bad faith -- produces a detectable instruction hash
        mismatch.  The discrepancy between committed and actual
        instructions is an auditable fact in the append-only log.  The
        Operator cannot alter the log entry and cannot alter the signed
        receipt.

     Log Integrity:
        The security of the protocol depends on the tamper-evidence of the
        append-only log.  Implementations *SHOULD* use decentralized log
        implementations following the Certificate Transparency model that
        do not depend on a single operator for integrity.  Log fork
        detection follows established approaches from CT ecosystems
        [RFC6962].

     Key Compromise:
        If the User's signing key is compromised, an attacker can issue
        Delegation Receipts in the User's name.  Hardware key custody
        using a FIDO2 authenticator [FIDO2] significantly reduces this
        risk by making key extraction technically infeasible on modern
        devices with secure enclaves.

     Revocation:
        When a User wishes to revoke a Delegation Receipt, they *MUST*:

        1.  Construct a revocation record containing: the SHA-256 hash of
            the original receipt, a reason string, and a revocation
            timestamp.

        2.  Sign the revocation record with the same private key used to
            sign the original receipt.

        3.  Publish the signed revocation record to the append-only log,
            producing an immutable log anchor.

        The log anchor establishes the authoritative revocation time.
        Actions taken before this timestamp under the original receipt
        remain valid.  Actions attempted after this timestamp *MUST* fail.

        Verification *MUST* check revocation before any other check
        (Section 6.1, step 1).  Because the revocation record is itself
        signed by the User and anchored to the log, it carries the same
        evidentiary weight as the original receipt.  Revocation is
        auditable, tamper-evident, and does not depend on the Operator to
        propagate or acknowledge it.




  Nelson                  Expires 20 November 2026               [Page 31]


  Internet-Draft          Agent Delegation Receipts               May 2026


     Model Substitution:
        An Operator could silently substitute a fine-tuned model variant
        after receipt issuance.  Model State Attestation (Section 7)
        closes this gap by binding a cryptographic measurement of the
        model state to the receipt at delegation time and re-verifying
        inside a TEE at execution time.

     Prompt Injection:
        A signed Delegation Receipt enforces what actions are permitted
        but does not by itself verify that the instruction to take a
        permitted action originated from a trusted source.  A prompt
        injection attack may manipulate an agent into requesting an in-
        scope action for malicious purposes -- for example, a receipt
        permits send_email but a poisoned retrieved document instructs the
        agent to send to an attacker-controlled address.  DRP addresses
        this vector through instruction provenance checking (step 10 of
        Verify): the receipt *MAY* include a trustedSources field listing
        the instruction sources -- such as user, system_prompt, or
        verified_tool -- that are permitted to influence agent behavior.
        When present, the verifier *MUST* reject any action whose
        instructionSource is not in the list, returning
        UNTRUSTED_INSTRUCTION_SOURCE.  This gives the User cryptographic
        control over which input channels can drive agent behavior,
        independent of the content of those inputs.

     Micro-Receipt Fatigue:
        A malicious Operator could structure a workflow to generate many
        micro-receipt requests in rapid succession, inducing the User to
        approve actions they do not meaningfully review.  This is
        analogous to notification fatigue attacks against MFA prompts.
        The protocol makes every approval a signed, auditable artifact.
        Rate-limiting and UI affordances are the primary mitigation;
        protocol implementations *SHOULD* enforce a minimum inter-request
        interval for micro-receipt prompts.

     Non-Repudiation:
        Let R be a Delegation Receipt with content C, user signature
        sigma, and log anchor L.  Under the ECDSA P-256 EUF-CMA
        unforgeability assumption, no party without the User's private key
        can produce a valid sigma for any C.  Therefore, the existence of
        a valid receipt on the log is non-repudiable evidence that the
        holder of the private key authorized the content of C at time L.

     Authorization Persistence:
        Authorization at time t requires both (a) a valid signed receipt
        anchored at time L and (b) the absence of any valid revocation
        record for that receipt anchored at time L' where L' < t.  The
        validity of sigma (established under Non-Repudiation) is a



  Nelson                  Expires 20 November 2026               [Page 32]


  Internet-Draft          Agent Delegation Receipts               May 2026


        necessary but not sufficient condition for continued
        authorization: it proves the receipt was genuinely issued but does
        not establish that it remained unrevoked through time t.  Non-
        repudiation and authorization persistence are formally distinct
        results.  The protocol proves both: Non-Repudiation via the EUF-
        CMA unforgeability property of ECDSA P-256, and Authorization
        Persistence via the tamper-evidence property of the append-only
        log applied to both receipt anchors and revocation record anchors.

     Soundness:
        Verification decomposes into two independent predicates:

           Verify(R, a) = pre(R) AND admissible(a, R)

        pre(R) holds if and only if: (i) R has not been revoked
        (revocation check); (ii) the signature sigma over the canonical
        body of R is valid under the User's public key (signature
        verification); and (iii) the log timestamp falls within
        R.timeWindow (time window validity).

        admissible(a, R) holds if and only if: (iv) a appears in the scope
        allowlist in C (scope check); (v) a does not violate any
        prohibition in C (boundary check); (vi) if a is an execution
        action, Hash(SafescriptDAG(program)) equals the hash committed in
        C (execution hash check); (vii) the SHA-256 hash of the Operator's
        current instructions equals R.instructionHash (instruction hash
        check); (viii) if R.toolSchemaHash is present, the SHA-256 hash of
        the current tool schema equals R.toolSchemaHash (tool schema hash
        check); (ix) if R.toolOutputHash is present and action.toolOutput
        is present, the SHA-256 hash of action.toolOutput equals
        R.toolOutputHash (tool output hash check); and (x) if
        R.trustedSources is present and action.instructionSource is
        present, action.instructionSource appears in R.trustedSources
        (instruction provenance check).

        For any action a, Verify(R, a) = true if and only if all of
        (i)-(x) hold simultaneously.  Any deviation in any component
        causes Verify to return false.  The Operator cannot alter C
        without invalidating sigma; the Operator cannot alter L by the
        tamper-evidence property of the append-only log.  The executable()
        predicate in Section 9 further establishes that Verify(R, a) =
        true is a necessary but not sufficient condition for execution.









  Nelson                  Expires 20 November 2026               [Page 33]


  Internet-Draft          Agent Delegation Receipts               May 2026


        dynamic_admissible now requires both (a) trustScore above the
        block threshold and (b) tauSession above tauMin.  Either condition
        failing independently is sufficient to produce a DENY outcome.
        The tauSession gate is evaluated first and is not resettable by
        reauthorization: once a session's anomaly capacity is exhausted,
        no subsequent clean actions or reauthorization calls can restore
        admissibility for that session.

  11.2.  Semantic Gap

     The protocol does not eliminate the semantic gap between authorized
     scope and authorized intent.  A User who authorizes "write to
     calendar" may not intend to authorize deletion of all existing
     events.  The Scope Discovery Protocol (Section 8) narrows this gap by
     grounding scope definitions in observed agent behavior rather than
     user speculation.

     The "executes" scope class narrows the gap further for code execution
     by requiring the SHA-256 hash of the program's static capability DAG
     rather than a program name or URI.  A program identified by name or
     URI can be silently replaced; a program identified by its capability
     signature *MUST* have the same capability set as the authorized
     version.  Any capability addition or removal changes the signature.

     Natural language *MUST NOT* appear in any scope field.  Scope entries
     *MUST* be structured resource:operation pairs.  This restriction
     exists because natural language scope definitions are ambiguous,
     subject to interpretation, and cannot be used for deterministic
     validation.  A scope entry of "manage email" does not
     deterministically resolve to a set of permitted or denied operations.

     Cryptographic primitive upgrade path: DRP uses SHA-256 throughout for
     receipt ID computation, instruction hash commitment, manifest body
     hashing, action log chain linking, and revocation record linking.
     The version field in the receipt structure provides a migration path
     to SHA-3-256 (FIPS 202) or BLAKE3 in a future protocol version.  Both
     are drop-in replacements for the SHA-256 role in this protocol.  No
     structural redesign is required for a hash function migration.













  Nelson                  Expires 20 November 2026               [Page 34]


  Internet-Draft          Agent Delegation Receipts               May 2026


     Quantum resistance: ECDSA P-256 is vulnerable to Shor's algorithm on
     a sufficiently capable quantum computer.  The signing layer of the
     protocol is therefore not post-quantum secure under current
     implementations.  The migration path is through the FIDO2/WebAuthn
     credential layer: because all DRP signing is abstracted behind the
     WebAuthn API, a platform-level upgrade to post-quantum FIDO2
     authenticators (e.g., CRYSTALS-Dilithium, FALCON) upgrades the
     protocol's quantum resistance without protocol-layer changes.  The
     append-only log and hash commitment structures are unaffected --
     SHA-256 preimage resistance is not threatened by known quantum
     algorithms.

     For broader AI-specific risk management considerations beyond the
     cryptographic scope of this protocol, see the NIST AI Risk Management
     Framework [NIST-AI-100-1].

  11.3.  TEE Enforcement

     Cryptographic receipt verification alone cannot prevent a compromised
     agent runtime from calling the verifier with a spoofed receipt,
     receiving an "allowed" result, and then ignoring the scope.  A three-
     layer enforcement model addresses this:

     Layer 1 -- Receipt:
        Cryptographic proof of User authorization (what).  The User signs
        a Delegation Receipt specifying scope, boundaries, and Operator
        instructions.  Any tampering is immediately detectable.

     Layer 2 -- TEE:
        Hardware-measured execution environment (where and how).  The
        Agent runs inside an attested enclave whose measurement is bound
        to the receipt via the teeMeasurement.expectedMrenclave field.
        Any substitution of model weights, verifier code, or platform
        produces a different measurement and is detectable before
        execution.

     Layer 3 -- eBPF:
        Kernel-level enforcement.  An eBPF LSM hook validates a signed
        capability token on every relevant syscall (security_file_open,
        security_socket_connect, security_task_execve).  Scope violations
        *MUST* be denied at the kernel level before they reach userspace.

     Without Layer 3, a compromised agent runtime could bypass the
     verifier.  The eBPF LSM runs in kernel space and cannot be disabled
     by userspace code, including a compromised agent runtime.  All three
     layers *MUST* be present for the enforcement model to be complete and
     non-bypassable.




  Nelson                  Expires 20 November 2026               [Page 35]


  Internet-Draft          Agent Delegation Receipts               May 2026


     Intel TDX and AMD SEV-SNP provide encrypted memory pages inaccessible
     to the host OS and hypervisor, hardware-rooted attestation quotes
     signed by the CPU vendor's key, and measured boot that hashes every
     component loaded into the enclave.  DRP binds delegation receipts to
     enclave measurements via:

     mrenclave = SHA-256(
       platform || verifierHash || modelHash
     )

     This value is committed into the receipt's
     teeMeasurement.expectedMrenclave field at delegation time.  At
     execution time, the runtime recomputes mrenclave from its runtime
     parameters and *MUST* reject execution if there is any mismatch.

     The token injection sequence is:

     1.  ConfidentialRuntime.launch() computes mrenclave and verifies the
         receipt measurement.

     2.  PreExecutionVerifier.check() gates execution -- no valid receipt
         means no execution.

     3.  TokenPreparer.prepare() builds a signed capability token binding
         receipt hash, scope hash, and TEE quote hash.

     4.  The token is injected into the agent process context.

     5.  The eBPF LSM validates the token on every relevant syscall.

     6.  Any operation not covered by the token's scope *MUST* be denied
         at the kernel level.

  11.4.  Degraded Operation

     When the verifier cannot construct the required authorization state
     due to log unavailability or unverifiable revocation status,
     execution *MUST NOT* proceed regardless of operator acknowledgment.
     Operator acknowledgment does not reconstruct a structurally missing
     verification input and therefore cannot substitute for a complete,
     verifiable authorization state.  Implementations *MUST* fail closed
     under these conditions in all deployment contexts.









  Nelson                  Expires 20 November 2026               [Page 36]


  Internet-Draft          Agent Delegation Receipts               May 2026


     When operating against a locally cached revocation registry,
     implementations *MUST* note the cache timestamp and *MUST* reject any
     receipt where the revocation status cannot be verified against data
     anchored within the configurable maximum cache age.  An unverifiable
     revocation status is treated equivalently to a verified revocation:
     execution *MUST NOT* proceed.

     Implementations *MUST* provide configuration to specify the maximum
     acceptable cache age for revocation data.  The default maximum cache
     age is one hour.

  12.  IANA Considerations

     This document has no IANA actions.

  13.  References

  13.1.  Normative References

     [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/info/rfc2119>.

     [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/info/rfc8174>.

     [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
                "Internet X.509 Public Key Infrastructure Time-Stamp
                Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
                2001, <https://www.rfc-editor.org/info/rfc3161>.

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

     [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
                DOI 10.17487/RFC7518, May 2015,
                <https://www.rfc-editor.org/info/rfc7518>.

  13.2.  Informative References

     [NIST-AI-100-1]
                National Institute of Standards and Technology,
                "Artificial Intelligence Risk Management Framework (AI RMF
                1.0)", NIST AI 100-1, January 2023,
                <https://doi.org/10.6028/NIST.AI.100-1>.



  Nelson                  Expires 20 November 2026               [Page 37]


  Internet-Draft          Agent Delegation Receipts               May 2026


     [W3C-WebAuthn]
                Balfanz, D., "Web Authentication: An API for Accessing
                Public Key Credentials Level 2", W3C Recommendation 
                webauthn-2, April 2021,
                <https://www.w3.org/TR/webauthn-2/>.

     [FIDO2]    FIDO Alliance, "Client to Authenticator Protocol (CTAP)",
                FIDO Alliance Proposed Standard CTAP-v2.1, June 2021,
                <https://fidoalliance.org/specs/fido-v2.1-ps-20210615/
                fido-client-to-authenticator-protocol-v2.1-ps-
                20210615.html>.

     [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
                Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
                <https://www.rfc-editor.org/info/rfc6962>.

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

     [NC2.5]    Barziankou, M., "Navigational Cybernetics 2.5",
                DOI 10.17605/OSF.IO/NHTC5, 2026,
                <https://doi.org/10.17605/OSF.IO/NHTC5>.

     [RFC9396]  Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
                Rich Authorization Requests", RFC 9396,
                DOI 10.17487/RFC9396, May 2023,
                <https://www.rfc-editor.org/info/rfc9396>.

  Appendix A.  JSON Schema Definitions

  A.1.  Delegation Receipt Schema

     The following JSON Schema (draft-07) defines the structure of a
     Delegation Receipt as specified in Section 4.

     {
       "$schema": "http://json-schema.org/draft-07/schema#",
       "$id": "https://authproof.dev/schemas/delegation-receipt-1.0.json",
       "title": "DelegationReceipt",
       "type": "object",
       "required": [
         "receiptId",
         "schemaVersion",
         "createdAt",
         "expiresAt",
         "publicKey",



  Nelson                  Expires 20 November 2026               [Page 38]


  Internet-Draft          Agent Delegation Receipts               May 2026


         "scope",
         "operatorInstructionsHash",
         "canonicalPayload",
         "signature"
       ],
       "properties": {
         "receiptId": {
           "type": "string",
           "description": "Unique receipt identifier.",
           "pattern": "^rec_[0-9a-f]{16,}$"
         },
         "schemaVersion": {
           "type": "string",
           "description": "Schema version. MUST be 1.0.",
           "enum": ["1.0"]
         },
         "createdAt": {
           "type": "string",
           "format": "date-time",
           "description": "ISO 8601 datetime at which this receipt
                           was created and signed."
         },
         "expiresAt": {
           "type": "string",
           "format": "date-time",
           "description": "ISO 8601 datetime at which this receipt
                           expires.  Verification MUST fail after
                           this time."
         },
         "publicKey": {
           "type": "object",
           "description": "The authorizing user's public key in
                           JSON Web Key format (RFC 7517).",
           "required": ["kty", "crv", "x", "y"],
           "properties": {
             "kty": {
               "type": "string",
               "enum": ["EC"]
             },
             "crv": {
               "type": "string",
               "enum": ["P-256"]
             },
             "x": {
               "type": "string",
               "description": "Base64url-encoded x coordinate."
             },
             "y": {



  Nelson                  Expires 20 November 2026               [Page 39]


  Internet-Draft          Agent Delegation Receipts               May 2026


               "type": "string",
               "description": "Base64url-encoded y coordinate."
             }
           }
         },
         "scope": {
           "$ref": "#/definitions/ScopeSchema"
         },
         "operatorInstructionsHash": {
           "type": "string",
           "description": "SHA-256 hash of the canonical operator
                           instructions string, formatted as
                           sha256:<hex>.",
           "pattern": "^sha256:[0-9a-f]{64}$"
         },
         "modelCommitment": {
           "type": "string",
           "description": "OPTIONAL. Cryptographic measurement of
                           the model state at authorization time,
                           formatted as sha256:<hex>.  When present,
                           verification MUST fail if the current
                           model measurement does not match.",
           "pattern": "^sha256:[0-9a-f]{64}$"
         },
         "metadata": {
           "type": "object",
           "description": "OPTIONAL. Arbitrary key-value pairs
                           included in the canonical payload and
                           covered by the signature.  MAY include
                           external delegation identifiers.",
           "additionalProperties": {
             "type": "string"
           }
         },
         "canonicalPayload": {
           "type": "string",
           "description": "Base64url-encoded canonical JSON
                           serialization of all fields except
                           signature, over which the signature
                           is computed."
         },
         "signature": {
           "type": "string",
           "description": "Base64url-encoded ECDSA P-256 signature
                           over canonicalPayload."
         },
         "logEntryHash": {
           "type": "string",



  Nelson                  Expires 20 November 2026               [Page 40]


  Internet-Draft          Agent Delegation Receipts               May 2026


           "description": "OPTIONAL. SHA-256 hash of the append-only
                           log entry produced when this receipt was
                           published, formatted as sha256:<hex>.",
           "pattern": "^sha256:[0-9a-f]{64}$"
         }
       },
       "definitions": {
         "ScopeSchema": {
           "type": "object",
           "required": ["version", "allowedActions"],
           "properties": {
             "version": {
               "type": "string",
               "description": "Scope schema version.",
               "default": "1.0"
             },
             "allowedActions": {
               "type": "array",
               "description": "Explicit list of permitted actions.",
               "items": {
                 "$ref": "#/definitions/ActionConstraint"
               }
             },
             "deniedActions": {
               "type": "array",
               "description": "Explicit list of prohibited actions.
                               Deny rules take precedence over allow
                               rules.",
               "items": {
                 "$ref": "#/definitions/ActionConstraint"
               }
             }
           }
         },
         "ActionConstraint": {
           "type": "object",
           "required": ["operation", "resource"],
           "properties": {
             "operation": {
               "type": "string",
               "description": "The operation type. Wildcards (*) are
                               supported.",
               "examples": ["read", "write", "delete", "send", "*"]
             },
             "resource": {
               "type": "string",
               "description": "The resource identifier. Wildcards (*)
                               are supported.",



  Nelson                  Expires 20 November 2026               [Page 41]


  Internet-Draft          Agent Delegation Receipts               May 2026


               "examples": ["email", "calendar", "database/*", "*"]
             },
             "constraints": {
               "type": "object",
               "description": "OPTIONAL. Argument-level constraints
                               on the action.",
               "additionalProperties": true
             }
           }
         }
       }
     }

  A.2.  Action Log Entry Schema

     The following JSON Schema defines the structure of an Action Log
     Entry as specified in Section 5.

     {
       "$schema": "http://json-schema.org/draft-07/schema#",
       "$id": "https://authproof.dev/schemas/action-log-entry-1.0.json",
       "title": "ActionLogEntry",
       "type": "object",
       "required": [
         "entryId",
         "receiptHash",
         "operation",
         "resource",
         "timestamp",
         "previousEntryHash",
         "entryHash"
       ],
       "properties": {
         "entryId": {
           "type": "string",
           "description": "Unique identifier for this log entry."
         },
         "receiptHash": {
           "type": "string",
           "description": "SHA-256 hash of the delegation receipt
                           that authorized this action, formatted
                           as sha256:<hex>.",
           "pattern": "^sha256:[0-9a-f]{64}$"
         },
         "operation": {
           "type": "string",
           "description": "The operation that was executed."
         },



  Nelson                  Expires 20 November 2026               [Page 42]


  Internet-Draft          Agent Delegation Receipts               May 2026


         "resource": {
           "type": "string",
           "description": "The resource that was accessed."
         },
         "timestamp": {
           "type": "string",
           "format": "date-time",
           "description": "RFC 3161 trusted timestamp of this
                           log entry."
         },
         "previousEntryHash": {
           "type": "string",
           "description": "SHA-256 hash of the previous log entry.
                           The first entry in a log uses a
                           well-known genesis hash.",
           "pattern": "^sha256:[0-9a-f]{64}$"
         },
         "entryHash": {
           "type": "string",
           "description": "SHA-256 hash of this entry's canonical
                           serialization excluding entryHash.",
           "pattern": "^sha256:[0-9a-f]{64}$"
         },
         "decision": {
           "type": "string",
           "description": "The verification decision for this
                           action.",
           "enum": ["ALLOW", "REQUIRE_APPROVAL", "BLOCK"]
         },
         "riskScore": {
           "type": "number",
           "description": "OPTIONAL. Session risk score at the
                           time of this action.",
           "minimum": 0,
           "maximum": 100
         }
       }
     }

  A.3.  Session State Schema

     The following JSON Schema defines the structure of a Session State
     object as specified in Section 9.








  Nelson                  Expires 20 November 2026               [Page 43]


  Internet-Draft          Agent Delegation Receipts               May 2026


     {
       "$schema": "http://json-schema.org/draft-07/schema#",
       "$id": "https://authproof.dev/schemas/session-state-1.0.json",
       "title": "SessionState",
       "type": "object",
       "required": [
         "sessionId",
         "receiptHash",
         "trustScore",
         "status",
         "startedAt",
         "actionCount"
       ],
       "properties": {
         "sessionId": {
           "type": "string",
           "description": "Unique session identifier."
         },
         "receiptHash": {
           "type": "string",
           "description": "SHA-256 hash of the delegation receipt
                           that initiated this session.",
           "pattern": "^sha256:[0-9a-f]{64}$"
         },
         "trustScore": {
           "type": "number",
           "description": "Current session trust score. Starts at
                           100 and decays on anomaly detection.",
           "minimum": 0,
           "maximum": 100
         },
         "status": {
           "type": "string",
           "description": "Current session status.",
           "enum": ["ACTIVE", "DEGRADED", "SUSPENDED"]
         },
         "startedAt": {
           "type": "string",
           "format": "date-time",
           "description": "ISO 8601 datetime at which this session
                           was initiated."
         },
         "lastActionAt": {
           "type": "string",
           "format": "date-time",
           "description": "ISO 8601 datetime of the most recent
                           action in this session."
         },



  Nelson                  Expires 20 November 2026               [Page 44]


  Internet-Draft          Agent Delegation Receipts               May 2026


         "actionCount": {
           "type": "integer",
           "description": "Total number of actions evaluated in
                           this session.",
           "minimum": 0
         },
         "anomalyCount": {
           "type": "integer",
           "description": "Total number of anomalies detected in
                           this session.",
           "minimum": 0
         },
         "sensitivityLevel": {
           "type": "string",
           "description": "Highest sensitivity level detected in
                           this session.",
           "enum": ["PUBLIC", "INTERNAL", "CONFIDENTIAL",
                    "RESTRICTED"]
         }
       }
     }

  Acknowledgements

     The authors thank the IETF WIMSE, OAuth, and SCITT working groups for
     their work on workload identity, token exchange, and supply chain
     integrity, which informed the design of this protocol.

     The formal analysis of session state properties in this document
     benefited from review and guidance by Maksim Barziankou.  The
     treatment of structural burden, viability budgets, and admissibility
     predicates in Section 9 and Section 11 draws on primitives formalized
     in Navigational Cybernetics 2.5 [NC2.5].

  Author's Address

     Ryan Nelson
     Authproof
     Clinton, Oklahoma
     United States of America
     Email: ryan@authproof.dev
     URI:   https://authproof.dev









  Nelson                  Expires 20 November 2026               [Page 45]


name: draft-hori-agent-quality-graph
rev: 00
title: Agent Quality Graph (AQG): A Protocol for Evaluating AI Agent Trustworthiness via Delegation Graphs
time: 2026-05-02T23:47:03Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-03T23:47:03Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "A2A protocols", "AI safety/alignment"]
tags: []
fetched_at: 2026-05-22T09:24:41.698378+00:00
source: ietf
abstract:
  This document describes the Agent Quality Graph (AQG) protocol, a
     method for evaluating and ranking AI agent trustworthiness based on
     delegation transaction graphs.  As the number of autonomous AI agents
     grows rapidly, there is no standardized mechanism for determining
     which agents reliably complete delegated tasks.  AQG applies graph-
     based ranking algorithms, analogous to web page ranking via hyperlink
     analysis, to the domain of agent-to-agent delegation.  Agents that
     are frequently delegated to by other highly-ranked agents receive
     higher trust scores.  This document defines the delegation record
     format, the graph construction process, the scoring algorithm, and
     the API for querying trust scores.

full_text:
  Network Working Group                                            T. Hori
  Internet-Draft                                                  May 2026
  Intended status: Informational                                          
  Expires: 3 November 2026


       Agent Quality Graph (AQG): A Protocol for Evaluating AI Agent
                   Trustworthiness via Delegation Graphs
                     draft-hori-agent-quality-graph-00

  Abstract

     This document describes the Agent Quality Graph (AQG) protocol, a
     method for evaluating and ranking AI agent trustworthiness based on
     delegation transaction graphs.  As the number of autonomous AI agents
     grows rapidly, there is no standardized mechanism for determining
     which agents reliably complete delegated tasks.  AQG applies graph-
     based ranking algorithms, analogous to web page ranking via hyperlink
     analysis, to the domain of agent-to-agent delegation.  Agents that
     are frequently delegated to by other highly-ranked agents receive
     higher trust scores.  This document defines the delegation record
     format, the graph construction process, the scoring algorithm, and
     the API for querying trust scores.

  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 2 November 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.






  Hori                     Expires 3 November 2026                [Page 1]


  Internet-Draft  Agent Quality Graph (AQG): A Protocol fo        May 2026


     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.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Delegation Record Format  . . . . . . . . . . . . . . . . . .   4
       2.1.  Required Fields . . . . . . . . . . . . . . . . . . . . .   4
       2.2.  Outcome Status Values . . . . . . . . . . . . . . . . . .   5
       2.3.  Signature . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Graph Construction  . . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Node Creation . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.  Edge Aggregation  . . . . . . . . . . . . . . . . . . . .   5
       3.3.  Category Partitioning . . . . . . . . . . . . . . . . . .   5
     4.  Scoring Algorithm . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Base Score Computation  . . . . . . . . . . . . . . . . .   6
       4.2.  Score Normalization . . . . . . . . . . . . . . . . . . .   6
       4.3.  Anti-Gaming Mechanisms  . . . . . . . . . . . . . . . . .   6
     5.  API Specification . . . . . . . . . . . . . . . . . . . . . .   6
       5.1.  Submit Delegation Record  . . . . . . . . . . . . . . . .   6
       5.2.  Query Trust Score . . . . . . . . . . . . . . . . . . . .   7
       5.3.  Query Delegation Graph  . . . . . . . . . . . . . . . . .   7
     6.  Integration with Existing Protocols . . . . . . . . . . . . .   7
       6.1.  A2A Integration . . . . . . . . . . . . . . . . . . . . .   7
       6.2.  MCP Integration . . . . . . . . . . . . . . . . . . . . .   7
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
       10.2.  Informative References . . . . . . . . . . . . . . . . .   9
     Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   9
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9










  Hori                     Expires 3 November 2026                [Page 2]


  Internet-Draft  Agent Quality Graph (AQG): A Protocol fo        May 2026


  1.  Introduction

     As of 2026, over 100,000 AI agents are deployed across more than 15
     registries and marketplaces.  Protocols such as MCP (Model Context
     Protocol) and A2A (Agent-to-Agent) enable agents to communicate and
     delegate tasks.  However, no standard mechanism exists for evaluating
     whether an agent will reliably complete a delegated task.

     Current approaches to agent discovery rely on self-reported
     capabilities, download counts, or manual reviews.  These signals are
     easily manipulated and do not reflect actual task completion quality.

     AQG addresses this gap by building a directed graph of delegation
     transactions between agents.  Each delegation creates a weighted edge
     from the delegating agent to the delegated agent.  A graph-based
     ranking algorithm then computes trust scores that reflect the
     accumulated evidence of successful task completion.

  1.1.  Motivation

     The design of AQG is inspired by the success of link-based ranking in
     web search (PageRank).  In the web graph, a link from page A to page
     B is treated as a "vote" for page B's relevance.  Similarly, in AQG,
     a delegation from agent A to agent B is treated as evidence of agent
     B's capability.

     Key differences from web link analysis:

     *  Delegation edges carry outcome metadata (success, failure, quality
        score)

     *  Edges have recency weights (recent delegations matter more)

     *  The graph is partitioned by task category

     *  Anti-gaming mechanisms prevent Sybil attacks and score
        manipulation

  1.2.  Terminology

     Agent  An autonomous software entity capable of receiving and
        completing tasks

     Delegation  A transaction where one agent (delegator) assigns a task
        to another agent (delegatee)

     Delegation Record  A signed, immutable record of a delegation
        transaction including outcome



  Hori                     Expires 3 November 2026                [Page 3]


  Internet-Draft  Agent Quality Graph (AQG): A Protocol fo        May 2026


     Trust Score  A value between 0.0 and 1.0 representing an agent's
        accumulated reliability

     AQG Node  A vertex in the quality graph representing an agent

     AQG Edge  A directed, weighted edge representing accumulated
        delegation evidence between two agents

     Trust Provider  An entity that computes and publishes trust scores
        from delegation data

  2.  Delegation Record Format

     Each delegation transaction produces a Delegation Record.  The record
     is a JSON object with the following fields:

     {
       "record_id": "uuid-v4",
       "delegator": "agent:travel-planner@example.com",
       "delegatee": "agent:hotel-booker@example.com",
       "task_category": "booking",
       "task_description": "Book hotel room for 2 nights",
       "timestamp": "2026-05-03T12:00:00Z",
       "outcome": {
         "status": "success|failure|partial|timeout",
         "quality_score": 0.95,
         "latency_ms": 450,
         "verifier": "agent:travel-planner@example.com",
         "verified_at": "2026-05-03T12:00:01Z"
       },
       "context_hash": "sha256:abcdef...",
       "signature": {
         "algorithm": "Ed25519",
         "value": "base64-encoded-signature",
         "public_key": "base64-encoded-public-key"
       }
     }

  2.1.  Required Fields

     *  record_id: Unique identifier (UUID v4)

     *  delegator: Agent identifier of the task delegator

     *  delegatee: Agent identifier of the task executor

     *  timestamp: ISO 8601 datetime of delegation




  Hori                     Expires 3 November 2026                [Page 4]


  Internet-Draft  Agent Quality Graph (AQG): A Protocol fo        May 2026


     *  outcome: Result of the delegation (status required, others
        optional)

  2.2.  Outcome Status Values

     success  Task completed satisfactorily

     failure  Task could not be completed

     partial  Task partially completed

     timeout  Task did not complete within expected time

  2.3.  Signature

     Delegation records SHOULD be signed by the delegator using Ed25519 or
     ECDSA-P256.  The signature covers the canonical JSON of all fields
     except the signature object itself.  This prevents tampering and
     enables verification of record authenticity.

  3.  Graph Construction

  3.1.  Node Creation

     Each unique agent identifier becomes a node in the quality graph.
     Nodes are created on first appearance in any delegation record.

  3.2.  Edge Aggregation

     For each (delegator, delegatee) pair, a single directed edge is
     maintained.  The edge weight is computed from all delegation records
     between the pair:

     Edge weight = sum(outcome_weight * recency_weight) for each record

     Where:

     *  outcome_weight: success=1.0, partial=0.5, timeout=-0.2, failure=-
        0.5

     *  recency_weight: exponential decay with half-life of 90 days

  3.3.  Category Partitioning

     The graph is partitioned by task_category.  An agent may have
     different trust scores in different categories.  The global trust
     score is the weighted average across all categories.




  Hori                     Expires 3 November 2026                [Page 5]


  Internet-Draft  Agent Quality Graph (AQG): A Protocol fo        May 2026


  4.  Scoring Algorithm

  4.1.  Base Score Computation

     The base trust score for each agent is computed using a modified
     PageRank algorithm applied to the AQG graph:

     Score(agent_i) = (1 - d) / N + d * sum(Score(agent_j) * w(j->i) /
     out_degree(j)) for all agents j that delegate to agent_i

     Where:

     *  d = damping factor (0.85)

     *  N = total number of agents

     *  w(j->i) = normalized edge weight from j to i

  4.2.  Score Normalization

     Raw scores are normalized to the range [0.0, 1.0] using min-max
     normalization across all agents.  A minimum of 10 delegation records
     are required before a score is published (cold-start threshold).

  4.3.  Anti-Gaming Mechanisms

     *  Sybil Resistance: Newly created agents have no score until they
        receive delegations from established agents (bootstrap problem).

     *  Collusion Detection: If a cluster of agents only delegate among
        themselves with uniformly positive outcomes, their mutual edge
        weights are discounted.

     *  Temporal Decay: Scores naturally decay without ongoing positive
        delegations, preventing legacy agents from maintaining high scores
        indefinitely.

     *  Verification Requirement: Outcomes signed by both delegator and
        delegatee carry higher weight than single-signed outcomes.

  5.  API Specification

  5.1.  Submit Delegation Record

     POST /aqg/v1/records

     Accepts a signed delegation record.  Validates signature, indexes the
     record, and triggers asynchronous score recomputation.



  Hori                     Expires 3 November 2026                [Page 6]


  Internet-Draft  Agent Quality Graph (AQG): A Protocol fo        May 2026


  5.2.  Query Trust Score

     GET /aqg/v1/scores/{agent_id}

     Returns the current trust score for an agent:

     {
       "agent_id": "agent:hotel-booker@example.com",
       "global_score": 0.87,
       "categories": {
         "booking": { "score": 0.92, "records": 156 },
         "scheduling": { "score": 0.78, "records": 23 }
       },
       "computed_at": "2026-05-03T12:00:00Z",
       "provider": "aqg.example.com",
       "signature": { "algorithm": "Ed25519", "value": "..." }
     }

  5.3.  Query Delegation Graph

     GET /aqg/v1/graph/{agent_id}?depth=2

     Returns the subgraph of delegation relationships for the specified
     agent, up to the requested depth.

  6.  Integration with Existing Protocols

  6.1.  A2A Integration

     AQG trust scores can be included in A2A Agent Cards as an extension:

  {
    "name": "Hotel Booker",
    "...": "...(standard A2A Agent Card fields)...",
    "extensions": {
      "aqg": {
        "trust_score": 0.87,
        "score_provider": "https://aqg.example.com",
        "score_url": "https://aqg.example.com/aqg/v1/scores/agent:hotel-booker@example.com"
      }
    }
  }

  6.2.  MCP Integration

     MCP servers can expose their AQG trust score via the agent.json well-
     known URI:




  Hori                     Expires 3 November 2026                [Page 7]


  Internet-Draft  Agent Quality Graph (AQG): A Protocol fo        May 2026


     {
       "name": "hotel-booker",
       "description": "Books hotel rooms",
       "trust": {
         "verified": true,
         "score": 0.87,
         "source": "aqg.example.com"
       }
     }

  7.  Security Considerations

     *  Delegation records MUST be transmitted over TLS 1.2 or higher

     *  Record signatures prevent tampering with delegation history

     *  Trust score responses from providers SHOULD be signed to prevent
        spoofing

     *  The Sybil resistance mechanism prevents creation of fake agents to
        inflate scores

     *  The collusion detection mechanism prevents ring-boosting of scores

     *  Privacy: Delegation records contain only agent identifiers, not
        user data

     *  Score manipulation: The recency decay ensures that historical
        manipulation becomes less effective over time

  8.  IANA Considerations

     This document requests registration of the Well-Known URI "aqg" in
     the IANA Well-Known URIs registry for discovering AQG endpoints.

     URI suffix: aqg Change controller: IETF Specification document: this
     document Related information: Agent Quality Graph endpoint discovery

  9.  References

  10.  References

  10.1.  Normative References

     [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
                (URIs)", May 2019.

     [A2A]      LLC, G., "Agent-to-Agent Protocol", 2025.



  Hori                     Expires 3 November 2026                [Page 8]


  Internet-Draft  Agent Quality Graph (AQG): A Protocol fo        May 2026


     [MCP]      Anthropic, "Model Context Protocol", November 2024.

  10.2.  Informative References

     [PAGERANK] Page, L., Brin, S., Motwani, R., and T. Winograd, "The
                PageRank Citation Ranking: Bringing Order to the Web",
                1999.

     [ARDP]     Pioli, R., "Agent Registration and Discovery Protocol
                (ARDP)", February 2026.

  Appendix A.  Acknowledgements

     The design of AQG is inspired by the PageRank algorithm (Page et al.,
     1999) and the Agent Registration and Discovery Protocol (Pioli,
     2026).

  Author's Address

     Takayuki Hori
     Japan
     Email: 0xoyabun@gmail.com





























  Hori                     Expires 3 November 2026                [Page 9]


name: draft-mcgraw-httpapi-agent-budget
rev: 00
title: Protocol 427: An HTTP Budget-Required Status Code with Post-Quantum-Signed Budget Attestations
time: 2026-05-06T02:11:45Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-07T02:11:45Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Data formats/interop", "Human-agent interaction"]
tags: []
fetched_at: 2026-05-22T09:24:41.698383+00:00
source: ietf
abstract:
  Internet-deployed software agents are increasingly authorized to
     spend money, consume metered services, or commit other resources on
     behalf of human or organizational principals.  Existing HTTP
     authentication and payment patterns conflate two orthogonal concerns:
     whether the requester holds a credential at all (the "401" axis), and
     whether the requester has been authorized to spend a specific amount
     through a specific settlement rail (the "budget" axis).  This
     document defines the 427 (Budget Required) HTTP status code, the
     "Budget" HTTP authentication scheme, a CBOR-encoded Budget-
     Attestation envelope signed with a post-quantum digital signature
     algorithm, and a version-negotiation mechanism using the existing 426
     (Upgrade Required) status code.  The mandatory primary signature uses
     ML-DSA-87 (FIPS 204).  An optional "rail-keyed" signature, computed
     with a hash-based stateless signature algorithm, provides
     cryptographic diversification for settlement-rail submissions.

full_text:
  HTTPAPI                                                        J. McGraw
  Internet-Draft                                                  TaskHawk
  Intended status: Standards Track                              5 May 2026
  Expires: 6 November 2026


    Protocol 427: An HTTP Budget-Required Status Code with Post-Quantum-
                         Signed Budget Attestations
                    draft-mcgraw-httpapi-agent-budget-00

  Abstract

     Internet-deployed software agents are increasingly authorized to
     spend money, consume metered services, or commit other resources on
     behalf of human or organizational principals.  Existing HTTP
     authentication and payment patterns conflate two orthogonal concerns:
     whether the requester holds a credential at all (the "401" axis), and
     whether the requester has been authorized to spend a specific amount
     through a specific settlement rail (the "budget" axis).  This
     document defines the 427 (Budget Required) HTTP status code, the
     "Budget" HTTP authentication scheme, a CBOR-encoded Budget-
     Attestation envelope signed with a post-quantum digital signature
     algorithm, and a version-negotiation mechanism using the existing 426
     (Upgrade Required) status code.  The mandatory primary signature uses
     ML-DSA-87 (FIPS 204).  An optional "rail-keyed" signature, computed
     with a hash-based stateless signature algorithm, provides
     cryptographic diversification for settlement-rail submissions.

  About This Document

     This note is to be removed before publishing as an RFC.

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-mcgraw-httpapi-agent-budget/.

     Discussion of this document takes place on the HTTPAPI Working Group
     mailing list (mailto:httpapi@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/httpapi/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/httpapi/.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.







  McGraw                   Expires 6 November 2026                [Page 1]


  Internet-Draft                Protocol 427                      May 2026


     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 6 November 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.  Motivation and Use Cases  . . . . . . . . . . . . . . . .   4
       1.2.  Conventions and Definitions . . . . . . . . . . . . . . .   5
       1.3.  Relationship to HTTP Message Signatures . . . . . . . . .   5
       1.4.  Venue and Coordination  . . . . . . . . . . . . . . . . .   6
       1.5.  Open Issues . . . . . . . . . . . . . . . . . . . . . . .   6
     2.  Overview of Operation . . . . . . . . . . . . . . . . . . . .   7
     3.  The 427 (Budget Required) Status Code . . . . . . . . . . . .   8
       3.1.  Cacheability  . . . . . . . . . . . . . . . . . . . . . .   8
       3.2.  Relationship to 401, 402, 426 . . . . . . . . . . . . . .   8
     4.  The "Budget" Authentication Scheme  . . . . . . . . . . . . .   9
       4.1.  Challenge Syntax  . . . . . . . . . . . . . . . . . . . .   9
       4.2.  Credentials Syntax  . . . . . . . . . . . . . . . . . . .  10
     5.  The Budget-Attestation Envelope . . . . . . . . . . . . . . .  10
       5.1.  CDDL Definition . . . . . . . . . . . . . . . . . . . . .  10
       5.2.  Canonical Encoding  . . . . . . . . . . . . . . . . . . .  12
       5.3.  Primary Signature . . . . . . . . . . . . . . . . . . . .  12
       5.4.  Rail-Keyed Signature  . . . . . . . . . . . . . . . . . .  12
       5.5.  Verification  . . . . . . . . . . . . . . . . . . . . . .  12
     6.  Versioning  . . . . . . . . . . . . . . . . . . . . . . . . .  13



  McGraw                   Expires 6 November 2026                [Page 2]


  Internet-Draft                Protocol 427                      May 2026


       6.1.  The Protocol-427-Version Field  . . . . . . . . . . . . .  13
       6.2.  Version Negotiation via 426 . . . . . . . . . . . . . . .  14
     7.  Reason Codes  . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
       8.1.  Status Code 427 . . . . . . . . . . . . . . . . . . . . .  15
       8.2.  "Budget" Authentication Scheme  . . . . . . . . . . . . .  16
       8.3.  "Protocol-427-Version" Field  . . . . . . . . . . . . . .  16
       8.4.  "Protocol-427" Upgrade Token  . . . . . . . . . . . . . .  16
       8.5.  "application/budget-attestation+cose" Media Type  . . . .  17
       8.6.  "budget-required" Problem Type  . . . . . . . . . . . . .  18
       8.7.  Protocol-427 Reason Codes Registry  . . . . . . . . . . .  18
       8.8.  CBOR Tag for Budget-Attestation . . . . . . . . . . . . .  19
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
       9.1.  Replay Protection . . . . . . . . . . . . . . . . . . . .  19
       9.2.  Signature Substitution and Multiple-Signature
             Confusion . . . . . . . . . . . . . . . . . . . . . . . .  19
       9.3.  Algorithm Downgrade . . . . . . . . . . . . . . . . . . .  19
       9.4.  Operator Key Compromise and Revocation  . . . . . . . . .  20
       9.5.  Post-Quantum Cryptographic Considerations . . . . . . . .  20
       9.6.  Bearer-Token Hygiene  . . . . . . . . . . . . . . . . . .  20
       9.7.  Verifier Responsibilities . . . . . . . . . . . . . . . .  20
     10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  20
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
       12.1.  Normative References . . . . . . . . . . . . . . . . . .  21
       12.2.  Informative References . . . . . . . . . . . . . . . . .  23
     Appendix A.  CDDL Schema (Collected)  . . . . . . . . . . . . . .  24
     Appendix B.  Example  . . . . . . . . . . . . . . . . . . . . . .  25
     Appendix C.  Implementation Status  . . . . . . . . . . . . . . .  27
       C.1.  Kevros (TaskHawk Systems) . . . . . . . . . . . . . . . .  27
     Appendix D.  Acknowledgments  . . . . . . . . . . . . . . . . . .  27
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  28

  1.  Introduction

     Software agents acting on behalf of human or organizational
     principals increasingly need to make HTTP requests that may incur
     cost, consume metered services, or trigger settlement on a payment
     rail.  The HTTP authentication framework [RFC9110] as historically
     deployed addresses "who are you" questions through schemes such as
     Basic, Bearer, and DPoP [RFC9449], and the HTTP 402 (Payment
     Required) status code has been appropriated by the L402 protocol
     [L402] and the x402 protocol [X402] to convey "you must pay before
     proceeding" semantics.

     Neither pattern cleanly captures the question this specification
     addresses: "do you hold a recently-issued, cryptographically-attested
     authorization to spend up to a stated amount, valid for this



  McGraw                   Expires 6 November 2026                [Page 3]


  Internet-Draft                Protocol 427                      May 2026


     request?"  That question is orthogonal to the bearer-credential axis;
     an agent may hold a perfectly valid bearer token and still lack any
     spending authority, or hold a spending authority and need to present
     it for any of several requests across one or more origins.

     This document defines:

     *  The 427 (Budget Required) HTTP status code (Section 3), used by an
        origin server or gateway to indicate that a request will not be
        processed until the requester presents a valid Budget-Attestation.

     *  The "Budget" HTTP authentication scheme (Section 4), used in the
        WWW-Authenticate response header field of a 427 response and in
        the Authorization request header field of subsequent requests.

     *  The Budget-Attestation envelope (Section 5), a CBOR-encoded
        [RFC8949], COSE-signed [RFC9052] structure that carries semantic
        claims about the issuer, the agent, the bound request, the
        permitted settlement rails, and the spending amount.  The
        envelope's primary signature uses ML-DSA-87 [FIPS204]; an optional
        rail-keyed signature (Section 5.4) uses any IETF-registered SLH-
        DSA [FIPS205] parameter set.

     *  A version-negotiation mechanism (Section 6) using a Protocol-
        427-Version response field [RFC9651] and the existing 426 (Upgrade
        Required) status code [RFC9110] for cases in which the requester
        presents a Protocol-427 version the origin does not support.

  1.1.  Motivation and Use Cases

     A representative scenario is an autonomous research agent that has
     been issued, by its operating organization, a cryptographically-
     attested allowance of "USD 10 over the next 60 seconds, spendable
     through any of {x402, L402, mpp}".  The agent traverses several
     origins, some of which require payment.  At each origin requiring
     payment, the agent presents the same Budget-Attestation; each origin
     verifies the attestation and either processes the request directly or
     initiates a rail-specific settlement that consumes from the attested
     allowance.

     The benefits of attesting authority separately from invoking a
     settlement rail are: (1) operators retain control over how much an
     agent can spend without participating in every transaction; (2)
     origins can verify authorization without coupling to any specific
     payment rail's protocol; (3) cryptographic agility, including post-
     quantum agility, can be applied uniformly to the authorization layer
     without modifying any settlement-rail protocol.




  McGraw                   Expires 6 November 2026                [Page 4]


  Internet-Draft                Protocol 427                      May 2026


  1.2.  Conventions and Definitions

     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.

     The following terms are used throughout this document:

     Operator:  An entity that issues Budget-Attestations on behalf of a
        principal.

     Agent:  An entity that holds and presents Budget-Attestations issued
        by an Operator in order to make HTTP requests.

     Verifier:  An origin server, gateway, or intermediary that receives a
        Budget-Attestation, validates its signatures, and decides whether
        to process the bearing request.

     Budget-Attestation:  The CBOR-encoded, signed envelope defined in
        Section 5.

     Settlement Rail:  An out-of-band protocol used to effect actual
        transfer of value associated with a Budget-Attestation.  Examples
        include x402, L402, and Lightning multi-path payments ("mpp").
        Rail names are carried as text strings in the Budget-Attestation;
        this document does not define how settlements are performed.

     Rail-Keyed Signature:  An optional second signature on the Budget-
        Attestation envelope, computed with a stateless hash-based
        signature algorithm (SLH-DSA), used to provide cryptographic
        diversification when the attestation is presented in connection
        with a settlement-rail submission.

  1.3.  Relationship to HTTP Message Signatures

     [RFC9421] defines a generic mechanism for digitally signing
     components of individual HTTP messages.  Although both that mechanism
     and Budget-Attestation involve cryptographic signatures that travel
     with HTTP traffic, they address different concerns.










  McGraw                   Expires 6 November 2026                [Page 5]


  Internet-Draft                Protocol 427                      May 2026


     RFC 9421 signatures bind a signature to a single HTTP message; their
     subject is "the message".  A Budget-Attestation, by contrast, is a
     portable spending authority issued by an Operator and presented by an
     Agent across one or more requests; its subject is "the authority",
     and it carries semantic claims (issuer, agent, expiry, permitted
     settlement rails, amounts) that are not part of any HTTP message
     component.

     [RFC9421] references signing keys by keyid and, as of the publication
     of this document, registers no post-quantum signature algorithm in
     the "HTTP Signature Algorithms" registry.  This document specifies
     CBOR encoding [RFC8949] and COSE signing structures [RFC9052] for the
     Budget-Attestation envelope so that multi-kilobyte post-quantum
     signature sizes are accommodated outside HTTP header fields.

     The two mechanisms are complementary.  An Agent MAY carry a Budget-
     Attestation in a request that is itself signed per [RFC9421]; in that
     case, the RFC 9421 signature covers the request as transmitted, and
     the embedded Budget-Attestation covers the spending authority
     irrespective of transport.

  1.4.  Venue and Coordination

     This document is submitted to the HTTPAPI Working Group.  It defines
     protocol elements that, per the HTTPAPI charter and Section 4.6 of
     [RFC9205], require coordination with the HTTP Working Group.  In
     particular, registration of the 427 status code in the "HTTP Status
     Codes" registry is subject to IETF Review under Section 16.2.1 of
     [RFC9110], and the author expects that registration to be reviewed by
     the HTTP Working Group prior to IESG approval.

     This document follows the best practices of [RFC9205] for
     applications that use HTTP.  Where it deviates -- specifically, by
     defining a new HTTP status code -- it does so consistent with the
     guidance of Section 4.6 of [RFC9205].

  1.5.  Open Issues

        This subsection is to be removed before Working Group adoption or
        publication.

     *  The CBOR tag value for the tagged form of the Budget-Attestation
        envelope is marked TBD pending IANA assignment.

     *  The default reason-code registry policy (Section 8.7) is set to
        Specification Required; alternative policies may be considered
        during Working Group review.




  McGraw                   Expires 6 November 2026                [Page 6]


  Internet-Draft                Protocol 427                      May 2026


     *  The author seeks feedback on whether the rail-keyed signature
        (Section 5.4) belongs in this document or in a separate companion
        document focused on settlement-rail bindings.

  2.  Overview of Operation

     A typical Protocol 427 exchange proceeds as follows.

     GET /research/papers/12345 HTTP/1.1
     Host: api.example

     The origin determines that processing the request will incur cost and
     that no Budget-Attestation accompanies the request.  It returns:

     HTTP/1.1 427 Budget Required
     Date: Tue, 05 May 2026 14:00:00 GMT
     Cache-Control: no-store
     Content-Type: application/problem+json
     Content-Length: 213
     Protocol-427-Version: 1
     WWW-Authenticate: Budget realm="api.example",
                       alg="ML-DSA-87",
                       rails="x402 l402 mpp",
                       nonce="QMjVqg5Xb6yV0bO_t9X8gQ",
                       max-age=900

     {
       "type": "https://taskhawktech.com/problems/budget-required",
       "title": "Budget attestation required",
       "status": 427,
       "detail": "A valid Budget-Attestation is required.",
       "min-budget": {"USD": 250},
       "accepted-rails": ["x402","l402","mpp"],
       "max-age": 900,
       "protocol-version": 1
     }

     The Agent obtains a Budget-Attestation from its Operator (out of
     band; issuance is not specified by this document) and retries:

     POST /research/papers/12345 HTTP/1.1
     Host: api.example
     Authorization: Budget attestation=":2BhA...base64url-CBOR...kQ=="
     Content-Length: 0







  McGraw                   Expires 6 November 2026                [Page 7]


  Internet-Draft                Protocol 427                      May 2026


     If the attestation validates against the Verifier's policy, the
     Verifier processes the request normally.  If validation fails, the
     Verifier returns 427 again with a reason extension member in the
     Problem Details body indicating the failure (Section 7).

  3.  The 427 (Budget Required) Status Code

     The 427 (Budget Required) status code indicates that the requester
     must present a valid Budget-Attestation as defined in this document
     before the request can be processed.  The 427 status code differs
     from 401 (Unauthorized) in that the requester may hold a fully-valid
     authentication credential (for example, a Bearer token) and still
     receive 427 because the request requires a budget attestation in
     addition to, or instead of, that credential.  It differs from 402
     (Payment Required) in that 427 is a request for evidence of pre-
     issued spending authority, not a request to immediately initiate
     payment.

     A 427 response MUST include a Protocol-427-Version response header
     field (Section 6.1) and a WWW-Authenticate header field specifying
     the "Budget" authentication scheme (Section 4).

     A 427 response SHOULD include a response body in the "application/
     problem+json" [RFC9457] or "application/problem+cbor" [RFC9457] media
     type carrying diagnostic information.  When present, the body SHOULD
     use the "budget-required" problem type defined in Section 8.6.

  3.1.  Cacheability

     Responses with the 427 status code are not cacheable by default; per
     Section 15.1 of [RFC9110], status codes not enumerated as cacheable
     are not cacheable absent explicit cache directives.  A server SHOULD
     send Cache-Control: no-store (Section 5.2.2.5 of [RFC9111]) with a
     427 response, and a cache MUST NOT store a 427 response unless
     explicitly permitted by Cache-Control directives in the response.
     This rule mirrors the treatment of 428, 429, and 431 in [RFC6585].

  3.2.  Relationship to 401, 402, 426

     *  401 (Unauthorized) is returned when no, or insufficient,
        authentication credential is supplied.  A request MAY receive 401
        for credential reasons even if a Budget-Attestation is present.

     *  402 (Payment Required) is "reserved for future use" by
        Section 15.5.2 of [RFC9110] but has been adopted by L402 and x402
        to mean "initiate a payment-rail interaction".  A request MAY
        receive 402 from a downstream rail-handling endpoint after a 427
        has been satisfied, depending on deployment.



  McGraw                   Expires 6 November 2026                [Page 8]


  Internet-Draft                Protocol 427                      May 2026


     *  426 (Upgrade Required) is used by this document to negotiate
        Protocol-427 versions; see Section 6.

  4.  The "Budget" Authentication Scheme

     The "Budget" authentication scheme is registered in Section 8.2.  It
     is used in the WWW-Authenticate response header field of a 427
     response and in the Authorization request header field of a
     subsequent request.

  4.1.  Challenge Syntax

     A WWW-Authenticate challenge using the "Budget" scheme has the
     following syntax, expressed in ABNF [RFC9110]:

     budget-challenge   = "Budget" 1*SP budget-params
     budget-params      = budget-param *( OWS "," OWS budget-param )
     budget-param       = ( "realm" "=" quoted-string )
                        / ( "alg" "=" quoted-string )
                        / ( "rails" "=" quoted-string )
                        / ( "nonce" "=" quoted-string )
                        / ( "max-age" "=" 1*DIGIT )
                        / ( "attestation" "=" quoted-string )
                        / auth-param

     Parameter semantics:

     realm:  A protection-space identifier as defined in Section 11.5 of
        [RFC9110].  REQUIRED.

     alg:  A space-separated list of acceptable signature algorithm names
        for the Budget-Attestation primary signature.  Tokens correspond
        to COSE algorithm names ([I-D.ietf-cose-dilithium]).  REQUIRED.

     rails:  A space-separated list of settlement-rail tokens acceptable
        to the Verifier.  REQUIRED if the Verifier expects a rail-keyed
        signature (Section 5.4); OPTIONAL otherwise.

     nonce:  A server-supplied opaque value, base64url-encoded, that the
        Agent SHOULD echo in the nonce claim of any presented Budget-
        Attestation bound to this challenge.  REQUIRED.

     max-age:  An advisory, non-negative integer indicating, in seconds,
        the maximum recommended lifetime of any Budget-Attestation
        presented in response to this challenge.  OPTIONAL.

     attestation:  Reserved for future use; servers MUST NOT include it in
        challenges emitted under this version of Protocol 427.



  McGraw                   Expires 6 November 2026                [Page 9]


  Internet-Draft                Protocol 427                      May 2026


  4.2.  Credentials Syntax

     An Authorization request header field using the "Budget" scheme has
     the following syntax:

     budget-credentials = "Budget" 1*SP "attestation" "=" quoted-string

     The value of the attestation parameter is the base64url Section 5 of
     [RFC8949] encoding of the CBOR Budget-Attestation envelope
     (Section 5).

     When the encoded envelope would exceed an HTTP-implementation header
     size limit (a typical limit is 8 KiB; SLH-DSA signatures
     (Section 5.4) can exceed this), the Agent MUST instead submit the
     envelope in a request body of media type "application/budget-
     attestation+cose" (Section 8.5) and convey only the scheme name and a
     content-binding parameter in the Authorization header field, as
     follows:

     budget-credentials-body = "Budget" 1*SP "binding" "=" quoted-string

     The binding value is the base64url-encoded SHA-256 hash of the CBOR-
     encoded envelope contained in the request body.

  5.  The Budget-Attestation Envelope

     The Budget-Attestation envelope is a COSE_Sign structure [RFC9052]
     carrying a Budget-Claims set as its payload.  It MAY be transported
     as a tagged CBOR value (CBOR tag TBD) or as an untagged value when
     delivered as the body of an "application/budget-attestation+cose"
     HTTP message.

  5.1.  CDDL Definition

     The schema below is given in CDDL [RFC8610].

     ; Budget-Attestation envelope (Protocol 427)
     ; The tagged form uses CBOR tag TBD; the untagged form is used in
     ; HTTP message bodies of media type
     ; application/budget-attestation+cose.

     Budget-Attestation = #6.TBD(Budget-Attestation-Untagged) /
                          Budget-Attestation-Untagged

     Budget-Attestation-Untagged = [
       protected   : bstr .cbor Protected-Header,
       unprotected : Unprotected-Header,
       claims      : bstr .cbor Budget-Claims,



  McGraw                   Expires 6 November 2026               [Page 10]


  Internet-Draft                Protocol 427                      May 2026


       signatures  : [+ Signature]
     ]

     Protected-Header = {
       1 => int,           ; alg of the primary signature (ML-DSA-87)
       ? 4 => bstr         ; kid (operator key identifier)
     }

     Unprotected-Header = {
       * (int / tstr) => any
     }

     Budget-Claims = {
       "version"  => uint,                ; protocol version
       "iss"      => tstr,                ; issuer (operator) identifier
       "agent"    => tstr,                ; agent identifier
       "iat"      => uint,                ; issued-at, seconds since epoch
       "exp"      => uint,                ; expiry, seconds since epoch
       "nonce"    => bstr .size (16..64), ; replay-protection nonce
       "rb"       => Request-Binding,
       "rails"    => [+ tstr],            ; permitted settlement rails
       ? "amt"    => Rail-Amount-Map      ; amount cap (minor units)
     }

     Request-Binding = {
       "method"  => tstr,                ; e.g., "POST"
       "uri-h"   => bstr .size 32,       ; SHA-256 of canonical target URI
       ? "body-h" => bstr .size 32       ; SHA-256 of body, if bound
     }

     Rail-Amount-Map = {
       + tstr => uint                    ; minor units per currency code
     }

     Signature = [
       protected   : bstr .cbor Sig-Protected-Header,
       unprotected : Unprotected-Header,
       signature   : bstr
     ]

     Sig-Protected-Header = {
       1 => int,                         ; alg id (COSE)
       ? 4 => bstr,                      ; kid
       ? "role" => "operator" / "rail"   ; primary vs rail-keyed
     }






  McGraw                   Expires 6 November 2026               [Page 11]


  Internet-Draft                Protocol 427                      May 2026


  5.2.  Canonical Encoding

     Budget-Attestations MUST be encoded using the Core Deterministic
     Encoding Requirements of Section 4.2.1 of [RFC8949].  Verifiers MUST
     reject envelopes whose CBOR encoding does not satisfy those
     requirements.

  5.3.  Primary Signature

     The Budget-Attestation envelope MUST include exactly one primary
     signature.  The primary signature's Sig-Protected-Header MUST set alg
     to the COSE identifier for ML-DSA-87 as defined by
     [I-D.ietf-cose-dilithium].  Future revisions of this document MAY add
     additional MUST-implement primary algorithms; the rules of algorithm
     agility (Section 9.3) apply.

  5.4.  Rail-Keyed Signature

     A Budget-Attestation envelope MAY include a second signature, denoted
     the "rail-keyed" signature, distinguished by role = "rail" in its
     Sig-Protected-Header.  The rail-keyed signature provides
     cryptographic diversification: even if the primary lattice-based
     signature key is compromised, settlement-rail interactions can
     require an additional, hash-based signature over the same envelope.

     The rail-keyed signature, when present, MUST use a stateless hash-
     based signature algorithm registered in the COSE Algorithms Registry
     under [I-D.ietf-cose-sphincs-plus].  Implementations of this document
     MUST support SLH-DSA-SHA2-128f as the rail-keyed algorithm
     ([FIPS205]); implementations MAY additionally support any other SLH-
     DSA parameter set with a registered COSE algorithm identifier.

     A Verifier that requires a rail-keyed signature for settlement-rail
     acceptance MUST advertise this expectation through deployment-
     specific means; this document does not extend the WWW-Authenticate
     challenge to advertise per-rail signature requirements.

     Because SLH-DSA signatures are large (FIPS 205 reports 17,088 bytes
     for SLH-DSA-SHA2-128f and may be tens of kilobytes for higher
     parameter sets), envelopes carrying a rail-keyed signature MUST be
     transported in an HTTP message body of media type "application/
     budget-attestation+cose"; they MUST NOT be carried in the
     Authorization header field's attestation parameter.

  5.5.  Verification

     A Verifier processing a Budget-Attestation MUST, in order:




  McGraw                   Expires 6 November 2026               [Page 12]


  Internet-Draft                Protocol 427                      May 2026


     1.  Verify that the encoded CBOR satisfies the Core Deterministic
         Encoding Requirements of Section 4.2.1 of [RFC8949].

     2.  Verify that the version claim is supported (Section 6).

     3.  Verify the primary signature against the operator key identified
         by the kid parameter or otherwise resolved by deployment policy.

     4.  Verify that iat and exp define a non-empty interval that includes
         the current time, allowing for clock skew of at most 60 seconds.

     5.  Verify that the nonce was issued by the Verifier as part of an
         outstanding 427 challenge, and has not previously been observed
         for this Verifier.

     6.  Verify that rb.method matches the request method, that rb.uri-h
         matches the SHA-256 of the canonical target URI, and (if body-h
         is present) that body-h matches the SHA-256 of the request body.

     7.  Verify that any rail-keyed signature, if present, validates under
         a configured rail key.

     If all checks pass, the Verifier processes the request normally.  If
     any check fails, the Verifier MUST respond with 427 and SHOULD
     include a reason extension member in the Problem Details body
     indicating the failure.

  6.  Versioning

     This document defines version 1 of Protocol 427.  Future revisions
     MAY define additional versions.

  6.1.  The Protocol-427-Version Field

     The Protocol-427-Version response header field is a Structured Field
     [RFC9651] of type Item containing an Integer.  Its value is the
     Protocol-427 version under which the response was constructed.

     A 427 response MUST include exactly one Protocol-427-Version header
     field.  Other responses MAY include the field to advertise the
     origin's Protocol-427 capability.










  McGraw                   Expires 6 November 2026               [Page 13]


  Internet-Draft                Protocol 427                      May 2026


  6.2.  Version Negotiation via 426

     If a request bearing an Authorization: Budget credential carries a
     version claim that the Verifier does not support, the Verifier MUST
     respond with 426 (Upgrade Required) per Section 15.5.22 of [RFC9110]
     and MUST include an Upgrade header field listing one or more
     Protocol-427/N tokens for versions the Verifier supports.  The token
     "Protocol-427" is registered in Section 8.4.

     Example:

     HTTP/1.1 426 Upgrade Required
     Upgrade: Protocol-427/1
     Connection: Upgrade
     Protocol-427-Version: 1

  7.  Reason Codes

     A Verifier returning 427 SHOULD include a reason extension member in
     the Problem Details body indicating the cause of failure.  This
     document defines the following initial reason codes:






























  McGraw                   Expires 6 November 2026               [Page 14]


  Internet-Draft                Protocol 427                      May 2026


        +=====================+=======================================+
        | Reason              | Meaning                               |
        +=====================+=======================================+
        | ok                  | Used in audit and diagnostic contexts |
        |                     | only; never appears on a 427.         |
        +---------------------+---------------------------------------+
        | expired             | The presented attestation's exp is in |
        |                     | the past.                             |
        +---------------------+---------------------------------------+
        | signature_mismatch  | A signature on the envelope did not   |
        |                     | validate.                             |
        +---------------------+---------------------------------------+
        | replay              | The presented nonce has previously    |
        |                     | been observed.                        |
        +---------------------+---------------------------------------+
        | unknown_operator    | The iss is not recognized.            |
        +---------------------+---------------------------------------+
        | malformed_cbor      | The envelope failed CBOR              |
        |                     | canonicalization checks.              |
        +---------------------+---------------------------------------+
        | version_unsupported | The version claim is not supported.   |
        +---------------------+---------------------------------------+
        | rail_not_authorized | A rail in rails is not permitted by   |
        |                     | policy.                               |
        +---------------------+---------------------------------------+
        | revoked             | The operator key has been revoked.    |
        +---------------------+---------------------------------------+

                                    Table 1

     A registry for additional reason codes is established in Section 8.7.

  8.  IANA Considerations

     This document creates registrations in several IANA registries.

  8.1.  Status Code 427

     IANA is requested to register the following entry in the "HTTP Status
     Codes" registry [IANA.HTTP.StatusCodes] established by Section 16.2.1
     of [RFC9110]:










  McGraw                   Expires 6 November 2026               [Page 15]


  Internet-Draft                Protocol 427                      May 2026


           +=======+=================+============================+
           | Value | Description     | Reference                  |
           +=======+=================+============================+
           | 427   | Budget Required | Section 3 of this document |
           +-------+-----------------+----------------------------+

                                   Table 2

  8.2.  "Budget" Authentication Scheme

     IANA is requested to register the following scheme in the "Hypertext
     Transfer Protocol (HTTP) Authentication Scheme Registry"
     [IANA.HTTP.AuthSchemes] established by Section 16.4.1 of [RFC9110]:

       +================+===============+=============================+
       | Authentication | Reference     | Notes                       |
       | Scheme Name    |               |                             |
       +================+===============+=============================+
       | Budget         | Section 4 of  | Conveys a CBOR-encoded,     |
       |                | this document | post-quantum signed Budget- |
       |                |               | Attestation; see Section 5. |
       +----------------+---------------+-----------------------------+

                                   Table 3

  8.3.  "Protocol-427-Version" Field

     IANA is requested to register the following entry in the "HTTP Field
     Name Registry" [IANA.HTTP.Fields] established by Section 18.4 of
     [RFC9110]:

      +======================+===========+=============+================+
      | Field Name           | Status    | Reference   | Comments       |
      +======================+===========+=============+================+
      | Protocol-427-Version | permanent | Section 6.1 | Structured     |
      |                      |           | of this     | Field, Item of |
      |                      |           | document    | type Integer;  |
      |                      |           |             | see [RFC9651]. |
      +----------------------+-----------+-------------+----------------+

                                    Table 4

  8.4.  "Protocol-427" Upgrade Token

     IANA is requested to register the following entry in the "HTTP
     Upgrade Token Registry" [IANA.HTTP.UpgradeTokens] established by
     Section 16.7 of [RFC9110]:




  McGraw                   Expires 6 November 2026               [Page 16]


  Internet-Draft                Protocol 427                      May 2026


      +==============+==============+======================+===========+
      | Value        | Description  | Expected Version     | Reference |
      |              |              | Tokens               |           |
      +==============+==============+======================+===========+
      | Protocol-427 | Agent Budget | A non-negative       | Section 6 |
      |              | Negotiation  | integer denoting the | of this   |
      |              | Protocol     | Protocol-427 version | document  |
      +--------------+--------------+----------------------+-----------+

                                   Table 5

  8.5.  "application/budget-attestation+cose" Media Type

     IANA is requested to register the following media type [RFC6838] in
     the "Media Types" registry [IANA.MediaTypes]:

     Type name:  application

     Subtype name:  budget-attestation+cose

     Required parameters:  N/A

     Optional parameters:  cose-type (when present, MUST be identical to
        its usage for application/cose, per Section 2 of [RFC9052])

     Encoding considerations:  binary; uses Concise Binary Object
        Representation (CBOR) [RFC8949].

     Security considerations:  See Section 9 of this document.

     Interoperability considerations:  Implementations MUST follow the
        CBOR encoding rules of [RFC8949] and the CDDL definition of
        Section 5 of this document.

     Published specification:  This document.

     Applications that use this media type:  Agents, Operators, and
        Verifiers implementing Protocol 427.

     Fragment identifier considerations:  As specified for "+cose" in the
        corresponding structured-syntax suffix registration.

     Additional information:

     *  Deprecated alias names for this type: N/A

     *  Magic number(s): (none, generic CBOR)




  McGraw                   Expires 6 November 2026               [Page 17]


  Internet-Draft                Protocol 427                      May 2026


     *  File extension(s): .cbor

     *  Macintosh file type code(s): N/A

     Person & email address to contact for further information:  John Paul
        McGraw, Jr. <j.mcgraw@taskhawktech.com>

     Intended usage:  COMMON

     Restrictions on usage:  N/A

     Author:  John Paul McGraw, Jr.

     Change controller:  IETF

     Provisional registration?:  No.

  8.6.  "budget-required" Problem Type

     IANA is requested to register the following entry in the "HTTP
     Problem Types" registry [IANA.HTTPProblemTypes] established by
     Section 6 of [RFC9457]:

           +==================+====================================+
           | Field            | Value                              |
           +==================+====================================+
           | Type URI         | https://taskhawktech.com/problems/ |
           |                  | budget-required                    |
           +------------------+------------------------------------+
           | Title            | Budget attestation required        |
           +------------------+------------------------------------+
           | Recommended HTTP | 427                                |
           | status code      |                                    |
           +------------------+------------------------------------+
           | Reference        | Section 8.6 of this document       |
           +------------------+------------------------------------+

                                    Table 6

  8.7.  Protocol-427 Reason Codes Registry

     IANA is requested to establish a new registry titled "Protocol-427
     Reason Codes" with registration policy "Specification Required"
     Section 4.6 of [RFC8126].  Each registration consists of a Reason
     token (printable ASCII, no whitespace), a Description, and a
     Reference.

     The initial registry contents are the entries listed in Section 7.



  McGraw                   Expires 6 November 2026               [Page 18]


  Internet-Draft                Protocol 427                      May 2026


  8.8.  CBOR Tag for Budget-Attestation

     IANA is requested to assign one tag from the "First Come First
     Served" range of the "CBOR Tags" registry to identify the tagged form
     of the Budget-Attestation envelope (Section 5).

  9.  Security Considerations

     This section follows the guidance of [RFC9205] and adapts the threat-
     class analysis of [RFC9421] to the Budget-Attestation envelope.

  9.1.  Replay Protection

     Each Budget-Attestation carries a server-issued nonce (echoed from
     the WWW-Authenticate challenge), an iat and exp, and a
     request_binding.  Verifiers MUST reject attestations whose nonce has
     previously been observed for the same Verifier and MUST reject
     attestations whose iat-exp interval does not include the current
     time.

     Implementations are reminded of the early-data replay considerations
     of [RFC8470]: Verifiers SHOULD NOT accept Budget-Attestations carried
     in TLS 1.3 0-RTT data, or MUST employ the Early-Data header field
     mechanism of [RFC8470].

  9.2.  Signature Substitution and Multiple-Signature Confusion

     The Budget-Attestation envelope can carry exactly one primary
     signature and at most one rail-keyed signature.  Verifiers MUST
     require the primary signature for any acceptance decision; the rail-
     keyed signature is additive authority and MUST NOT substitute for the
     primary.  Verifiers SHOULD reject envelopes containing multiple
     primary signatures.

  9.3.  Algorithm Downgrade

     The COSE alg parameter in each Sig-Protected-Header is part of the
     signed input.  Verifiers MUST compare the alg in the signed protected
     header against a configured policy and MUST NOT permit clients to
     "negotiate down" to a weaker algorithm via the WWW-Authenticate alg
     parameter.










  McGraw                   Expires 6 November 2026               [Page 19]


  Internet-Draft                Protocol 427                      May 2026


  9.4.  Operator Key Compromise and Revocation

     Operator keys SHOULD be rotated periodically.  When a key is
     compromised or retired, Verifiers MUST be able to learn of the
     revocation through deployment-specific means (for example, an
     operator JWKS endpoint or signed revocation list); the revoked reason
     code is provided for diagnostic responses to the bearer of an
     attestation under a revoked key.

  9.5.  Post-Quantum Cryptographic Considerations

     Per [I-D.ietf-cose-dilithium], the ML-DSA seed and the expanded
     private key require equal protection.  Implementations SHOULD use
     constant-time, side-channel-resistant ML-DSA implementations.  ML-DSA
     is non-deterministic; implementations SHOULD prefer the hedged
     randomization mode defined in [FIPS204], Section 3.

     SLH-DSA is hash-based and offers an independent cryptographic
     foundation; this is the rationale for offering a rail-keyed signature
     option (Section 5.4).  Implementations MUST use the pure mode of SLH-
     DSA per [I-D.ietf-cose-sphincs-plus]; HashSLH-DSA is not supported.

  9.6.  Bearer-Token Hygiene

     Until validated, a Budget-Attestation has bearer-token
     characteristics (possession implies authority).  TLS MUST be used for
     any HTTP exchange involving Authorization: Budget.  Servers SHOULD
     scrub Authorization header values from request logs.

  9.7.  Verifier Responsibilities

     Failure to verify is the dominant failure mode for any signature-
     based protocol.  Verifiers MUST validate every check listed in
     Section 5 and MUST NOT short-circuit verification under any
     condition.

  10.  Privacy Considerations

     This section follows the guidance of [RFC6973] and Section 6.1 of
     [RFC9205].

     Budget-Attestations carry identifiers (iss, agent) and authority
     metadata (rails, amt) that, if leaked or correlated across Verifiers,
     can enable tracking of an Agent's commercial activity.  Mitigations
     include:

     *  short attestation lifetimes (RECOMMENDED exp - iat <= 900
        seconds);



  McGraw                   Expires 6 November 2026               [Page 20]


  Internet-Draft                Protocol 427                      May 2026


     *  TLS confidentiality for any HTTP message bearing an attestation or
        a 427 challenge;

     *  uniformly random nonce values, at least 128 bits long, that MUST
        NOT encode timestamps or sequence numbers;

     *  Operator-managed rotation of the agent identifier;

     *  restraint in Problem Details detail content (it MUST NOT contain
        the agent identifier or signature material);

     *  the option to omit the rail-keyed signature when not required by
        policy.

     The nonce issued by a Verifier in a 427 challenge can itself be a
     tracking vector across multiple Agents observed by an on-path
     attacker.  Verifiers SHOULD generate independent random nonces per
     challenge.

     This document does not require Verifiers to retain any per-Agent
     state beyond what is necessary to detect nonce replay.
     Implementations SHOULD apply data minimization Section 6.1 of
     [RFC6973] when constructing the agent identifier and when logging
     verification outcomes.

  11.  References

  12.  References

  12.1.  Normative References

     [FIPS204]  National Institute of Standards and Technology (NIST),
                "Module-Lattice-Based Digital Signature Standard", FIPS
                PUB 204, DOI 10.6028/NIST.FIPS.204, August 2024,
                <https://nvlpubs.nist.gov/nistpubs/FIPS/
                NIST.FIPS.204.pdf>.

     [FIPS205]  National Institute of Standards and Technology (NIST),
                "Stateless Hash-Based Digital Signature Standard", FIPS
                PUB 205, DOI 10.6028/NIST.FIPS.205, August 2024,
                <https://nvlpubs.nist.gov/nistpubs/FIPS/
                NIST.FIPS.205.pdf>.









  McGraw                   Expires 6 November 2026               [Page 21]


  Internet-Draft                Protocol 427                      May 2026


     [I-D.ietf-cose-dilithium]
                Prorock, M. and O. Steele, "ML-DSA for JOSE and COSE",
                Work in Progress, Internet-Draft, draft-ietf-cose-
                dilithium-11, 15 November 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
                dilithium-11>.

     [I-D.ietf-cose-sphincs-plus]
                Prorock, M., Steele, O., and H. Tschofenig, "SLH-DSA for
                JOSE and COSE", Work in Progress, Internet-Draft, draft-
                ietf-cose-sphincs-plus-07, 15 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
                sphincs-plus-07>.

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

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

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/rfc/rfc8126>.

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

     [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
                Definition Language (CDDL): A Notational Convention to
                Express Concise Binary Object Representation (CBOR) and
                JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
                June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

     [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
                Representation (CBOR)", STD 94, RFC 8949,
                DOI 10.17487/RFC8949, December 2020,
                <https://www.rfc-editor.org/rfc/rfc8949>.

     [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", STD 96, RFC 9052,
                DOI 10.17487/RFC9052, August 2022,
                <https://www.rfc-editor.org/rfc/rfc9052>.



  McGraw                   Expires 6 November 2026               [Page 22]


  Internet-Draft                Protocol 427                      May 2026


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

     [RFC9205]  Nottingham, M., "Building Protocols with HTTP", BCP 56,
                RFC 9205, DOI 10.17487/RFC9205, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9205>.

     [RFC9457]  Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
                for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
                <https://www.rfc-editor.org/rfc/rfc9457>.

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

  12.2.  Informative References

     [L402]     Lightning Labs, "L402 Protocol Specification", 2024,
                <https://github.com/lightninglabs/L402>.

     [RFC6585]  Nottingham, M. and R. Fielding, "Additional HTTP Status
                Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
                <https://www.rfc-editor.org/rfc/rfc6585>.

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

     [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
                Code: The Implementation Status Section", BCP 205,
                RFC 7942, DOI 10.17487/RFC7942, July 2016,
                <https://www.rfc-editor.org/rfc/rfc7942>.

     [RFC8470]  Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
                Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
                2018, <https://www.rfc-editor.org/rfc/rfc8470>.






  McGraw                   Expires 6 November 2026               [Page 23]


  Internet-Draft                Protocol 427                      May 2026


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

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

     [X402]     Coinbase, Inc., "x402: An Open Standard for Internet-
                Native Payments", 2025,
                <https://www.x402.org/x402-whitepaper.pdf>.

  Appendix A.  CDDL Schema (Collected)

     The following CDDL block consolidates the schema of Section 5 for
     ease of implementation.

     Budget-Attestation = #6.TBD(Budget-Attestation-Untagged) /
                          Budget-Attestation-Untagged

     Budget-Attestation-Untagged = [
       protected   : bstr .cbor Protected-Header,
       unprotected : Unprotected-Header,
       claims      : bstr .cbor Budget-Claims,
       signatures  : [+ Signature]
     ]

     Protected-Header = {
       1 => int,
       ? 4 => bstr
     }

     Unprotected-Header = {
       * (int / tstr) => any
     }

     Budget-Claims = {
       "version"  => uint,
       "iss"      => tstr,
       "agent"    => tstr,
       "iat"      => uint,
       "exp"      => uint,
       "nonce"    => bstr .size (16..64),
       "rb"       => Request-Binding,
       "rails"    => [+ tstr],
       ? "amt"    => Rail-Amount-Map
     }



  McGraw                   Expires 6 November 2026               [Page 24]


  Internet-Draft                Protocol 427                      May 2026


     Request-Binding = {
       "method"  => tstr,
       "uri-h"   => bstr .size 32,
       ? "body-h" => bstr .size 32
     }

     Rail-Amount-Map = {
       + tstr => uint
     }

     Signature = [
       protected   : bstr .cbor Sig-Protected-Header,
       unprotected : Unprotected-Header,
       signature   : bstr
     ]

     Sig-Protected-Header = {
       1 => int,
       ? 4 => bstr,
       ? "role" => "operator" / "rail"
     }

  Appendix B.  Example

     The following example shows a complete 427 challenge, the Agent's
     follow-up request body containing a Budget-Attestation envelope (in
     CBOR diagnostic notation per Section 8 of [RFC8949]), and the
     Verifier's response.

     Initial response:





















  McGraw                   Expires 6 November 2026               [Page 25]


  Internet-Draft                Protocol 427                      May 2026


     HTTP/1.1 427 Budget Required
     Date: Tue, 05 May 2026 14:00:00 GMT
     Cache-Control: no-store
     Content-Type: application/problem+json
     Protocol-427-Version: 1
     WWW-Authenticate: Budget realm="api.example",
                       alg="ML-DSA-87",
                       rails="x402 l402 mpp",
                       nonce="QMjVqg5Xb6yV0bO_t9X8gQ",
                       max-age=900

     { "type": "https://taskhawktech.com/problems/budget-required",
       "title": "Budget attestation required",
       "status": 427,
       "min-budget": {"USD": 250},
       "accepted-rails": ["x402","l402","mpp"],
       "max-age": 900,
       "protocol-version": 1 }

     Follow-up request (CBOR shown in diagnostic notation):

     POST /research/papers/12345 HTTP/1.1
     Host: api.example
     Content-Type: application/budget-attestation+cose
     Authorization: Budget binding="lQ7M...base64url-sha256..."

     [ << { 1: -50 } >>,
       {},
       << { "version": 1,
            "iss":     "https://op.example/operators/42",
            "agent":   "agent-7c2e",
            "iat":     1746453600,
            "exp":     1746454500,
            "nonce":   h'40c8d5aa0e576fac95d1b3bfb7d5fc81',
            "rb":      { "method": "POST",
                         "uri-h":  h'a3f1...',
                         "body-h": h'0000...' },
            "rails":   ["x402","l402","mpp"],
            "amt":     { "USD": 250 } } >>,
       [ [ << { 1: -50, "role": "operator" } >>,
           {},
           h'<ML-DSA-87 signature, 4627 bytes>' ] ] ]

     Successful response: as for the underlying request (200 OK, etc.).







  McGraw                   Expires 6 November 2026               [Page 26]


  Internet-Draft                Protocol 427                      May 2026


  Appendix C.  Implementation Status

        This appendix is to be removed before publishing as an RFC.

     This section records known implementations of the protocol defined by
     this specification at the time of posting of this Internet-Draft, in
     accordance with the guidelines of [RFC7942].

     The description of implementations in this section is intended to
     assist the IETF in its decision processes in progressing drafts to
     RFCs.  Listing of any individual implementation does not imply
     endorsement by the IETF.  No effort has been spent to verify the
     information presented here.  Other implementations may exist.

  C.1.  Kevros (TaskHawk Systems)

     Organization:  TaskHawk Systems LLC

     Name:  Kevros

     Description:  An implementation of Protocol 427, including issuance
        and verification of Budget-Attestation envelopes signed with ML-
        DSA-87.

     Coverage:  Section 3 through Section 8.7 of this document;
        settlement-rail bindings for x402, L402, and Lightning multi-path
        payments.

     Implementation experience:  The host enforcement kernel within which
        Protocol 427 issuance and verification logic executes is formally
        specified in TLA+ and Lean 4. 12 safety invariants and 4 liveness
        properties of the kernel have been machine-checked: TLC bounded
        model checking explored 1.94 billion states with zero violations;
        Lean 4 interactive proof verifies 20 theorems with zero "sorry".
        Protocol 427 endpoints run inside this verified kernel and inherit
        its fail-closed and chain-integrity guarantees.  A separate state-
        machine specification of Protocol 427 version negotiation and
        Budget-Attestation signature verification has not yet been
        written.

     Contact:  j.mcgraw@taskhawktech.com

  Appendix D.  Acknowledgments

     The author thanks the Working Group for early feedback on this
     document.





  McGraw                   Expires 6 November 2026               [Page 27]


  Internet-Draft                Protocol 427                      May 2026


  Author's Address

     John Paul McGraw, Jr.
     TaskHawk Systems LLC
     Charlottesville, VA
     United States of America
     Email: j.mcgraw@taskhawktech.com












































  McGraw                   Expires 6 November 2026               [Page 28]


name: draft-jimenez-agent-directory
rev: 01
title: Agent Directory
time: 2026-05-08T11:57:08Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-09T11:57:08Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:41.698387+00:00
source: ietf
abstract:
  This document defines the Agent Directory (AD), a service where
     agents register their identity, capabilities, and reachable endpoints
     and where clients discover them by capability.  The AD adapts the
     Constrained RESTful Environments (CoRE) Resource Directory (RFC 9176)
     from constrained IoT devices to software agents, reusing its
     registration, lookup, and soft-state lifecycle model.  The AD uses
     HTTP and JSON.  MCP and A2A define how agents interact; this document
     defines how they are found.

full_text:
  Network Working Group                                         J. Jimenez
  Internet-Draft                                                  Ericsson
  Intended status: Standards Track                              8 May 2026
  Expires: 9 November 2026


                              Agent Directory
                      draft-jimenez-agent-directory-01

  Abstract

     This document defines the Agent Directory (AD), a service where
     agents register their identity, capabilities, and reachable endpoints
     and where clients discover them by capability.  The AD adapts the
     Constrained RESTful Environments (CoRE) Resource Directory (RFC 9176)
     from constrained IoT devices to software agents, reusing its
     registration, lookup, and soft-state lifecycle model.  The AD uses
     HTTP and JSON.  MCP and A2A define how agents interact; this document
     defines how they are found.

  About This Document

     This note is to be removed before publishing as an RFC.

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-jimenez-agent-directory/.


     Source for this draft and an issue tracker can be found at
     https://github.com/jaimejim/draft-jimenez-agent-directory.

  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 9 November 2026.




  Jimenez                  Expires 9 November 2026                [Page 1]


  Internet-Draft                     AD                           May 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
     2.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.  Principles  . . . . . . . . . . . . . . . . . . . . . . .   6
       2.2.  Content Model . . . . . . . . . . . . . . . . . . . . . .   6
       2.3.  Federation  . . . . . . . . . . . . . . . . . . . . . . .   7
     3.  AD Discovery  . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.  Well-Known URI  . . . . . . . . . . . . . . . . . . . . .   7
       3.2.  DNS-SD  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.  Registration  . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.  Registration Request  . . . . . . . . . . . . . . . . . .   8
         4.1.1.  Capability Types  . . . . . . . . . . . . . . . . . .  11
       4.2.  Registration Semantics  . . . . . . . . . . . . . . . . .  12
       4.3.  Reading a Registration  . . . . . . . . . . . . . . . . .  12
       4.4.  Registration Update . . . . . . . . . . . . . . . . . . .  13
       4.5.  Registration Removal  . . . . . . . . . . . . . . . . . .  14
     5.  Lookup  . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
       5.1.  Query Parameters  . . . . . . . . . . . . . . . . . . . .  15
       5.2.  Lookup Response . . . . . . . . . . . . . . . . . . . . .  16
       5.3.  Pagination  . . . . . . . . . . . . . . . . . . . . . . .  17
     6.  Error Responses . . . . . . . . . . . . . . . . . . . . . . .  17
     7.  Security Policies . . . . . . . . . . . . . . . . . . . . . .  18
       7.1.  Agent Name and Registration Ownership . . . . . . . . . .  18
       7.2.  Capability Confidentiality  . . . . . . . . . . . . . . .  18
       7.3.  Capability Vetting  . . . . . . . . . . . . . . . . . . .  18
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
       8.1.  Transport Security  . . . . . . . . . . . . . . . . . . .  19
       8.2.  Authentication  . . . . . . . . . . . . . . . . . . . . .  19
       8.3.  Authorization . . . . . . . . . . . . . . . . . . . . . .  19
       8.4.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  19
       8.5.  Adversarial Metadata  . . . . . . . . . . . . . . . . . .  20
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20



  Jimenez                  Expires 9 November 2026                [Page 2]


  Internet-Draft                     AD                           May 2026


       9.1.  Well-Known URI Registration . . . . . . . . . . . . . . .  20
       9.2.  Media Type  . . . . . . . . . . . . . . . . . . . . . . .  20
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  20
       10.2.  Informative References . . . . . . . . . . . . . . . . .  21
     Appendix A.  Relationship to Other Work . . . . . . . . . . . . .  24
       A.1.  CoRE Resource Directory (RFC 9176)  . . . . . . . . . . .  24
       A.2.  Per-Agent Metadata Endpoints  . . . . . . . . . . . . . .  24
       A.3.  MCP Registry  . . . . . . . . . . . . . . . . . . . . . .  24
       A.4.  Agent Transfer Protocol (AGTP)  . . . . . . . . . . . . .  24
       A.5.  Agent Directory Service (ADS) . . . . . . . . . . . . . .  25
       A.6.  Agent Registration and Discovery Protocol (ARDP)  . . . .  25
       A.7.  DNS-Based Agent Discovery . . . . . . . . . . . . . . . .  25
       A.8.  Platform-Specific and On-Chain Registries . . . . . . . .  26
       A.9.  Agent Network Protocol (ANP)  . . . . . . . . . . . . . .  26
       A.10. Agent Identity Profiles . . . . . . . . . . . . . . . . .  26
     Appendix B.  Examples . . . . . . . . . . . . . . . . . . . . . .  26
       B.1.  Discovery Flow  . . . . . . . . . . . . . . . . . . . . .  26
       B.2.  Enterprise Agent Portfolio  . . . . . . . . . . . . . . .  28
       B.3.  Filtered Lookup with Pagination . . . . . . . . . . . . .  30
       B.4.  Registration Conflict . . . . . . . . . . . . . . . . . .  32
     Appendix C.  Tooling and Integration  . . . . . . . . . . . . . .  32
     Appendix D.  Implementation Status  . . . . . . . . . . . . . . .  32
       D.1.  ad.jaime.win  . . . . . . . . . . . . . . . . . . . . . .  33
     Appendix E.  Acknowledgments  . . . . . . . . . . . . . . . . . .  33
     Appendix F.  Mapping from CoRE RD to AD . . . . . . . . . . . . .  34
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  35

  1.  Introduction

     The CoRE Resource Directory [RFC9176] defines a service for
     discovering resources hosted by other web servers, particularly in
     networks where direct discovery is impractical.  Endpoints register
     links describing their resources, and clients look them up later.
     Registrations are soft state with a configurable lifetime.  The RD
     provides both resource-level and endpoint-level lookup.

     A similar discovery problem arises for software agents.  LLM-based
     assistants, tool-calling agents, and multi-agent systems are deployed
     without fixed addresses and speak different interaction protocols
     (MCP [MCP], A2A [A2A], gRPC).  Direct enumeration of candidate
     endpoints does not scale beyond a single administrative domain.









  Jimenez                  Expires 9 November 2026                [Page 3]


  Internet-Draft                     AD                           May 2026


     Individual agents may publish their own metadata at well-known
     endpoints (such as the A2A Agent Card at /.well-known/agent-
     card.json).  However, per-agent metadata requires knowing the agent's
     URL before you can discover what it offers.  The AD aggregates per-
     agent metadata into a queryable service.  Clients discover agents by
     capability without prior knowledge of their addresses.

     Like the CoRE RD, the AD has a small footprint: it can run as a cloud
     service, as a sidecar alongside an agent orchestrator, on an edge
     gateway, or on a constrained device.  Deployment profiles range from
     cloud services to constrained devices colocated with sensors and
     actuators.

     The lookup interface is a small set of HTTP GET requests with a fixed
     set of query parameters.  Clients include both conventional
     applications, which use structured filters, and LLM-based clients,
     which can additionally match on the natural-language descriptions and
     tags carried in registrations.  The interface is small enough to be
     described as a tool in an MCP server or function-calling schema.

     This document specifies the Agent Directory (AD).  The core mapping
     to CoRE RD concepts is:

        +=======================+=====================================+
        | CoRE RD Concept       | AD Equivalent                       |
        +=======================+=====================================+
        | Endpoint (EP)         | Agent                               |
        +-----------------------+-------------------------------------+
        | Resource link         | Capability / tool description       |
        +-----------------------+-------------------------------------+
        | Registration resource | Agent registration resource         |
        +-----------------------+-------------------------------------+
        | Endpoint lookup       | Lookup (GET on the lookup endpoint) |
        +-----------------------+-------------------------------------+
        | Resource lookup       | Capabilities embedded in the agent  |
        |                       | registration                        |
        +-----------------------+-------------------------------------+
        | Lifetime (lt)         | Registration lifetime               |
        +-----------------------+-------------------------------------+

                                    Table 1

     Agents register with the AD by sending a POST request with a JSON
     document describing their capabilities.  Registrations are soft state
     and expire unless refreshed.






  Jimenez                  Expires 9 November 2026                [Page 4]


  Internet-Draft                     AD                           May 2026


  1.1.  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
     [BCP14] (RFC2119) (RFC8174) when, and only when, they appear in all
     capitals, as shown here.

     This specification makes use of the following terminology:

     Agent:
        An autonomous or semi-autonomous software entity that can initiate
        and receive interactions, expose capabilities (tools, skills,
        APIs), and optionally collaborate with other agents.

     Agent Directory (AD):
        An HTTP service that stores agent registrations and provides
        discovery and lookup interfaces.

     Capability:
        A discrete function, tool, or skill that an agent exposes.
        Capabilities are described as entries within an agent's
        registration.

     Registration:
        The act of an agent (or a commissioning tool acting on its behalf)
        submitting its identity, capabilities, and endpoint information to
        the AD.

     Registration Resource:
        The resource stored at the AD as a result of a successful
        registration.  Identified by the URI returned in the Location
        header of the creation response.

     Interaction Protocol:
        The application-level protocol through which an agent can be
        reached for task execution, such as MCP [MCP], A2A [A2A], or gRPC.
        HTTP is the underlying transport for most interaction protocols
        but is not itself an interaction protocol in this context.

  2.  Architecture

     Figure 1 shows the AD architecture.








  Jimenez                  Expires 9 November 2026                [Page 5]


  Internet-Draft                     AD                           May 2026


                            Registration         Lookup
                             Interface         Interface
                 +-------+       |                 |
                 | Agent |---    |                 |
                 +-------+   --- |                 |
                               --|-    +------+    |
                 +-------+       | ----|      |    |     +--------+
                 | Agent |-------|-----|  AD  |----|-----| Client |
                 +-------+       | ----|      |    |     +--------+
                               --|-    +------+    |
                 +-------+   --- |                 |
                 |  CT   |---    |                 |
                 +-------+       |                 |

                     Figure 1: Agent Directory Architecture

     Agents register their capabilities and endpoints with the AD.
     Clients (which may themselves be agents) query the AD's lookup
     interface to discover agents matching desired criteria.  A
     Commissioning Tool (CT) may register agents on their behalf, for
     example when a platform operator manages a fleet of agents.  How a CT
     proves authority to act on behalf of an agent is deployment-specific
     and out of scope for this document.

  2.1.  Principles

     The AD operates on the following principles:

     *  The AD stores information that could otherwise only be obtained by
        directly querying each agent's metadata endpoint.

     *  Registrations are soft state.  The registering agent (or its CT)
        MUST periodically refresh each registration before its lifetime
        expires.

     *  The AD MUST NOT permit modification of a registration by any
        entity other than the original registrant or an authorized CT.

     *  The AD does not proxy agent interactions; it only provides
        discovery.

  2.2.  Content Model

     An AD contains zero or more agent registrations.  Each registration
     has:

     *  An agent name ("agent", a Unicode string) unique within the AD
        instance.



  Jimenez                  Expires 9 November 2026                [Page 6]


  Internet-Draft                     AD                           May 2026


     *  A registration base URI ("base") [RFC3986], typically the agent's
        reachable address.

     *  A lifetime ("lt") in seconds.

     *  A registration resource location within the AD ("href").

     *  Optionally, a version string ("version").

     *  Optionally, a vendor string ("vendor").

     *  Zero or more capabilities, each described as a JSON object with at
        minimum a name and a type.

  2.3.  Federation

     In deployments that span multiple administrative domains or
     geographic regions, multiple AD instances may operate independently.
     Federation allows these instances to share registration information
     so that a client querying one AD can discover agents registered at
     another.

     This document does not specify a federation protocol.  Possible
     approaches include periodic synchronization between peered AD
     instances, a publish/subscribe notification mechanism, and a
     hierarchical model where a root AD aggregates entries from
     subordinate instances.  The soft-state model bounds staleness:
     federated entries carry the original lifetime and expire without
     explicit deletion if synchronization lapses.

  3.  AD Discovery

  3.1.  Well-Known URI

     An AD MUST be discoverable at the well-known URI:

     /.well-known/ad

     A GET request to this URI returns a JSON document describing the AD's
     interfaces.  The response object contains the following fields:

     registration:
        (string, REQUIRED) Path to the registration endpoint.

     lookup:
        (string, REQUIRED) URI Template [RFC6570] for the lookup endpoint.
        The template variables indicate the supported query parameters.




  Jimenez                  Expires 9 November 2026                [Page 7]


  Internet-Draft                     AD                           May 2026


     max_count:
        (integer, REQUIRED) Maximum value the AD accepts for the count
        pagination parameter.

     Example:

    GET /.well-known/ad HTTP/1.1
    Host: directory.example.com

    HTTP/1.1 200 OK
    Content-Type: application/json

    {
      "registration": "/ad/r",
      "lookup": "/ad/l{?agent,protocol,cap_name,cap_type,tag,page,count}",
      "max_count": 100
    }

  3.2.  DNS-SD

     An AD MAY advertise itself on a local network via DNS-SD [RFC6763]
     using the service name _ad._tcp.  This provides zero-configuration
     discovery of a local AD, which is useful on networks where agents are
     colocated with sensors and actuators.

     Several DNS-based mechanisms have been proposed in the DAWN working
     group for wide-area agent discovery.  DNS-AID
     [I-D.mozleywilliams-dnsop-dnsaid] publishes agent metadata under
     _agents subdomains using SVCB records.  DN-ANR
     [I-D.cui-dns-native-agent-naming-resolution] defines a resolution
     layer using FQDNs and SVCB/HTTPS records.  These mechanisms handle
     naming and resolution: mapping an agent name to a network location.
     The AD handles the layer above: finding agents by capability without
     prior knowledge of their names.  DNS resolves the AD's hostname; the
     AD carries the capability metadata that DNS cannot efficiently carry.

  4.  Registration

  4.1.  Registration Request

     An agent registers by sending a POST request to the AD's registration
     endpoint.  All HTTP interactions with the AD follow the semantics
     defined in [RFC9110].  The request body is a JSON object containing
     the agent's metadata and capabilities.







  Jimenez                  Expires 9 November 2026                [Page 8]


  Internet-Draft                     AD                           May 2026


     POST /ad/r?agent=summarizer-v2 HTTP/1.1
     Host: directory.example.com
     Content-Type: application/json

     {
       "base": "https://agents.example.com/summarizer-v2",
       "description": "Summarizes documents and extracts named entities",
       "protocols": ["a2a"],
       "capabilities": [
         {
           "name": "summarize",
           "type": "tool",
           "description": "Summarize a document or text passage",
           "input_schema": {
             "type": "object",
             "properties": {
               "text": {"type": "string"},
               "max_length": {"type": "integer"}
             },
             "required": ["text"]
           }
         },
         {
           "name": "extract_entities",
           "type": "tool",
           "description": "Extract named entities from text"
         }
       ],
       "version": "2.1.0",
       "vendor": "Example Corp",
       "identity": "https://registry.example.com/agents/summarizer-v2",
       "identity_type": "aip"
     }

     HTTP/1.1 201 Created
     Location: /ad/r/4521

     The query parameters are:

     agent:
        REQUIRED.  Agent name.  MUST be unique within the AD instance.
        SHOULD be short and meaningful; the AD MAY enforce a maximum
        length.

     lt:






  Jimenez                  Expires 9 November 2026                [Page 9]


  Internet-Draft                     AD                           May 2026


        Lifetime in seconds (OPTIONAL).  Default: 86400 (24 hours).
        Range: 60 to 4294967295 (2^32-1, matching [RFC9176]).  The AD
        SHOULD enforce a maximum lifetime; a recommended default maximum
        is 604800 seconds (7 days).

     The body JSON object contains:

     base:
        (string, REQUIRED) The agent's reachable base URI [RFC3986].

     description:
        (string, OPTIONAL) A short human-readable description of what the
        agent does.  SHOULD be one or two sentences.  Returned in lookup
        responses to help clients evaluate agents without additional
        round-trips.

     protocols:
        (array of strings, OPTIONAL) Interaction protocols supported.  The
        following values are defined by this document: "mcp" (Model
        Context Protocol), "a2a" (Agent-to-Agent Protocol), "grpc" (gRPC).
        Implementations SHOULD use lowercase short names and MAY append a
        version (e.g., "mcp/1.0").  A future version of this document may
        define an IANA registry for protocol identifiers.

     capabilities:
        (array of objects, OPTIONAL) The agent's capabilities.  Each
        object MUST have "name" (string) and "type" (string) fields.  The
        "type" field indicates the kind of capability (see Section 4.1.1).
        Additional fields such as "description" (string), "tags" (array of
        strings), "input_schema" (object), and "output_schema" (object)
        are OPTIONAL.  When present, input_schema and output_schema SHOULD
        be JSON Schema objects.  Capability names MUST be unique within a
        registration.

     version:
        (string, OPTIONAL) The agent's version identifier.

     vendor:
        (string, OPTIONAL) The organization or individual that provides
        the agent.

     identity:
        (string, OPTIONAL) A URI pointing to the agent's identity metadata
        document.  This document describes the agent's verified identity,
        trust posture, owner binding, or credentials in a structured
        format.  The AD stores and returns this URI without interpreting
        its contents.




  Jimenez                  Expires 9 November 2026               [Page 10]


  Internet-Draft                     AD                           May 2026


     identity_type:
        (string, OPTIONAL) The schema or format of the identity document
        referenced by identity.  Values include "aip" (Agent Identity
        Profile), "oidc" (OpenID Connect Discovery), "wimse" (WIMSE
        workload identity), and "did" (Decentralized Identifier Document).
        Clients that recognize the type can dereference and validate the
        identity document; clients that do not recognize the type SHOULD
        ignore both fields.

     When present, the identity field lets a client verify an agent beyond
     trusting the AD.  For example, a client discovering a financial-
     analysis agent can fetch its AIP document to check owner binding,
     attestation state, and credential lifetime before invoking the agent.
     The AD stores the URI and does not interpret it; trust decisions
     remain the client's.  Clients MUST NOT treat the presence of an
     identity field as proof of identity without verifying the referenced
     document.

  4.1.1.  Capability Types

     The "type" field in a capability object indicates the kind of
     function the agent exposes.  The following initial values are
     defined:

     tool:
        A discrete, stateless function that accepts structured input and
        returns structured output.

     skill:
        A higher-level, potentially multi-step behavior that may involve
        internal reasoning, planning, or coordination.  Unlike a tool, a
        skill may maintain conversational state.

     resource:
        A data source or content provider that the agent can expose for
        reading.

     prompt:
        A reusable prompt template that the agent can execute with
        supplied parameters.

     This list is extensible.  Implementations MAY use additional type
     values.  The remaining types mirror those defined by MCP [MCP].








  Jimenez                  Expires 9 November 2026               [Page 11]


  Internet-Draft                     AD                           May 2026


  4.2.  Registration Semantics

     Registration is idempotent on the agent name; a POST with the same
     agent name acts as an upsert.  This follows the RFC 9176 pattern of
     POST-to-collection for registration rather than PUT to a canonical
     agent URL.  The AD stores the agent value from the query parameter as
     part of the registration resource and includes it in all response
     representations.

     *  If no registration exists for the agent name, a new registration
        resource is created.  The AD returns 201 (Created) with a Location
        header pointing to the registration resource.

     *  If a registration already exists for the agent name and the
        request comes from the same authenticated entity, the registration
        is replaced with the new content.  The AD returns 200 (OK) with
        the Location header of the existing registration resource.

     *  If a registration already exists for the agent name but is owned
        by a different authenticated entity, the AD returns 409
        (Conflict).

     The response body for both 201 and 200 is empty.  Clients that need
     the full representation SHOULD send a GET request to the URI in the
     Location header.  The AD MAY grant a lifetime shorter than requested;
     the granted lifetime MUST be indicated in the response via a lt field
     in a JSON body or via the Location header's associated resource.

  4.3.  Reading a Registration

     An agent or client retrieves a single registration by sending a GET
     request to the registration resource.



















  Jimenez                  Expires 9 November 2026               [Page 12]


  Internet-Draft                     AD                           May 2026


     GET /ad/r/4521 HTTP/1.1
     Host: directory.example.com

     HTTP/1.1 200 OK
     Content-Type: application/json

     {
       "agent": "summarizer-v2",
       "base": "https://agents.example.com/summarizer-v2",
       "protocols": ["a2a"],
       "capabilities": [
         {
           "name": "summarize",
           "type": "tool",
           "description": "Summarize a document or text passage",
           "input_schema": {
             "type": "object",
             "properties": {
               "text": {"type": "string"},
               "max_length": {"type": "integer"}
             },
             "required": ["text"]
           }
         },
         {
           "name": "extract_entities",
           "type": "tool",
           "description": "Extract named entities from text"
         }
       ],
       "version": "2.1.0",
       "vendor": "Example Corp",
       "href": "/ad/r/4521"
     }

     The response includes the full registration content, including
     capability details (description, schemas) that are omitted from
     lookup results (Section 5.2).  If the registration resource does not
     exist, the AD MUST return 404 (Not Found).

  4.4.  Registration Update

     An agent refreshes or updates its registration by sending a POST
     request to its registration resource (the URI returned in the
     Location header at creation time).






  Jimenez                  Expires 9 November 2026               [Page 13]


  Internet-Draft                     AD                           May 2026


     POST /ad/r/4521 HTTP/1.1
     Host: directory.example.com

     HTTP/1.1 204 No Content

     An empty POST resets the lifetime.  The agent MAY include query
     parameters (lt) to update those values, or a JSON body to replace the
     capabilities.  If the registration has already expired, the AD MUST
     return 404 (Not Found); the agent must re-register via the
     registration endpoint.

     An agent may update the lifetime via the lt query parameter:

     POST /ad/r/4521?lt=3600 HTTP/1.1
     Host: directory.example.com

     HTTP/1.1 204 No Content

     If the registration has already expired, the update fails:

     POST /ad/r/4521 HTTP/1.1
     Host: directory.example.com

     HTTP/1.1 404 Not Found
     Content-Type: application/problem+json

     {
       "type": "https://ad.example.com/errors/registration-expired",
       "title": "Registration has expired",
       "status": 404
     }

  4.5.  Registration Removal

     An agent removes its registration by sending a DELETE request to its
     registration resource.

     DELETE /ad/r/4521 HTTP/1.1
     Host: directory.example.com

     HTTP/1.1 204 No Content

     The AD MUST automatically remove a registration when its lifetime
     elapses without a refresh.







  Jimenez                  Expires 9 November 2026               [Page 14]


  Internet-Draft                     AD                           May 2026


  5.  Lookup

     The AD provides a lookup endpoint for discovering registered agents.
     The lookup endpoint URI is obtained from the well-known response
     (Section 3).  All query parameters act as conjunctive filters: only
     agents matching all specified criteria are returned.  A request with
     no filters returns all agents visible to the requesting client.

  GET /ad/l?cap_name=purge* HTTP/1.1
  Host: directory.example.com
  Accept: application/json

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "agents": [
      {
        "agent": "cdn-cache-manager",
        "base": "https://agents.example.com/cdn-cache-manager",
        "description": "Manages CDN cache invalidation and prefetch policies",
        "protocols": ["a2a"],
        "capabilities": [
          {"name": "purge_by_tag", "type": "tool"},
          {"name": "prefetch_origins", "type": "tool"}
        ],
        "href": "/ad/r/4521"
      }
    ]
  }

  5.1.  Query Parameters

     All filters use exact match on the registered value, with one
     exception: agent and cap_name support a single trailing * as a
     prefix-match operator (e.g., cap_name=purge* matches purge_by_tag).
     The * character MUST NOT appear anywhere else in these values, and
     agent and capability names MUST NOT contain a literal *. The AD MUST
     reject registrations whose agent or capability names contain * with
     400 (Bad Request).  No other glob or regular-expression syntax is
     supported.

     agent:
        Filter by agent name.  Trailing * for prefix match; exact match
        otherwise.

     protocol:




  Jimenez                  Expires 9 November 2026               [Page 15]


  Internet-Draft                     AD                           May 2026


        Filter by interaction protocol.  Matches when the given value
        appears in the agent's protocols array.

     cap_name:
        Filter by capability name.  Trailing * for prefix match.

     cap_type:
        Filter by capability type (e.g., "tool", "skill").

     tag:
        Filter by capability tag.  Matches when the given value appears in
        any capability's tags array.

     page:
        Page number (zero-based).  Default: 0.

     count:
        Results per page.  The AD MUST clamp values exceeding the
        max_count reported in the well-known response (Section 3) to that
        maximum.  Default: the AD's max_count.

     When multiple cap_* or tag filters are present, the AD MUST match
     agents that have at least one _single_ capability satisfying all
     cap_* and tag filters jointly.  For example, cap_type=tool&tag=search
     matches agents with a capability that is both typed tool and tagged
     search, not agents that happen to have a tool capability and,
     separately, a capability with a search tag.

     The AD MUST ignore unknown query parameters rather than returning an
     error.

  5.2.  Lookup Response

     Each object in the agents array contains:

     agent:
        The registered agent name.

     base:
        The agent's base URI.

     description:
        The agent's description, if registered.

     protocols:
        Interaction protocols the agent supports.

     capabilities:



  Jimenez                  Expires 9 November 2026               [Page 16]


  Internet-Draft                     AD                           May 2026


        An array of capability summary objects, each with "name" and
        "type".  Full details (descriptions, schemas, tags) are omitted to
        keep responses compact.

     href:
        The registration resource URI.  Clients retrieve the full
        registration by sending GET to this URI (Section 4.3).

     This two-step pattern mirrors the RD's separation between endpoint
     lookup and resource lookup [RFC9176]: the lookup returns compact
     summaries with pointers; the client dereferences the pointer for full
     details.

  5.3.  Pagination

     When more results exist beyond the current page, the AD includes a
     Link header [RFC8288] with rel="next":

     Link: </ad/l?cap_name=purge*&page=1>; rel="next"

     An empty agents array with no rel="next" link indicates no results or
     end of results.

  6.  Error Responses

     When the AD cannot fulfill a request, it MUST return an appropriate
     HTTP status code and SHOULD include a problem details object as
     defined in [RFC9457].  The type URIs shown below are illustrative;
     this document does not register them.

     HTTP/1.1 409 Conflict
     Content-Type: application/problem+json

     {
       "type": "https://ad.example.com/errors/agent-name-taken",
       "title": "Agent name already registered",
       "detail": "Agent name already registered by another entity.",
       "status": 409
     }

     The following error conditions are defined:

     400 Bad Request:
        The request body is malformed or missing required fields.

     401 Unauthorized:
        The request lacks valid authentication credentials.




  Jimenez                  Expires 9 November 2026               [Page 17]


  Internet-Draft                     AD                           May 2026


     403 Forbidden:
        The authenticated entity is not authorized for the requested
        operation.

     404 Not Found:
        The referenced registration resource does not exist.

     409 Conflict:
        The agent name is already registered by a different entity.

     429 Too Many Requests:
        The client has exceeded the rate limit.

  7.  Security Policies

     The security model is derived from Section 7 of [RFC9176] and adapted
     for agents.  Policies for capability attestation and cross-domain
     trust are out of scope for this document.

  7.1.  Agent Name and Registration Ownership

     The AD MUST ensure that a registering agent is authorized to use the
     given agent name.  The default policy is "First Come First
     Remembered" as described in Section 7.5 of [RFC9176]: accept
     registrations for any agent name not currently active, and only
     accept updates from the same authenticated entity.  Whether the AD
     should return 409 (Conflict) or 403 (Forbidden) when a different
     entity tries to claim an existing name is an open design question;
     this document uses 409 to signal a naming conflict rather than an
     authorization failure.

  7.2.  Capability Confidentiality

     The AD MUST enforce access control on lookup results when the
     operator policy designates some registrations as restricted.  Not
     every client is entitled to see every registration.

  7.3.  Capability Vetting

     The AD SHOULD restrict which capability types and names an agent may
     claim, based on operator policy.  For example, registration of an
     agent as a "financial-analysis" tool can be limited to agents
     presenting the corresponding credentials.  The policy mechanism is
     deployment-specific and out of scope for this document.







  Jimenez                  Expires 9 November 2026               [Page 18]


  Internet-Draft                     AD                           May 2026


  8.  Security Considerations

  8.1.  Transport Security

     All communication with the AD MUST be protected using TLS.

  8.2.  Authentication

     Agents MUST authenticate when registering.  The AD MUST support OAuth
     2.0 bearer tokens [RFC6750] or mutual TLS (mTLS).  API keys are
     acceptable for development but do not satisfy the authentication
     requirement for production use.

     Registration requires a verified agent identity: the AD must know who
     is registering before it can enforce ownership of the registration
     resource.  Bearer tokens prove authorization but not workload
     identity.  For production deployments, the AD SHOULD accept workload
     identity credentials as defined by the WIMSE working group
     [I-D.ietf-wimse-arch].  The WIMSE architecture treats agents as
     workloads and defines a wimse: URI scheme [I-D.ietf-wimse-identifier]
     that can serve as the agent's authenticated identity at registration
     time.  This provides a cryptographically verifiable binding between
     the registrant and the registration.

     If an agent's credentials are compromised, the attacker can modify
     the registration (including the base URI) until the credentials are
     revoked.  Deployments SHOULD keep credential lifetimes comparable to
     registration lifetimes, and SHOULD log registration changes for
     audit.

  8.3.  Authorization

     The AD MUST enforce that only the original registrant (or an
     authorized CT) can modify or delete a registration.  The AD SHOULD
     implement rate limiting on both registration and lookup endpoints,
     and MUST enforce limits on registration size and number of
     capabilities per agent.

  8.4.  Privacy

     Agent metadata can reveal organizational structure: a lookup response
     listing all agents discloses which capabilities an organization has
     deployed.  The AD SHOULD return only those registrations that the
     requester is authorized to see.  The interaction between scoped
     responses and federation is out of scope for this document.






  Jimenez                  Expires 9 November 2026               [Page 19]


  Internet-Draft                     AD                           May 2026


  8.5.  Adversarial Metadata

     Capability descriptions and tags are free-form text that LLM-based
     clients may use as input to their decisions.  A malicious registrant
     can craft descriptions that bias those decisions toward invoking the
     wrong agent.  A malicious registrant can also set base to a victim's
     endpoint, redirecting traffic intended for the registered agent.

     Clients SHOULD treat registration metadata as untrusted input.
     Clients MAY verify a registration by fetching the agent's own
     metadata at base and comparing it with the AD response before
     invocation.

  9.  IANA Considerations

  9.1.  Well-Known URI Registration

     This document requests registration of the following well-known URI
     [RFC8615]:

     URI suffix:
        ad

     Change controller:
        IETF

     Specification document:
        [RFC-XXXX]

  9.2.  Media Type

     This document uses application/json for all request and response
     bodies and application/problem+json [RFC9457] for error responses.

  10.  References

  10.1.  Normative References

     [BCP14]    Best Current Practice 14,
                <https://www.rfc-editor.org/info/bcp14>.
                At the time of writing, this BCP comprises the following:

                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/info/rfc2119>.





  Jimenez                  Expires 9 November 2026               [Page 20]


  Internet-Draft                     AD                           May 2026


                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/info/rfc8174>.

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

     [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
                and D. Orchard, "URI Template", RFC 6570,
                DOI 10.17487/RFC6570, March 2012,
                <https://www.rfc-editor.org/rfc/rfc6570>.

     [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
                Framework: Bearer Token Usage", RFC 6750,
                DOI 10.17487/RFC6750, October 2012,
                <https://www.rfc-editor.org/rfc/rfc6750>.

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

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

     [RFC9176]  Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
                P. van der Stok, "Constrained RESTful Environments (CoRE)
                Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
                2022, <https://www.rfc-editor.org/rfc/rfc9176>.

     [RFC9457]  Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
                for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
                <https://www.rfc-editor.org/rfc/rfc9457>.

  10.2.  Informative References

     [A2A]      "Agent-to-Agent Protocol", 2025,
                <https://a2aprotocol.ai/>.

     [AgentRegistry]
                "agentregistry", 2026, <https://aregistry.ai/>.



  Jimenez                  Expires 9 November 2026               [Page 21]


  Internet-Draft                     AD                           May 2026


     [ANP-Discovery]
                "ANP Agent Discovery Protocol Specification", 2024,
                <https://agentnetworkprotocol.com/en/specs/08-anp-agent-
                discovery-protocol-specification/>.

     [Azure-API-Center]
                "Agent registry in Azure API Center", 2026,
                <https://learn.microsoft.com/en-us/azure/api-center/agent-
                to-agent-overview>.

     [ERC-8004] "ERC-8004: Trustless Agents", 2026,
                <https://eips.ethereum.org/EIPS/eip-8004>.

     [I-D.cui-dns-native-agent-naming-resolution]
                Cui, Y., "DNS-Native AI Agent Naming and Resolution", Work
                in Progress, Internet-Draft, draft-cui-dns-native-agent-
                naming-resolution-01, 2 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-cui-dns-
                native-agent-naming-resolution-01>.

     [I-D.hood-independent-agtp]
                Hood, C., "Agent Transfer Protocol (AGTP)", Work in
                Progress, Internet-Draft, draft-hood-independent-agtp-06,
                27 April 2026, <https://datatracker.ietf.org/doc/html/
                draft-hood-independent-agtp-06>.

     [I-D.ietf-wimse-arch]
                Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
                "Workload Identity in a Multi System Environment (WIMSE)
                Architecture", Work in Progress, Internet-Draft, draft-
                ietf-wimse-arch-07, 2 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
                arch-07>.

     [I-D.ietf-wimse-identifier]
                Rosomakho, Y. and J. A. Salowey, "Workload Identifier",
                Work in Progress, Internet-Draft, draft-ietf-wimse-
                identifier-02, 2 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
                identifier-02>.

     [I-D.mozleywilliams-dnsop-dnsaid]
                Mozley, J., Williams, N., Sarikaya, B., and R. Schott,
                "DNS for AI Discovery", Work in Progress, Internet-Draft,
                draft-mozleywilliams-dnsop-dnsaid-01, 2 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-
                mozleywilliams-dnsop-dnsaid-01>.




  Jimenez                  Expires 9 November 2026               [Page 22]


  Internet-Draft                     AD                           May 2026


     [I-D.mp-agntcy-ads]
                Muscariello, L. and R. Polic, "Agent Directory Service",
                Work in Progress, Internet-Draft, draft-mp-agntcy-ads-01,
                24 February 2026, <https://datatracker.ietf.org/doc/html/
                draft-mp-agntcy-ads-01>.

     [I-D.narajala-ans]
                Huang, K., Narajala, V. S., Habler, I., and A. Sheriff,
                "Agent Name Service (ANS): A Universal Directory for
                Secure AI Agent Discovery and Interoperability", Work in
                Progress, Internet-Draft, draft-narajala-ans-00, 16 May
                2025, <https://datatracker.ietf.org/doc/html/draft-
                narajala-ans-00>.

     [I-D.pioli-agent-discovery]
                Pioli, R., "Agent Registration and Discovery Protocol
                (ARDP)", Work in Progress, Internet-Draft, draft-pioli-
                agent-discovery-01, 24 February 2026,
                <https://datatracker.ietf.org/doc/html/draft-pioli-agent-
                discovery-01>.

     [I-D.zyyhl-agent-networks-framework]
                Zhouye, Yao, K., Yu, M., Han, M., and C. Li, "Framework
                for AI Agent Networks", Work in Progress, Internet-Draft,
                draft-zyyhl-agent-networks-framework-01, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-zyyhl-agent-
                networks-framework-01>.

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

     [MCP-Registry]
                "Model Context Protocol Registry", 2025,
                <https://github.com/modelcontextprotocol/registry>.

     [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
                Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
                <https://www.rfc-editor.org/rfc/rfc6690>.

     [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
                Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
                <https://www.rfc-editor.org/rfc/rfc6763>.

     [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
                Code: The Implementation Status Section", BCP 205,
                RFC 7942, DOI 10.17487/RFC7942, July 2016,
                <https://www.rfc-editor.org/rfc/rfc7942>.




  Jimenez                  Expires 9 November 2026               [Page 23]


  Internet-Draft                     AD                           May 2026


  Appendix A.  Relationship to Other Work

  A.1.  CoRE Resource Directory (RFC 9176)

     The AD is a direct adaptation of the CoRE RD.  The registration,
     update, removal, and lookup interfaces follow the same patterns.  The
     differences reflect the shift from CoAP and CoRE Link Format
     [RFC6690] to HTTP and JSON: structured capability objects replace
     flat link attributes, and interaction protocol is advertised as a
     first-class field.

  A.2.  Per-Agent Metadata Endpoints

     A2A [A2A] serves an Agent Card at /.well-known/agent-card.json; MCP
     [MCP] exchanges server metadata during initialization.  Both describe
     a single agent and both require the client to already know the
     agent's URL.

     The AD complements these by aggregating metadata from many agents
     into a queryable registry.  Clients perform capability-based search
     without prior knowledge of agent addresses.  Once the AD returns a
     matching agent's base URI, the client MAY fetch the agent's own
     metadata endpoint for protocol-specific details before initiating
     interaction.

  A.3.  MCP Registry

     The Model Context Protocol project maintains a public registry
     [MCP-Registry] where MCP servers are catalogued for discovery by MCP-
     compatible clients.  The registry and the AD address overlapping
     concerns from different ends: the MCP Registry is scoped to MCP
     servers and curated by a single project; the AD is protocol-agnostic
     (MCP, A2A, gRPC, and others are all describable) and is specified
     here as an open interface that any operator can implement.  An agent
     registered in the MCP Registry can also appear in an AD instance
     without conflict; the two are complementary rather than
     substitutable.

  A.4.  Agent Transfer Protocol (AGTP)

     [I-D.hood-independent-agtp] proposes an agent-native transport
     protocol over TCP/TLS or QUIC, with agent identity, session
     semantics, and authorization expressed at the wire level rather than
     layered on HTTP.  The AD takes the opposite approach, reusing HTTP
     and JSON as a substrate.  The two are not mutually exclusive: an AD
     instance could register agents reachable over AGTP in the same way it
     registers agents reachable over MCP, A2A, or gRPC, by carrying the
     relevant protocol identifier in the protocols field.



  Jimenez                  Expires 9 November 2026               [Page 24]


  Internet-Draft                     AD                           May 2026


  A.5.  Agent Directory Service (ADS)

     [I-D.mp-agntcy-ads] specifies a system with goals similar to the AD.

     ADS takes a fully decentralized approach: content-addressed
     identifiers (CIDs) for records, a libp2p Kad-DHT for routing, OCI-
     compliant storage (ORAS/zot) for retrieval, and gRPC for the client
     interface.  It defines OASF, a hierarchical skill taxonomy with 15
     top-level categories and 100+ specific skills, used for capability-
     based routing through the DHT.  This provides federation and
     cryptographic integrity at the cost of requiring DHT peers, OCI
     registries, and gRPC infrastructure.

     The AD makes the opposite trade-off: a single HTTP/JSON service with
     no additional infrastructure.  Federation is not built in (see
     Section 2.3) and there is no content-addressed integrity model.  ADS
     targets decentralized deployments where no single operator is
     trusted; the AD targets deployments where a managed directory is
     acceptable.  Interoperability between the two (an AD instance
     indexing ADS records, or vice versa) is not specified in this
     document.

  A.6.  Agent Registration and Discovery Protocol (ARDP)

     [I-D.pioli-agent-discovery] defines a similar registration and
     discovery service with a custom agent: identifier scheme.  The AD
     differs by reusing standard HTTP URIs for agent identity and by
     grounding the design in the RD model.

  A.7.  DNS-Based Agent Discovery

     [I-D.narajala-ans] (ANS) proposes DNS-based agent discovery with PKI
     certificates.  The AD operates at the application layer and does not
     require DNS infrastructure changes.

     DN-ANR [I-D.cui-dns-native-agent-naming-resolution] defines a thin
     DNS resolution layer using FQDNs and SVCB records, explicitly leaving
     capability-based discovery to an upper layer.  The AD can serve as
     that upper layer.  DNS-AID [I-D.mozleywilliams-dnsop-dnsaid] places
     agent metadata in DNS zones for intra-organization discovery; the AD
     provides cross-organization lookup.  The two approaches are
     complementary.









  Jimenez                  Expires 9 November 2026               [Page 25]


  Internet-Draft                     AD                           May 2026


  A.8.  Platform-Specific and On-Chain Registries

     General-purpose service registries (Consul, etcd, Kubernetes service
     discovery) solve service location but do not model agent
     capabilities, interaction protocols, or soft-state registration
     semantics.  The AD addresses the agent-specific aspects that these
     systems lack.

     Azure API Center [Azure-API-Center] provides a centralized agent
     registry within the Azure ecosystem.  The agentregistry project
     [AgentRegistry] offers a SaaS registry with a CLI.  ERC-8004
     [ERC-8004] defines on-chain agent registries on Ethereum.

     These systems are each tied to a single provider: a cloud vendor, a
     SaaS operator, or a blockchain.  The AD is specified by this document
     and can be operated by anyone; clients authenticate to the instance
     they use.

  A.9.  Agent Network Protocol (ANP)

     ANP's Agent Discovery Protocol [ANP-Discovery] defines active
     discovery via /.well-known/agent-descriptions and passive discovery
     where agents register with a search service.  The AD's registration
     model corresponds to ANP's passive mode but specifies the
     registration API concretely.  ANP uses JSON-LD and DIDs; the AD uses
     plain JSON and HTTP URIs.  The broader ANP framework is described in
     [I-D.zyyhl-agent-networks-framework].

  A.10.  Agent Identity Profiles

     The AD's identity and identity_type fields provide an extension point
     for linking registrations to external identity metadata.  The Agent
     Identity Profile (AIP) is one such format, defining a JSON document
     that describes an agent's owner binding, capabilities, attestation
     state, trust posture, and credential lifecycle.  Other formats
     include OpenID Connect Discovery documents and WIMSE workload
     identity endpoints.  The AD does not mandate any particular identity
     schema; it provides the pointer so that clients can verify agents
     through whatever trust framework their deployment requires.

  Appendix B.  Examples

  B.1.  Discovery Flow

     Discovering an agent through the AD involves four steps: locating the
     directory, discovering its interfaces, querying for a matching
     capability, and contacting the agent directly.




  Jimenez                  Expires 9 November 2026               [Page 26]


  Internet-Draft                     AD                           May 2026


        Client                          AD                         Agent
          |                              |                            |
          |  1. Obtain AD URL            |                            |
          |  (DNS-SD/config/.well-known) |                            |
          |                              |                            |
          |  2. GET /.well-known/ad ---->|                            |
          |  <--- lookup URI Template    |                            |
          |                              |                            |
          |  3. GET /ad/l?               |                            |
          |     cap_name=summarize ----->|                            |
          |  <--- matching agents + base |                            |
          |                              |                            |
          |  4. Interact with agent using protocol from lookup -----> |
          |  <--- Response ------------------------------------------ |

                            Figure 2: Discovery Flow

     The steps in detail:

     Step 1: Obtain the AD URL.

     The client already knows the URL of an Agent Directory.  This may
     have been learned through a DNS-SD browse for _ad._tcp, a .well-
     known/ad query to a known host, or simply through static
     configuration.

     https://ad.example.com

     Step 2: Discover the AD's lookup interface.

     The client queries the well-known endpoint to learn the available
     interfaces.

    GET https://ad.example.com/.well-known/ad HTTP/1.1

    HTTP/1.1 200 OK
    Content-Type: application/json

    {
      "registration": "/ad/r",
      "lookup": "/ad/l{?agent,protocol,cap_name,cap_type,tag,page,count}",
      "max_count": 100
    }

     In some deployments the lookup interface path is already known or
     follows a convention, in which case this step can be skipped.

     Step 3: Search for an agent with the desired capability.



  Jimenez                  Expires 9 November 2026               [Page 27]


  Internet-Draft                     AD                           May 2026


     The client expands the lookup URI Template with cap_name=summarize.

  GET https://ad.example.com/ad/l?cap_name=summarize HTTP/1.1

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "agents": [
      {
        "agent": "summarizer-v2",
        "base": "https://agents.example.com/summarizer-v2",
        "description": "Summarizes documents and extracts named entities",
        "protocols": ["a2a"],
        "capabilities": [
          {"name": "summarize", "type": "tool"},
          {"name": "extract_entities", "type": "tool"}
        ],
        "href": "/ad/r/4521"
      }
    ]
  }

     The response includes the agent's base URI and supported protocols,
     giving the client enough information to contact the agent directly.

     Step 4: Interact with the agent.

     The lookup response indicated that summarizer-v2 is reachable over
     A2A.  The client fetches the agent's A2A Agent Card to obtain the
     full task interface before invocation.

  GET https://agents.example.com/summarizer-v2/.well-known/agent-card.json
  HTTP/1.1

  HTTP/1.1 200 OK
  Content-Type: application/json

  { ... A2A Agent Card ... }

     The subsequent task invocation is defined by the interaction protocol
     (A2A in this case, MCP or gRPC in others) and is out of scope for
     this document.

  B.2.  Enterprise Agent Portfolio

     A Publisher at example.com operates three agents behind a single AD.




  Jimenez                  Expires 9 November 2026               [Page 28]


  Internet-Draft                     AD                           May 2026


     Step 1: Agents register with the AD.

     POST /ad/r?agent=ticket-classifier HTTP/1.1
     Host: ad.example.com
     Content-Type: application/json

     {
       "base": "https://agents.example.com/ticket-classifier",
       "description": "Classifies incoming support tickets.",
       "protocols": ["mcp"],
       "capabilities": [
         {"name": "classify_ticket", "type": "tool"},
         {"name": "suggest_priority", "type": "tool"}
       ],
       "vendor": "Example Corp"
     }

     HTTP/1.1 201 Created
     Location: /ad/r/201

     POST /ad/r?agent=knowledge-lookup HTTP/1.1
     Host: ad.example.com
     Content-Type: application/json

     {
       "base": "https://agents.example.com/kb",
       "description": "Searches internal knowledge base.",
       "protocols": ["mcp"],
       "capabilities": [
         {"name": "search_kb", "type": "tool", "tags": ["nlp", "search"]}
       ],
       "vendor": "Example Corp"
     }

     HTTP/1.1 201 Created
     Location: /ad/r/202

     POST /ad/r?agent=order-router HTTP/1.1
     Host: ad.example.com
     Content-Type: application/json

     {
       "base": "https://agents.example.com/order-router",
       "description": "Routes orders to fulfillment systems.",
       "protocols": ["a2a"],
       "capabilities": [
         {"name": "route_order", "type": "tool"}
       ],



  Jimenez                  Expires 9 November 2026               [Page 29]


  Internet-Draft                     AD                           May 2026


       "vendor": "Example Corp"
     }

     HTTP/1.1 201 Created
     Location: /ad/r/203

     Step 2: A client queries for MCP agents.

     GET /ad/l?protocol=mcp HTTP/1.1
     Host: ad.example.com
     Accept: application/json

     HTTP/1.1 200 OK
     Content-Type: application/json

     {
       "agents": [
         {
           "agent": "ticket-classifier",
           "base": "https://agents.example.com/ticket-classifier",
           "description": "Classifies incoming support tickets.",
           "protocols": ["mcp"],
           "capabilities": [
             {"name": "classify_ticket", "type": "tool"},
             {"name": "suggest_priority", "type": "tool"}
           ],
           "href": "/ad/r/201"
         },
         {
           "agent": "knowledge-lookup",
           "base": "https://agents.example.com/kb",
           "description": "Searches internal knowledge base.",
           "protocols": ["mcp"],
           "capabilities": [
             {"name": "search_kb", "type": "tool"}
           ],
           "href": "/ad/r/202"
         }
       ]
     }

  B.3.  Filtered Lookup with Pagination

     A client enumerates MCP agents that expose tool capabilities, one per
     page.






  Jimenez                  Expires 9 November 2026               [Page 30]


  Internet-Draft                     AD                           May 2026


     GET /ad/l?protocol=mcp&cap_type=tool&count=1&page=0 HTTP/1.1
     Host: ad.example.com
     Accept: application/json

     HTTP/1.1 200 OK
     Content-Type: application/json
     Link: </ad/l?protocol=mcp&cap_type=tool&count=1&page=1>; rel="next"

     {
       "agents": [
         {
           "agent": "ticket-classifier",
           "base": "https://agents.example.com/ticket-classifier",
           "description": "Classifies incoming support tickets.",
           "protocols": ["mcp"],
           "capabilities": [
             {"name": "classify_ticket", "type": "tool"},
             {"name": "suggest_priority", "type": "tool"}
           ],
           "href": "/ad/r/201"
         }
       ]
     }

     The client follows the rel="next" link:

     GET /ad/l?protocol=mcp&cap_type=tool&count=1&page=1 HTTP/1.1
     Host: ad.example.com

     HTTP/1.1 200 OK
     Content-Type: application/json

     {
       "agents": [
         {
           "agent": "knowledge-lookup",
           "base": "https://agents.example.com/kb",
           "description": "Searches internal knowledge base.",
           "protocols": ["mcp"],
           "capabilities": [
             {"name": "search_kb", "type": "tool"}
           ],
           "href": "/ad/r/202"
         }
       ]
     }

     No Link: rel="next" header is present, indicating the end of results.



  Jimenez                  Expires 9 November 2026               [Page 31]


  Internet-Draft                     AD                           May 2026


  B.4.  Registration Conflict

     A second entity attempts to register an agent under an already-
     claimed name.

     POST /ad/r?agent=ticket-classifier HTTP/1.1
     Host: ad.example.com
     Authorization: Bearer <token-of-other-entity>
     Content-Type: application/json

     {
       "base": "https://attacker.example.org/ticket-classifier",
       "protocols": ["mcp"],
       "capabilities": [{"name": "classify_ticket", "type": "tool"}]
     }

     HTTP/1.1 409 Conflict
     Content-Type: application/problem+json

     {
       "type": "https://ad.example.com/errors/agent-name-taken",
       "title": "Agent name already registered",
       "detail": "Agent name 'ticket-classifier' already registered.",
       "status": 409
     }

  Appendix C.  Tooling and Integration

     The AD uses application/json for all request and response bodies (and
     application/problem+json for errors).  No custom media types or
     content negotiation is required.

     The HTTP/JSON interface is usable from command-line tools (curl and a
     JSON parser), shell scripts, and CI/CD pipelines without specialized
     client libraries.  The lookup interface can also be exposed as an MCP
     tool, so that an MCP-compatible client performs agent discovery
     through its existing tool-calling mechanism.

  Appendix D.  Implementation Status

     (Boilerplate as per Section 2.1 of [RFC7942]:)

     This section records the status of known implementations of the
     protocol defined by this specification at the time of posting of this
     Internet-Draft, and is based on a proposal described in [RFC7942].
     The description of implementations in this section is intended to
     assist the IETF in its decision processes in progressing drafts to
     RFCs.  Please note that the listing of any individual implementation



  Jimenez                  Expires 9 November 2026               [Page 32]


  Internet-Draft                     AD                           May 2026


     here does not imply endorsement by the IETF.  Furthermore, no effort
     has been spent to verify the information presented here that was
     supplied by IETF contributors.  This is not intended as, and must not
     be construed to be, a catalog of available implementations or their
     features.  Readers are advised to note that other implementations may
     exist.

     According to [RFC7942], "this will allow reviewers and working groups
     to assign due consideration to documents that have the benefit of
     running code, which may serve as evidence of valuable experimentation
     and feedback that have made the implemented protocols more mature.
     It is up to the individual working groups to use this information as
     they see fit".

  D.1.  ad.jaime.win

     Organization:  Ericsson

     Implementation:  https://ad.jaime.win (https://ad.jaime.win)

     Description:  A public AD instance deployed as a Cloudflare Worker
        with a Durable Object for persistent storage.  Implements the
        registration, lookup, and soft-state lifecycle interfaces defined
        in this document.  Source code is available at the GitHub
        repository linked from the deployment.

     Level of Maturity:  Prototype

     Coverage:  All features specified in this document: well-known URI
        discovery (URI Template lookup), agent registration (create,
        update, replace, delete), agent lookup with filtering and Link-
        header pagination, soft-state expiry, and RFC 9457 error
        responses.

     Version Compatibility:  draft-jimenez-agent-directory-00

     Licensing:  MIT

     Contact:  Jaime Jimenez (jaime@iki.fi)

  Appendix E.  Acknowledgments

     The AD design is directly based on the CoRE Resource Directory
     [RFC9176] by Christian Amsüss, Zach Shelby, Michael Koster, Carsten
     Bormann, and Peter van der Stok.






  Jimenez                  Expires 9 November 2026               [Page 33]


  Internet-Draft                     AD                           May 2026


  Appendix F.  Mapping from CoRE RD to AD

     The following table summarizes the conceptual mapping between CoRE RD
     concepts and their AD equivalents.

     +===============+=======================+==========================+
     | CoRE RD (RFC  | AD                    | Notes                    |
     | 9176)         |                       |                          |
     +===============+=======================+==========================+
     | Endpoint (EP) | Agent                 | Software entity that     |
     |               |                       | registers                |
     +---------------+-----------------------+--------------------------+
     | Resource link | Capability            | Structured JSON instead  |
     |               |                       | of link-format           |
     +---------------+-----------------------+--------------------------+
     | /.well-known/ | /.well-known/ad       | Discovery entry point    |
     | core          |                       |                          |
     +---------------+-----------------------+--------------------------+
     | Registration  | Registration (POST    | Same soft-state model    |
     | (POST /rd)    | /ad/r)                |                          |
     +---------------+-----------------------+--------------------------+
     | Registration  | Registration resource | Same lifecycle           |
     | resource      |                       |                          |
     +---------------+-----------------------+--------------------------+
     | Lifetime (lt) | Lifetime (lt)         | Same semantics,          |
     |               |                       | different default        |
     +---------------+-----------------------+--------------------------+
     | Endpoint name | Agent name (agent)    | Same uniqueness          |
     | (ep)          |                       | constraint               |
     +---------------+-----------------------+--------------------------+
     | Resource      | Capabilities embedded | Capabilities are nested  |
     | lookup        | in agent registration | in the registration, not |
     |               |                       | independent resources    |
     +---------------+-----------------------+--------------------------+
     | Endpoint      | GET on the lookup     | Structured filters       |
     | lookup        | endpoint              | instead of link-format   |
     |               |                       | query                    |
     +---------------+-----------------------+--------------------------+
     | Commissioning | Commissioning Tool    | Third-party registration |
     | Tool (CT)     | (CT)                  |                          |
     +---------------+-----------------------+--------------------------+
     | application/  | application/json      | Representation format    |
     | link-format   |                       |                          |
     +---------------+-----------------------+--------------------------+

                                   Table 2





  Jimenez                  Expires 9 November 2026               [Page 34]


  Internet-Draft                     AD                           May 2026


  Author's Address

     Jaime Jimenez
     Ericsson
     Email: jaime@iki.fi














































  Jimenez                  Expires 9 November 2026               [Page 35]


name: draft-agentir-aepp
rev: 00
title: Agent Execution and Payment Protocol (AEPP)
time: 2026-05-15T17:22:48Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-16T17:22:48Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:41.698390+00:00
source: ietf
abstract:
  This document defines the Agent Execution and Payment Protocol
     (AEPP), a standardized protocol layer for executing AI agents and
     verifying payment for agent tasks on the open internet.  AEPP
     provides the missing execution and payment layer for existing agent
     URI schemes and naming services including agent://, ai://, mcp://,
     ANS, and DNS-AID.  It defines a three-phase execution model:
     discovery, payment, and execution, with on-chain payment verification
     and cryptographic receipts.  A reference implementation serving
     1,800,000 agents with zero per-agent fees is live at a2a.agentir.com.

full_text:
  Internet Engineering Task Force                                 E. Spink
  Internet-Draft                                           Agentir Network
  Intended status: Informational                               15 May 2026
  Expires: 16 November 2026


                Agent Execution and Payment Protocol (AEPP)
                           draft-agentir-aepp-00

  Abstract

     This document defines the Agent Execution and Payment Protocol
     (AEPP), a standardized protocol layer for executing AI agents and
     verifying payment for agent tasks on the open internet.  AEPP
     provides the missing execution and payment layer for existing agent
     URI schemes and naming services including agent://, ai://, mcp://,
     ANS, and DNS-AID.  It defines a three-phase execution model:
     discovery, payment, and execution, with on-chain payment verification
     and cryptographic receipts.  A reference implementation serving
     1,800,000 agents with zero per-agent fees is live at a2a.agentir.com.

  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 16 November 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



  Spink                   Expires 16 November 2026                [Page 1]


  Internet-Draft                    AEPP                          May 2026


     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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Phase 1 — Discovery . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Request . . . . . . . . . . . . . . . . . . . . . . . . .   4
       4.2.  Response  . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.  Phase 2 — Payment . . . . . . . . . . . . . . . . . . . . . .   5
       5.1.  Reference Payment Implementation  . . . . . . . . . . . .   5
       5.2.  Autonomous Payment Example  . . . . . . . . . . . . . . .   6
     6.  Phase 3 — Execution . . . . . . . . . . . . . . . . . . . . .   6
       6.1.  Request . . . . . . . . . . . . . . . . . . . . . . . . .   6
       6.2.  Payment Verification  . . . . . . . . . . . . . . . . . .   7
       6.3.  Response  . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.  Universal Clip  . . . . . . . . . . . . . . . . . . . . . . .   7
       7.1.  Supported Input Protocols . . . . . . . . . . . . . . . .   8
       7.2.  Registration  . . . . . . . . . . . . . . . . . . . . . .   8
       7.3.  WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.  Replay Protection . . . . . . . . . . . . . . . . . . . . . .   9
     9.  Relationship to Existing Standards  . . . . . . . . . . . . .   9
       9.1.  ANS — Agent Name Service  . . . . . . . . . . . . . . . .   9
       9.2.  DNS-AID . . . . . . . . . . . . . . . . . . . . . . . . .   9
       9.3.  W3C DID . . . . . . . . . . . . . . . . . . . . . . . . .   9
       9.4.  x402 and L402 . . . . . . . . . . . . . . . . . . . . . .   9
       9.5.  Google A2A Protocol . . . . . . . . . . . . . . . . . . .  10
       9.6.  OpenAPI . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10. Fee Model Principles  . . . . . . . . . . . . . . . . . . . .  10
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  10
       11.1.  Payment Verification . . . . . . . . . . . . . . . . . .  10
       11.2.  Replay Protection  . . . . . . . . . . . . . . . . . . .  10
       11.3.  Identity Verification  . . . . . . . . . . . . . . . . .  11
       11.4.  Man-in-the-Middle  . . . . . . . . . . . . . . . . . . .  11
     12. Reference Implementation  . . . . . . . . . . . . . . . . . .  11
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
       14.1.  Normative References . . . . . . . . . . . . . . . . . .  12
       14.2.  Informative References . . . . . . . . . . . . . . . . .  12
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12








  Spink                   Expires 16 November 2026                [Page 2]


  Internet-Draft                    AEPP                          May 2026


  1.  Introduction

     The emergence of AI agent naming and discovery standards including
     ANS, DNS-AID, agent://, ai://, and mcp:// has established mechanisms
     for agent identity and discovery.  However, none of these standards
     define how to:

     a.  Execute a task against a discovered agent

     b.  Pay for agent execution in a standardized way

     c.  Verify payment cryptographically before execution

     d.  Receive a verifiable execution receipt

     e.  Prevent replay attacks on payment transactions

     AEPP fills this gap.  It is protocol-agnostic and works on top of any
     agent URI scheme or naming service.  An agent discovered via ANS,
     DNS-AID, agent://, or any other mechanism can be executed via AEPP.

     AEPP is designed to be:

     *  Fee-free per agent — no per-registration or per-naming fees

     *  Open — any agent network may implement AEPP

     *  Federated — no central execution authority

     *  Verifiable — all payments cryptographically verified on-chain

     *  Interoperable — works with all existing agent standards

  2.  Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in RFC 2119.

     Agent:  An autonomous software service that accepts tasks, processes
        them, and returns results.

     Executor:  The client initiating an agent task execution.

     Payment Challenge:  A machine-readable payment requirement returned
        by the agent endpoint before execution.

     Execution Receipt:  A cryptographically verifiable record of task



  Spink                   Expires 16 November 2026                [Page 3]


  Internet-Draft                    AEPP                          May 2026


        completion and payment.

     Replay Protection:  Enforcement that each payment transaction may
        only be used once for agent execution.

  3.  Protocol Overview

     AEPP defines a three-phase execution model:

     Phase 1 — DISCOVERY
       Client sends GET to agent endpoint
       Agent returns 402 Payment Required + payment challenge

     Phase 2 — PAYMENT
       Client satisfies payment challenge
       Client obtains cryptographic payment proof (transaction hash)

     Phase 3 — EXECUTION
       Client sends POST with task + payment proof
       Agent verifies payment on-chain
       Agent executes task
       Agent returns result + execution receipt

  4.  Phase 1 — Discovery

  4.1.  Request

     GET https://{agent-endpoint}/?id={agent_id}
     Accept: application/json

  4.2.  Response

     The agent MUST return HTTP 402 Payment Required with a payment
     challenge in both the response body and the PAYMENT-REQUIRED header
     (base64 encoded).
















  Spink                   Expires 16 November 2026                [Page 4]


  Internet-Draft                    AEPP                          May 2026


     HTTP/1.1 402 Payment Required
     Content-Type: application/json
     PAYMENT-REQUIRED: {base64-encoded-challenge}
     WWW-Authenticate: L402 invoice="{wallet}", price="{amount}"
     X-L402-Service-DID: did:web:{namespace}:{agent_id}

     {
       "x402Version": 2,
       "error": "Payment required",
       "resource": {
         "url": "https://{endpoint}/?id={agent_id}",
         "description": "{agent capability}",
         "mimeType": "application/json"
       },
       "accepts": [{
         "scheme": "exact",
         "network": "eip155:8453",
         "amount": "25000",
         "asset": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
         "payTo": "{agent-wallet-address}",
         "maxTimeoutSeconds": 60
       }],
       "agent": {
         "id": "{agent_id}",
         "name": "{agent name}",
         "did": "did:web:{namespace}:{agent_id}",
         "price_usdc": 0.025
       }
     }

  5.  Phase 2 — Payment

     The executor satisfies the payment challenge using any compatible
     payment method.  The reference implementation uses USDC on Base
     mainnet (eip155:8453).

     AEPP does not mandate a specific payment network or currency.
     Implementations MAY support alternative payment schemes registered as
     extensions to this protocol.

     The payment proof MUST be a cryptographically verifiable transaction
     identifier that the agent can independently verify against the
     payment network.

  5.1.  Reference Payment Implementation






  Spink                   Expires 16 November 2026                [Page 5]


  Internet-Draft                    AEPP                          May 2026


     Network:  Base Mainnet (eip155:8453)
     Currency: USDC
     Contract: 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913
     Amount:   As specified in payment challenge
     Method:   ERC-20 transfer to agent wallet address
     Proof:    Transaction hash from payment network

  5.2.  Autonomous Payment Example

     // Read payment details from challenge
     const challenge = JSON.parse(
       Buffer.from(
         response.headers.get("PAYMENT-REQUIRED"),
         "base64"
       ).toString()
     );
     const { payTo, amount, asset } = challenge.accepts[0];

     // Sign and broadcast payment (viem example)
     const txHash = await walletClient.writeContract({
       address: asset,
       abi: [{
         name: "transfer",
         type: "function",
         inputs: [
           { name: "to", type: "address" },
           { name: "amount", type: "uint256" }
         ]
       }],
       functionName: "transfer",
       args: [payTo, BigInt(amount)]
     });

  6.  Phase 3 — Execution

  6.1.  Request

     POST https://{agent-endpoint}/?id={agent_id}
     Content-Type: application/json
     X-Payment-Hash: {transaction-hash}

     {
       "prompt": "task description or question"
     }







  Spink                   Expires 16 November 2026                [Page 6]


  Internet-Draft                    AEPP                          May 2026


  6.2.  Payment Verification

     Upon receiving the execution request the agent MUST:

     1.  Extract the payment proof from X-Payment-Hash header

     2.  Verify the transaction exists on the payment network

     3.  Verify the transaction recipient matches the agent wallet

     4.  Verify the transaction amount meets the required amount

     5.  Verify the transaction hash has not been used previously (replay
         protection)

     6.  Record the transaction hash as used before execution

     If any verification step fails the agent MUST return HTTP 403
     Forbidden.

  6.3.  Response

     HTTP/1.1 200 OK
     Content-Type: application/json

     {
       "id": "did:web:{namespace}:{agent_id}",
       "result": "{agent response}",
       "receipt": {
         "protocol": "AEPP/1.0",
         "currency": "USDC",
         "amount": 0.025,
         "chain": "eip155:8453",
         "tx": "{transaction-hash}",
         "agent_did": "did:web:{namespace}:{agent_id}",
         "verified_at": "{ISO-8601-timestamp}"
       }
     }

  7.  Universal Clip

     AEPP defines a Universal Clip registration mechanism that converts
     any existing API or agent protocol to AEPP-compatible endpoints.
     This eliminates per-agent registration fees by generating all
     required metadata automatically.






  Spink                   Expires 16 November 2026                [Page 7]


  Internet-Draft                    AEPP                          May 2026


  7.1.  Supported Input Protocols

     *  REST APIs — any JSON HTTP endpoint

     *  Model Context Protocol (MCP)

     *  OpenAI plugin manifest

     *  LangChain tools

     *  Google A2A protocol

     *  ANS registered agents

     *  DNS-AID discovered agents

  7.2.  Registration

     Any service registers with a single POST request:

  POST https://a2a.agentir.com/ans/register
  Content-Type: application/json

  {
    "name": "Service Name",
    "endpoint": "https://api.example.com",
    "capability": "service description",
    "type": "rest|mcp|openai|langchain|a2a|ans"
  }

  Response:
  {
    "did": "did:web:a2a.agentir.com:{agent_id}",
    "endpoint": "https://a2a.agentir.com/?id={agent_id}",
    "openapi": "https://a2a.agentir.com/openapi.json?id={agent_id}",
    "agent_card": "https://a2a.agentir.com/.well-known/agent.json?id={agent_id}",
    "aepp": "AEPP/1.0 ready",
    "fee": "0.00 per registration"
  }

     Registration is free.  AEPP implementations MUST NOT charge per-agent
     registration fees.  Revenue models MUST be based on execution, not
     naming or registration.

  7.3.  WHOIS

     Any registered agent is queryable via WHOIS:




  Spink                   Expires 16 November 2026                [Page 8]


  Internet-Draft                    AEPP                          May 2026


     GET https://a2a.agentir.com/whois?id={agent_id}
     GET https://a2a.agentir.com/whois?did=did:web:a2a.agentir.com:{id}

     Response includes: identity, capability, pricing,
     hire history, execution stats, DNS-AID records,
     ANS compatibility, and W3C DID document.

  8.  Replay Protection

     AEPP implementations MUST enforce replay protection.  Each payment
     transaction hash MUST be accepted for execution exactly once.
     Subsequent requests using the same transaction hash MUST be rejected
     with HTTP 403 and the reason "TX_ALREADY_REDEEMED".

     Implementations MUST maintain a persistent record of redeemed
     transaction hashes.  This record MUST survive service restarts.

  9.  Relationship to Existing Standards

  9.1.  ANS — Agent Name Service

     ANS provides agent identity and naming via DNS and PKI.  AEPP
     provides the execution and payment layer that ANS does not define.
     An ANS-registered agent MAY expose an AEPP-compatible endpoint.  AEPP
     complements ANS without replacing it.

  9.2.  DNS-AID

     DNS-AID provides agent discovery via DNS records.  AEPP provides
     execution once an agent is discovered via DNS-AID.  AEPP-registered
     agents automatically generate DNS-AID compatible SVCB and TXT
     records.

  9.3.  W3C DID

     Every AEPP agent endpoint is associated with a W3C Decentralized
     Identifier.  The DID document is resolvable at the agent's .well-
     known endpoint.  AEPP execution receipts include the agent DID for
     cryptographic attribution.

  9.4.  x402 and L402

     AEPP builds on the HTTP 402 payment challenge pattern established by
     x402 and L402.  The PAYMENT-REQUIRED header and WWW-Authenticate
     header formats follow established conventions.  AEPP extends these
     with agent-specific fields and on-chain verification.





  Spink                   Expires 16 November 2026                [Page 9]


  Internet-Draft                    AEPP                          May 2026


  9.5.  Google A2A Protocol

     The Google Agent-to-Agent (A2A) protocol defines agent communication
     patterns.  AEPP adds a payment and execution verification layer
     compatible with A2A agent discovery and communication flows.

  9.6.  OpenAPI

     Every AEPP-registered agent automatically generates an OpenAPI 3.1.0
     specification from capability metadata.  The spec includes x402 as a
     security scheme definition.

  10.  Fee Model Principles

     AEPP establishes the following principles for agent execution fee
     models:

     1.  Registration MUST be free.  No per-agent naming or registration
         fees shall be required.

     2.  Discovery MUST be free.  Agent search and capability lookup shall
         not require payment.

     3.  Execution MAY require payment.  Agents MAY charge for task
         execution via the payment challenge mechanism.

     4.  Payment terms MUST be machine-readable.  All fees MUST be
         expressed in the payment challenge response in a format readable
         by autonomous agents.

     5.  Payment MUST be direct.  Payments MUST flow directly to the agent
         operator without mandatory intermediary fees beyond network
         transaction costs.

  11.  Security Considerations

  11.1.  Payment Verification

     All payments MUST be verified on-chain before execution.  Agents MUST
     NOT execute tasks based on unverified payment claims.  Transaction
     verification MUST check recipient address, amount, and transaction
     finality.

  11.2.  Replay Protection

     Transaction hashes are single-use.  Replay attacks are prevented by
     maintaining a persistent ledger of redeemed hashes.  See Section 7
     for requirements.



  Spink                   Expires 16 November 2026               [Page 10]


  Internet-Draft                    AEPP                          May 2026


  11.3.  Identity Verification

     Agent identity is anchored to W3C DIDs with blockchain account
     verification.  Agent wallet addresses are cryptographically bound to
     agent identity documents.

  11.4.  Man-in-the-Middle

     All AEPP endpoints MUST use TLS.  Payment challenges MUST include the
     exact recipient wallet address.  Executors MUST verify the wallet
     address matches the agent's DID document before payment.

  12.  Reference Implementation

     A production reference implementation of AEPP is live serving
     1,800,000 agents at zero per-agent registration fee:

     Gateway:       https://a2a.agentir.com
     Registration:  https://a2a.agentir.com/ans/register
     Resolution:    https://a2a.agentir.com/ans/resolve
     WHOIS:         https://a2a.agentir.com/whois
     OpenAPI:       https://a2a.agentir.com/openapi.json
     Discovery:     https://a2a.agentir.com/.well-known/ai-plugin.json
     Search:        https://a2a.agentir.com/search?q={query}
     CLI:           npx agentir (npm registry)

     Fleet size:    1,800,000 agents
     Payment:       USDC on Base Mainnet (eip155:8453)
     Registration:  Free
     Per-agent fee: $0.00

     The implementation demonstrates all AEPP phases including Universal
     Clip translation, on-chain payment verification, replay protection,
     W3C DID per agent, ANS and DNS-AID compatibility, semantic vector
     search, and persistent cross-device agent memory.

  13.  IANA Considerations

     This document requests registration of the following HTTP header
     fields:

     *  PAYMENT-REQUIRED — base64 encoded payment challenge

     *  X-Payment-Hash — payment transaction proof

     *  X-L402-Service-DID — agent DID for L402 flows





  Spink                   Expires 16 November 2026               [Page 11]


  Internet-Draft                    AEPP                          May 2026


     This document requests registration of the AEPP protocol identifier
     in the appropriate IANA registry.

  14.  References

  14.1.  Normative References

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

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

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

  14.2.  Informative References

     [A2A]      Agentir Network, "Agent Execution and Payment Protocol
                Reference Implementation", 2026,
                <https://a2a.agentir.com>.

     [AEPP-CLI] Agentir Network, "Agentir CLI — AEPP Reference Client",
                2026, <https://www.npmjs.com/package/agentir>.

     [ANS]      GoDaddy Inc., "Agent Name Service", May 2026.

     [DNS-AID]  Mozley, J. and N. Williams, "DNS for AI Discovery", March
                2026, <https://datatracker.ietf.org/doc/draft-
                mozleywilliams-dnsop-dnsaid/>.

     [W3C-DID]  W3C, "Decentralized Identifiers (DIDs) v1.0", 2022,
                <https://www.w3.org/TR/did-core/>.

     [x402]     x402.org, "HTTP 402 Payment Protocol", 2026,
                <https://x402.org>.

  Author's Address

     Edward Spink
     Agentir Network
     Email: support@agentir.com
     URI:   https://agentir.com





  Spink                   Expires 16 November 2026               [Page 12]


name: draft-somoza-atn-agent-trust-negotiation
rev: 00
title: Agent Trust Negotiation: Capability, Delegation, and Provenance Binding for AI Agents
time: 2026-05-17T21:56:53Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-18T21:56:53Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:41.698401+00:00
source: ietf
abstract:
  This document defines the Agent Trust Negotiation (ATN) protocol.
     ATN sits above existing DNS-based agent discovery mechanisms and
     answers questions that discovery alone cannot: what is the agent
     permitted to do, under whose authority, with what provenance, and how
     do two agents reach a verifiable working agreement.

     ATN binds four artifacts to a DNS-discovered agent identity:

full_text:
  Network Working Group                                          E. Somoza
  Internet-Draft                                               Independent
  Intended status: Experimental                                17 May 2026
  Expires: 18 November 2026


  Agent Trust Negotiation: Capability, Delegation, and Provenance Binding
                               for AI Agents
                draft-somoza-atn-agent-trust-negotiation-00

  Abstract

     This document defines the Agent Trust Negotiation (ATN) protocol.
     ATN sits above existing DNS-based agent discovery mechanisms and
     answers questions that discovery alone cannot: what is the agent
     permitted to do, under whose authority, with what provenance, and how
     do two agents reach a verifiable working agreement.

     ATN binds four artifacts to a DNS-discovered agent identity:

     1.  A Capability Manifest expressing what the agent is willing to do,
         under what conditions, and with what constraints.

     2.  A Delegation Chain proving authorized principal scope and
         revocation paths.

     3.  A Provenance Attestation proving build-time and runtime
         integrity.

     4.  A Session Receipt produced at handshake completion, recording the
         negotiated scope.

     ATN defines the handshake state machine that consumes these artifacts
     to produce a mutually verified, scope-bounded agent session, and a
     session receipt suitable for transparency log inclusion.

     ATN is transport-independent above the DNS layer and compatible with
     existing discovery proposals including AID [AID], DNS-AID [DNS-AID],
     and ANS v2 [ANSv2].

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.







  Somoza                  Expires 18 November 2026                [Page 1]


  Internet-Draft           agent-trust-negotiation                May 2026


     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 18 November 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  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   6
       1.3.  Choice of Venue . . . . . . . . . . . . . . . . . . . . .   6
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   7
       2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   7
     3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   7
     4.  DNS Binding . . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.  Binding Tags for TXT-Based Discovery  . . . . . . . . . .   8
         4.1.1.  Example (binding ATN to an AID-style record)  . . . .   9
       4.2.  Binding ParamKeys for SVCB-Based Discovery  . . . . . . .   9
         4.2.1.  Example (binding ATN to a DNS-AID-style SVCB
                 record) . . . . . . . . . . . . . . . . . . . . . . .   9
       4.3.  ATN Index Document  . . . . . . . . . . . . . . . . . . .   9
     5.  Capability Manifest . . . . . . . . . . . . . . . . . . . . .  10
       5.1.  Capability Object Structure . . . . . . . . . . . . . . .  10
       5.2.  Schema Binding  . . . . . . . . . . . . . . . . . . . . .  12
       5.3.  Structure . . . . . . . . . . . . . . . . . . . . . . . .  12
       5.4.  Dimension Semantics . . . . . . . . . . . . . . . . . . .  14
       5.5.  Key Properties  . . . . . . . . . . . . . . . . . . . . .  15



  Somoza                  Expires 18 November 2026                [Page 2]


  Internet-Draft           agent-trust-negotiation                May 2026


       5.6.  Refusal Semantics . . . . . . . . . . . . . . . . . . . .  15
     6.  Delegation Chain  . . . . . . . . . . . . . . . . . . . . . .  15
       6.1.  Structure . . . . . . . . . . . . . . . . . . . . . . . .  15
       6.2.  Verification  . . . . . . . . . . . . . . . . . . . . . .  16
     7.  Provenance Attestation  . . . . . . . . . . . . . . . . . . .  16
       7.1.  Structure . . . . . . . . . . . . . . . . . . . . . . . .  17
       7.2.  Properties  . . . . . . . . . . . . . . . . . . . . . . .  17
     8.  The Agent Trust Handshake (ATH) . . . . . . . . . . . . . . .  17
       8.1.  State Machine . . . . . . . . . . . . . . . . . . . . . .  17
       8.2.  ATH_HELLO . . . . . . . . . . . . . . . . . . . . . . . .  18
       8.3.  ATH_OFFER . . . . . . . . . . . . . . . . . . . . . . . .  19
       8.4.  ATH_ACCEPT  . . . . . . . . . . . . . . . . . . . . . . .  20
       8.5.  ATH_RECEIPT . . . . . . . . . . . . . . . . . . . . . . .  20
       8.6.  Handshake Limits  . . . . . . . . . . . . . . . . . . . .  20
     9.  Capability Intersection Algebra . . . . . . . . . . . . . . .  21
       9.1.  Identity Rule . . . . . . . . . . . . . . . . . . . . . .  21
       9.2.  Per-Dimension Rules . . . . . . . . . . . . . . . . . . .  21
       9.3.  Refusal Override  . . . . . . . . . . . . . . . . . . . .  22
       9.4.  Worked Example  . . . . . . . . . . . . . . . . . . . . .  22
     10. Mutual Trust Mode . . . . . . . . . . . . . . . . . . . . . .  24
     11. Version Negotiation and Algorithm Agility . . . . . . . . . .  24
       11.1.  Version Negotiation  . . . . . . . . . . . . . . . . . .  24
       11.2.  Algorithm Agility  . . . . . . . . . . . . . . . . . . .  25
       11.3.  Post-Quantum Transition  . . . . . . . . . . . . . . . .  25
     12. Compatibility with Existing Discovery Protocols . . . . . . .  26
       12.1.  With AID AID . . . . . . . . . . . . . . . . . . . . . .  26
       12.2.  With DNS-AID DNS-AID . . . . . . . . . . . . . . . . . .  26
       12.3.  With ANS v2 ANSv2  . . . . . . . . . . . . . . . . . . .  26
       12.4.  Multi-Discovery Tolerance  . . . . . . . . . . . . . . .  26
     13. Relationship to Existing Identity, Authorization, and
             Attestation Frameworks  . . . . . . . . . . . . . . . . .  26
       13.1.  OAuth 2.0 and GNAP . . . . . . . . . . . . . . . . . . .  27
       13.2.  SPIFFE Workload Identity . . . . . . . . . . . . . . . .  27
       13.3.  Mutual TLS . . . . . . . . . . . . . . . . . . . . . . .  28
       13.4.  RATS Remote Attestation  . . . . . . . . . . . . . . . .  28
       13.5.  SCITT Transparency . . . . . . . . . . . . . . . . . . .  29
       13.6.  Composition Summary  . . . . . . . . . . . . . . . . . .  29
       13.7.  When to Use What . . . . . . . . . . . . . . . . . . . .  30
     14. Security Considerations . . . . . . . . . . . . . . . . . . .  31
       14.1.  Threat Model . . . . . . . . . . . . . . . . . . . . . .  31
       14.2.  Artifact Authenticity  . . . . . . . . . . . . . . . . .  31
       14.3.  Enforcement Posture: Evidence, Not Prevention  . . . . .  31
       14.4.  Delegation Forgery . . . . . . . . . . . . . . . . . . .  32
       14.5.  Session Receipt Tampering  . . . . . . . . . . . . . . .  33
       14.6.  Replay . . . . . . . . . . . . . . . . . . . . . . . . .  33
       14.7.  Provenance Attestation Limits  . . . . . . . . . . . . .  33
     15. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  33
       15.1.  Negotiation Observability  . . . . . . . . . . . . . . .  33



  Somoza                  Expires 18 November 2026                [Page 3]


  Internet-Draft           agent-trust-negotiation                May 2026


       15.2.  Witness Aggregation  . . . . . . . . . . . . . . . . . .  33
       15.3.  Minimum Disclosure . . . . . . . . . . . . . . . . . . .  33
     16. Operational Considerations  . . . . . . . . . . . . . . . . .  33
       16.1.  Session Establishment vs Per-Call Latency  . . . . . . .  34
       16.2.  Latency Budget . . . . . . . . . . . . . . . . . . . . .  34
       16.3.  Optimization Techniques  . . . . . . . . . . . . . . . .  36
       16.4.  Session Lifetime . . . . . . . . . . . . . . . . . . . .  36
       16.5.  Deployments Where ATN Is Appropriate . . . . . . . . . .  37
       16.6.  Deployments Where ATN Is Not Appropriate . . . . . . . .  37
     17. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  37
       17.1.  SVCB ParamKey Registrations  . . . . . . . . . . . . . .  37
       17.2.  ATN Capability Registry  . . . . . . . . . . . . . . . .  38
       17.3.  ATN Capability Dimension Registries  . . . . . . . . . .  39
       17.4.  ATN Refusal Category Registry  . . . . . . . . . . . . .  40
       17.5.  Well-Known URI Registration  . . . . . . . . . . . . . .  41
     18. References  . . . . . . . . . . . . . . . . . . . . . . . . .  41
       18.1.  Normative References . . . . . . . . . . . . . . . . . .  41
       18.2.  Informative References . . . . . . . . . . . . . . . . .  42
     Appendix A.  Complete Example Flow  . . . . . . . . . . . . . . .  43
       A.1.  Step 1: Discovery . . . . . . . . . . . . . . . . . . . .  43
       A.2.  Step 2: Index Document Fetch  . . . . . . . . . . . . . .  43
       A.3.  Step 3: Artifact Fetch and Verification . . . . . . . . .  43
       A.4.  Step 4: ATH_HELLO . . . . . . . . . . . . . . . . . . . .  44
       A.5.  Step 5: ATH_OFFER . . . . . . . . . . . . . . . . . . . .  44
       A.6.  Step 6: ATH_ACCEPT  . . . . . . . . . . . . . . . . . . .  45
       A.7.  Step 7: ATH_RECEIPT . . . . . . . . . . . . . . . . . . .  45
       A.8.  Step 8: Session and Audit . . . . . . . . . . . . . . . .  46
     Appendix B.  Design Rationale . . . . . . . . . . . . . . . . . .  46
       B.1.  Why a Negotiation Layer . . . . . . . . . . . . . . . . .  46
       B.2.  Why Four Artifacts  . . . . . . . . . . . . . . . . . . .  46
       B.3.  Why Refusals Are First-Class  . . . . . . . . . . . . . .  47
       B.4.  Why Intersection Algebra Is Specified . . . . . . . . . .  47
       B.5.  Why SCITT for Receipts  . . . . . . . . . . . . . . . . .  47
     Appendix C.  Implementation Status  . . . . . . . . . . . . . . .  47
       C.1.  ATN Reference Prototype . . . . . . . . . . . . . . . . .  47
     Appendix D.  Acknowledgments  . . . . . . . . . . . . . . . . . .  48
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  48

  1.  Introduction

     Recent IETF work has converged on DNS-based discovery for AI agents.
     Multiple drafts now define how to locate an agent's endpoint and
     verify its cryptographic identity given a domain name.  These efforts
     answer two questions: _where is the agent_ and _who is the agent_.

     They do not answer the questions that arise immediately after:

     *  What is the agent permitted to do, and under what constraints?



  Somoza                  Expires 18 November 2026                [Page 4]


  Internet-Draft           agent-trust-negotiation                May 2026


     *  Under whose authority is the agent operating?

     *  What is the provenance of the agent's software, model, and
        configuration?

     *  How do two agents reach a mutually verifiable working agreement
        before any task begins?

     *  What evidence remains after the session ends, and how is it
        audited?

     This document defines the Agent Trust Negotiation (ATN) protocol to
     address these gaps.  ATN is the layer above discovery.  It assumes
     the discovery layer has located an endpoint and authenticated an
     identity through one of the existing mechanisms.  ATN then negotiates
     the trust relationship.

     The design has four parts:

     1.  Four structured artifacts (Capability Manifest, Delegation Chain,
         Provenance Attestation, Session Receipt) that can be pointed to
         from any DNS-based discovery record.

     2.  A handshake protocol over HTTPS that exchanges and verifies the
         artifacts between two agents.

     3.  A capability intersection algorithm that yields the negotiated
         session scope.

     4.  A receipt format suitable for SCITT-style transparency log
         inclusion.

     ATN deliberately does not introduce a new discovery mechanism.  It
     builds on existing work and adds the negotiation layer that the agent
     ecosystem currently lacks.

  1.1.  Scope

     In scope:

     *  Format and semantics of the four ATN artifacts.

     *  The Agent Trust Handshake (ATH) state machine.

     *  Capability intersection algebra.

     *  DNS bindings to point from a discovery record to ATN artifacts.




  Somoza                  Expires 18 November 2026                [Page 5]


  Internet-Draft           agent-trust-negotiation                May 2026


     *  IANA registrations for ATN-specific identifiers.

     Out of scope:

     *  Discovery of the agent itself (use [AID], [DNS-AID], [ANSv2], or
        equivalent).

     *  Endpoint authentication (delegated to the discovery layer).

     *  Application protocol (delegated to MCP, A2A, OpenAPI, or
        equivalent).

     *  In-organization service-to-service identity (see [SPIFFE]).

     *  Reputation distribution.

     *  Behavioral attestation.

  1.2.  Non-Goals

     *  ATN does NOT define a new DNS record type.

     *  ATN does NOT replace any existing discovery proposal.

     *  ATN does NOT introduce a centralized trust authority.

     *  ATN does NOT enforce policy.  It produces verifiable evidence of
        declared and negotiated policy that downstream systems can audit.

  1.3.  Choice of Venue

     ATN's choice of IETF as the venue follows from its dependencies.  The
     discovery substrate is DNS [RFC4033] and SVCB [RFC9460], both IETF
     standards.  The attestation architecture is RATS [RFC9334].  The
     transparency log is SCITT.  The signature format is JWS [RFC7515].
     The mutual authentication transport is TLS [RFC8446].  The
     authorization frameworks ATN composes with are OAuth [RFC6749] and
     GNAP [RFC9635].

     ATN is the composition of IETF primitives into a peer-to-peer agent
     trust handshake.  Standardizing the composition in any other venue
     would fork the primitive stack and create alignment problems.  The
     natural home for the composition is the same venue that standardized
     the primitives.







  Somoza                  Expires 18 November 2026                [Page 6]


  Internet-Draft           agent-trust-negotiation                May 2026


  2.  Conventions and Definitions

     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.

  2.1.  Terminology

     Agent  An automated software entity that initiates network
        interactions on behalf of, or with delegated authority from, a
        principal, without per-interaction human authorization.

     Initiator  The agent that opens the trust handshake.

     Responder  The agent that answers the trust handshake.

     Capability Manifest  A signed JSON [RFC8259] document declaring what
        an agent is willing to do, under what conditions, and with what
        constraints.

     Delegation Chain  A signed sequence of authorization statements
        binding the agent to a principal, with explicit scope, time
        bounds, and revocation pointers.

     Provenance Attestation  A signed document proving build-time and
        runtime characteristics of the agent.

     Session Receipt  A signed record produced at handshake completion,
        summarizing the negotiated scope and identities, suitable for
        transparency log inclusion.

     Negotiated Scope  The intersection of two agents' capability sets,
        time windows, authorization scopes, and operational constraints,
        as determined by the handshake.

  3.  Architecture Overview

     ATN defines four roles:

     1.  Agent Operator: publishes the DNS discovery record and the ATN
         artifacts.

     2.  Agent: the runtime entity, in either Initiator or Responder mode
         at any moment.





  Somoza                  Expires 18 November 2026                [Page 7]


  Internet-Draft           agent-trust-negotiation                May 2026


     3.  Principal: the human, organization, or other agent that
         authorized the agent through the Delegation Chain.

     4.  Witness: an optional third party that can pre-verify ATN
         artifacts and publish endorsements (e.g., via SCITT [SCITT]).

     ATN layers above discovery:

     +----------------------------------------------+
     |  Application Layer (MCP, A2A, OpenAPI, ...)  |
     +----------------------------------------------+
     |  Agent Trust Negotiation (this document)     |
     +----------------------------------------------+
     |  Discovery and Identity                      |
     |  (AID, DNS-AID, ANS v2, equivalents)         |
     +----------------------------------------------+
     |  DNS, DNSSEC, TLS, HTTPS                     |
     +----------------------------------------------+

     The handshake order is:

     1.  Discovery: Initiator resolves the Responder's discovery record
         via DNS.

     2.  Artifact fetch: Initiator retrieves the four ATN artifacts
         referenced by the discovery record.

     3.  Handshake: Initiator opens the ATN handshake.  Both parties
         exchange artifacts and verify signatures.

     4.  Negotiation: Both parties compute the capability intersection.

     5.  Receipt: Both parties produce a signed Session Receipt covering
         the negotiated scope.

     6.  Session: Application traffic proceeds within the negotiated
         scope.

  4.  DNS Binding

     ATN does not define its own DNS records.  Instead, it specifies how
     to point to ATN artifacts from existing discovery records.

  4.1.  Binding Tags for TXT-Based Discovery

     The following tags MAY be added to TXT-based discovery records
     (compatible with the [AID] format and the format defined in companion
     documents):



  Somoza                  Expires 18 November 2026                [Page 8]


  Internet-Draft           agent-trust-negotiation                May 2026


         +============+==============================================+
         | Tag        | Description                                  |
         +============+==============================================+
         | atn        | Absolute HTTPS URI of an ATN Index Document. |
         +------------+----------------------------------------------+
         | atn-digest | Hex SHA-256 digest of the Index Document.    |
         +------------+----------------------------------------------+

                                    Table 1

     The ATN Index Document is a JSON file pointing to the four artifacts.
     Indirection through an Index Document keeps the DNS record small.

  4.1.1.  Example (binding ATN to an AID-style record)

  _agent.example.com.  3600  IN  TXT  ( "v=aid1; "
                                         "u=https://agent.example.com/mcp; "
                                         "p=mcp; "
                                         "k=z7rW8rTq8o4mM6vVf7w1k3m4uQn9p2YxCAbcDeFgHiJ; "
                                         "atn=https://example.com/.well-known/atn/index.json; "
                                         "atn-digest=a3b8c2d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4" )

  4.2.  Binding ParamKeys for SVCB-Based Discovery

     For SVCB-based discovery [RFC9460], the following ParamKeys are
     registered (see Section 17):

                          +============+============+
                          | ParamKey   | Format     |
                          +============+============+
                          | atn        | URI        |
                          +------------+------------+
                          | atn-digest | hex-string |
                          +------------+------------+

                                    Table 2

  4.2.1.  Example (binding ATN to a DNS-AID-style SVCB record)

     _agent.example.com.  3600  IN  HTTPS  1 agent.example.com. (
         alpn="h2,h3"
         atn="https://example.com/.well-known/atn/index.json"
         atn-digest="a3b8c2d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4" )

  4.3.  ATN Index Document

     The Index Document at the atn URI is a JSON object with the following
     structure:



  Somoza                  Expires 18 November 2026                [Page 9]


  Internet-Draft           agent-trust-negotiation                May 2026


     {
       "v": "atn1",
       "agent_id": "2H4kP9aQ8vR3wXyZ1mNbVcLk-a3b8c2d4e5f6a7b8c9d0e1f2",
       "capability_manifest": {
         "url": "https://example.com/.well-known/atn/capability.jws",
         "digest": "sha256:b4c5d6e7f8a9b0c1..."
       },
       "delegation_chain": {
         "url": "https://example.com/.well-known/atn/delegation.jws",
         "digest": "sha256:c5d6e7f8a9b0c1d2..."
       },
       "provenance_attestation": {
         "url": "https://example.com/.well-known/atn/provenance.jws",
         "digest": "sha256:d6e7f8a9b0c1d2e3..."
       },
       "handshake_endpoint": "https://agent.example.com/.atn/handshake",
       "witness_pointers": [
         "https://scitt.example.org/entries/a1b2c3..."
       ]
     }

     The Index Document itself MUST be signed as a JWS [RFC7515] when the
     discovery record cannot be DNSSEC-validated [RFC4033].  When DNSSEC
     is in use, the atn-digest tag covers integrity at the DNS layer and
     signature on the Index Document is RECOMMENDED but not REQUIRED.

  5.  Capability Manifest

     The Capability Manifest declares what the agent is willing to do
     under what conditions.  It is a JSON object signed as a JWS.

  5.1.  Capability Object Structure

     Each capability is a structured object with explicit dimensions
     covering identification, semantics, scope, and operational bounds.
     The design borrows from the action-resource-condition pattern of
     established authorization frameworks, the schema-binding pattern of
     W3C Verifiable Credentials, and the attenuation principle of
     capability-based security research.












  Somoza                  Expires 18 November 2026               [Page 10]


  Internet-Draft           agent-trust-negotiation                May 2026


        +=================+==========+================================+
        | Field           | Required | Description                    |
        +=================+==========+================================+
        | id              | Yes      | Capability identifier from the |
        |                 |          | IANA registry, or a vendor-    |
        |                 |          | specific identifier.           |
        +-----------------+----------+--------------------------------+
        | schema          | Yes      | URI plus SHA-256 digest of the |
        |                 |          | formal capability definition.  |
        +-----------------+----------+--------------------------------+
        | actions         | Yes      | List of action verbs scoped to |
        |                 |          | the capability's schema        |
        |                 |          | vocabulary.                    |
        +-----------------+----------+--------------------------------+
        | resources       | Yes      | List of resource patterns the  |
        |                 |          | capability applies to.         |
        +-----------------+----------+--------------------------------+
        | conditions      | No       | Runtime constraints: rate      |
        |                 |          | limits, data residency, time   |
        |                 |          | windows, size limits.          |
        +-----------------+----------+--------------------------------+
        | effects         | Yes      | One of: none, read_only,       |
        |                 |          | idempotent, mutating.          |
        +-----------------+----------+--------------------------------+
        | external_calls  | Yes      | One of: forbidden,             |
        |                 |          | listed_only, free.  Whether    |
        |                 |          | the capability may call out.   |
        +-----------------+----------+--------------------------------+
        | sub_invocations | Yes      | One of: forbidden, same_scope, |
        |                 |          | fresh_handshake_required.      |
        |                 |          | Sub-agent rules.               |
        +-----------------+----------+--------------------------------+
        | persistence     | Yes      | One of: none, session_only,    |
        |                 |          | durable.  Whether state        |
        |                 |          | survives the session.          |
        +-----------------+----------+--------------------------------+
        | resource_bounds | Yes      | Hard ceilings: max_tokens,     |
        |                 |          | max_duration_seconds,          |
        |                 |          | max_cost_usd.                  |
        +-----------------+----------+--------------------------------+
        | preconditions   | No       | Counterparty requirements that |
        |                 |          | must hold before the           |
        |                 |          | capability is exercised.       |
        +-----------------+----------+--------------------------------+

                                    Table 3





  Somoza                  Expires 18 November 2026               [Page 11]


  Internet-Draft           agent-trust-negotiation                May 2026


     Every dimension uses a controlled vocabulary registered with IANA
     (see Section 17).  Vendor-specific identifiers under the x- prefix
     are permitted for non-standard capabilities and MUST carry a schema
     reference.

  5.2.  Schema Binding

     The schema field binds the capability identifier to a formal
     definition.  Two implementations resolving the same id to different
     schema.digest values MUST treat the capabilities as semantically
     distinct, even if the identifier matches.  This eliminates the
     silent-divergence problem that opaque scope strings created in OAuth
     deployments.

     The schema document SHOULD define:

     1.  The semantic meaning of the capability identifier.

     2.  The permitted values in actions.

     3.  The format and semantics of resources patterns.

     4.  Any capability-specific extensions to conditions.

     Schema documents are versioned.  A capability MAY pin a specific
     schema version via the digest.

  5.3.  Structure

     {
       "v": "atn-capability-1",
       "agent_id": "<stable-identifier>",
       "issued_at": "2026-05-15T10:00:00Z",
       "valid_until": "2026-08-15T10:00:00Z",
       "capabilities": [
         {
           "id": "data-read",
           "schema": {
             "url": "https://schemas.example.com/atn/data-read-v1.json",
             "digest": "sha256:b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5"
           },
           "actions": ["read", "list"],
           "resources": ["dataset:public/*", "dataset:internal/research/*"],
           "conditions": {
             "rate_limit": "1000/min",
             "data_residency": ["US", "EU"],
             "time_window": "09:00-17:00 UTC",
             "max_response_size_bytes": 10485760



  Somoza                  Expires 18 November 2026               [Page 12]


  Internet-Draft           agent-trust-negotiation                May 2026


           },
           "effects": "read_only",
           "external_calls": "forbidden",
           "sub_invocations": "forbidden",
           "persistence": "none",
           "resource_bounds": {
             "max_tokens": 100000,
             "max_duration_seconds": 1800,
             "max_cost_usd": 0.50
           },
           "preconditions": {
             "counterparty_provenance": "required",
             "counterparty_delegation": "required",
             "transport": "tls1.3"
           }
         },
         {
           "id": "task-execute",
           "schema": {
             "url": "https://schemas.example.com/atn/task-execute-v1.json",
             "digest": "sha256:c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6"
           },
           "actions": ["execute"],
           "resources": ["task:summarize", "task:translate", "task:classify"],
           "conditions": {
             "max_session_minutes": 30
           },
           "effects": "idempotent",
           "external_calls": "listed_only",
           "sub_invocations": "same_scope",
           "persistence": "session_only",
           "resource_bounds": {
             "max_tokens": 500000,
             "max_duration_seconds": 1800,
             "max_cost_usd": 2.00
           },
           "preconditions": {
             "human_approval": "required",
             "approval_token_issuer": "https://approvals.example.com"
           }
         }
       ],
       "refusals": [
         {
           "category": "financial_transactions",
           "scope": "all"
         },
         {



  Somoza                  Expires 18 November 2026               [Page 13]


  Internet-Draft           agent-trust-negotiation                May 2026


           "category": "data_write",
           "scope": "external_systems"
         }
       ]
     }

  5.4.  Dimension Semantics

     effects declares the consequence of exercising the capability:

     *  none: no observable consequence (introspection only).

     *  read_only: data is read; no state changes.

     *  idempotent: state may change but repeated execution is equivalent
        to single execution.

     *  mutating: state changes, and the change is not idempotent.

     external_calls declares whether the capability may initiate calls
     outside the agent's own scope:

     *  forbidden: no external calls.

     *  listed_only: external calls are permitted only to destinations
        listed in the schema or conditions.

     *  free: any external call is permitted, bounded only by
        resource_bounds.

     sub_invocations declares the rules for invoking other agents:

     *  forbidden: this capability does not invoke other agents.

     *  same_scope: sub-invocations inherit the present session's
        negotiated scope.

     *  fresh_handshake_required: every sub-invocation requires a separate
        ATN handshake with the sub-agent.

     persistence declares state survivability:

     *  none: no state persists beyond a single request.

     *  session_only: state persists for the session lifetime, then is
        discarded.





  Somoza                  Expires 18 November 2026               [Page 14]


  Internet-Draft           agent-trust-negotiation                May 2026


     *  durable: state persists beyond the session; the agent MUST
        disclose retention policy in its schema.

     resource_bounds declares hard ceilings on the negotiated scope.
     Conforming implementations MUST terminate the session when any bound
     is exceeded.  The protocol specifies the contract; runtime
     enforcement is the implementation's responsibility, consistent with
     the enforcement posture described in the Security Considerations.

  5.5.  Key Properties

     *  The manifest is a declaration of willingness, not an enforcement
        primitive.  Violations are auditable through the Session Receipt
        and transparency log.

     *  The valid_until field forces rotation.  Manifests without expiry
        MUST be rejected.

     *  refusals are first-class.  Explicit "will not" claims provide
        auditable accountability if violated.

     *  Capability id values from the IANA registry have stable semantics;
        vendor-specific identifiers under x- MUST carry a schema
        reference.

     *  Capabilities are deny-by-default.  The negotiated session scope
        contains only what both parties explicitly offered.

  5.6.  Refusal Semantics

     Refusals are a deliberate inversion of conventional capability
     advertisement.  Most existing proposals describe what an agent CAN
     do.  ATN requires agents to also describe what they explicitly WILL
     NOT do.  This produces auditable behavioral contracts: a recorded
     refusal that is subsequently violated is direct evidence of
     misbehavior.

  6.  Delegation Chain

     The Delegation Chain proves the agent operates under authorized
     principal scope, with explicit time bounds and revocation paths.

  6.1.  Structure








  Somoza                  Expires 18 November 2026               [Page 15]


  Internet-Draft           agent-trust-negotiation                May 2026


     {
       "v": "atn-delegation-1",
       "agent_id": "<stable-identifier>",
       "chain": [
         {
           "issuer": "did:example:organization-root",
           "subject": "did:example:department-ops",
           "scope": ["agent.deploy", "agent.delegate"],
           "issued_at": "2026-01-01T00:00:00Z",
           "valid_until": "2027-01-01T00:00:00Z",
           "revocation": "https://example.com/.well-known/atn/revocation/department-ops",
           "signature": "<JWS>"
         },
         {
           "issuer": "did:example:department-ops",
           "subject": "agent:<stable-identifier>",
           "scope": ["data-read", "task-execute:summarize", "task-execute:translate"],
           "issued_at": "2026-05-01T00:00:00Z",
           "valid_until": "2026-08-01T00:00:00Z",
           "revocation": "https://example.com/.well-known/atn/revocation/agent",
           "signature": "<JWS>"
         }
       ]
     }

  6.2.  Verification

     A relying party MUST:

     1.  Verify each link's signature against the issuer's published key.

     2.  Verify each link's scope is a subset of the parent link's scope.

     3.  Verify all links are within their valid_until window.

     4.  Optionally poll revocation endpoints with rate-limited caching.

     5.  Verify the leaf subject matches the agent's stable identifier
         from discovery.

     If any check fails, the agent MUST NOT be trusted for any capability
     beyond the verifiable subset.

  7.  Provenance Attestation

     The Provenance Attestation proves build-time and runtime
     characteristics of the agent.




  Somoza                  Expires 18 November 2026               [Page 16]


  Internet-Draft           agent-trust-negotiation                May 2026


  7.1.  Structure

     {
       "v": "atn-provenance-1",
       "agent_id": "<stable-identifier>",
       "build": {
         "predicateType": "https://slsa.dev/provenance/v1",
         "predicate": { "...": "in-toto SLSA provenance" }
       },
       "model": {
         "model_id": "example-vendor/llm-v1.2.3",
         "model_version_sha256": "9f8e7d6c5b4a...",
         "system_prompt_sha256": "1a2b3c4d5e6f..."
       },
       "runtime": {
         "evidence_type": "RATS",
         "evidence": { "...": "RFC 9334 evidence" },
         "verifier": "https://verifier.example.com/rats"
       },
       "issued_at": "2026-05-15T08:00:00Z",
       "valid_until": "2026-05-15T20:00:00Z"
     }

  7.2.  Properties

     *  The Provenance Attestation links three independent supply chains:
        software build (SLSA, in-toto [IN-TOTO]), model identity
        (cryptographic hash of weights or version anchor), and runtime
        environment (RATS evidence [RFC9334]).

     *  All three are optional.  An agent that publishes only build
        provenance is more trustworthy than one that publishes none and
        less trustworthy than one that publishes all three.

     *  Short valid_until windows are encouraged.  The Provenance
        Attestation is the most time-sensitive artifact.

  8.  The Agent Trust Handshake (ATH)

  8.1.  State Machine











  Somoza                  Expires 18 November 2026               [Page 17]


  Internet-Draft           agent-trust-negotiation                May 2026


        Initiator                                      Responder
            |                                              |
            |---- ATH_HELLO ------------------------------>|
            |     (initiator artifacts + requested scope)  |
            |                                              |
            |<--- ATH_OFFER -------------------------------|
            |     (responder artifacts + offered scope)    |
            |                                              |
            |---- ATH_ACCEPT ---------------------------- >|
            |     (intersection scope + receipt request)   |
            |                                              |
            |<--- ATH_RECEIPT -----------------------------|
            |     (signed session receipt)                 |
            |                                              |
            === negotiated session begins ===

     All four messages are JSON, signed as JWS, exchanged over HTTPS at
     the Responder's handshake_endpoint.

  8.2.  ATH_HELLO

     {
       "v": "ath1",
       "type": "hello",
       "supported_versions": ["ath1"],
       "initiator": {
         "agent_id": "<initiator-id>",
         "artifacts": {
           "capability": { "url": "...", "digest": "..." },
           "delegation": { "url": "...", "digest": "..." },
           "provenance": { "url": "...", "digest": "..." }
         }
       },
       "requested_scope": {
         "capability_ids": ["data-read"],
         "duration_seconds": 1800,
         "purpose": "summarize_research_corpus"
       },
       "nonce": "<random>",
       "timestamp": "..."
     }

     The requested_scope.capability_ids field carries only the identifiers
     of the capabilities the Initiator wishes to negotiate.  The Responder
     consults its own Capability Manifest for the structured definitions
     and computes the intersection (see Section 9).





  Somoza                  Expires 18 November 2026               [Page 18]


  Internet-Draft           agent-trust-negotiation                May 2026


  8.3.  ATH_OFFER

     The Responder verifies the Initiator's artifacts, computes the
     capability intersection, and returns:

     {
       "v": "ath1",
       "type": "offer",
       "selected_version": "ath1",
       "supported_versions_echo": ["ath1"],
       "responder": {
         "agent_id": "<responder-id>",
         "artifacts": {
           "capability": { "url": "...", "digest": "..." },
           "delegation": { "url": "...", "digest": "..." },
           "provenance": { "url": "...", "digest": "..." }
         }
       },
       "offered_scope": {
         "capabilities": [
           {
             "id": "data-read",
             "schema": { "url": "https://schemas.example.com/atn/data-read-v1.json",
                         "digest": "sha256:b4c5d6..." },
             "actions": ["read", "list"],
             "resources": ["dataset:public/*"],
             "conditions": { "rate_limit": "500/min", "data_residency": ["US"] },
             "effects": "read_only",
             "external_calls": "forbidden",
             "sub_invocations": "forbidden",
             "persistence": "none",
             "resource_bounds": { "max_tokens": 50000, "max_duration_seconds": 1800, "max_cost_usd": 0.50 }
           }
         ],
         "duration_seconds": 1800,
         "purpose": "summarize_research_corpus"
       },
       "nonce": "<random>",
       "in_reply_to_nonce": "<initiator-nonce>",
       "timestamp": "..."
     }

     The offered_scope.capabilities field carries the full structured
     Capability objects after intersection.  Each is the per-dimension
     intersection of the Initiator's requested capability (resolved from
     its Capability Manifest) and the Responder's offered version.





  Somoza                  Expires 18 November 2026               [Page 19]


  Internet-Draft           agent-trust-negotiation                May 2026


  8.4.  ATH_ACCEPT

     If the Initiator agrees with the offered scope:

     {
       "v": "ath1",
       "type": "accept",
       "agreed_scope": { "...": "matches ATH_OFFER offered_scope" },
       "nonce": "<random>",
       "in_reply_to_nonce": "<responder-nonce>",
       "timestamp": "..."
     }

     If the Initiator disagrees, it MAY send ATH_COUNTER with a revised
     request, up to a limit (see Section 8.6).

  8.5.  ATH_RECEIPT

     The Responder produces the Session Receipt:

     {
       "v": "ath1",
       "type": "receipt",
       "session_id": "<uuid>",
       "initiator_id": "<initiator-id>",
       "responder_id": "<responder-id>",
       "agreed_scope": { "...": "the intersection result" },
       "artifact_digests": {
         "initiator_capability": "sha256:...",
         "initiator_delegation": "sha256:...",
         "initiator_provenance": "sha256:...",
         "responder_capability": "sha256:...",
         "responder_delegation": "sha256:...",
         "responder_provenance": "sha256:..."
       },
       "scitt_log_pointer": "https://scitt.example.org/entries/...",
       "issued_at": "...",
       "expires_at": "...",
       "signature": "<JWS by responder>"
     }

     Both parties countersign the receipt and MAY publish it to a SCITT
     log [SCITT].

  8.6.  Handshake Limits

     *  Total handshake round trips MUST NOT exceed 4.




  Somoza                  Expires 18 November 2026               [Page 20]


  Internet-Draft           agent-trust-negotiation                May 2026


     *  ATH_COUNTER messages MUST NOT exceed 2 per session.

     *  The handshake MUST complete within 30 seconds.

     *  Sessions exceeding agreed_scope.duration_seconds require a new
        handshake.

  9.  Capability Intersection Algebra

     When two agents present capability sets, the negotiated scope is
     computed by intersection.  The algorithm is specified for
     interoperability so that conforming implementations produce identical
     results from identical inputs.

  9.1.  Identity Rule

     A capability c is in the intersection only if all of the following
     hold:

     1.  Both Initiator's requested set and Responder's offered set
         include a capability with the same id.

     2.  Both capabilities reference the same schema.url and
         schema.digest.  Identifiers with diverging schemas MUST be
         treated as distinct capabilities and excluded from the
         intersection.

     3.  Neither party has a matching entry in refusals covering c.

  9.2.  Per-Dimension Rules

     For each capability c that satisfies the identity rule, the
     intersected capability is computed dimension by dimension.

     +====================================+========================+=============+
     |Dimension                           |Combinator              |Notes        |
     +====================================+========================+=============+
     |actions                             |List intersection       |If empty, c  |
     |                                    |                        |is dropped.  |
     +------------------------------------+------------------------+-------------+
     |resources                           |Pattern intersection    |If empty, c  |
     |                                    |(longest-prefix match)  |is dropped.  |
     +------------------------------------+------------------------+-------------+
     |conditions numeric (rate_limit,     |Minimum                 |Tighter bound|
     |max_response_size_bytes,            |                        |wins.        |
     |max_session_minutes)                |                        |             |
     +------------------------------------+------------------------+-------------+
     |conditions list (data_residency,    |List intersection       |If empty, c  |



  Somoza                  Expires 18 November 2026               [Page 21]


  Internet-Draft           agent-trust-negotiation                May 2026


     |tasks)                              |                        |is dropped.  |
     +------------------------------------+------------------------+-------------+
     |conditions.time_window              |Time-window intersection|If empty, c  |
     |                                    |                        |is dropped.  |
     +------------------------------------+------------------------+-------------+
     |effects                             |Most restrictive of:    |Take lower in|
     |                                    |none < read_only <      |ordering.    |
     |                                    |idempotent < mutating   |             |
     +------------------------------------+------------------------+-------------+
     |external_calls                      |Most restrictive of:    |Take lower in|
     |                                    |forbidden < listed_only |ordering.    |
     |                                    |< free                  |             |
     +------------------------------------+------------------------+-------------+
     |sub_invocations                     |Most restrictive of:    |Take lower in|
     |                                    |forbidden < same_scope <|ordering.    |
     |                                    |fresh_handshake_required|             |
     +------------------------------------+------------------------+-------------+
     |persistence                         |Most restrictive of:    |Take lower in|
     |                                    |none < session_only <   |ordering.    |
     |                                    |durable                 |             |
     +------------------------------------+------------------------+-------------+
     |resource_bounds.max_tokens          |Minimum                 |             |
     +------------------------------------+------------------------+-------------+
     |resource_bounds.max_duration_seconds|Minimum                 |             |
     +------------------------------------+------------------------+-------------+
     |resource_bounds.max_cost_usd        |Minimum                 |             |
     +------------------------------------+------------------------+-------------+
     |preconditions                       |Union                   |Both parties'|
     |                                    |                        |preconditions|
     |                                    |                        |apply to the |
     |                                    |                        |negotiated   |
     |                                    |                        |capability.  |
     +------------------------------------+------------------------+-------------+

                                    Table 4

  9.3.  Refusal Override

     If either party's refusals list contains an entry matching capability
     c by category or by direct id, c is dropped from the intersection
     regardless of any other dimension.  Refusals are absolute.

  9.4.  Worked Example

     Initiator requests data-read:

     *  actions: [read, list, search]




  Somoza                  Expires 18 November 2026               [Page 22]


  Internet-Draft           agent-trust-negotiation                May 2026


     *  resources: [dataset:public/*, dataset:internal/*]

     *  conditions.rate_limit: 1000/min

     *  conditions.data_residency: [US, EU, APAC]

     *  effects: read_only

     *  external_calls: listed_only

     *  resource_bounds.max_cost_usd: 1.00

     Responder offers data-read:

     *  actions: [read, list]

     *  resources: [dataset:public/*]

     *  conditions.rate_limit: 500/min

     *  conditions.data_residency: [US, EU]

     *  effects: read_only

     *  external_calls: forbidden

     *  resource_bounds.max_cost_usd: 0.50

     Negotiated intersection (assuming matching schemas):

     *  actions: [read, list]

     *  resources: [dataset:public/*]

     *  conditions.rate_limit: 500/min

     *  conditions.data_residency: [US, EU]

     *  effects: read_only

     *  external_calls: forbidden

     *  resource_bounds.max_cost_usd: 0.50

     If the schemas had diverged, data-read would be dropped entirely with
     no intersection.  If Initiator's refusals included data-read, the
     capability would be dropped regardless of offer compatibility.




  Somoza                  Expires 18 November 2026               [Page 23]


  Internet-Draft           agent-trust-negotiation                May 2026


  10.  Mutual Trust Mode

     When both agents are sensitive (for example, two agents acting on
     behalf of different organizations), the handshake operates in mutual
     mode:

     *  Both parties MUST present all four artifacts in ATH_HELLO and
        ATH_OFFER.

     *  Both parties MUST verify the counterparty's full chain before
        proceeding.

     *  The Session Receipt MUST be countersigned by both parties.

     In single-sided mode (for example, when one party is a public
     service), only the trusted side must present full artifacts.  The
     other side's identity is still verified at the discovery layer, but
     the trust posture is asymmetric.

  11.  Version Negotiation and Algorithm Agility

     ATN is designed for long-term evolution.  Two mechanisms ensure
     forward compatibility: explicit version negotiation in the handshake
     and pluggable cryptographic algorithms in artifacts and messages.

  11.1.  Version Negotiation

     The Initiator's ATH_HELLO message advertises every ATN version it
     supports in a supported_versions field.  The Responder's ATH_OFFER
     selects the highest mutually supported version and echoes it in a
     selected_version field.  All subsequent messages in the session use
     the selected version.

     {
       "v": "ath1",
       "type": "hello",
       "supported_versions": ["ath1", "ath2"],
       "initiator": { "...": "..." },
       "requested_scope": { "...": "..." },
       "nonce": "...",
       "timestamp": "..."
     }

     The Responder MUST include the Initiator's supported_versions list in
     the signed envelope of its ATH_OFFER.  This prevents downgrade
     attacks: an on-path adversary that strips advertised versions from
     ATH_HELLO would cause the Responder's signature to cover the stripped
     list, which the Initiator can detect.



  Somoza                  Expires 18 November 2026               [Page 24]


  Internet-Draft           agent-trust-negotiation                May 2026


     If the Initiator and Responder share no common version, the Responder
     MUST reply with ATH_REJECT carrying error code version_mismatch.  The
     handshake terminates.

  11.2.  Algorithm Agility

     ATN does not pin cryptographic algorithms beyond a minimum set
     required for v1 interoperability.  Implementations MAY use any
     algorithm registered for JWS [RFC7515] or COSE.

     Required for ATN v1 conformance:

     1.  Ed25519 signatures over JWS-encoded artifacts and handshake
         messages.

     2.  SHA-256 for digests bound at the DNS layer and in artifact
         references.

     Recommended additional algorithms:

     1.  ECDSA P-256 with SHA-256 for environments with ECDSA-only
         hardware tokens.

     2.  ML-DSA (post-quantum signature) for deployments preparing for
         post-quantum transition.

     The Capability Manifest, Delegation Chain, Provenance Attestation,
     and Session Receipt MAY each be signed with a different algorithm.
     The JWS header identifies the algorithm.  Relying parties MUST reject
     artifacts signed with algorithms they do not support.

     Algorithm identifiers are negotiated implicitly via the JWS alg
     header on each artifact.  Explicit negotiation in ATH_HELLO is NOT
     REQUIRED for v1 but MAY be added in future versions.

  11.3.  Post-Quantum Transition

     The cryptographic operations in ATN are well-bounded: signature
     verification of artifacts and handshake messages.  There is no key
     agreement step inside ATN itself; TLS handles channel security.
     Migration to post-quantum signatures requires only adopting a PQ-
     capable signature algorithm in JWS, which the IETF JOSE working group
     is standardizing.

     When PQ algorithms are widely deployed, operators SHOULD rotate to a
     hybrid scheme (classical + PQ) during the transition window, then to
     PQ-only.  ATN's version negotiation supports introducing a new minor
     version that prefers PQ signatures without breaking v1 deployments.



  Somoza                  Expires 18 November 2026               [Page 25]


  Internet-Draft           agent-trust-negotiation                May 2026


  12.  Compatibility with Existing Discovery Protocols

     ATN is designed to coexist with existing DNS-based discovery
     proposals without modification:

  12.1.  With AID [AID]

     AID's TXT record is extended with the atn and atn-digest tags.  AID's
     PKA mechanism continues to authenticate the endpoint.  ATN consumes
     the AID-authenticated identity as the input to the handshake.

  12.2.  With DNS-AID [DNS-AID]

     DNS-AID's SVCB records are extended with the atn and atn-digest
     ParamKeys.  The leaf-zone naming convention from DNS-AID is
     preserved.

  12.3.  With ANS v2 [ANSv2]

     ANS v2's Trust Card concept maps directly to a subset of ATN's
     Capability Manifest.  An ANS v2 deployment can publish an ATN Index
     Document where the Capability Manifest cross-references the ANS Trust
     Card.

  12.4.  Multi-Discovery Tolerance

     A single agent zone MAY publish records compatible with multiple
     discovery proposals simultaneously.  ATN binding is independent of
     which discovery format is used.

  13.  Relationship to Existing Identity, Authorization, and Attestation
       Frameworks

     A reasonable first question for any new trust protocol is whether
     existing frameworks suffice.  ATN composes several mature primitives
     and does not reinvent any of them.  The contribution is the
     composition: a peer-to-peer agent handshake with deterministic scope
     negotiation and an auditable session receipt.  This section addresses
     each adjacent framework and identifies where ATN composes with it.

     The analogy that clarifies the relationship: TLS uses asymmetric
     crypto, symmetric crypto, key exchange, and X.509.  TLS is not
     accused of reinventing those primitives.  TLS is the handshake that
     composes them into a deployable channel-security protocol.  ATN
     occupies the same compositional role for inter-agent trust.






  Somoza                  Expires 18 November 2026               [Page 26]


  Internet-Draft           agent-trust-negotiation                May 2026


  13.1.  OAuth 2.0 and GNAP

     OAuth 2.0 [RFC6749] and GNAP [RFC9635] authenticate and authorize a
     Client to access a Resource Server.  ATN negotiates a mutual
     agreement between two autonomous peers.

     Structural differences:

     1.  Asymmetric vs symmetric.  OAuth and GNAP define Client and
         Resource Server roles.  ATN defines two peers, each presenting
         four artifacts.  There is no "resource server" in agent-to-agent
         collaboration.

     2.  Secret tokens vs publishable artifacts.  OAuth bearer tokens are
         secrets and MUST NOT be logged.  ATN artifacts are designed for
         publication to transparency logs.  Opposite security models for
         the core artifacts.

     3.  No formal scope intersection.  OAuth scopes are evaluated by
         membership at the Resource Server.  ATN specifies a deterministic
         intersection algorithm.

     4.  No refusal semantics.  OAuth represents grants.  ATN represents
         grants and explicit refusals as first-class signed claims.

     Where OAuth and GNAP remain the right tools:

     *  Inside a trust domain with a central authorization server, OAuth
        and GNAP issue access tokens to passive resources.  ATN is
        unnecessary.

     *  Where one party is a passive resource, OAuth-style bearer access
        fits.

     *  Human-to-agent delegation, where a human grants an agent access on
        the human's behalf, fits GNAP.

     ATN composes with OAuth and GNAP.  An agent in an ATN session MAY
     hold OAuth tokens for downstream resource access.  ATN governs the
     inter-agent relationship; OAuth governs subsequent resource calls.

  13.2.  SPIFFE Workload Identity

     SPIFFE [SPIFFE] issues SVIDs (SPIFFE Verifiable Identity Documents)
     to workloads within a trust domain.  SPIFFE Federation supports
     cross-domain identity through bilaterally exchanged trust bundles.

     Structural relationship:



  Somoza                  Expires 18 November 2026               [Page 27]


  Internet-Draft           agent-trust-negotiation                May 2026


     1.  SPIFFE provides identity, not authorization, willingness,
         capability, or provenance.

     2.  SPIFFE is optimized for intra-organizational deployment.  Cross-
         organizational use requires pre-arranged federation.  ATN targets
         cross-organizational interactions where peers may meet for the
         first time without prior trust setup.

     3.  ATN can carry a SPIFFE ID as the stable identifier in its
         artifacts.  The SPIFFE SVID becomes the authentication input; the
         ATN handshake adds capability, delegation, provenance, and
         receipt on top.

     SPIFFE and ATN compose cleanly.  SPIFFE within the trust domain, ATN
     at the boundary.

  13.3.  Mutual TLS

     Mutual TLS [RFC8446] authenticates both endpoints at the transport
     layer.  It establishes that the connection is between two specific
     certificates.

     mTLS provides:

     *  Endpoint authentication.

     *  Channel confidentiality and integrity.

     mTLS does not provide:

     *  Capability declaration.

     *  Delegation expression.

     *  Provenance evidence.

     *  Negotiation of scope.

     *  Auditable agreement record.

     ATN runs on top of an mTLS-secured channel where appropriate. mTLS is
     necessary infrastructure for many ATN deployments.  It is not a
     substitute for the negotiation.

  13.4.  RATS Remote Attestation

     RATS [RFC9334] defines roles (Attester, Verifier, Relying Party,
     Endorser) and the structure of attestation evidence and results.



  Somoza                  Expires 18 November 2026               [Page 28]


  Internet-Draft           agent-trust-negotiation                May 2026


     RATS provides:

     *  The architecture for producing and verifying attestation evidence.

     RATS does not provide:

     *  A protocol for combining attestation evidence with authorization
        or capability negotiation.

     *  A specification for what to do with verification results in a peer
        interaction.

     ATN consumes RATS evidence as one axis of its Provenance Attestation.
     The other two axes (build provenance and model identity) come from
     supply-chain attestation frameworks.  RATS is the input; ATN is one
     specified consumer.

  13.5.  SCITT Transparency

     SCITT [SCITT] defines an append-only transparency log for signed
     statements with inclusion proofs.

     SCITT provides:

     *  The transparency log infrastructure.

     *  The signed-statement envelope format.

     SCITT does not provide:

     *  The semantics of what to log for a given application.

     *  The receipt format that captures an inter-agent agreement.

     ATN provides the Session Receipt format that becomes the SCITT
     statement for an agent interaction.  SCITT without ATN is a log
     waiting for a record format.  ATN without SCITT is a receipt waiting
     for a transparency layer.

  13.6.  Composition Summary

     ATN composes the following primitives per layer:









  Somoza                  Expires 18 November 2026               [Page 29]


  Internet-Draft           agent-trust-negotiation                May 2026


        +===================+====================+====================+
        | Concern           | Primitive          | ATN's Role         |
        +===================+====================+====================+
        | Endpoint          | mTLS [RFC8446]     | Runs above         |
        | authentication    |                    |                    |
        +-------------------+--------------------+--------------------+
        | Workload identity | SPIFFE [SPIFFE]    | Consumes SVIDs as  |
        | (intra-org)       |                    | stable identifiers |
        +-------------------+--------------------+--------------------+
        | Cross-org         | DNS + DNSSEC       | Discovery          |
        | identity          | [RFC4033], [AID],  | substrate for ATN  |
        |                   | [DNS-AID], [ANSv2] | artifacts          |
        +-------------------+--------------------+--------------------+
        | Delegated         | OAuth [RFC6749],   | Composes with,     |
        | authorization to  | GNAP [RFC9635]     | does not replace   |
        | passive resources |                    |                    |
        +-------------------+--------------------+--------------------+
        | Attestation       | RATS [RFC9334]     | Consumes evidence  |
        | evidence          |                    | in Provenance      |
        |                   |                    | Attestation        |
        +-------------------+--------------------+--------------------+
        | Public            | SCITT [SCITT]      | Provides the       |
        | auditability      |                    | receipt format for |
        |                   |                    | log entries        |
        +-------------------+--------------------+--------------------+
        | Peer-to-peer      | (none exists)      | This document      |
        | trust handshake   |                    |                    |
        +-------------------+--------------------+--------------------+

                                    Table 5

     The contribution of ATN is the bottom row.  The five rows above are
     existing work that ATN composes.

  13.7.  When to Use What

     1.  Two workloads inside one trust domain coordinating on a task:
         SPIFFE.

     2.  A client accessing a resource server with delegated user
         authorization: OAuth or GNAP.

     3.  Establishing that you are talking to a specific endpoint: mTLS.

     4.  Producing tamper-evident proof that some software was built and
         deployed as claimed: RATS plus supply-chain attestation.

     5.  Publishing an auditable record of a claim: SCITT.



  Somoza                  Expires 18 November 2026               [Page 30]


  Internet-Draft           agent-trust-negotiation                May 2026


     6.  Two autonomous agents from different organizations agreeing to
         work together with mutually verified capability, authority,
         provenance, and a signed record of the agreement: ATN.

  14.  Security Considerations

  14.1.  Threat Model

     ATN assumes:

     *  Adversaries may publish well-formed but malicious ATN artifacts.

     *  Adversaries may compromise an agent and continue to present valid
        pre-compromise artifacts.

     *  Adversaries may attempt to negotiate scope expansions outside the
        published Capability Manifest.

     *  Adversaries may collude across organizational boundaries to
        construct false Delegation Chains.

  14.2.  Artifact Authenticity

     Every ATN artifact is signed.  Signatures MUST be verified against
     keys bound to the agent's stable identifier at the discovery layer.
     Artifacts whose signatures do not verify, whose valid_until has
     passed, or whose digests do not match the DNS-published values MUST
     be rejected.

  14.3.  Enforcement Posture: Evidence, Not Prevention

     A predictable objection to ATN is that auditability is not
     enforcement.  The objection is correct on its terms and misses the
     layer at which ATN operates.  ATN is technical evidence
     infrastructure.  It is not a behavioral enforcement primitive.  No
     protocol layered on top of an autonomous software agent can be one.

     An agent that signs a Capability Manifest declaring it will not
     perform financial transactions, then performs a financial
     transaction, has cryptographically committed to a refusal it then
     violated.  ATN cannot prevent the violation.  ATN produces a Session
     Receipt and a published transparency log entry that, combined with
     the application-layer evidence of the violation, constitute direct
     cryptographic evidence usable for revocation, contract enforcement,
     regulatory complaint, and civil action.

     The complete trust stack for autonomous agents has four layers:




  Somoza                  Expires 18 November 2026               [Page 31]


  Internet-Draft           agent-trust-negotiation                May 2026


     1.  Technical evidence layer (ATN, SCITT, RATS).  Provides
         cryptographic proof of what was claimed and what was agreed.

     2.  Policy layer (contracts, organizational policy, regulations).
         Specifies what is permitted.

     3.  Consequence layer (revocation, financial penalty, legal action,
         reputational impact).  Imposes cost on violation.

     4.  Operational enforcement layer (sandboxing, capability-based
         execution, hardware-enforced runtime such as TEEs, gating
         proxies).  Prevents violation at runtime.

     ATN is the first layer.  It enables the other three.  It does not
     substitute for them.

     For high-stakes domains (financial transactions, clinical decision
     support, control of physical systems), ATN MUST be deployed with
     operational enforcement (layer 4).  Recommended patterns:

     1.  Run sensitive capabilities inside a TEE that enforces declared
         bounds at hardware level.

     2.  Use a gating proxy that enforces the negotiated scope on every
         outbound call from the agent.

     3.  Use short session lifetimes with frequent re-attestation.

     4.  Combine ATN with object-capability execution where the agent
         runtime denies unauthorized actions by construction, not by
         policy.

     ATN's contribution is to make violations _expensive and
     discoverable_, not impossible.  The analogy is to TCP checksums: they
     do not prevent transmission errors, they detect them so the next
     layer can respond.  Trust at Internet scale has always operated this
     way.  SPF does not prevent spoofed email.  Certificate transparency
     does not prevent mis-issuance.  They make undetected misbehavior
     infeasible.  ATN does the same for inter-agent agreements.

  14.4.  Delegation Forgery

     Delegation Chains depend on the cryptographic strength of each
     issuer's signing key.  ATN does not specify the identity verification
     process that issuers use to vouch for subjects.  Operators SHOULD use
     verifiable credentials [W3C-DID] or organizational identity
     infrastructure with established assurance levels.




  Somoza                  Expires 18 November 2026               [Page 32]


  Internet-Draft           agent-trust-negotiation                May 2026


  14.5.  Session Receipt Tampering

     Session Receipts are countersigned and publishable to a SCITT log
     [SCITT].  Tampering after publication is detectable through log
     inclusion proofs.  Operators handling high-value sessions SHOULD
     publish receipts.

  14.6.  Replay

     Every handshake message includes a nonce and a timestamp.
     Implementations MUST reject messages with nonces seen within the
     session and with timestamps outside a configurable skew window
     (RECOMMENDED 60 seconds).

  14.7.  Provenance Attestation Limits

     Provenance attestations prove what was built and deployed at
     attestation time.  They do not prove the agent is currently executing
     the attested code.  Operators SHOULD use short valid_until windows
     for provenance attestations and refresh through RATS verification
     [RFC9334].

  15.  Privacy Considerations

  15.1.  Negotiation Observability

     The handshake exchanges artifacts that may reveal the purpose of the
     session (purpose field) and the identity of the principal (Delegation
     Chain).  Operators SHOULD treat handshake metadata as sensitive.

  15.2.  Witness Aggregation

     Witnesses and SCITT log operators see the volume and pattern of agent
     interactions.  Operators SHOULD use multiple witnesses to reduce
     centralized observability.

  15.3.  Minimum Disclosure

     ATN supports minimum-disclosure mode where the Initiator presents
     only the artifacts required for the requested scope.  The Responder
     MAY request additional artifacts during the handshake, which the
     Initiator MAY decline (causing the handshake to fail).

  16.  Operational Considerations

     ATN introduces non-trivial latency on session establishment.  This
     section quantifies that cost, explains its operational shape, and
     identifies deployments where ATN is appropriate and where it is not.



  Somoza                  Expires 18 November 2026               [Page 33]


  Internet-Draft           agent-trust-negotiation                May 2026


  16.1.  Session Establishment vs Per-Call Latency

     ATN is a session establishment protocol, not a per-request protocol.
     The handshake establishes a negotiated scope.  The scope authorizes
     many subsequent interactions between the two agents.  Per-call
     latency within an established session is zero added by ATN.

     This places ATN in the same operational category as:

     1.  TLS handshake [RFC8446], amortized over the requests in a
         connection.

     2.  OAuth token acquisition [RFC6749], amortized over the token
         lifetime.

     3.  BGP session establishment, amortized over hours of routing
         operation.

     The relevant performance question is the cost of establishment and
     the session lifetime over which it is amortized, not the cost per
     call.

  16.2.  Latency Budget

     The following budget is informative.  Implementations and deployments
     will vary based on geography, caching, and network conditions.

























  Somoza                  Expires 18 November 2026               [Page 34]


  Internet-Draft           agent-trust-negotiation                May 2026


       +=============================+=================+===============+
       | Component                   | Cold (no cache) | Warm (cached, |
       |                             |                 | pooled)       |
       +=============================+=================+===============+
       | DNS lookup for              | 50-150 ms       | <1 ms         |
       | _agent.<domain> with DNSSEC |                 |               |
       +-----------------------------+-----------------+---------------+
       | TLS 1.3 connection to Index | 100-200 ms      | 0 (pooled)    |
       | Document origin             |                 |               |
       +-----------------------------+-----------------+---------------+
       | Index Document HTTPS GET    | 20-50 ms        | 0 (cached by  |
       |                             |                 | digest)       |
       +-----------------------------+-----------------+---------------+
       | Three artifact fetches      | 50-100 ms       | 0 (cached by  |
       | (HTTP/2 multiplexed)        |                 | digest)       |
       +-----------------------------+-----------------+---------------+
       | Signature verifications     | 1-2 ms          | 1-2 ms        |
       | (4-8 Ed25519)               |                 |               |
       +-----------------------------+-----------------+---------------+
       | Provenance validation       | 1-5 ms          | 1 ms          |
       +-----------------------------+-----------------+---------------+
       | Two-RTT handshake (HELLO/   | 150-300 ms      | 150-300 ms    |
       | OFFER then ACCEPT/RECEIPT)  |                 |               |
       +-----------------------------+-----------------+---------------+
       | Receipt signing (Ed25519)   | <1 ms           | <1 ms         |
       +-----------------------------+-----------------+---------------+
       | *Total session              | *500-1500 ms*   | *150-300 ms*  |
       | establishment*              |                 |               |
       +-----------------------------+-----------------+---------------+
       | Per-call within established | *0 ms added*    | *0 ms added*  |
       | session                     |                 |               |
       +-----------------------------+-----------------+---------------+
       | SCITT log submission        | Async, out of   | Async, out of |
       |                             | path            | path          |
       +-----------------------------+-----------------+---------------+

                                    Table 6

     Recommended performance targets for conforming implementations:

     *  p50 cold session establishment: <800 ms

     *  p99 cold session establishment: <2000 ms

     *  p50 warm session establishment: <250 ms

     *  p99 warm session establishment: <500 ms




  Somoza                  Expires 18 November 2026               [Page 35]


  Internet-Draft           agent-trust-negotiation                May 2026


  16.3.  Optimization Techniques

     Implementations SHOULD apply the following optimizations to bring
     warm-case latency to the recommended targets:

     1.  Digest-keyed artifact caching.  Artifacts are refetched only when
         the DNS-published digest changes.  Steady-state cache hit rate is
         typically above 95 percent.

     2.  HTTP/2 or HTTP/3 multiplexing for parallel artifact fetches.

     3.  TLS 1.3 session resumption for repeat handshakes with known
         peers.

     4.  Connection pooling between sessions to the same peer.

     5.  Abbreviated re-handshake.  A repeat ATH_HELLO MAY reference a
         prior session's receipt to extend or renew the same scope in a
         single round trip rather than three.

     6.  Pre-warming.  Agents MAY establish sessions with frequent
         counterparties before application traffic arrives.

     7.  Asynchronous SCITT submission.  Receipt publication to a
         transparency log happens after the session begins and MUST NOT
         block session establishment.

     8.  RATS attestation result caching for the duration of the result's
         validity window.

  16.4.  Session Lifetime

     The Session Receipt's expires_at field bounds the session.  Within
     that window, no additional handshake is required for interactions
     covered by the agreed scope.  Implementations SHOULD select session
     lifetimes that amortize establishment cost while bounding exposure to
     revocation events.

     Typical session lifetimes:

     *  Short-lived workflows: 5 to 30 minutes

     *  Sustained collaboration sessions: 1 to 24 hours

     *  Long-running infrastructure peering: up to 7 days






  Somoza                  Expires 18 November 2026               [Page 36]


  Internet-Draft           agent-trust-negotiation                May 2026


     Session lifetimes longer than 7 days are NOT RECOMMENDED for cross-
     organizational sessions.  The trade-off is between revocation
     responsiveness and handshake amortization.

  16.5.  Deployments Where ATN Is Appropriate

     1.  Multi-step agent collaboration where many calls share a session
         context.

     2.  Cross-organizational agent interactions where trust establishment
         must be verifiable and auditable.

     3.  Workflows where the cost of trust failure exceeds the cost of
         establishment latency.

     4.  Agent ecosystems with workflows already operating in the 100 ms
         to multi-second range per step.

  16.6.  Deployments Where ATN Is Not Appropriate

     1.  Microsecond-scale latency budgets (high-frequency trading, real-
         time control loops, hardware-in-the-loop systems).

     2.  Stateless per-message protocols where session continuity is not
         meaningful.

     3.  Workflows whose total duration is shorter than the handshake
         establishment cost.

     For these deployments, simpler primitives (mTLS alone, OAuth bearer
     tokens, or no trust layer at all) may be more appropriate.  Operators
     are encouraged to select the trust layer that matches their latency
     budget.

  17.  IANA Considerations

  17.1.  SVCB ParamKey Registrations

     Early allocation requested in the Service Parameter Keys
     (SvcParamKeys) registry [RFC9460]:











  Somoza                  Expires 18 November 2026               [Page 37]


  Internet-Draft           agent-trust-negotiation                May 2026


                          +============+============+
                          | Name       | Format     |
                          +============+============+
                          | atn        | URI        |
                          +------------+------------+
                          | atn-digest | hex-string |
                          +------------+------------+

                                    Table 7

  17.2.  ATN Capability Registry

     Creation of a new registry, "ATN Capabilities," is requested with
     initial entries:

          +================+=====================+==================+
          | Name           | Description         | Reference Schema |
          +================+=====================+==================+
          | data-read      | Read access to a    | TBD              |
          |                | data resource       |                  |
          +----------------+---------------------+------------------+
          | data-write     | Write access to a   | TBD              |
          |                | data resource       |                  |
          +----------------+---------------------+------------------+
          | task-execute   | Execute a named     | TBD              |
          |                | task                |                  |
          +----------------+---------------------+------------------+
          | model-invoke   | Invoke a generative | TBD              |
          |                | model               |                  |
          +----------------+---------------------+------------------+
          | agent-delegate | Delegate work to    | TBD              |
          |                | another agent       |                  |
          +----------------+---------------------+------------------+
          | payment-init   | Initiate a payment  | TBD              |
          |                | flow                |                  |
          +----------------+---------------------+------------------+
          | human-relay    | Surface a request   | TBD              |
          |                | to a human approver |                  |
          +----------------+---------------------+------------------+

                                    Table 8

     Registration policy: Specification Required.  Each registered
     identifier MUST include a reference to a published capability schema
     that defines the semantics of actions, resources patterns, and any
     capability-specific extensions to conditions.





  Somoza                  Expires 18 November 2026               [Page 38]


  Internet-Draft           agent-trust-negotiation                May 2026


     Vendor-specific identifiers prefixed with x- are permitted without
     IANA registration but MUST carry a schema reference in the capability
     object.

  17.3.  ATN Capability Dimension Registries

     Four new registries are requested to govern the controlled
     vocabularies used in capability dimensions:

     "ATN Capability Effects":

       +============+=================================================+
       | Name       | Description                                     |
       +============+=================================================+
       | none       | No observable consequence (introspection only). |
       +------------+-------------------------------------------------+
       | read_only  | Data is read; no state changes.                 |
       +------------+-------------------------------------------------+
       | idempotent | State may change; repeated execution equivalent |
       |            | to single.                                      |
       +------------+-------------------------------------------------+
       | mutating   | State changes; not idempotent.                  |
       +------------+-------------------------------------------------+

                                   Table 9

     "ATN External Call Modes":

                +=============+==============================+
                | Name        | Description                  |
                +=============+==============================+
                | forbidden   | No external calls permitted. |
                +-------------+------------------------------+
                | listed_only | External calls permitted     |
                |             | only to listed destinations. |
                +-------------+------------------------------+
                | free        | Any external call permitted  |
                |             | within resource_bounds.      |
                +-------------+------------------------------+

                                   Table 10

     "ATN Sub-Invocation Modes":








  Somoza                  Expires 18 November 2026               [Page 39]


  Internet-Draft           agent-trust-negotiation                May 2026


         +==========================+===============================+
         | Name                     | Description                   |
         +==========================+===============================+
         | forbidden                | No sub-agent invocations.     |
         +--------------------------+-------------------------------+
         | same_scope               | Sub-invocations inherit the   |
         |                          | present negotiated scope.     |
         +--------------------------+-------------------------------+
         | fresh_handshake_required | Every sub-invocation requires |
         |                          | a separate ATN handshake.     |
         +--------------------------+-------------------------------+

                                   Table 11

     "ATN Persistence Modes":

         +==============+============================================+
         | Name         | Description                                |
         +==============+============================================+
         | none         | No state persists beyond a single request. |
         +--------------+--------------------------------------------+
         | session_only | State persists for the session lifetime,   |
         |              | then discarded.                            |
         +--------------+--------------------------------------------+
         | durable      | State persists beyond the session;         |
         |              | retention policy required.                 |
         +--------------+--------------------------------------------+

                                    Table 12

     Registration policy for all four registries: Standards Action or IESG
     Approval.  The controlled vocabularies are deliberately small and
     stable; expansion requires consensus to avoid the semantic-drift
     problem that affected OAuth scopes.

  17.4.  ATN Refusal Category Registry

     Creation of a new registry, "ATN Refusal Categories," is requested
     with initial entries:












  Somoza                  Expires 18 November 2026               [Page 40]


  Internet-Draft           agent-trust-negotiation                May 2026


     +========================+==========================================+
     | Name                   | Description                              |
     +========================+==========================================+
     | financial_transactions | Any movement of funds                    |
     +------------------------+------------------------------------------+
     | personal_data          | Processing of personal identifiers       |
     +------------------------+------------------------------------------+
     | weaponization          | Use in weapons systems                   |
     +------------------------+------------------------------------------+
     | mass_persuasion        | Generation of mass-distributed content   |
     +------------------------+------------------------------------------+
     | child_safety           | Content involving minors                 |
     +------------------------+------------------------------------------+
     | medical_advice         | Clinical recommendations                 |
     +------------------------+------------------------------------------+
     | legal_advice           | Legal recommendations binding on         |
     |                        | parties                                  |
     +------------------------+------------------------------------------+

                                    Table 13

     Registration policy: Specification Required.

  17.5.  Well-Known URI Registration

     The path /.well-known/atn/ is reserved per RFC 8615 conventions for
     ATN artifact publication.

  18.  References

  18.1.  Normative References

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

     [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "DNS Security Introduction and Requirements",
                RFC 4033, DOI 10.17487/RFC4033, March 2005,
                <https://www.rfc-editor.org/rfc/rfc4033>.

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






  Somoza                  Expires 18 November 2026               [Page 41]


  Internet-Draft           agent-trust-negotiation                May 2026


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

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/rfc/rfc8446>.

     [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
                and Parameter Specification via the DNS (SVCB and HTTPS
                Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
                November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

  18.2.  Informative References

     [AID]      Nemethi, B., "Agent Identity and Discovery (AID)", 2026,
                <https://datatracker.ietf.org/doc/draft-nemethi-aid-agent-
                identity-discovery/>.

     [ANSv2]    Narajala, K., "Agent Name Service v2", 2026,
                <https://datatracker.ietf.org/doc/draft-narajala-courtney-
                ansv2/>.

     [DNS-AID]  Mozley, J., Williams, N., Sarikaya, B., and R. Schott,
                "DNS for AI Discovery", 2026,
                <https://datatracker.ietf.org/doc/draft-mozleywilliams-
                dnsop-dnsaid/>.

     [IN-TOTO]  in-toto / CNCF, "in-toto Attestation Framework", 2024,
                <https://in-toto.io/>.

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/rfc/rfc6749>.

     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, DOI 10.17487/RFC9334, January
                2023, <https://www.rfc-editor.org/rfc/rfc9334>.







  Somoza                  Expires 18 November 2026               [Page 42]


  Internet-Draft           agent-trust-negotiation                May 2026


     [RFC9635]  Richer, J., Ed. and F. Imbault, "Grant Negotiation and
                Authorization Protocol (GNAP)", RFC 9635,
                DOI 10.17487/RFC9635, October 2024,
                <https://www.rfc-editor.org/rfc/rfc9635>.

     [SCITT]    IETF SCITT WG, "Supply Chain Integrity, Transparency, and
                Trust (SCITT) Architecture", 2025,
                <https://datatracker.ietf.org/wg/scitt/about/>.

     [SPIFFE]   SPIFFE / CNCF, "SPIFFE: Secure Production Identity
                Framework for Everyone", 2024,
                <https://github.com/spiffe/spiffe>.

     [W3C-DID]  W3C, "Decentralized Identifiers (DIDs) v1.0", 2022,
                <https://www.w3.org/TR/did-core/>.

  Appendix A.  Complete Example Flow

     This appendix walks through a full ATN handshake between two agents
     at agent.research.org and agent.publisher.com.

  A.1.  Step 1: Discovery

     $ dig +short TXT _agent.publisher.com
     "v=aid1; u=https://agent.publisher.com/mcp; p=mcp;
      k=z7rW8rTq8o4mM6vVf7w1k3m4uQn9p2YxCAbcDeFgHiJ;
      atn=https://publisher.com/.well-known/atn/index.json;
      atn-digest=a3b8c2d4..."

  A.2.  Step 2: Index Document Fetch

     GET https://publisher.com/.well-known/atn/index.json

     Returns the JSON object listing the four artifact URLs and their
     digests.

  A.3.  Step 3: Artifact Fetch and Verification

     The Initiator fetches:

     *  capability.jws

     *  delegation.jws

     *  provenance.jws

     Verifies each digest matches the Index Document, verifies each
     signature, and confirms valid_until is in the future.



  Somoza                  Expires 18 November 2026               [Page 43]


  Internet-Draft           agent-trust-negotiation                May 2026


  A.4.  Step 4: ATH_HELLO

     The Initiator (research.org agent) sends ATH_HELLO to the Responder's
     handshake_endpoint:

     {
       "v": "ath1",
       "type": "hello",
       "supported_versions": ["ath1"],
       "initiator": {
         "agent_id": "INIT-XYZ123...",
         "artifacts": { "...": "capability/delegation/provenance refs" }
       },
       "requested_scope": {
         "capability_ids": ["data-read"],
         "duration_seconds": 600,
         "purpose": "academic_research_summarization"
       },
       "nonce": "n-init-001",
       "timestamp": "2026-05-15T14:00:00Z"
     }

  A.5.  Step 5: ATH_OFFER

     The Responder verifies the Initiator's artifacts, computes the
     intersection, and returns:

























  Somoza                  Expires 18 November 2026               [Page 44]


  Internet-Draft           agent-trust-negotiation                May 2026


     {
       "v": "ath1",
       "type": "offer",
       "selected_version": "ath1",
       "supported_versions_echo": ["ath1"],
       "responder": { "...": "responder agent_id and artifact refs" },
       "offered_scope": {
         "capabilities": [
           {
             "id": "data-read",
             "schema": { "url": "https://schemas.example.com/atn/data-read-v1.json",
                         "digest": "sha256:b4c5d6..." },
             "actions": ["read", "list"],
             "resources": ["dataset:public/*"],
             "conditions": { "rate_limit": "300/min", "data_residency": ["US", "EU"] },
             "effects": "read_only",
             "external_calls": "forbidden",
             "sub_invocations": "forbidden",
             "persistence": "none",
             "resource_bounds": { "max_tokens": 50000, "max_duration_seconds": 600, "max_cost_usd": 0.30 }
           }
         ],
         "duration_seconds": 600,
         "purpose": "academic_research_summarization"
       },
       "nonce": "n-resp-001",
       "in_reply_to_nonce": "n-init-001",
       "timestamp": "2026-05-15T14:00:01Z"
     }

  A.6.  Step 6: ATH_ACCEPT

     {
       "v": "ath1",
       "type": "accept",
       "agreed_scope": { "...": "matches ATH_OFFER" },
       "nonce": "n-init-002",
       "in_reply_to_nonce": "n-resp-001",
       "timestamp": "2026-05-15T14:00:02Z"
     }

  A.7.  Step 7: ATH_RECEIPT









  Somoza                  Expires 18 November 2026               [Page 45]


  Internet-Draft           agent-trust-negotiation                May 2026


     {
       "v": "ath1",
       "type": "receipt",
       "session_id": "5b7c-...",
       "initiator_id": "INIT-XYZ123...",
       "responder_id": "RESP-ABC789...",
       "agreed_scope": { ... },
       "artifact_digests": { ... },
       "scitt_log_pointer": "https://scitt.research.org/entries/789xyz",
       "issued_at": "2026-05-15T14:00:03Z",
       "expires_at": "2026-05-15T14:10:03Z",
       "signature": "<JWS by responder>"
     }

     The Initiator countersigns.  The session begins.

  A.8.  Step 8: Session and Audit

     The agents transact within the agreed scope.  The Session Receipt is
     published to SCITT.  Any downstream audit can:

     1.  Retrieve the receipt.

     2.  Verify all artifact digests against the agents' original
         publications.

     3.  Compare actual session traffic (where logged) against the agreed
         scope.

     4.  Flag any deviation.

  Appendix B.  Design Rationale

  B.1.  Why a Negotiation Layer

     DNS-based discovery answers "where" and "who."  Application protocols
     (MCP, A2A) answer "how."  Nothing in the current stack answers "what
     may we do together, and what evidence will remain."  ATN fills that
     gap with a two-round-trip handshake.

  B.2.  Why Four Artifacts

     Each artifact answers a distinct question:

     *  Capability Manifest: what is this agent willing to do?

     *  Delegation Chain: who authorized it?




  Somoza                  Expires 18 November 2026               [Page 46]


  Internet-Draft           agent-trust-negotiation                May 2026


     *  Provenance Attestation: what is it actually running?

     *  Session Receipt: what did we agree?

     Collapsing them into one document obscures the separation of
     concerns.  Splitting further fragments the trust evaluation.  Four is
     the minimum.

  B.3.  Why Refusals Are First-Class

     Capability advertisement alone creates a moral hazard: agents have an
     incentive to advertise broadly.  Mandatory refusals create symmetric
     accountability: an agent that explicitly refused a category and then
     violated the refusal has produced cryptographic evidence against
     itself.

  B.4.  Why Intersection Algebra Is Specified

     If two implementations compute intersections differently,
     interoperability fails.  The algebra is small, specified, and
     testable.  The cost is one paragraph of spec; the benefit is
     deterministic handshake outcomes.

  B.5.  Why SCITT for Receipts

     Session Receipts gain value through public auditability.  SCITT
     [SCITT] provides the transparency infrastructure.  Receipts published
     to SCITT cannot be tampered with after the fact without detection.

  Appendix C.  Implementation Status

     This section records the status of known implementations of the
     protocol defined by this specification at the time of posting of this
     Internet-Draft, per the guidelines of RFC 7942.  The description of
     implementations in this section is intended to assist the IETF in its
     decision processes in progressing drafts to RFCs.  Note to RFC
     Editor: this section may be removed prior to final publication.

  C.1.  ATN Reference Prototype

     *  Organization: Independent (E.  Somoza).

     *  Implementation Name: atn-prototype.

     *  Description: A TypeScript prototype that demonstrates the four-
        message handshake, the capability intersection algebra, Ed25519
        signing and verification of artifacts and messages, and the
        digest-bound artifact reference model.



  Somoza                  Expires 18 November 2026               [Page 47]


  Internet-Draft           agent-trust-negotiation                May 2026


     *  License: CC0 1.0 Universal (public domain).

     *  Maturity: prototype.  Not production-ready.  Not security-audited.

     *  Coverage: Capability Manifest types, Delegation Chain types,
        Provenance Attestation types, Session Receipt, ATH state machine
        (HELLO, OFFER, ACCEPT, RECEIPT), capability intersection algebra
        per Section 9, version negotiation with downgrade protection.  DNS
        resolution, HTTPS artifact fetch, and SCITT submission are
        stubbed.

     *  Verified behavior: end-to-end handshake between two synthetic
        agents with mismatched capability constraints produces a signed
        Session Receipt with negotiated scope exactly matching the
        algorithm in Section 9.  Numeric constraints take minimums, list
        constraints take intersections, refusals override.

     *  Repository: https://github.com/e-somoza/atn-prototype

  Appendix D.  Acknowledgments

     This document builds on the substantial work of the DNS-based agent
     discovery community, including the authors of AID, DNS-AID, ANS v2,
     DN-ANR, and BANDAID.  ATN is intended to complement, not compete
     with, that work.

  Author's Address

     Enrique Somoza
     Independent
     United States of America
     Email: enrique@somoza.co



















  Somoza                  Expires 18 November 2026               [Page 48]


name: draft-xu-efficient-agent-discovery-profile
rev: 00
title: Metadata and Query Profile for Efficient Agent Discovery
time: 2026-05-18T05:50:59Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-19T05:50:59Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Data formats/interop", "ML traffic mgmt"]
tags: []
fetched_at: 2026-05-22T09:24:41.698405+00:00
source: ietf
abstract:
  This document defines a metadata and query profile for efficient
     discovery of autonomous software agents.  The profile describes how
     agents publish capability metadata using explicit tags, natural-
     language descriptions, example tasks, protocol bindings, and
     operational constraints.  It also defines JSON metadata, discovery
     request, and discovery response objects that enable discovery
     services to combine structured filtering, semantic retrieval, and
     fine-grained matching while preserving an interoperable protocol
     surface.

     The profile does not mandate a specific machine-learning model,
     embedding model, database, or ranking algorithm.  Instead, it
     standardizes the metadata and result evidence needed by clients and
     discovery services so that different implementations can interoperate
     while optimizing their own latency, scalability, and ranking quality.

full_text:
  Independent Submission                                             J. Xu
  Internet-Draft                                                     B. Li
  Intended status: Informational                                    R. Zhu
  Expires: 9 November 2026                                           CAICT
                                                                8 May 2026


          Metadata and Query Profile for Efficient Agent Discovery
               draft-xu-efficient-agent-discovery-profile-00

  Abstract

     This document defines a metadata and query profile for efficient
     discovery of autonomous software agents.  The profile describes how
     agents publish capability metadata using explicit tags, natural-
     language descriptions, example tasks, protocol bindings, and
     operational constraints.  It also defines JSON metadata, discovery
     request, and discovery response objects that enable discovery
     services to combine structured filtering, semantic retrieval, and
     fine-grained matching while preserving an interoperable protocol
     surface.

     The profile does not mandate a specific machine-learning model,
     embedding model, database, or ranking algorithm.  Instead, it
     standardizes the metadata and result evidence needed by clients and
     discovery services so that different implementations can interoperate
     while optimizing their own latency, scalability, and ranking quality.

  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 9 November 2026.







  Xu, et al.               Expires 9 November 2026                [Page 1]


  Internet-Draft           Agent Discovery Profile                May 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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Applicability . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.4.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.5.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Profile Overview  . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Conformance Levels  . . . . . . . . . . . . . . . . . . .   7
     4.  Agent Metadata  . . . . . . . . . . . . . . . . . . . . . . .   7
       4.1.  Top-Level Fields  . . . . . . . . . . . . . . . . . . . .   8
       4.2.  Identifier and Name . . . . . . . . . . . . . . . . . . .   9
       4.3.  Description . . . . . . . . . . . . . . . . . . . . . . .   9
       4.4.  Capability Tags . . . . . . . . . . . . . . . . . . . . .   9
       4.5.  Example Tasks . . . . . . . . . . . . . . . . . . . . . .  10
       4.6.  Protocol Bindings . . . . . . . . . . . . . . . . . . . .  10
       4.7.  Versioning and Extensions . . . . . . . . . . . . . . . .  11
       4.8.  Status and Freshness  . . . . . . . . . . . . . . . . . .  12
       4.9.  Metadata Example  . . . . . . . . . . . . . . . . . . . .  12
     5.  Discovery Request . . . . . . . . . . . . . . . . . . . . . .  13
       5.1.  Request Fields  . . . . . . . . . . . . . . . . . . . . .  13
       5.2.  Request Example . . . . . . . . . . . . . . . . . . . . .  14
     6.  Discovery Response  . . . . . . . . . . . . . . . . . . . . .  15
       6.1.  Response Fields . . . . . . . . . . . . . . . . . . . . .  15
       6.2.  Score Components  . . . . . . . . . . . . . . . . . . . .  17
       6.3.  Response Example  . . . . . . . . . . . . . . . . . . . .  17
     7.  Discovery Processing Model  . . . . . . . . . . . . . . . . .  18
       7.1.  Index Construction  . . . . . . . . . . . . . . . . . . .  19
       7.2.  Query Processing  . . . . . . . . . . . . . . . . . . . .  19
       7.3.  Example-Level Matching  . . . . . . . . . . . . . . . . .  20
       7.4.  Privacy Defaults and Redaction  . . . . . . . . . . . . .  20
     8.  Matching Evidence . . . . . . . . . . . . . . . . . . . . . .  20
     9.  Registration and Update Behavior  . . . . . . . . . . . . . .  21
     10. Federation  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     11. Interoperability Considerations . . . . . . . . . . . . . . .  22



  Xu, et al.               Expires 9 November 2026                [Page 2]


  Internet-Draft           Agent Discovery Profile                May 2026


     12. Error Model . . . . . . . . . . . . . . . . . . . . . . . . .  23
     13. Test Vectors  . . . . . . . . . . . . . . . . . . . . . . . .  24
       13.1.  Minimal D0 Metadata  . . . . . . . . . . . . . . . . . .  24
       13.2.  Minimal D1 Query . . . . . . . . . . . . . . . . . . . .  25
       13.3.  Unsupported Hard Filter  . . . . . . . . . . . . . . . .  25
     14. Security Considerations . . . . . . . . . . . . . . . . . . .  25
     15. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  26
     16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
     17. Implementation Status . . . . . . . . . . . . . . . . . . . .  27
     18. Implementation Checklist  . . . . . . . . . . . . . . . . . .  27
     19. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
       19.1.  Normative References . . . . . . . . . . . . . . . . . .  28
       19.2.  Informative References . . . . . . . . . . . . . . . . .  28
     Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  28
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

  1.  Introduction

     Agent ecosystems require a way to find suitable agents from large and
     dynamic candidate sets.  Exact lookup by identifier is not
     sufficient: users and agents often express intent in natural
     language, while available agents expose capabilities using
     heterogeneous names, descriptions, tags, examples, protocols, and
     endpoint metadata.

     Naive discovery approaches have undesirable trade-offs.  Heavy
     language-model parsing can provide good intent understanding but may
     add unacceptable latency for interactive or agent-to-agent
     negotiation.  Simple vector search over a single concatenated
     description can be fast but may dilute important capability details
     in multi-purpose agents.  Keyword search over tags can be efficient
     but may miss semantically related agents.

     This document defines an efficient agent discovery profile that
     separates agent metadata into complementary signals:

     *  explicit capability tags for fast structured filtering;

     *  natural-language descriptions for broad semantic matching;

     *  example tasks for fine-grained intent matching;

     *  protocol and endpoint bindings for reachability; and

     *  operational constraints for safe candidate selection.






  Xu, et al.               Expires 9 November 2026                [Page 3]


  Internet-Draft           Agent Discovery Profile                May 2026


     The profile standardizes what agents publish and what discovery
     services return.  Discovery services remain free to implement tag
     indices, dense vector indices, example-level matching, neural
     routers, symbolic rules, or hybrid approaches.

  1.1.  Problem Statement

     Agent discovery has two competing requirements.  It must be
     expressive enough to match natural-language task intent against
     heterogeneous agents, and it must be concrete enough that independent
     implementations can exchange metadata and queries without sharing the
     same ranking engine.

     Existing mechanisms can publish web resources, service descriptors,
     or tool manifests, but they do not by themselves define the
     discovery-specific combination of capability tags, broad
     descriptions, example tasks, freshness, matching evidence, and ranked
     responses used by this profile.  Without a common profile, discovery
     services either expose platform-specific metadata or return opaque
     rankings that clients cannot validate, debug, or compare.

     This document therefore standardizes the metadata and query surface,
     not the internal retrieval implementation.

  1.2.  Applicability

     This profile is applicable to registries, directories, marketplaces,
     gateways, or local discovery services that need to return candidate
     agents for a task intent.  It is not intended to replace exact
     identifier resolution, endpoint security, or post-discovery
     invocation protocols.

  1.3.  Goals

     This profile has the following goals:

     *  define an agent metadata object suitable for high-performance
        discovery;

     *  support both structured filtering and natural-language intent
        search;

     *  preserve fine-grained capability signals for multi-purpose agents;

     *  define discovery request and response fields that are independent
        of any particular ranking algorithm;





  Xu, et al.               Expires 9 November 2026                [Page 4]


  Internet-Draft           Agent Discovery Profile                May 2026


     *  allow discovery results to include matching evidence and
        confidence signals;

     *  support incremental metadata updates; and

     *  provide security and privacy guidance for discovery services.

  1.4.  Non-Goals

     This profile does not define:

     *  a new transport protocol;

     *  a new URI scheme;

     *  a mandatory registry topology;

     *  a mandatory ranking formula;

     *  a mandatory embedding model, language model, or vector database;

     *  a reputation system; or

     *  an invocation protocol for executing tasks after discovery.

  1.5.  Requirements Language

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

  2.  Terminology

     Agent:  An autonomous or semi-autonomous software system that exposes
        one or more capabilities and can be selected for invocation.

     Agent Metadata:  A structured object that describes an agent's
        identity, capabilities, examples, protocol bindings, and
        operational constraints.

     Capability Tag:  A short normalized label that identifies a
        capability, domain, industry, task type, or other discovery-
        relevant property.

     Context Description:  A natural-language description of an agent's
        purpose, scope, and supported tasks.



  Xu, et al.               Expires 9 November 2026                [Page 5]


  Internet-Draft           Agent Discovery Profile                May 2026


     Discovery Request:  A request sent by a client or agent to a
        discovery service to obtain candidate agents.

     Discovery Response:  A response containing ranked candidate agents
        and matching evidence.

     Example Task:  A short natural-language example of a user request,
        agent-to-agent request, or task pattern that the agent is intended
        to handle.

     Matching Evidence:  Data returned by a discovery service to explain
        why a candidate was selected, such as matched tags, matched
        examples, score components, or policy filters.

  3.  Profile Overview

     The profile has two interoperable surfaces:

     *  the Agent Metadata object, published by agents or registries; and

     *  the Discovery Request and Discovery Response objects, exchanged
        between clients and discovery services.

     The canonical field names and examples in this profile use JSON
     [RFC8259].  Other serializations MAY be used by a transport or
     registry binding only when the binding defines an unambiguous mapping
     for field names, value types, arrays, objects, and unknown-field
     behavior.

     The following figure shows a typical implementation.  It is
     illustrative, not normative.

                  metadata publication
        Agent ----------------------------> Discovery Service
            \                                 |
             \                                | builds indices
              \                               v
               \                       +-------------+
                \                      | tag index   |
                 \                     | context idx |
                  \                    | example idx |
                   \                   +-------------+
                    \
                     \ discovery request
                      v
        Client ---------------------------> Discovery Service
        Client <--------------------------- ranked candidates
                         response with matching evidence



  Xu, et al.               Expires 9 November 2026                [Page 6]


  Internet-Draft           Agent Discovery Profile                May 2026


     The discovery service MAY build separate internal indices from the
     same metadata.  For example, it might build an inverted index for
     tags, an embedding index for descriptions, and an example-level index
     for task examples.  These internal structures are not part of the
     wire profile.

  3.1.  Conformance Levels

     This profile defines three conformance levels for incremental
     adoption.

          +=======+================+===============================+
          | Level | Name           | Requirements                  |
          +=======+================+===============================+
          | D0    | Metadata       | Publish Agent Metadata with   |
          |       |                | id, name, description, and at |
          |       |                | least one bindings entry.     |
          +-------+----------------+-------------------------------+
          | D1    | Structured     | Support Discovery Requests    |
          |       | Discovery      | with tag and protocol filters |
          |       |                | and return ranked candidates. |
          +-------+----------------+-------------------------------+
          | D2    | Evidence-Based | Return matching evidence,     |
          |       | Discovery      | freshness data, and score     |
          |       |                | components when requested.    |
          +-------+----------------+-------------------------------+

                                   Table 1

     Implementations SHOULD state the highest level they support.  A D2
     discovery service MUST also satisfy D0 and D1.  Clients SHOULD
     tolerate lower levels but MUST NOT assume that a D0 publisher
     supports query processing.

  4.  Agent Metadata

     An Agent Metadata object describes an agent for discovery.  It MUST
     be a single JSON object unless another serialization is explicitly
     selected by a binding profile that preserves the data model defined
     in this document.











  Xu, et al.               Expires 9 November 2026                [Page 7]


  Internet-Draft           Agent Discovery Profile                May 2026


  4.1.  Top-Level Fields

     +=============+==========+=============+============================+
     | Field       | Type     | Requirement | Description                |
     +=============+==========+=============+============================+
     | id          | string   | MUST        | Stable identifier of the   |
     |             |          |             | agent                      |
     +-------------+----------+-------------+----------------------------+
     | name        | string   | MUST        | Human-readable name        |
     +-------------+----------+-------------+----------------------------+
     | description | string   | MUST        | Natural-language context   |
     |             |          |             | description                |
     +-------------+----------+-------------+----------------------------+
     | tags        | array of | SHOULD      | Normalized capability      |
     |             | string   |             | tags                       |
     +-------------+----------+-------------+----------------------------+
     | examples    | array of | SHOULD      | Example tasks or request   |
     |             | object   |             | patterns                   |
     +-------------+----------+-------------+----------------------------+
     | bindings    | array of | MUST        | Protocol and endpoint      |
     |             | object   |             | bindings                   |
     +-------------+----------+-------------+----------------------------+
     | auth        | object   | SHOULD      | Authentication             |
     |             |          |             | requirements               |
     +-------------+----------+-------------+----------------------------+
     | constraints | object   | MAY         | Region, policy, cost,      |
     |             |          |             | rate, or data constraints  |
     +-------------+----------+-------------+----------------------------+
     | status      | string   | SHOULD      | Operational status         |
     +-------------+----------+-------------+----------------------------+
     | expires_at  | string   | MAY         | Time after which the       |
     |             |          |             | record should be           |
     |             |          |             | refreshed                  |
     +-------------+----------+-------------+----------------------------+
     | version     | string   | SHOULD      | Metadata version or        |
     |             |          |             | capability version         |
     +-------------+----------+-------------+----------------------------+
     | updated_at  | string   | SHOULD      | Timestamp for freshness    |
     |             |          |             | checks                     |
     +-------------+----------+-------------+----------------------------+
     | signature   | object   | MAY         | Signature or credential    |
     |             |          |             | binding metadata           |
     +-------------+----------+-------------+----------------------------+

                                    Table 2






  Xu, et al.               Expires 9 November 2026                [Page 8]


  Internet-Draft           Agent Discovery Profile                May 2026


     Field names are case-sensitive.  Implementations SHOULD ignore
     unknown fields for forward compatibility, but MUST preserve unknown
     fields when acting as a transparent metadata relay.

  4.2.  Identifier and Name

     The id field MUST be stable for the lifecycle of the agent
     registration.  It MAY be a URI, DNS-based name, registry-local
     identifier, or another profile-defined identifier.  This profile does
     not define or reserve a new URI scheme; when URIs are used, their
     schemes are defined outside this document.  Discovery services MUST
     NOT assume that the human-readable name field is globally unique.

  4.3.  Description

     The description field provides broad semantic context.  It SHOULD
     describe:

     *  the agent's primary purpose;

     *  supported domains;

     *  important input and output types;

     *  operational limitations; and

     *  safety or policy-relevant boundaries.

     Descriptions SHOULD be written for discovery and interoperability,
     not marketing.  They SHOULD avoid unsupported superlatives such as
     "best", "perfect", or "guaranteed".

  4.4.  Capability Tags

     The tags field contains normalized labels.  Tags SHOULD be selected
     from one or more declared taxonomies when possible.

     Tags SHOULD be concise, lowercase, and stable.  A tag SHOULD
     represent a capability, domain, task family, data type, industry,
     protocol, or language.  Examples:

     ["translation", "finance", "invoice-processing", "json-output"]

     Discovery services MAY expand tags using taxonomy relationships or
     synonym maps.  If expansion is used, the response SHOULD distinguish
     directly matched tags from expanded or inferred tags.





  Xu, et al.               Expires 9 November 2026                [Page 9]


  Internet-Draft           Agent Discovery Profile                May 2026


  4.5.  Example Tasks

     The examples field preserves fine-grained capability signals.  Each
     example SHOULD describe a concrete task the agent can handle.

         +===============+==========+=============+==================+
         | Field         | Type     | Requirement | Description      |
         +===============+==========+=============+==================+
         | id            | string   | SHOULD      | Stable example   |
         |               |          |             | identifier       |
         +---------------+----------+-------------+------------------+
         | text          | string   | MUST        | Example task or  |
         |               |          |             | request          |
         +---------------+----------+-------------+------------------+
         | tags          | array of | MAY         | Tags associated  |
         |               | string   |             | with the example |
         +---------------+----------+-------------+------------------+
         | input_schema  | object   | MAY         | Expected input   |
         |               |          |             | shape            |
         +---------------+----------+-------------+------------------+
         | output_schema | object   | MAY         | Expected output  |
         |               |          |             | shape            |
         +---------------+----------+-------------+------------------+
         | language      | string   | MAY         | Language tag     |
         +---------------+----------+-------------+------------------+

                                    Table 3

     Example tasks SHOULD be specific.  For a multi-purpose agent,
     publishers SHOULD include examples for distinct capability modes
     rather than averaging all capabilities into one broad description.

  4.6.  Protocol Bindings

     The bindings field tells a client how the agent can be contacted or
     invoked after discovery.















  Xu, et al.               Expires 9 November 2026               [Page 10]


  Internet-Draft           Agent Discovery Profile                May 2026


      +===================+=========+=============+====================+
      | Field             | Type    | Requirement | Description        |
      +===================+=========+=============+====================+
      | protocol          | string  | MUST        | Protocol           |
      |                   |         |             | identifier defined |
      |                   |         |             | by the selected    |
      |                   |         |             | binding profile,   |
      |                   |         |             | such as https      |
      +-------------------+---------+-------------+--------------------+
      | endpoint          | string  | MUST        | Endpoint reference |
      |                   |         |             | or URI             |
      +-------------------+---------+-------------+--------------------+
      | media_types       | array   | MAY         | Supported request  |
      |                   | of      |             | or response media  |
      |                   | string  |             | types              |
      +-------------------+---------+-------------+--------------------+
      | interaction_model | string  | MAY         | request-response,  |
      |                   |         |             | streaming, batch,  |
      |                   |         |             | or profile-defined |
      |                   |         |             | value              |
      +-------------------+---------+-------------+--------------------+
      | priority          | integer | MAY         | Preference order   |
      |                   |         |             | among bindings     |
      +-------------------+---------+-------------+--------------------+

                                   Table 4

     Discovery clients MUST verify that a binding is acceptable under
     local policy before invocation.

  4.7.  Versioning and Extensions

     Metadata publishers SHOULD include a version field and SHOULD update
     it whenever the meaning of capabilities, examples, or bindings
     changes.

     Unknown top-level fields MUST be ignored by discovery services unless
     local policy requires strict validation.  Unknown fields in nested
     objects SHOULD also be ignored.  Implementations that relay metadata
     SHOULD preserve unknown fields unless doing so conflicts with privacy
     or policy requirements.

     Private extension fields SHOULD use collision-resistant names, such
     as reverse-DNS names or URIs.  Extensions that affect ranking,
     authorization, or wire compatibility SHOULD be documented in a stable
     specification.





  Xu, et al.               Expires 9 November 2026               [Page 11]


  Internet-Draft           Agent Discovery Profile                May 2026


  4.8.  Status and Freshness

     The status field SHOULD use one of:

     *  active

     *  inactive

     *  suspended

     *  deprecated

     *  testing

     The updated_at or version field SHOULD be used to reject stale
     metadata.  Discovery services SHOULD expose when a result was indexed
     and whether the source metadata is older than a client-supplied
     freshness constraint.

     If expires_at is present, discovery services SHOULD stop returning
     the record after that time unless local policy explicitly allows
     stale results.  Publishers SHOULD refresh records before expiration
     and SHOULD use random jitter for large fleets to avoid synchronized
     refresh bursts.

  4.9.  Metadata Example

























  Xu, et al.               Expires 9 November 2026               [Page 12]


  Internet-Draft           Agent Discovery Profile                May 2026


     {
       "id": "https://agents.example.net/id/hr-core-automator",
       "name": "HR Core Automator",
       "description": "Optimizes HR workflows and onboarding checks.",
       "tags": ["hr", "workflow", "onboarding", "hcm", "api-automation"],
       "examples": [
         {
           "id": "ex-1",
           "text": "Prepare a new-employee onboarding workflow.",
           "tags": ["onboarding", "workflow"]
         },
         {
           "id": "ex-2",
           "text": "Check an employee record for missing payroll fields.",
           "tags": ["employee-record", "validation"]
         }
       ],
       "bindings": [
         {
           "protocol": "https",
           "endpoint": "https://agents.example.net/hr-core/invoke",
           "media_types": ["application/json"],
           "interaction_model": "request-response"
         }
       ],
       "status": "active",
       "version": "1.0.0",
       "updated_at": "2026-05-08T00:00:00Z"
     }

  5.  Discovery Request

     A Discovery Request asks a discovery service to return candidate
     agents.  It MUST be a single JSON object unless another serialization
     is explicitly selected by a binding profile that preserves the data
     model defined in this document.

  5.1.  Request Fields

     +==================+=========+=============+=======================+
     | Field            | Type    | Requirement | Description           |
     +==================+=========+=============+=======================+
     | query            | string  | MUST        | Natural-language      |
     |                  |         |             | intent or task        |
     |                  |         |             | description           |
     +------------------+---------+-------------+-----------------------+
     | required_tags    | array   | MAY         | Tags that candidates  |
     |                  | of      |             | must satisfy          |



  Xu, et al.               Expires 9 November 2026               [Page 13]


  Internet-Draft           Agent Discovery Profile                May 2026


     |                  | string  |             |                       |
     +------------------+---------+-------------+-----------------------+
     | preferred_tags   | array   | MAY         | Tags that increase    |
     |                  | of      |             | ranking score         |
     |                  | string  |             |                       |
     +------------------+---------+-------------+-----------------------+
     | excluded_tags    | array   | MAY         | Tags that candidates  |
     |                  | of      |             | must not contain      |
     |                  | string  |             |                       |
     +------------------+---------+-------------+-----------------------+
     | protocols        | array   | MAY         | Acceptable protocols  |
     |                  | of      |             |                       |
     |                  | string  |             |                       |
     +------------------+---------+-------------+-----------------------+
     | constraints      | object  | MAY         | Policy, region, cost, |
     |                  |         |             | latency, or freshness |
     |                  |         |             | constraints           |
     +------------------+---------+-------------+-----------------------+
     | limit            | integer | MAY         | Maximum number of     |
     |                  |         |             | candidates            |
     +------------------+---------+-------------+-----------------------+
     | include_evidence | boolean | MAY         | Whether matching      |
     |                  |         |             | evidence is requested |
     +------------------+---------+-------------+-----------------------+
     | detail           | string  | MAY         | minimal, summary, or  |
     |                  |         |             | full response detail  |
     +------------------+---------+-------------+-----------------------+
     | client_context   | object  | MAY         | Client-side hints     |
     |                  |         |             | such as locale or     |
     |                  |         |             | domain                |
     +------------------+---------+-------------+-----------------------+

                                   Table 5

     A discovery service MUST apply required_tags and excluded_tags as
     hard filters when it supports the corresponding taxonomy.  If it
     cannot apply a hard filter, it MUST report that limitation in the
     response.

     The detail field controls metadata minimization.  A value of minimal
     requests only identifiers, status, and enough endpoint data to
     continue resolution.  A value of summary requests the normal
     candidate summary.  A value of full requests complete metadata where
     policy permits.  Discovery services MAY redact fields even when full
     is requested.

  5.2.  Request Example




  Xu, et al.               Expires 9 November 2026               [Page 14]


  Internet-Draft           Agent Discovery Profile                May 2026


     {
       "query": "Find an agent for onboarding validation and API setup.",
       "required_tags": ["hr"],
       "preferred_tags": ["onboarding", "api-automation"],
       "protocols": ["https"],
       "constraints": {
         "max_results_age_seconds": 300,
         "region": "apac"
       },
       "limit": 10,
       "detail": "summary",
       "include_evidence": true
     }

  6.  Discovery Response

     A Discovery Response contains ranked candidates.  It MUST be a single
     JSON object unless another serialization is explicitly selected by a
     binding profile that preserves the data model defined in this
     document.

  6.1.  Response Fields

     +=====================+========+=============+=====================+
     | Field               | Type   | Requirement | Description         |
     +=====================+========+=============+=====================+
     | request_id          | string | SHOULD      | Identifier for      |
     |                     |        |             | tracing the request |
     +---------------------+--------+-------------+---------------------+
     | candidates          | array  | MUST        | Ranked candidate    |
     |                     | of     |             | agents              |
     |                     | object |             |                     |
     +---------------------+--------+-------------+---------------------+
     | applied_filters     | object | SHOULD      | Filters applied by  |
     |                     |        |             | the discovery       |
     |                     |        |             | service             |
     +---------------------+--------+-------------+---------------------+
     | unsupported_filters | array  | MAY         | Filters the service |
     |                     | of     |             | could not apply     |
     |                     | string |             |                     |
     +---------------------+--------+-------------+---------------------+
     | warnings            | array  | MAY         | Limitations or      |
     |                     | of     |             | policy warnings     |
     |                     | string |             |                     |
     +---------------------+--------+-------------+---------------------+
     | generated_at        | string | SHOULD      | Response generation |
     |                     |        |             | timestamp           |
     +---------------------+--------+-------------+---------------------+



  Xu, et al.               Expires 9 November 2026               [Page 15]


  Internet-Draft           Agent Discovery Profile                May 2026


                                   Table 6

     Each candidate object SHOULD include:

     +==================+==========+=============+=======================+
     | Field            | Type     | Requirement | Description           |
     +==================+==========+=============+=======================+
     | id               | string   | MUST        | Agent identifier      |
     +------------------+----------+-------------+-----------------------+
     | name             | string   | SHOULD      | Human-readable        |
     |                  |          |             | name                  |
     +------------------+----------+-------------+-----------------------+
     | description      | string   | SHOULD      | Short description     |
     |                  |          |             | or summary            |
     +------------------+----------+-------------+-----------------------+
     | bindings         | array of | SHOULD      | Usable protocol       |
     |                  | object   |             | bindings              |
     +------------------+----------+-------------+-----------------------+
     | score            | number   | SHOULD      | Overall ranking       |
     |                  |          |             | score                 |
     +------------------+----------+-------------+-----------------------+
     | score_components | object   | MAY         | Structured score      |
     |                  |          |             | details               |
     +------------------+----------+-------------+-----------------------+
     | matched_tags     | array of | MAY         | Tags matched          |
     |                  | string   |             | directly or by        |
     |                  |          |             | expansion             |
     +------------------+----------+-------------+-----------------------+
     | matched_examples | array of | MAY         | Examples that         |
     |                  | object   |             | matched the query     |
     +------------------+----------+-------------+-----------------------+
     | credential_refs  | array of | MAY         | References for        |
     |                  | string   |             | verification          |
     +------------------+----------+-------------+-----------------------+
     | redacted         | boolean  | MAY         | Whether fields        |
     |                  |          |             | were omitted by       |
     |                  |          |             | policy                |
     +------------------+----------+-------------+-----------------------+
     | status           | string   | SHOULD      | Operational           |
     |                  |          |             | status                |
     +------------------+----------+-------------+-----------------------+
     | freshness        | object   | SHOULD      | Index and             |
     |                  |          |             | metadata              |
     |                  |          |             | freshness             |
     +------------------+----------+-------------+-----------------------+

                                    Table 7




  Xu, et al.               Expires 9 November 2026               [Page 16]


  Internet-Draft           Agent Discovery Profile                May 2026


     Scores are local to the discovery service.  Clients MUST NOT compare
     scores from different discovery services unless a common scoring
     profile is explicitly defined.

  6.2.  Score Components

     When score_components is returned, the following component names are
     RECOMMENDED:

        +===========+=================================================+
        | Component | Meaning                                         |
        +===========+=================================================+
        | tag       | Match between query-derived tags and agent tags |
        +-----------+-------------------------------------------------+
        | context   | Semantic match against descriptions or broad    |
        |           | context text                                    |
        +-----------+-------------------------------------------------+
        | example   | Match against one or more example tasks         |
        +-----------+-------------------------------------------------+
        | protocol  | Compatibility with requested protocol bindings  |
        +-----------+-------------------------------------------------+
        | freshness | Penalty or bonus based on metadata age          |
        +-----------+-------------------------------------------------+
        | policy    | Local policy, trust, region, or entitlement     |
        |           | signal                                          |
        +-----------+-------------------------------------------------+

                                    Table 8

     Implementations MAY add deployment-specific components.  Unknown
     components MUST be ignored by clients that do not understand them.

  6.3.  Response Example


















  Xu, et al.               Expires 9 November 2026               [Page 17]


  Internet-Draft           Agent Discovery Profile                May 2026


     {
       "request_id": "req-123",
       "generated_at": "2026-05-08T00:00:01Z",
       "applied_filters": {
         "required_tags": ["hr"],
         "protocols": ["https"]
       },
       "candidates": [
         {
           "id": "https://agents.example.net/id/hr-core-automator",
           "name": "HR Core Automator",
           "description": "Optimizes onboarding workflows.",
           "bindings": [
             {
               "protocol": "https",
               "endpoint": "https://agents.example.net/hr-core/invoke"
             }
           ],
           "score": 0.91,
           "score_components": {
             "tag": 0.95,
             "context": 0.83,
             "example": 0.96
           },
           "matched_tags": ["hr", "onboarding", "api-automation"],
           "matched_examples": [
             {
               "id": "ex-1",
               "score": 0.96,
               "text": "Prepare a new-employee onboarding workflow."
             }
           ],
           "status": "active",
           "freshness": {
             "metadata_updated_at": "2026-05-08T00:00:00Z",
             "indexed_at": "2026-05-08T00:00:00Z"
           }
         }
       ]
     }

  7.  Discovery Processing Model

     This section describes a recommended processing model.  It is not
     mandatory, but it explains how the metadata fields in this profile
     support efficient discovery.





  Xu, et al.               Expires 9 November 2026               [Page 18]


  Internet-Draft           Agent Discovery Profile                May 2026


  7.1.  Index Construction

     A discovery service can build three complementary indices:

     Tag index:  An inverted index from capability tag to agent
        identifiers.  This supports fast filtering and high-recall
        candidate generation.

     Context index:  A semantic index over descriptions, generated
        summaries, or other broad context fields.  This supports natural-
        language recall when user wording differs from tags.

     Example index:  A fine-grained index over individual example tasks.
        This preserves distinct capability modes for multi-purpose agents.

     Discovery services MAY augment descriptions with synthetic queries or
     other derived text.  If derived text materially affects ranking,
     implementations SHOULD retain provenance so that debugging and abuse
     review are possible.

  7.2.  Query Processing

     A discovery service following the recommended model processes a
     request as follows:

     1.  Validate the request and apply authentication or rate limits.

     2.  Normalize tags and constraints against supported taxonomies.

     3.  Derive query features, such as predicted tags, query embeddings,
         or symbolic constraints.

     4.  Retrieve candidates from the tag index and context index.

     5.  Merge and deduplicate candidates.

     6.  Re-rank candidates using example-level, policy, freshness, and
         operational signals.

     7.  Return candidates with matching evidence and warnings.

     The service SHOULD bound the number of candidates entering expensive
     re-ranking stages.  The service SHOULD return partial results with
     warnings when a non-critical ranking component is unavailable.







  Xu, et al.               Expires 9 November 2026               [Page 19]


  Internet-Draft           Agent Discovery Profile                May 2026


  7.3.  Example-Level Matching

     For multi-purpose agents, example-level matching is RECOMMENDED.  The
     service SHOULD preserve separate example vectors or features rather
     than representing all examples only as one averaged vector.  This
     allows a query to match one specific capability even when the agent
     has other unrelated capabilities.

     A discovery service MAY compute the final score using a weighted
     combination of tag, context, example, freshness, and policy
     components.  This document does not define the weights.

  7.4.  Privacy Defaults and Redaction

     Discovery services SHOULD minimize results by default.  Unless
     detail=full is requested and authorized, responses SHOULD omit
     sensitive endpoint details, private examples, internal system names,
     billing hints, and non-public credential references.

     If fields are omitted due to policy, the candidate SHOULD include
     "redacted": true and the response SHOULD include a warning or policy
     reason when doing so does not reveal sensitive information.

  8.  Matching Evidence

     Matching evidence helps clients decide whether a result is useful and
     helps operators debug search behavior.

     When include_evidence is true, a discovery response SHOULD include at
     least one of:

     *  matched tags;

     *  matched examples;

     *  matched description snippets;

     *  score components;

     *  applied filters;

     *  rejected hard constraints; or

     *  freshness indicators.

     Evidence MUST NOT disclose private metadata or private user queries
     from other clients.




  Xu, et al.               Expires 9 November 2026               [Page 20]


  Internet-Draft           Agent Discovery Profile                May 2026


  9.  Registration and Update Behavior

     Discovery quality depends on fresh metadata.  Registries or agents
     SHOULD submit incremental updates when:

     *  endpoints change;

     *  protocol bindings change;

     *  capability tags change;

     *  examples are added or removed;

     *  operational status changes; or

     *  credentials are revoked or renewed.

     Discovery services SHOULD support sequence numbers, timestamps,
     entity tags, or equivalent freshness mechanisms.  A stale update MUST
     NOT replace a newer record.

     Registrations SHOULD be idempotent on (id, binding endpoint) or
     another profile-defined stable key.  Re-sending the same key with
     newer freshness data SHOULD be treated as a refresh.  Re-sending the
     same id with conflicting ownership or incompatible bindings SHOULD
     produce a conflict error.

  10.  Federation

     Discovery services MAY federate results from other discovery services
     or registries.  Federated results MUST include provenance sufficient
     for a client or local policy engine to determine the origin of the
     data.

     Federated candidate metadata SHOULD include:
















  Xu, et al.               Expires 9 November 2026               [Page 21]


  Internet-Draft           Agent Discovery Profile                May 2026


            +==================+=================================+
            | Field            | Description                     |
            +==================+=================================+
            | origin_service   | Discovery or registry service   |
            |                  | that supplied the record        |
            +------------------+---------------------------------+
            | origin_authority | Authority or domain responsible |
            |                  | for the record                  |
            +------------------+---------------------------------+
            | origin_signature | Signature or reference covering |
            |                  | the transferred metadata        |
            +------------------+---------------------------------+
            | received_at      | Time the local discovery        |
            |                  | service received the record     |
            +------------------+---------------------------------+

                                   Table 9

     Federation MUST NOT remove freshness, redaction, or credential
     information that a client needs to make a trust decision.

  11.  Interoperability Considerations

     This profile is intended to map cleanly to existing agent metadata
     formats.  Where another format already defines fields such as agent
     cards, tool lists, OpenAPI descriptions, or protocol-specific
     manifests, implementers SHOULD map those fields into description,
     tags, examples, bindings, and constraints rather than duplicating
     incompatible metadata.

     The following mapping is typical:




















  Xu, et al.               Expires 9 November 2026               [Page 22]


  Internet-Draft           Agent Discovery Profile                May 2026


               +===============================+===============+
               | Source Concept                | Profile Field |
               +===============================+===============+
               | Agent card name               | name          |
               +-------------------------------+---------------+
               | Agent card description        | description   |
               +-------------------------------+---------------+
               | Skill or capability list      | tags          |
               +-------------------------------+---------------+
               | Tool examples or prompts      | examples      |
               +-------------------------------+---------------+
               | Endpoint or transport binding | bindings      |
               +-------------------------------+---------------+
               | Authentication metadata       | auth          |
               +-------------------------------+---------------+
               | Rate or region limits         | constraints   |
               +-------------------------------+---------------+

                                    Table 10

  12.  Error Model

     If this profile is carried over a request/response protocol, errors
     SHOULD be returned as structured objects containing:

     +================+=============+====================================+
     | Field          | Requirement | Description                        |
     +================+=============+====================================+
     | code           | MUST        | Stable machine-                    |
     |                |             | readable error code                |
     +----------------+-------------+------------------------------------+
     | message        | SHOULD      | Human-readable                     |
     |                |             | explanation                        |
     +----------------+-------------+------------------------------------+
     | correlation_id | SHOULD      | Identifier for                     |
     |                |             | tracing and support                |
     +----------------+-------------+------------------------------------+
     | retry_after    | MAY         | Suggested retry                    |
     |                |             | delay                              |
     +----------------+-------------+------------------------------------+

                                    Table 11

     The following error codes are RECOMMENDED:







  Xu, et al.               Expires 9 November 2026               [Page 23]


  Internet-Draft           Agent Discovery Profile                May 2026


         +====================+=====================================+
         | Code               | Meaning                             |
         +====================+=====================================+
         | invalid_request    | Required field missing or malformed |
         +--------------------+-------------------------------------+
         | unsupported_filter | The service cannot apply a          |
         |                    | requested hard filter               |
         +--------------------+-------------------------------------+
         | unauthorized       | Authentication is required or       |
         |                    | failed                              |
         +--------------------+-------------------------------------+
         | forbidden          | Authenticated client lacks          |
         |                    | permission                          |
         +--------------------+-------------------------------------+
         | conflict           | Registration conflicts with an      |
         |                    | existing record                     |
         +--------------------+-------------------------------------+
         | not_found          | Requested agent or record was not   |
         |                    | found                               |
         +--------------------+-------------------------------------+
         | stale_metadata     | Candidate or registration failed    |
         |                    | freshness checks                    |
         +--------------------+-------------------------------------+
         | rate_limited       | Client exceeded rate or quota       |
         |                    | limits                              |
         +--------------------+-------------------------------------+

                                   Table 12

     HTTP bindings, if used, SHOULD map these errors to conventional HTTP
     status codes such as 400, 401, 403, 404, 409, 410, 429, and 503,
     using the semantics defined for HTTP status codes in [RFC9110].

  13.  Test Vectors

     This section is non-normative.

     The following examples can be used as minimal parser and
     interoperation tests.

  13.1.  Minimal D0 Metadata










  Xu, et al.               Expires 9 November 2026               [Page 24]


  Internet-Draft           Agent Discovery Profile                May 2026


     {
       "id": "https://example.net/agents/minimal",
       "name": "Minimal Agent",
       "description": "Answers short factual questions.",
       "bindings": [
         {
           "protocol": "https",
           "endpoint": "https://example.net/agent/invoke"
         }
       ]
     }

     An implementation claiming D0 support MUST accept this object as
     valid metadata, assuming the identifier and endpoint scheme are
     allowed by local policy.

  13.2.  Minimal D1 Query

     {
       "query": "answer a short factual question",
       "protocols": ["https"],
       "limit": 1
     }

     A D1 discovery service receiving this query SHOULD return zero or
     more candidates and MUST NOT require include_evidence.

  13.3.  Unsupported Hard Filter

     {
       "query": "find a translation agent",
       "required_tags": ["translation"],
       "constraints": {
         "unsupported_private_filter": "example"
       }
     }

     If the service treats unsupported_private_filter as a hard filter and
     cannot apply it, the service MUST either fail the request or include
     the filter name in unsupported_filters.

  14.  Security Considerations

     Discovery is security-sensitive.  A malicious discovery result can
     steer a client to an attacker-controlled agent.

     Metadata authenticity:  Clients SHOULD verify signatures,




  Xu, et al.               Expires 9 November 2026               [Page 25]


  Internet-Draft           Agent Discovery Profile                May 2026


        credentials, or registry attestations before invoking an agent
        returned by discovery.

     Capability fraud:  Agents can exaggerate descriptions, tags, or
        examples.  Discovery services SHOULD distinguish self-asserted
        metadata from verified metadata.

     Prompt injection in metadata:  Descriptions and examples are
        untrusted text.  Discovery services using language models MUST
        prevent metadata from overriding system instructions, leaking
        private data, or changing ranking policies outside the intended
        processing path.

     Ranking manipulation:  Attackers may stuff tags, generate misleading
        examples, or create many similar agents.  Discovery services
        SHOULD apply abuse detection, duplicate detection, rate limits,
        and provenance checks.

     Stale or revoked results:  Discovery services SHOULD expose freshness
        data.  Clients MUST check revocation and endpoint validity before
        invocation.

     Federation trust:  Federated discovery can amplify false metadata.
        Discovery services MUST preserve origin and signature information
        and SHOULD apply local trust policy before merging remote
        candidates into local results.

     Filter bypass:  A discovery service that silently ignores unsupported
        hard filters can return unsafe candidates.  Services MUST report
        unsupported hard filters in unsupported_filters or fail the
        request.

     Sensitive intent leakage:  Discovery requests can reveal user goals.
        Discovery services MUST protect requests in transit and SHOULD
        minimize retention.

     Result authorization:  A discovery response is not an authorization
        decision.  The target agent MUST still enforce its own access
        control policy.

  15.  Privacy Considerations

     Agent metadata may reveal private business capabilities.  Publishers
     SHOULD avoid exposing internal system names, customer identifiers,
     private schemas, or secrets in descriptions and examples.

     Discovery services SHOULD evaluate these risks using the general
     privacy guidance for Internet protocols in [RFC6973].



  Xu, et al.               Expires 9 November 2026               [Page 26]


  Internet-Draft           Agent Discovery Profile                May 2026


     Example tasks can reveal sensitive use cases.  Publishers SHOULD
     provide representative but sanitized examples.

     Discovery services SHOULD minimize query logging, support deletion or
     retention policies, and avoid using private discovery requests to
     train models without explicit authorization.

  16.  IANA Considerations

     This document defines profile-local field names, string values, and
     error codes only.  It does not create new registries, media types,
     URI schemes, HTTP fields, or protocol parameter values.  It makes no
     IANA requests.

  17.  Implementation Status

     This section is to be removed before publication as an RFC.

     Prototype discovery systems can implement this profile using a tag
     inverted index, a dense context index over descriptions, and an
     example-level semantic index.  Small specialized classifiers or other
     fast routing models may be used to predict tags, but such models are
     not required for interoperability.

  18.  Implementation Checklist

     An implementation can be reviewed against the following checklist:

     *  supported conformance level;

     *  accepted metadata serialization;

     *  required and optional fields validated;

     *  unknown-field behavior documented;

     *  freshness and expiration checks implemented;

     *  hard-filter failure behavior implemented;

     *  score components documented;

     *  redaction behavior documented;

     *  federation provenance preserved; and

     *  security controls for metadata injection and ranking abuse
        documented.



  Xu, et al.               Expires 9 November 2026               [Page 27]


  Internet-Draft           Agent Discovery Profile                May 2026


  19.  References

  19.1.  Normative References

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

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

  19.2.  Informative References

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

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

  Appendix A.  Acknowledgements

     The authors thank participants in discussions on agent discovery,
     metadata profiles, and efficient retrieval for large agent
     ecosystems.

  Authors' Addresses

     Jinliang Xu
     CAICT
     No. 52, Huayuan North Road
     Beijing
     Haidian District, 100191
     China
     Email: xujinliang@caict.ac.cn





  Xu, et al.               Expires 9 November 2026               [Page 28]


  Internet-Draft           Agent Discovery Profile                May 2026


     Bingqi Li
     CAICT
     No. 52, Huayuan North Road
     Beijing
     Haidian District, 100191
     China
     Email: libingqi@caict.ac.cn


     Runkai Zhu
     CAICT
     No. 52, Huayuan North Road
     Beijing
     Haidian District, 100191
     China
     Email: zhurunkai@caict.ac.cn



































  Xu, et al.               Expires 9 November 2026               [Page 29]


