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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . 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, . 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, . [RFC9576] Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June 2024, . Authors' Addresses Rim Vilgalys Google Email: interweb@google.com Pablo Gonzalez Google Email: pablogm@google.com Vilgalys & Gonzalez Expires 6 May 2027 [Page 15]