The Signed-Agent-Metadata HTTP Header Field for Web Bot Auth
draft-vilgalys-webbotauth-signed-agent-metadata-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Rim Vilgalys , Pablo González | ||
| Last updated | 2026-11-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vilgalys-webbotauth-signed-agent-metadata-00
Web Bot Auth R. Vilgalys
Internet-Draft P. Gonzalez
Intended status: Standards Track Google
Expires: 6 May 2027 2 November 2026
The Signed-Agent-Metadata HTTP Header Field for Web Bot Auth
draft-vilgalys-webbotauth-signed-agent-metadata-00
Abstract
Web Bot Auth uses HTTP Message Signatures to let automated HTTP
clients authenticate their identity to origins via the Signature-
Agent header field. When a multi-tenant agent platform signs
outbound requests with a shared key, all customer workloads on that
platform share a single cryptographic identity. Abusive traffic from
one tenant or workload can degrade the reputation of the entire
platform and cause origins to block legitimate tenants.
This document defines the Signed-Agent-Metadata HTTP header field, an
RFC 9651 Dictionary that carries optional, pseudonymous per-request
metadata (product, project, and session). By signing Signed-Agent-
Metadata inside the Web Bot Auth signature, a platform enables
verifiers to evaluate traffic, apply rate limits, and isolate
reputation at a narrower scope than the signing origin.
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 6 May 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Vilgalys & Gonzalez Expires 6 May 2027 [Page 1]
Internet-Draft Signed-Agent-Metadata November 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Problem Statement: Shared Fate on Multi-Tenant
Platforms . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Relationship to Web Bot Auth and Signature Agent Cards . 3
1.3. Related Approaches and Use Cases . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. The Signed-Agent-Metadata Header Field . . . . . . . . . . . 6
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Dictionary Members . . . . . . . . . . . . . . . . . . . 6
3.3. Hierarchical Scoping and Chaining . . . . . . . . . . . . 7
3.4. Identifier Generation, Stability, and Origin Scoping . . 8
4. Signing and Verification . . . . . . . . . . . . . . . . . . 9
4.1. Signing Requests . . . . . . . . . . . . . . . . . . . . 9
4.2. Verifier Processing . . . . . . . . . . . . . . . . . . . 9
4.3. Complete HTTP Request Example . . . . . . . . . . . . . . 10
5. Verifier Considerations (Non-Normative) . . . . . . . . . . . 10
5.1. Reputation Isolation and Fallback . . . . . . . . . . . . 10
5.2. Abuse Reporting to Platform Operators . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. Unsigned or Stripped Headers . . . . . . . . . . . . . . 11
6.2. Cross-Tenant Identifier Spoofing . . . . . . . . . . . . 12
6.3. Sybil Attacks and Identifier Churn . . . . . . . . . . . 12
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
7.1. Prohibition of Personally Identifiable Information . . . 12
7.2. Cross-Origin Correlation . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. HTTP Field Name Registration . . . . . . . . . . . . . . 13
9. Open Questions for the Working Group . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Vilgalys & Gonzalez Expires 6 May 2027 [Page 2]
Internet-Draft Signed-Agent-Metadata November 2026
1.1. Problem Statement: Shared Fate on Multi-Tenant Platforms
Web Bot Auth ([I-D.ietf-webbotauth-httpsig-protocol]) allows
automated HTTP clients to cryptographically sign requests using HTTP
Message Signatures ([RFC9421]) and advertise their key discovery URI
in the Signature-Agent header field.
This model maps cleanly when a single organization operates a single
crawler or bot with robust abuse controls. However, cloud browser
providers, hosted AI agent platforms, and enterprise gateways run
thousands of independent customer workloads behind shared egress
infrastructure. Consider a fictional Acme Corp (platform.acme.com),
which has pivoted from mail-order industrial products into hosting
cloud AI agents. When Acme signs outbound requests with its platform
domain key, all traffic from its customers shares one Signature-Agent
identity:
# NOTE: '\' line wrapping per RFC 8792
Signature-Agent: "https://platform.acme.com/.well-known/\
http-message-signatures-directory"
This creates a shared-fate problem for both platforms and verifiers
(origins, CDNs, and security services). Suppose one tenant runs an
aggressive scraping workload against shopping.com, while hundreds of
other tenants run benign research and shopping agents on the same
platform. The verifier at shopping.com observes malicious traffic
authenticated only by platform.acme.com. Without sub-identifiers,
the verifier must choose between two poor outcomes:
1. *Penalize the entire platform*: Apply rate limits, challenges, or
blocks to all requests from platform.acme.com, which disrupts
legitimate tenants sharing the platform.
2. *Permit platform-level abuse*: Allow traffic from
platform.acme.com to bypass controls, which leaves shopping.com
exposed to the abusive tenant.
Platforms and verifiers need a lightweight mechanism to disambiguate
sub-identities and convey per-request operational metadata under a
shared Signature-Agent key without exposing personally identifiable
information (PII) on the wire.
1.2. Relationship to Web Bot Auth and Signature Agent Cards
The Web Bot Auth ecosystem separates cryptographic key discovery,
static agent description, and dynamic per-request metadata:
Vilgalys & Gonzalez Expires 6 May 2027 [Page 3]
Internet-Draft Signed-Agent-Metadata November 2026
* *Base Protocol ([I-D.ietf-webbotauth-httpsig-protocol])*: Defines
how an automated client signs HTTP requests and points verifiers
to its public keys via Signature-Agent.
* *Signature Agent Card ([I-D.meunier-webbotauth-registry])*:
Defines a hosted JSON metadata document where an agent operator
advertises static, operator-level properties, including
client_name, contacts, and a web_bot_auth object (purpose,
trigger, rate-expectation, rfc9309-product-token, and
rfc9309-compliance).
* *Per-Request Metadata (Signed-Agent-Metadata, this document)*:
Defines an in-band HTTP header field that carries dynamic,
pseudonymous sub-identifiers (product, project, session) covered
by the per-request HTTP Message Signature.
Signed-Agent-Metadata (SAM) is additive to the Signature Agent Card.
Static properties that describe the agent as a whole (such as purpose
or trigger) belong in the hosted Signature Agent Card and are
intentionally omitted from Signed-Agent-Metadata to avoid redundancy.
Similarly, if an operator already publishes a separate Signature-
Agent URI and Signature Agent Card for each product, the operator
does not need to include the product member in Signed-Agent-Metadata.
1.3. Related Approaches and Use Cases
Several existing or proposed mechanisms address adjacent bot
authentication problems, each targeting a different operational
model:
Vilgalys & Gonzalez Expires 6 May 2027 [Page 4]
Internet-Draft Signed-Agent-Metadata November 2026
+=================+===================+============================+
| Mechanism | Primary Use Case | Limitation for Multi- |
| | | Tenant Shared Keys |
+=================+===================+============================+
| Distinct | First-party | Provisioning, hosting, and |
| Signature-Agent | crawlers, single- | caching separate key |
| URIs and Keys | tenant bots, or | directories for thousands |
| | distinct product | of dynamic customer |
| | lines where the | projects or millions of |
| | operator hosts a | ephemeral sessions creates |
| | dedicated JWK Set | high operational and key- |
| | per identity. | fetch overhead. |
+-----------------+-------------------+----------------------------+
| HTTP Cookies | Maintaining | Cookies are absent on the |
| | stateful session | first request to an |
| | continuity within | origin, are not persisted |
| | a single browser | by stateless HTTP |
| | instance on a | fetchers, and can be |
| | single origin | cleared or modified by the |
| | after an initial | client workload. A signed |
| | HTTP response. | header provides platform- |
| | | attested continuity from |
| | | the first request. |
+-----------------+-------------------+----------------------------+
| Anonymous Rate- | Locally running | Unlinkable tokens do not |
| Limiting Tokens | agents or | allow a verifier to |
| (e.g., Privacy | privacy-sensitive | isolate and block a |
| Pass [RFC9576]) | clients proving | specific abusive tenant |
| | attestation or | mid-attack, nor do they |
| | rate-limit | give the platform an |
| | compliance | identifier to investigate |
| | without linkable | when an origin reports |
| | identifiers. | abuse. |
+-----------------+-------------------+----------------------------+
Table 1
Signed-Agent-Metadata specifically addresses multi-tenant platforms
that sign traffic under a common origin and need low-overhead sub-
identity or specific behavior isolation.
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.
Vilgalys & Gonzalez Expires 6 May 2027 [Page 5]
Internet-Draft Signed-Agent-Metadata November 2026
This document uses the following terms:
* *Platform*: An entity that operates agent execution infrastructure
and signs outbound HTTP requests with its Signature-Agent key on
behalf of multiple products, customer projects, customers, or
sessions/workflows.
* *Tenant*: A customer organization, developer account, or billing
workspace that deploys or runs automated workloads on a Platform.
* *Verifier*: An HTTP origin server, reverse proxy, Content Delivery
Network (CDN), or security provider that validates the HTTP
Message Signature and evaluates the Signed-Agent-Metadata header
field.
* *Effective Identity*: The hierarchical tuple formed by the
verified Signature-Agent URI and the signed Signed-Agent-Metadata
identifier members present on a request, ordered from broadest to
narrowest scope: (Signature-Agent, product, project, session).
3. The Signed-Agent-Metadata Header Field
3.1. Syntax
The Signed-Agent-Metadata HTTP header field is a Dictionary
Structured Field as defined in Section 3.2 of [RFC9651]. Its ABNF
syntax follows the sf-dictionary production rule:
Signed-Agent-Metadata = sf-dictionary
Each dictionary member key is a lowercase token (key in [RFC9651]).
Each member value defined in this specification MUST be a String (sf-
string in [RFC9651]). Parameters on dictionary members are not
defined by this specification and MUST be ignored by verifiers.
An example Signed-Agent-Metadata header field with all three members
present:
Signed-Agent-Metadata: product="Acme-Research", project="prj_89a0f",
session="sess_88b1"
3.2. Dictionary Members
Sending the Signed-Agent-Metadata header field is OPTIONAL, and all
dictionary members within it are OPTIONAL. A platform MAY include
any subset of members that fits its architecture and tenancy model to
reduce shared-fate penalties across its workloads.
Vilgalys & Gonzalez Expires 6 May 2027 [Page 6]
Internet-Draft Signed-Agent-Metadata November 2026
+=========+===========+====================+======================+
| Member | Type | Description | Example |
| Key | | | |
+=========+===========+====================+======================+
| product | sf-string | Identifier or | product="Acme-Labs" |
| | | application name | |
| | | of the agent | |
| | | software or | |
| | | service under the | |
| | | signing platform. | |
+---------+-----------+--------------------+----------------------+
| project | sf-string | Opaque identifier | project="prj_9012" |
| | | for the tenant | |
| | | account, | |
| | | workspace, or | |
| | | billing project on | |
| | | the host platform. | |
+---------+-----------+--------------------+----------------------+
| session | sf-string | Ephemeral, opaque | session="run_3a2b1c" |
| | | identifier for a | |
| | | single bounded | |
| | | task execution, | |
| | | workflow run, or | |
| | | isolated browser | |
| | | context lifecycle. | |
+---------+-----------+--------------------+----------------------+
Table 2
Verifiers MUST ignore unrecognized member keys in the Signed-Agent-
Metadata dictionary to allow backward-compatible extensions.
3.3. Hierarchical Scoping and Chaining
Identifiers carried in Signed-Agent-Metadata are scoped namespaces,
not globally unique identifiers. They form a strict hierarchy under
the signing Signature-Agent:
Signature-Agent (Tier 0: Platform / Signing Origin)
+-- product (Tier 1: Application / Product)
+-- project (Tier 2: Tenant / Workspace)
+-- session (Tier 3: Task / Session)
When evaluating Signed-Agent-Metadata, verifiers MUST apply the
following scoping rules:
Vilgalys & Gonzalez Expires 6 May 2027 [Page 7]
Internet-Draft Signed-Agent-Metadata November 2026
1. *Chained Tuple Evaluation*: A narrower identifier MUST always be
evaluated within the namespace of the verified Signature-Agent
and all broader Signed-Agent-Metadata identifier members present
in the request. For example, session="sess_1" under
project="prj_a" and session="sess_1" under project="prj_b" MUST
be treated as distinct sessions.
2. *Omitted Intermediate Tiers*: If a platform omits an intermediate
member (for example, sending product and session without
project), the scoping chain consists of the present members in
their defined hierarchical order: (Signature-Agent, product,
session).
3.4. Identifier Generation, Stability, and Origin Scoping
To make Signed-Agent-Metadata effective for isolating noisy neighbors
and avoiding shared-fate penalties, platforms SHOULD follow these
generation practices:
1. *Platform Attestation and Tenant Isolation*: The platform SHOULD
populate Signed-Agent-Metadata members from authenticated
platform state rather than allowing tenant workloads to supply
arbitrary unverified values for project (or for product if shared
across tenants). If a platform passes through tenant-supplied
session identifiers, the platform SHOULD also include an
authenticated project member (or namespace the session identifier
per tenant) so that one tenant cannot collide with or spoof
identifiers belonging to another tenant.
2. *Identifier Stability*:
* product and project values SHOULD remain stable across
requests and across signing key rotations for the lifetime of
the product or tenant workspace. Generating a new random
project value on every HTTP request prevents reputation
accrual and reduces the utility of the field.
* session values SHOULD remain constant across HTTP requests
belonging to a single bounded task execution, workflow run, or
browser context lifecycle, and SHOULD change when a new task
or session starts. If a platform rotates session on every
request, verifiers cannot link requests within a task and will
evaluate traffic at a broader tier.
Vilgalys & Gonzalez Expires 6 May 2027 [Page 8]
Internet-Draft Signed-Agent-Metadata November 2026
3. *Origin Scoping for session*: To prevent unrelated websites from
correlating a session across origins, platforms SHOULD derive
session values per target origin (or per registrable domain).
For example, a platform can compute an origin-scoped identifier
using a keyed hash over the internal session identifier and the
target authority:
session_token = base64url(
HMAC_SHA256(
platform_secret,
internal_session_id + ":" + target_origin
)
)
With origin scoping, a verifier at https://shopping.com observes a
consistent session identifier across requests to its own origin,
while https://content.org and https://news.net observe different,
uncorrelated values.
4. Signing and Verification
4.1. Signing Requests
When a platform chooses to send Signed-Agent-Metadata on a signed Web
Bot Auth request ([I-D.ietf-webbotauth-httpsig-protocol]), it binds
the header field to the HTTP request so verifiers can authenticate
it:
1. *Construct the Header*: The platform sets the Signed-Agent-
Metadata header field with the applicable dictionary members.
2. *Include in Signature-Input*: The platform adds "signed-agent-
metadata" to the list of covered components in the Signature-
Input header field alongside "@authority" and "signature-agent".
3. *Compute the Signature*: The platform computes the HTTP Message
Signature over the signature base as specified in [RFC9421].
4.2. Verifier Processing
When receiving an HTTP request containing Signed-Agent-Metadata, a
verifier performs the following steps:
1. *Verify Signature Coverage*: Check that the Signature-Input
header field for the Web Bot Auth signature (tag="web-bot-auth")
includes "signed-agent-metadata" in its covered component list.
If "signed-agent-metadata" is not covered by the signature, the
verifier MUST ignore the Signed-Agent-Metadata header field.
Vilgalys & Gonzalez Expires 6 May 2027 [Page 9]
Internet-Draft Signed-Agent-Metadata November 2026
2. *Validate the Signature*: Verify the HTTP Message Signature using
the public key discovered via Signature-Agent, as specified in
[I-D.ietf-webbotauth-httpsig-protocol]. If signature
verification fails, the verifier MUST NOT trust the Signed-Agent-
Metadata header field.
3. *Parse and Scope*: Parse Signed-Agent-Metadata as an [RFC9651]
Dictionary. If parsing fails, ignore the header field.
Otherwise, extract the recognized string members (product,
project, session) and construct the Effective Identity tuple
scoped under the verified Signature-Agent.
4.3. Complete HTTP Request Example
The following example shows an HTTP GET request to www.shopping.com,
signed by Acme's agent platform (https://platform.acme.com) on behalf
of its Acme-Research product, including product, project, and session
in Signed-Agent-Metadata (lines folded for readability):
# NOTE: '\' line wrapping per RFC 8792
GET /catalog/anvils HTTP/1.1
Host: www.shopping.com
Signature-Agent: "https://platform.acme.com/.well-known/\
http-message-signatures-directory"
Signed-Agent-Metadata:
product="Acme-Research", project="prj_104", session="sess_3a2b1c"
Signature-Input:
sig1=("@authority" "signature-agent" "signed-agent-metadata");\
created=1772400000;expires=1772400300;\
keyid="TtgsnS5fiN3jhav0LuKROGskI1rrkxZmeKndLaD8_Fg";\
tag="web-bot-auth"
Signature:
sig1=:OwviNIOl6eMJ4Vn006OoVEvgwglY3A6FRfjQgXYKPqBK62/0l2q3bfYiEOf+\
wwcf3mM0UP7P99ebmYjb/xylCw==:
5. Verifier Considerations (Non-Normative)
This section describes how verifiers (including origin servers such
as shopping.com, content.org, and news.net, as well as WAFs, CDNs,
and bot management services) can use Signed-Agent-Metadata to manage
traffic policy and reputation.
5.1. Reputation Isolation and Fallback
Verifiers can maintain reputation and rate-limiting state at each
level of the Effective Identity tuple:
Vilgalys & Gonzalez Expires 6 May 2027 [Page 10]
Internet-Draft Signed-Agent-Metadata November 2026
* *Targeted Enforcement*: If a single session
(session="sess_3a2b1c") under project="prj_104" exhibits abusive
behavior on shopping.com (such as hoarding rocket-powered roller
skates or aggressive price scraping), the verifier can rate-limit,
challenge, or block that specific session. Other sessions under
prj_104 and other projects on platform.acme.com keep their normal
standing.
* *Hierarchical Rollup*: If a tenant rotates session identifiers
rapidly to evade per-session limits on content.org, the verifier
can aggregate anomaly signals at the parent project tier
(project="prj_104") and restrict the entire project without
penalizing the rest of platform.acme.com.
* *Graceful Fallback*: If a platform signs only product="Acme-Labs"
and project="prj_104", the verifier evaluates traffic at the
project tier. If a request has no signed Signed-Agent-Metadata
header, the verifier falls back to Tier 0 (evaluating all traffic
under the platform.acme.com Signature-Agent URI).
5.2. Abuse Reporting to Platform Operators
When a platform publishes contact endpoints in its Signature Agent
Card (contacts in [I-D.meunier-webbotauth-registry]), a verifier that
detects severe abuse can report the incident to the platform by
providing:
* The Signature-Agent URI and keyid
* The exact signed Signed-Agent-Metadata header value
* The target origin (@authority) and request timestamp (created)
Because the platform generated the pseudonymous project and session
identifiers (or derived session via HMAC with the target origin), the
platform can map the reported tuple back to the responsible internal
tenant account and take corrective action.
6. Security Considerations
6.1. Unsigned or Stripped Headers
An attacker or intermediary could inject a forged Signed-Agent-
Metadata header onto an unsigned request or append Signed-Agent-
Metadata to a request whose Signature-Input does not cover "signed-
agent-metadata". As required in Section 4.2, verifiers MUST ignore
Signed-Agent-Metadata unless "signed-agent-metadata" is included in
the verified Signature-Input component list.
Vilgalys & Gonzalez Expires 6 May 2027 [Page 11]
Internet-Draft Signed-Agent-Metadata November 2026
An intermediary could also strip Signed-Agent-Metadata only if
"signed-agent-metadata" was not included in Signature-Input. Once
"signed-agent-metadata" is listed in Signature-Input, removing or
modifying the header invalidates the HTTP Message Signature.
6.2. Cross-Tenant Identifier Spoofing
If a multi-tenant platform allows customer code to set raw Signed-
Agent-Metadata headers directly before the platform's signing proxy
signs the outbound request, a malicious customer could set product or
project values belonging to another customer. For example, a tenant
operating product="Acme-Crimes" could claim product="Acme-Research",
project="prj_104" on requests to news.net, either to inherit a
trusted customer's reputation or to send abusive traffic that
degrades a competitor's standing.
To protect its own tenants from cross-tenant spoofing, the signing
platform SHOULD overwrite, namespace, or validate Signed-Agent-
Metadata at its signing boundary using authenticated tenant metadata
(Section 3.4).
6.3. Sybil Attacks and Identifier Churn
A malicious tenant may attempt to reset a poor reputation by cycling
through newly created session or project identifiers on every
request. Verifiers SHOULD treat newly observed identifiers as having
neutral (unestablished) standing rather than high trust, and SHOULD
track the rate of new sub-identifiers created under each parent
project, product, or Signature-Agent. High sub-identifier churn
under a parent tier is itself a signal to apply policy at the parent
tier.
7. Privacy Considerations
7.1. Prohibition of Personally Identifiable Information
Signed-Agent-Metadata is transmitted in cleartext HTTP headers to
origin servers and intermediaries. Platforms MUST NOT place
personally identifiable information (PII)—such as email addresses,
legal names, usernames, phone numbers, IP addresses, or billing
account names—into project or session. All values for these fields
MUST be opaque tokens, UUIDs, or cryptographic hashes.
Vilgalys & Gonzalez Expires 6 May 2027 [Page 12]
Internet-Draft Signed-Agent-Metadata November 2026
7.2. Cross-Origin Correlation
As documented in the Privacy Considerations of
[I-D.ietf-webbotauth-httpsig-protocol], persistent identifiers in
signed HTTP requests allow visited origins to correlate client
activity across websites.
In Signed-Agent-Metadata, product and project identify commercial
software or tenant workspaces, whereas session represents an
individual task or browsing context. Scoping session identifiers to
the target origin (Section 3.4) prevents two collaborating origins
from linking a session's activity across sites, while still giving
each origin a stable handle for local rate limiting and abuse
defense.
8. IANA Considerations
8.1. HTTP Field Name Registration
IANA is requested to register the following entry in the "Hypertext
Transfer Protocol (HTTP) Field Name Registry" defined in [RFC9110]:
Field Name: Signed-Agent-Metadata
Status: provisional (or permanent if adopted on Standards Track)
Structured Type: Dictionary
Reference: This document (Section 3)
9. Open Questions for the Working Group
The authors welcome Working Group feedback on the following topics at
IETF 127:
1. *Header Field Naming and Future Metadata*: This draft proposes
Signed-Agent-Metadata (SAM) to indicate that the header field
must be covered by the request signature and can accommodate both
sub-identifiers (product, project, session) and future per-
request metadata (such as session start timestamps or account
tenure). Should the Working Group keep Signed-Agent-Metadata, or
prefer an alternative such as Agent-Metadata, Signature-Agent-
Metadata, Signature-Agent-IDs, Signature-Agent-Scope, or Agent-
Context?
2. *Intermediate Identifier Between project and session*: Is a
fourth identifier needed between project (the customer tenant or
workspace) and session (a single task run) to represent a
Vilgalys & Gonzalez Expires 6 May 2027 [Page 13]
Internet-Draft Signed-Agent-Metadata November 2026
specific deployed agent, sub-tenant, or credential without
introducing a human-level user identifier? If so, what term best
fits that tier (for example, resource, label, workload, or
parent)?
3. *Alignment with the Signature Agent Card Registry*:
[I-D.meunier-webbotauth-registry] establishes an IANA registry
for web_bot_auth metadata parameters. Should the Signed-Agent-
Metadata dictionary keys be registered in a sub-registry or
shared registry, and should a Signature Agent Card be able to
declare which Signed-Agent-Metadata keys the platform signs?
4. *Origin Scoping vs. Cross-Origin Security Providers*: Origin-
scoped identifiers protect cross-site privacy, whereas security
providers operating across multiple origins can reduce cold-start
challenges when a pseudonymous identifier is consistent across
protected origins. Should the specification define an explicit
parameter or convention indicating whether identifiers are
origin-scoped or platform-scoped?
10. References
10.1. Normative References
[I-D.ietf-webbotauth-httpsig-protocol]
Meunier, T. and S. Major, "HTTP Message Signatures for
automated traffic", Work in Progress, Internet-Draft,
draft-ietf-webbotauth-httpsig-protocol-01, 29 October
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
webbotauth-httpsig-protocol-01>.
[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>.
[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/info/rfc9110>.
[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/info/rfc9421>.
Vilgalys & Gonzalez Expires 6 May 2027 [Page 14]
Internet-Draft Signed-Agent-Metadata November 2026
[RFC9651] Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
<https://www.rfc-editor.org/info/rfc9651>.
10.2. Informative References
[I-D.meunier-webbotauth-registry]
Guerreiro, M., Kirazci, U., and T. Meunier, "Registry and
Signature Agent card for Web bot auth", Work in Progress,
Internet-Draft, draft-meunier-webbotauth-registry-04, 27
October 2026, <https://datatracker.ietf.org/doc/html/
draft-meunier-webbotauth-registry-04>.
[RFC9576] Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy
Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June
2024, <https://www.rfc-editor.org/info/rfc9576>.
Authors' Addresses
Rim Vilgalys
Google
Email: interweb@google.com
Pablo Gonzalez
Google
Email: pablogm@google.com
Vilgalys & Gonzalez Expires 6 May 2027 [Page 15]