{
 "generated": "2026-09-07",
 "url": "https://agenticweb.wiki/news/",
 "items": [
  {
   "date": "2026-09-04",
   "title": "WebMCP published as a Draft Community Group Report",
   "url": "https://webmachinelearning.github.io/webmcp/",
   "summary": "The W3C Web Machine Learning Community Group published a 4 September 2026 draft of WebMCP, the browser API for pages to expose tools to agents.",
   "related": [
    "webmcp"
   ],
   "anchor": "2026-09-04-webmcp-published-as-a-draft-community-group-report",
   "related_articles": [
    {
     "acronym": "",
     "adoption": {
      "by": null,
      "level": "unmeasured",
      "probe_run": null
     },
     "aliases": [],
     "analog": "In-page JavaScript API (window.* APIs)",
     "collisions": [
      "Model Context Protocol (MCP)"
     ],
     "discovery": {
      "mechanism": "In-page JavaScript object (window.modelContext / the ModelContext tool map); a page registers tools imperatively (registerTool()) or declaratively via annotated HTML form elements",
      "path": "none — a client or agent must load the page itself to see whether it registers WebMCP tools; this is a stated limitation of the API (\"Clients and browsers must visit a site directly to know if it has callable tools\")"
     },
     "dispute": null,
     "evidence": [
      {
       "claim": "WebMCP API enables web applications to provide JavaScript-based tools to AI agents; published as a Draft Community Group Report by the W3C Web Machine Learning Community Group, dated 4 September 2026, explicitly not on the W3C Standards Track. Editors are from Microsoft and Google.",
       "date": "2026-09-04",
       "label": "VERIFIED",
       "url": "https://webmachinelearning.github.io/webmcp/"
      },
      {
       "claim": "Chrome runs a WebMCP origin trial starting Chrome 149, with a chrome://flags/#enable-webmcp-testing local-development flag; two APIs exist (imperative and declarative); published demos and a Model Context Tool Inspector Chrome extension exist. Last updated 2026-08-07.",
       "date": "2026-08-07",
       "label": "VERIFIED",
       "url": "https://developer.chrome.com/docs/ai/webmcp"
      }
     ],
     "form": "browser-api",
     "governance": "W3C Web Machine Learning Community Group; editors are Brandon Walderman (Microsoft), Khushal Sagar (Google), Dominic Farolino (Google)",
     "group": null,
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against webmachinelearning.github.io/webmcp (4 Sept 2026 draft) and developer.chrome.com/docs/ai/webmcp (updated 2026-08-07); Cloudflare BrowserRun claim dropped, unverified in this pass"
      }
     ],
     "id": "webmcp",
     "implementation": "developer-trial",
     "last_verified": "2026-09-06",
     "name": "WebMCP",
     "native_status": "Draft Community Group Report, dated 4 September 2026; explicitly \"not a W3C Standard nor on the W3C Standards Track\"",
     "origin": {
      "date": "2026",
      "org": "Google and Microsoft engineers, via the W3C Web Machine Learning Community Group"
     },
     "part_of": null,
     "parties": [
      "agent-site"
     ],
     "phase": "draft",
     "probe": {
      "method": "in-page script execution (not a network probe)",
      "on_absent": "window.modelContext is undefined, or getTools() returns an empty map: the page exposes no WebMCP tools (this cannot be checked without executing JavaScript in a real browser context — it is not curl-probable)",
      "parse": "presence of a non-empty tool map returned by getTools() (or the declarative equivalent synthesized from annotated form elements)",
      "path": "typeof window.modelContext !== 'undefined' && window.modelContext.getTools()"
     },
     "question": "What JavaScript tools can a web page register so an in-browser AI agent can call them directly instead of scraping the DOM?",
     "scope": "general",
     "spec_url": "https://webmachinelearning.github.io/webmcp/",
     "step": "act",
     "summary_md": "WebMCP is a proposed JavaScript API that lets a web page register \"tools\" — functions with natural-language descriptions and JSON Schema input definitions — that an AI agent (in-browser or otherwise) can call directly, instead of inferring intent by scraping the rendered DOM [1]. A page using WebMCP can be thought of as running an MCP server client-side: the tool concepts (name, description, input schema, annotations) deliberately mirror MCP's tool definition so that the same mental model and, in principle, the same downstream tooling apply on both sides of the fetch boundary [1].\n\nIt solves the reliability gap in DOM-scraping-based browser agents: rather than an agent guessing which button does \"checkout\" from visual and structural cues, the site declares the tool's purpose explicitly, with a JSON Schema for inputs, reducing hallucination and misclicks [2]. It supports two authoring styles: an imperative JavaScript API (registerTool()) and a declarative API that annotates standard HTML form elements.\n\nWebMCP does not solve discovery at scale: a client or crawler cannot learn whether a given origin exposes WebMCP tools without loading the page and executing its JavaScript — the Chrome team's own documentation lists \"tool discoverability\" as a stated limitation, alongside unsuitability for headless/automated scenarios (it is designed for a human-in-the-loop local browser session) and added engineering overhead for complex interfaces [2]. It also does not standardize server-side or non-browser agent tool-calling; that is MCP's job.\n\nAs of this verification (September 2026), WebMCP is a W3C Community Group Draft Report — not a W3C Standard and not on the Standards Track — dated 4 September 2026, edited by engineers from Microsoft and Google [1]. Chrome is running a public origin trial from Chrome 149 (Intent to Experiment filed with blink-dev), with a local-development flag (chrome://flags/#enable-webmcp-testing) and a Chrome Web Store \"Model Context Tool Inspector\" extension for manually exercising tools; documentation was last updated 2026-08-07 [2]. The seed record's premise that Cloudflare's BrowserRun product had confirmed WebMCP support (per a 2026-08-06 Cloudflare blog post) could not be verified in this pass — that specific page was not fetched, so this claim is dropped rather than carried forward unsourced; it should be checked directly in a future pass. What remains open: whether any browser besides Chrome will implement WebMCP, and whether the spec advances beyond Community Group status toward a W3C Working Group.",
     "track": "w3c",
     "version": {
      "date": "2026-09-04",
      "label": "Draft Community Group Report, 4 September 2026"
     }
    }
   ],
   "cat": "act"
  },
  {
   "date": "2026-09-01",
   "title": "IETF webbotauth working group adopts the HTTP signature draft",
   "url": "https://datatracker.ietf.org/doc/draft-ietf-webbotauth-httpsig-protocol/",
   "summary": "draft-ietf-webbotauth-httpsig-protocol-00 replaced the individual Web Bot Auth draft as a working-group document.",
   "related": [
    "webbotauth",
    "http-message-signatures"
   ],
   "anchor": "2026-09-01-ietf-webbotauth-working-group-adopts-the-http-signature-draf",
   "related_articles": [
    {
     "acronym": "WebBotAuth",
     "adoption": {
      "by": "Cloudflare (edge verification, verified-bots program) and independent client/server implementations listed in the draft's own appendix",
      "level": "observed",
      "probe_run": null
     },
     "aliases": [
      "Web Bot Auth",
      "HTTP Message Signatures for automated traffic"
     ],
     "analog": "Signed User-Agent / client authentication",
     "collisions": [],
     "discovery": {
      "mechanism": "Signature-Agent HTTP header points to a key directory; the directory is fetched from a fixed well-known path",
      "path": "/.well-known/http-message-signatures-directory"
     },
     "dispute": null,
     "evidence": [
      {
       "claim": "The protocol defines the Signature-Agent header (profiling RFC 9421's Signature-Input/Signature fields) for in-band key discovery, and a well-known URI serving a JWKS-based key directory. The draft's own appendix lists independent public client implementations (Chrome MV3 and Cloudflare Workers/Rust libraries by Cloudflare, a Puppeteer example, a Guzzle/PHP middleware, Python scripts) and server implementations (Cloudflare Workers, a Caddy plugin, an Apache module).",
       "date": "2026-06-26",
       "label": "VERIFIED",
       "url": "https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-protocol-00"
      },
      {
       "claim": "As of 2026-09-01 the document was adopted by the IETF webbotauth Working Group as draft-ietf-webbotauth-httpsig-protocol-00, superseding the individual submission",
       "date": "2026-09-01",
       "label": "VERIFIED",
       "url": "https://datatracker.ietf.org/doc/draft-ietf-webbotauth-httpsig-protocol/"
      },
      {
       "claim": "Cloudflare verifies Web Bot Auth signatures at the edge as part of its Verified Bots program, requiring the key directory at /.well-known/http-message-signatures-directory and specific Signature-Input parameters (tag=web-bot-auth, keyid, created, expires)",
       "date": "2026-07-01",
       "label": "VERIFIED",
       "url": "https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/"
      }
     ],
     "form": "http-header",
     "governance": "IETF webbotauth Working Group (chartered; document adopted as a WG item 2026-09-01)",
     "group": "Web Bot Auth family",
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against draft-meunier-webbotauth-httpsig-protocol-00, its WG-adopted successor draft-ietf-webbotauth-httpsig-protocol-00 (2026-09-01), and Cloudflare's Web Bot Auth integration docs"
      }
     ],
     "id": "webbotauth",
     "implementation": "multi-implementation",
     "last_verified": "2026-09-06",
     "name": "Web Bot Auth HTTP Message Signatures",
     "native_status": "Active Internet-Draft, WG Document, Intended Status: Informational",
     "origin": {
      "date": "2025-04",
      "org": "Thibault Meunier (Cloudflare), Sandor Major (Google)"
     },
     "part_of": null,
     "parties": [
      "agent-site"
     ],
     "phase": "working-group",
     "probe": {
      "method": "GET",
      "on_absent": "No published key directory; the origin cannot verify Web Bot Auth signatures from this Signature-Agent identity",
      "parse": "200 response with Content-Type: application/http-message-signatures-directory+json and a JWKS body ({\"keys\":[...]}), itself signed with a Signature/Signature-Input pair tagged http-message-signatures-directory",
      "path": "https://{origin}/.well-known/http-message-signatures-directory"
     },
     "question": "Which automated client made this HTTP request, and can the origin verify it cryptographically?",
     "scope": "general",
     "spec_url": "https://datatracker.ietf.org/doc/draft-ietf-webbotauth-httpsig-protocol/",
     "step": "identify",
     "summary_md": "Web Bot Auth is an IETF specification that lets an automated HTTP client (a crawler, agent, or bot) cryptographically sign its outbound requests using RFC 9421 HTTP Message Signatures, so the receiving server can verify the client's identity and intent without relying on spoofable signals like the User-Agent string or source IP [1]. A client sends a Signature-Agent header naming where its public keys can be found; the origin resolves that to a JSON Web Key Set served at a fixed well-known path and verifies the request's Signature/Signature-Input fields against it [1].\n\nIt solves bot/agent attribution at the transport layer: an origin can distinguish a signed, identity-bearing automated client from unsigned traffic, and can grant differentiated treatment (rate limits, access, billing) based on a verified identity rather than heuristics [1][3]. It does not define what a client is *authorized* to do once verified (that is left to the origin's own policy), does not cover payment, and does not itself specify how a verifier should be told which identities to trust — that is the job of the companion Signature Agent Card / registry draft.\n\nCurrent state: originally an individual submission (draft-meunier-webbotauth-httpsig-protocol, first published 2025-04, reaching -00 of the current \"httpsig-protocol\" naming on 2026-06-26). On 2026-09-01 it was formally adopted as a document of the newly chartered IETF **webbotauth** Working Group, republished as draft-ietf-webbotauth-httpsig-protocol-00 [2]. Intended status is Informational, not yet a Working Group last call or RFC.\n\nWho implements it: Cloudflare verifies Web Bot Auth signatures at the edge for its Verified Bots program and publishes an integration guide with the exact required headers and the /.well-known/http-message-signatures-directory path [3]. The draft's own appendix lists further independent implementations: a Chrome MV3 extension and Rust/TypeScript libraries from Cloudflare, a Puppeteer-based client example, a PHP Guzzle middleware, Python scripts, and server-side modules for Caddy and Apache [1]. Cloudflare previously reported signing bots from OpenAI as an early adopter (2025-05-15, per the prior seed research; not independently re-verified in this pass).\n\nDisputed or unknown: the spec's naming and draft numbering have churned repeatedly (it replaces draft-meunier-web-bot-auth-architecture and draft-meunier-webbotauth-httpsig-directory), which makes citing a stable version number difficult; always resolve to the datatracker's \"current\" redirect rather than a pinned draft-NN URL. Adoption beyond Cloudflare's own edge and the listed open-source projects has not been independently counted.",
     "track": "ietf",
     "version": {
      "date": "2026-09-01",
      "label": "draft-ietf-webbotauth-httpsig-protocol-00, adopted by the webbotauth WG, last updated 2026-09-01 (supersedes the individual draft-meunier-webbotauth-httpsig-protocol-00 of 2026-06-26)"
     }
    },
    {
     "acronym": "",
     "adoption": {
      "by": "Multiple libraries and at least one profile in production use (Web Bot Auth / Cloudflare); RFC 9421 is a general-purpose base standard, not agent-specific",
      "level": "observed",
      "probe_run": null
     },
     "aliases": [],
     "analog": "JWS for HTTP components",
     "collisions": [],
     "discovery": {
      "mechanism": "Signature and Signature-Input HTTP fields carried directly on the message; no fixed discovery path of its own",
      "path": "none"
     },
     "dispute": null,
     "evidence": [
      {
       "claim": "RFC 9421 is a Proposed Standard published by the IETF (2024) defining a mechanism for creating, encoding and verifying signatures over HTTP message components, including a means to request that a signature be applied to a subsequent message",
       "date": "2024-02",
       "label": "VERIFIED",
       "url": "https://www.rfc-editor.org/info/rfc9421"
      },
      {
       "claim": "Web Bot Auth's protocol draft explicitly builds its Agent/Origin signature exchange on top of RFC 9421's Signature and Signature-Input fields, adding the Signature-Agent field as an RFC 9421 signature component",
       "date": "2026-06-26",
       "label": "VERIFIED",
       "url": "https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-protocol-00"
      }
     ],
     "form": "http-header",
     "governance": "IETF",
     "group": "Web Bot Auth family",
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against RFC 9421 primary source and confirmed as the base standard profiled by Web Bot Auth"
      }
     ],
     "id": "http-message-signatures",
     "implementation": "multi-implementation",
     "last_verified": "2026-09-06",
     "name": "HTTP Message Signatures",
     "native_status": "Proposed Standard",
     "origin": {
      "date": "2024-02",
      "org": "A. Backman, J. Richer, M. Sporny (IETF httpbis Working Group)"
     },
     "part_of": null,
     "parties": [
      "agent-site"
     ],
     "phase": "stable",
     "probe": {
      "method": "GET",
      "on_absent": "The message carries no RFC 9421 signature; any profile built on it (e.g. Web Bot Auth) cannot be verified",
      "parse": "Presence of Signature and Signature-Input HTTP fields (or their Content-Digest/Signature-related trailers) conforming to RFC 9421's structured-field syntax",
      "path": "n/a — inspect response/request headers on any HTTP exchange"
     },
     "question": "How can HTTP messages carry end-to-end component integrity and proof of possession, independent of transport-layer security?",
     "scope": "general",
     "spec_url": "https://www.rfc-editor.org/info/rfc9421",
     "step": "identify",
     "summary_md": "RFC 9421 (HTTP Message Signatures) is a general-purpose IETF Proposed Standard, not specific to agents. It defines how to create, encode and verify digital signatures or message authentication codes over selected components of an HTTP message (headers, derived components like @authority or @method, and optionally the body), so that a signature survives intermediaries that might otherwise alter or drop parts of the message [1]. It also defines how to request that a future message in an ongoing exchange be signed [1].\n\nIt solves message-level integrity and proof-of-possession for HTTP independent of transport security (TLS terminates at intermediaries; RFC 9421 signatures do not) [1]. It does not define identity discovery, key distribution, or any notion of \"bot\" or \"agent\" — those are added by profiles built on top of it. In this map, it is the base standard that Web Bot Auth (see the `webbotauth` record) profiles: Web Bot Auth adds the Signature-Agent header as a signed component and defines a specific key-discovery mechanism (a well-known JWKS directory), while RFC 9421 itself stays agnostic to what a signature proves or where keys come from [2].\n\nCurrent state: published as a Proposed Standard in February 2024 and stable since; it is not itself under active revision as far as this check found.\n\nWho implements it: general HTTP signing libraries exist across languages (this check did not re-survey the full ecosystem); its most visible agent-relevant use is as the substrate for Web Bot Auth, which Cloudflare verifies at the edge [2].\n\nDisputed or unknown: none specific to the base standard found in this pass. Because RFC 9421 is general and widely referenced, this record exists mainly to anchor the agent-specific profiles (Web Bot Auth, and potentially others) that depend on it; it should not be read as agent-specific adoption evidence on its own.",
     "track": "ietf",
     "version": {
      "date": "2024-02",
      "label": "RFC 9421, February 2024, Proposed Standard"
     }
    }
   ],
   "cat": "identify"
  },
  {
   "date": "2026-08-26",
   "title": "Agentic Resource Discovery v0.91 published",
   "url": "https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md",
   "summary": "The ARD specification reached v0.91, with the manifest served at /.well-known/ard.json.",
   "related": [
    "ard"
   ],
   "anchor": "2026-08-26-agentic-resource-discovery-v0-91-published",
   "related_articles": [
    {
     "acronym": "ARD",
     "adoption": {
      "by": "agenticresources.dev own probe, 2026-09-04",
      "level": "observed",
      "probe_run": {
       "origins_probed": 50,
       "origins_found": 6,
       "last": "2026-09-04"
      }
     },
     "aliases": [
      "AI Catalog",
      "ai-catalog.json (predecessor path)"
     ],
     "analog": "sitemap plus a search engine index",
     "collisions": [
      "ARDP (Agent Registration and Discovery Protocol, unrelated IETF draft)",
      "AIR (the urn:air: identifier namespace this spec defines is sometimes referred to standalone)"
     ],
     "discovery": {
      "mechanism": "well-known manifest, robots.txt Agentmap directive, HTML <link rel=\"ard\">, DNS SVCB, in-page JSON-LD",
      "path": "/.well-known/ard.json"
     },
     "dispute": {
      "claims": [
       "v0.91 text: /.well-known/ard.json is canonical; /.well-known/ai-catalog.json is an optional predecessor",
       "2026-09-04 probe: 100% of observed manifests are still at ai-catalog.json; only 19% also serve ard.json",
       "Identifier form is urn:air:<publisher>:<namespace>:<agent-name>, not urn:ard as some earlier notes assumed"
      ],
      "summary": "The path this specification calls canonical has changed between revisions and prior internal notes got this backwards: v0.91 (26 Aug 2026) makes /.well-known/ard.json canonical and demotes /.well-known/ai-catalog.json to an optional, non-required-to-consult predecessor path. Our own probe (2026-09-04, prior to this verification) found the entire observed deployment base still on the old ai-catalog.json path, with only 6 of 31 also serving the new path -- so real-world adoption lags the spec text by at least one full path rename. Adoption level is left as \"observed\" rather than \"measured\" here because no probe-run artifact exists inside this repository (data/) to cite by filename; the probe that produced the 31/50 figure lives in the sibling agenticresources.dev project."
     },
     "evidence": [
      {
       "claim": "ARD v0.91 (26 Aug 2026), authored by Google/Microsoft/Hugging Face individuals, defines the ARD entry as a JSON-LD node and moves the canonical manifest path to /.well-known/ard.json, explicitly naming /.well-known/ai-catalog.json as the deprecated predecessor path that consumers MAY but need not consult.",
       "date": "2026-08-26",
       "label": "VERIFIED",
       "url": "https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md"
      },
      {
       "claim": "Google announced the Agentic Resource Discovery Specification and directed publishers to a well-known catalog mechanism.",
       "date": "2026-06-17",
       "label": "REPORTED",
       "url": "https://developers.googleblog.com/en/announcing-the-agentic-resource-discovery-specification/"
      },
      {
       "claim": "AGNTCY's Agent Directory Service (ADS) implements AI Catalog interoperability, serving /.well-known/ai-catalog.json and exporting records to a2a/mcp/oasf formats -- one real implementation of the ARD manifest side.",
       "date": "2026-07-06",
       "label": "VERIFIED",
       "url": "https://datatracker.ietf.org/doc/html/draft-mp-agntcy-ads-02"
      },
      {
       "claim": "A probe of 50 domains run by this site's publisher (agenticresources) on 2026-09-04 found 31 serving a manifest, all 31 on the predecessor ai-catalog.json path, and only 6 of those also on the new ard.json path -- i.e. the ecosystem has not yet moved to the canonical path this v0.91 revision defines.",
       "date": "2026-09-04",
       "label": "REPORTED",
       "url": "https://agenticresources.dev/"
      }
     ],
     "form": "well-known-file",
     "governance": "Authored by individuals at Google, Microsoft and Hugging Face (Junjie Bu, R.V. Guha, Shaun Smith); published as an open GitHub project (ards-project/ard-spec) with no formal standards body yet; contributions acknowledged from AWS, Cisco, Databricks, GitHub, GoDaddy, Nvidia, Salesforce and Snowflake",
     "group": null,
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against ARD v0.91 spec text (raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md); corrected canonical path from ai-catalog.json to ard.json; folded ai-catalog-well-known-file into this record"
      }
     ],
     "id": "ard",
     "implementation": "shipping",
     "last_verified": "2026-09-06",
     "name": "Agentic Resource Discovery",
     "native_status": "Proposal",
     "origin": {
      "date": "2026-06-17",
      "org": "Google, Microsoft, Hugging Face"
     },
     "part_of": null,
     "parties": [
      "agent-site",
      "agent-registry"
     ],
     "phase": "draft",
     "probe": {
      "method": "GET",
      "on_absent": "Domain publishes no ARD manifest at the current canonical path; it may still publish at the deprecated predecessor path /.well-known/ai-catalog.json, which conformant consumers are not required to consult",
      "parse": "200 response is JSON with a top-level \"entries\" array of ARD entries (each with identifier/displayName/type/url-or-data); a consumer MAY also check the predecessor /.well-known/ai-catalog.json and an HTML <link rel=\"ard\"> tag",
      "path": "https://{origin}/.well-known/ard.json"
     },
     "question": "Where are an organization's discoverable agentic resources (MCP servers, A2A agents, skills, registries), and how can they be found by search rather than pre-installed one at a time?",
     "scope": "general",
     "spec_url": "https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md",
     "step": "discover",
     "summary_md": "Agentic Resource Discovery (ARD) is a specification for how agentic resources -- MCP servers, A2A agents, skills, and other callable services -- are described, discovered, and searched across a federated network of registries [1]. It is authored by individuals at Google, Microsoft and Hugging Face and published as an open GitHub project (ards-project/ard-spec) rather than through a formal standards body; the current text is version v0.91, dated 26 August 2026, and is explicitly labelled a \"Proposal\" [1].\n\nARD solves the problem of scaling tool selection beyond an LLM's context window: instead of injecting every possible tool description into a prompt, a client searches a registry's index using natural language plus structured filters, and the registry returns ranked entries [1]. Each entry is a JSON-LD node with a small set of required terms (identifier, displayName, type, and either url or data), and publishers can extend it with arbitrary namespaced terms without waiting for a spec revision [1]. Entries are advertised through a well-known manifest, robots.txt Agentmap directives, an HTML `<link rel=\"ard\">` tag, DNS SVCB records, or in-page markup; the manifest path is `/.well-known/ard.json` [1].\n\nA significant correction to earlier internal notes: the v0.91 text makes `/.well-known/ard.json` the canonical path and explicitly demotes the older `/.well-known/ai-catalog.json` path (and the `ai-catalog` link relation) to an optional predecessor that a conformant consumer is not required to consult [1]. Prior assumptions that ai-catalog.json was still canonical as of this version are wrong as of the text fetched 2026-09-06.\n\nARD does not define a signing or authentication scheme of its own (it defers to whatever trust framework a publisher's `trustManifest` declares), does not constrain artifact-specific schemas (MCP, A2A, etc. remain external), and does not define a normative way to fetch a full entry by identifier from a search result [1].\n\nImplementation exists: AGNTCY's Agent Directory Service explicitly serves `/.well-known/ai-catalog.json` and can export records into a2a, mcp, oasf and agent-skill formats, functioning as one real ARD-manifest-compatible implementation [3]. Beyond that, adoption is thin and lagging the spec's own migration: a probe of 50 domains run by this site's publisher (agenticresources) on 2026-09-04 found 31 serving some manifest, all 31 still on the deprecated ai-catalog.json path, and only 6 of those also serving the new ard.json path [4] -- meaning the observed deployment base predates this very revision's path rename. Because that probe artifact is not present in this repository, adoption here is recorded as \"observed\" rather than \"measured\".\n\nWhat is disputed or unknown: whether the ecosystem migrates to ard.json before a competing discovery mechanism (DNS-AID, AID, ADP) becomes the practical default; whether any registry beyond ADS has implemented the POST /search and POST /explore REST surface this spec mandates; and how the optional `trustManifest` verification step will be operationalized across publishers who have never coordinated on a trust framework.\n\nThe record `ai-catalog-well-known-file`, which previously modelled the manifest file as a separate entity, has been folded into this record: it described the same well-known artifact that this specification now supersedes with `ard.json`, and keeping it separate obscured that the two are one lineage, not two competing formats.",
     "track": "vendor-consortium",
     "version": {
      "date": "2026-08-26",
      "label": "v0.91"
     }
    }
   ],
   "cat": "discover"
  },
  {
   "date": "2026-08-25",
   "title": "Universal Commerce Protocol documentation released",
   "url": "https://ucp.dev/documentation/core-concepts/",
   "summary": "The UCP site published its core-concepts documentation, dated 25 August 2026, with Shopping, Lodging and Food tracks.",
   "related": [
    "ucp"
   ],
   "anchor": "2026-08-25-universal-commerce-protocol-documentation-released",
   "related_articles": [
    {
     "acronym": "UCP",
     "adoption": {
      "by": "UCP project (ucp.dev launch-partner list)",
      "level": "claimed",
      "probe_run": null
     },
     "aliases": [
      "UCP"
     ],
     "analog": "Commerce API plus a machine-readable merchant capability document",
     "collisions": [],
     "discovery": {
      "mechanism": "well-known capability/profile document",
      "path": "/.well-known/ucp"
     },
     "dispute": null,
     "evidence": [
      {
       "claim": "UCP's own site lists co-development partners across Shopping (Google, Shopify, Etsy, Wayfair, Target, Walmart, Amazon, Microsoft, Meta, Salesforce, Stripe), Lodging (Amadeus, Booking.com, Expedia Group, Google, Hilton, Marriott, Trip.com), and Food (DoorDash, Google, Square, Toast, Uber Eats).",
       "date": null,
       "label": "VERIFIED",
       "url": "https://ucp.dev"
      },
      {
       "claim": "The GitHub org's central MAINTAINERS.md names a Shopping Tech Council (Google, Shopify, Etsy, Meta, Amazon, Microsoft, Target, Stripe, Salesforce) and a Food Tech Council (Google, Square, Toast, DoorDash, Uber Eats), governed per GOVERNANCE.md's Domain Tech Council / Governing Council model.",
       "date": null,
       "label": "VERIFIED",
       "url": "https://raw.githubusercontent.com/Universal-Commerce-Protocol/.github/main/MAINTAINERS.md"
      },
      {
       "claim": "UCP core concepts documentation defines discovery via a well-known capability document at /.well-known/ucp (also referencing /.well-known/oauth-authorization-server for identity linking), and states UCP is built on REST and JSON-RPC transports with AP2, A2A, and MCP support built in.",
       "date": null,
       "label": "VERIFIED",
       "url": "https://ucp.dev/documentation/core-concepts/"
      },
      {
       "claim": "The UCP GitHub repository describes UCP as an open standard for interoperability between commerce entities (platforms, businesses, PSPs, Credential Providers), with Capabilities such as Checkout, Identity Linking, Order, and Payment Token Exchange.",
       "date": null,
       "label": "VERIFIED",
       "url": "https://raw.githubusercontent.com/Universal-Commerce-Protocol/ucp/main/README.md"
      }
     ],
     "form": "well-known-file",
     "governance": "Domain Tech Councils (DTC) per vertical — Shopping Tech Council and Food Tech Council seated — under an overall Governing Council (GC); DTC seats held by Google, Shopify, Etsy, Meta, Amazon, Microsoft, Target, Stripe, Salesforce, Wayfair, Square, Toast, DoorDash, Uber Eats",
     "group": null,
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against ucp.dev (home, core-concepts), Universal-Commerce-Protocol/ucp README, and Universal-Commerce-Protocol/.github MAINTAINERS.md / GOVERNANCE.md"
      }
     ],
     "id": "ucp",
     "implementation": "multi-implementation",
     "last_verified": "2026-09-06",
     "name": "Universal Commerce Protocol",
     "native_status": "Open standard; specification expanding beyond Shopping into Lodging and Food",
     "origin": {
      "date": "2026-01",
      "org": "Google"
     },
     "part_of": null,
     "parties": [
      "agent-site"
     ],
     "phase": "living",
     "probe": {
      "method": "GET",
      "on_absent": "A missing or non-JSON response at /.well-known/ucp means the origin does not (yet) declare UCP capabilities; UCP also supports MCP/A2A transports, so a 404 on the well-known path does not rule out a business exposing UCP only via those channels.",
      "parse": "200 response with a UCP profile JSON document declaring supported Capabilities (e.g. Checkout, Identity Linking, Order) and Extensions",
      "path": "{origin}/.well-known/ucp"
     },
     "question": "Can an agent discover a business's commerce capabilities, build a cart, and check out interoperably across shopping, lodging, and food ordering?",
     "scope": "commerce",
     "spec_url": "https://ucp.dev/documentation/core-concepts/",
     "step": "pay",
     "summary_md": "The Universal Commerce Protocol (UCP) is an open standard, initiated by Google, that gives platforms (AI agents, apps, procurement systems) and businesses a common language and set of REST/JSON-RPC \"Capabilities\" — Checkout, Identity Linking, Order, Payment Token Exchange — so agentic commerce can work without bespoke, one-off integrations per merchant [3][4]. Businesses declare what they support in a machine-readable profile discoverable at a well-known path (`/.well-known/ucp`), and platforms use that to autonomously configure themselves for a given origin [3].\n\nUCP solves cross-vertical interoperability for agentic shopping, lodging, and food ordering by defining Capabilities and optional Extensions on top of transport-agnostic REST, MCP, or A2A bindings, and it explicitly builds on the Agent Payments Protocol (AP2) for payment authorization and OAuth 2.0 for identity linking rather than reinventing either [3][4]. It does not itself move money or replace a merchant's payment processor — the merchant remains \"Merchant of Record\" — and its Lodging and Food verticals are still described by the project as pending detailed specifications as of the current documentation snapshot [1].\n\nGovernance runs through per-vertical Domain Tech Councils (DTC) — a seated Shopping Tech Council and Food Tech Council as of this verification — operating under an overall Governing Council, with seats and maintainer nomination rights tied to actual contribution rather than fixed vendor slots [2]. Seated companies span Google, Shopify, Etsy, Meta, Amazon, Microsoft, Target, Stripe, and Salesforce (Shopping) and Google, Square, Toast, DoorDash, and Uber Eats (Food) [2]. UCP's own launch materials additionally name Walmart, Amadeus, Booking.com, Expedia Group, Hilton, Marriott, and Trip.com as co-development partners across Shopping and Lodging verticals, though Lodging has no seated council yet in the maintainers file [1][2].\n\nBecause every adoption figure available — the partner list, the council rosters — comes from UCP's own site and repository, adoption here is recorded as claimed by the UCP project rather than independently measured; nobody outside the project has published a count of live UCP-conformant merchant endpoints. What is unresolved: how many of the named partners have a working `/.well-known/ucp` profile live today versus having only committed to the initiative, and how UCP's scope divides from AP2 in practice given the two are designed to interlock.",
     "track": "vendor-consortium",
     "version": {
      "date": "2026-08-25",
      "label": "documentation site dated 2026-08-25; active/expanding specification (Lodging and Food detailed specs pending)"
     }
    }
   ],
   "cat": "pay"
  },
  {
   "date": "2026-08-12",
   "title": "IAB Tech Lab publishes ARTF v1.0",
   "url": "https://iabtechlab.com/standards/artf/",
   "summary": "The Agentic RTB Framework reached v1.0 and IAB Tech Lab reported production use by unnamed companies.",
   "related": [
    "artf"
   ],
   "anchor": "2026-08-12-iab-tech-lab-publishes-artf-v1-0",
   "related_articles": [
    {
     "acronym": "ARTF",
     "adoption": {
      "by": "IAB Tech Lab",
      "level": "claimed",
      "probe_run": null
     },
     "aliases": [
      "agentic-rtb-framework"
     ],
     "analog": "a plugin/sidecar execution framework for real-time bidding -- closer to a serverless function contract than a classic-web analog",
     "collisions": [],
     "discovery": {
      "mechanism": "endpoint",
      "path": "http://{host}:{health-port}/health/ready"
     },
     "dispute": null,
     "evidence": [
      {
       "claim": "IAB Tech Lab announced ARTF v1.0 for public comment on 2025-11-13, open until 2026-01-15, describing a containerized architecture aiming to cut bid request/response time up to 80%; quotes from Index Exchange, Chalice and The Trade Desk describe early implementation work.",
       "date": "2025-11-13",
       "label": "VERIFIED",
       "url": "https://iabtechlab.com/press-releases/iab-tech-lab-announces-agentic-rtb-framework-artf-v1-0-for-public-comment/"
      },
      {
       "claim": "The standards page (last modified 2026-08-12) says public comment ran until 2026-01-15 and links to the finalized v1.0 specification and sample code repositories.",
       "date": "2026-08-12",
       "label": "VERIFIED",
       "url": "https://iabtechlab.com/standards/artf/"
      },
      {
       "claim": "IAB Tech Lab's 2026-08-12 milestone post says v1.0 'is now being used in production by various companies, including several of the organizations that helped design it,' adds a Rust reference implementation and an orchestration layer for chaining ARTF nodes, and states that v2.0 work has already begun -- without naming which companies are in production.",
       "date": "2026-08-12",
       "label": "VERIFIED",
       "url": "https://iabtechlab.com/a-milestone-for-the-agentic-advertising-ecosystem/"
      },
      {
       "claim": "The GitHub repository's v1.0 tag/release was published 2026-07-20; the Go reference implementation exposes gRPC (port 50051), an MCP server (port 50052, or /mcp on the web-UI port), a web UI (8081) and Kubernetes health endpoints at /health/live and /health/ready (port 8080, default).",
       "date": "2026-07-20",
       "label": "VERIFIED",
       "url": "https://github.com/IABTechLab/agentic-real-time-framework"
      }
     ],
     "form": "endpoint",
     "governance": "IAB Tech Lab (non-profit standards consortium); Agentic Task Force working group",
     "group": null,
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against iabtechlab.com/standards/artf/, the 2025-11-13 launch press release, the 2026-08-12 milestone post, and github.com/IABTechLab/agentic-real-time-framework (README, internal/health, cmd/agent/main.go); moved step from 'account' to 'act'; filled probe, discovery, adoption=claimed"
      }
     ],
     "id": "artf",
     "implementation": "multi-implementation",
     "last_verified": "2026-09-06",
     "name": "Agentic Real Time Framework",
     "native_status": "Final v1.0 specification, published after public comment; v2.0 development already underway",
     "origin": {
      "date": "2025-11-13",
      "org": "IAB Tech Lab, Agentic Task Force"
     },
     "part_of": null,
     "parties": [
      "agent-site"
     ],
     "phase": "stable",
     "probe": {
      "method": "GET",
      "on_absent": "Connection refused or non-200 means no ARTF container is deployed at that host/port -- expected for the overwhelming majority of ad-tech origins, since ARTF nodes run inside a host platform's private infrastructure rather than being publicly addressable.",
      "parse": "HTTP 200 with the readiness handler's OK body indicates a running ARTF node (per internal/health in the Go reference implementation); a companion MCP tool 'extend_rtb' is exposed at {host}:8081/mcp and a gRPC RTBExtensionPoint.GetMutations service at port 50051.",
      "path": "http://{host}:8080/health/ready"
     },
     "question": "How does a host advertising platform invoke a third party's agent service, deployed as a container inside its own infrastructure, to mutate a bid request in real time?",
     "scope": "advertising",
     "spec_url": "https://github.com/IABTechLab/agentic-real-time-framework",
     "step": "act",
     "summary_md": "ARTF defines how a host advertising platform (an SSP or DSP) can let a third party's agent service run inside the host's own infrastructure -- packaged as a container -- and be called directly to mutate an OpenRTB bid request in real time: fraud detection, bid shading, audience augmentation, viewability scoring and similar tasks [1][2]. It is the execution/runtime layer of IAB Tech Lab's broader AAMP advertising-agent program (see the separate AAMP record), specifically the piece that answers \"how does an agent invoke a capability inside someone else's system\" -- which is why this record has been moved from the site's original 'account' placement to 'act.' The framework standardizes container runtime behavior, a gRPC RTBExtensionPoint.GetMutations service, an MCP tool (extend_rtb) as an alternative interface for AI agents, and Kubernetes-style health endpoints, all built on existing infrastructure primitives (Kubernetes, Docker, Protobuf, gRPC) rather than inventing new transport [3][4].\n\n**What it does not do.** ARTF does not define agent identity or authentication (containers run inside the host's own trusted network, with no external network access by default), does not standardize commercial terms or negotiation (that is AAMP's Agentic Direct/Deals-API layer), and does not itself provide an audit trail beyond whatever the host platform's own logging does.\n\n**Current state.** IAB Tech Lab opened public comment on ARTF v1.0 on 2025-11-13, closing 2026-01-15 [1]. The finalized v1.0 specification and a Git tag were published 2026-07-20, with an accompanying Go reference implementation, and the project's own August 2026 recap describes v1.0 as already in production use by unnamed companies, several of whom helped design it, while adding a Rust reference implementation and cross-node orchestration; work on v2.0 was already underway at that point [2][3][4].\n\n**Who implements it.** IAB Tech Lab publishes an open-source Go reference server (gRPC + MCP + web UI + health checks) and, per the August 2026 post, a Rust reference implementation; the November 2025 launch quoted named ad-tech companies (Index Exchange, Chalice, The Trade Desk) describing implementation work, though none of those sources names a company as live in production as of the v1.0 release.\n\n**Disputed / unknown.** No independent, named list of production deployments exists in public sources; \"used in production by a number of companies\" is IAB Tech Lab's own claim, not something this site has measured. Because ARTF nodes are deployed inside a host's private infrastructure by design, there is no public origin to probe for adoption counting -- the probe above will almost always come back absent from the outside, which is expected behavior, not evidence of non-adoption.",
     "track": "industry-body",
     "version": {
      "date": "2026-07-20",
      "label": "v1.0"
     }
    }
   ],
   "cat": "act"
  },
  {
   "date": "2026-08-07",
   "title": "Chrome documents a WebMCP origin trial",
   "url": "https://developer.chrome.com/docs/ai/webmcp",
   "summary": "Chrome's developer documentation described a WebMCP origin trial running from Chrome 149.",
   "related": [
    "webmcp"
   ],
   "anchor": "2026-08-07-chrome-documents-a-webmcp-origin-trial",
   "related_articles": [
    {
     "acronym": "",
     "adoption": {
      "by": null,
      "level": "unmeasured",
      "probe_run": null
     },
     "aliases": [],
     "analog": "In-page JavaScript API (window.* APIs)",
     "collisions": [
      "Model Context Protocol (MCP)"
     ],
     "discovery": {
      "mechanism": "In-page JavaScript object (window.modelContext / the ModelContext tool map); a page registers tools imperatively (registerTool()) or declaratively via annotated HTML form elements",
      "path": "none — a client or agent must load the page itself to see whether it registers WebMCP tools; this is a stated limitation of the API (\"Clients and browsers must visit a site directly to know if it has callable tools\")"
     },
     "dispute": null,
     "evidence": [
      {
       "claim": "WebMCP API enables web applications to provide JavaScript-based tools to AI agents; published as a Draft Community Group Report by the W3C Web Machine Learning Community Group, dated 4 September 2026, explicitly not on the W3C Standards Track. Editors are from Microsoft and Google.",
       "date": "2026-09-04",
       "label": "VERIFIED",
       "url": "https://webmachinelearning.github.io/webmcp/"
      },
      {
       "claim": "Chrome runs a WebMCP origin trial starting Chrome 149, with a chrome://flags/#enable-webmcp-testing local-development flag; two APIs exist (imperative and declarative); published demos and a Model Context Tool Inspector Chrome extension exist. Last updated 2026-08-07.",
       "date": "2026-08-07",
       "label": "VERIFIED",
       "url": "https://developer.chrome.com/docs/ai/webmcp"
      }
     ],
     "form": "browser-api",
     "governance": "W3C Web Machine Learning Community Group; editors are Brandon Walderman (Microsoft), Khushal Sagar (Google), Dominic Farolino (Google)",
     "group": null,
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against webmachinelearning.github.io/webmcp (4 Sept 2026 draft) and developer.chrome.com/docs/ai/webmcp (updated 2026-08-07); Cloudflare BrowserRun claim dropped, unverified in this pass"
      }
     ],
     "id": "webmcp",
     "implementation": "developer-trial",
     "last_verified": "2026-09-06",
     "name": "WebMCP",
     "native_status": "Draft Community Group Report, dated 4 September 2026; explicitly \"not a W3C Standard nor on the W3C Standards Track\"",
     "origin": {
      "date": "2026",
      "org": "Google and Microsoft engineers, via the W3C Web Machine Learning Community Group"
     },
     "part_of": null,
     "parties": [
      "agent-site"
     ],
     "phase": "draft",
     "probe": {
      "method": "in-page script execution (not a network probe)",
      "on_absent": "window.modelContext is undefined, or getTools() returns an empty map: the page exposes no WebMCP tools (this cannot be checked without executing JavaScript in a real browser context — it is not curl-probable)",
      "parse": "presence of a non-empty tool map returned by getTools() (or the declarative equivalent synthesized from annotated form elements)",
      "path": "typeof window.modelContext !== 'undefined' && window.modelContext.getTools()"
     },
     "question": "What JavaScript tools can a web page register so an in-browser AI agent can call them directly instead of scraping the DOM?",
     "scope": "general",
     "spec_url": "https://webmachinelearning.github.io/webmcp/",
     "step": "act",
     "summary_md": "WebMCP is a proposed JavaScript API that lets a web page register \"tools\" — functions with natural-language descriptions and JSON Schema input definitions — that an AI agent (in-browser or otherwise) can call directly, instead of inferring intent by scraping the rendered DOM [1]. A page using WebMCP can be thought of as running an MCP server client-side: the tool concepts (name, description, input schema, annotations) deliberately mirror MCP's tool definition so that the same mental model and, in principle, the same downstream tooling apply on both sides of the fetch boundary [1].\n\nIt solves the reliability gap in DOM-scraping-based browser agents: rather than an agent guessing which button does \"checkout\" from visual and structural cues, the site declares the tool's purpose explicitly, with a JSON Schema for inputs, reducing hallucination and misclicks [2]. It supports two authoring styles: an imperative JavaScript API (registerTool()) and a declarative API that annotates standard HTML form elements.\n\nWebMCP does not solve discovery at scale: a client or crawler cannot learn whether a given origin exposes WebMCP tools without loading the page and executing its JavaScript — the Chrome team's own documentation lists \"tool discoverability\" as a stated limitation, alongside unsuitability for headless/automated scenarios (it is designed for a human-in-the-loop local browser session) and added engineering overhead for complex interfaces [2]. It also does not standardize server-side or non-browser agent tool-calling; that is MCP's job.\n\nAs of this verification (September 2026), WebMCP is a W3C Community Group Draft Report — not a W3C Standard and not on the Standards Track — dated 4 September 2026, edited by engineers from Microsoft and Google [1]. Chrome is running a public origin trial from Chrome 149 (Intent to Experiment filed with blink-dev), with a local-development flag (chrome://flags/#enable-webmcp-testing) and a Chrome Web Store \"Model Context Tool Inspector\" extension for manually exercising tools; documentation was last updated 2026-08-07 [2]. The seed record's premise that Cloudflare's BrowserRun product had confirmed WebMCP support (per a 2026-08-06 Cloudflare blog post) could not be verified in this pass — that specific page was not fetched, so this claim is dropped rather than carried forward unsourced; it should be checked directly in a future pass. What remains open: whether any browser besides Chrome will implement WebMCP, and whether the spec advances beyond Community Group status toward a W3C Working Group.",
     "track": "w3c",
     "version": {
      "date": "2026-09-04",
      "label": "Draft Community Group Report, 4 September 2026"
     }
    }
   ],
   "cat": "act"
  },
  {
   "date": "2026-07-30",
   "title": "IAB Tech Lab releases AAMP 2.3",
   "url": "https://iabtechlab.com/press-releases/iab-tech-lab-releases-aamp-2-3-bringing-enterprise-grade-infrastructure-and-privacy-diligence-to-agentic-advertising/",
   "summary": "AAMP 2.3 added infrastructure and privacy-diligence components contributed by AWS, HyperMindZ, Mixpeek, SafeGuard Privacy and Adform.",
   "related": [
    "aamp"
   ],
   "anchor": "2026-07-30-iab-tech-lab-releases-aamp-2-3",
   "related_articles": [
    {
     "acronym": "AAMP",
     "adoption": {
      "by": "IAB Tech Lab and named partners (AWS, HyperMindZ, Mixpeek, SafeGuard Privacy, Adform)",
      "level": "claimed",
      "probe_run": null
     },
     "aliases": [],
     "analog": "no single classic-web analog; closest is an umbrella of OpenRTB/OpenDirect-style transaction protocols reworked for agent-to-agent negotiation",
     "collisions": [
      "Agent Authorization Profile (also abbreviated AAP, IETF OAuth draft, unrelated)"
     ],
     "discovery": {
      "mechanism": "endpoint",
      "path": "https://registry.iabtechlab.ai/"
     },
     "dispute": {
      "claims": [
       "'AAMP 2.3' names a coordinated release of several independently-versioned repos, not a version of one document.",
       "Its Trust and Transparency pillar (Agent Registry) functions like an identity/disclosure directory, which arguably also belongs partly under this site's 'identify' step."
      ],
      "summary": "AAMP is not one protocol: it is a named umbrella for at least five separately-versioned repositories and three conceptually distinct pillars (execution via ARTF, which this site tracks as its own record under 'act'; negotiation/transaction via Agentic Direct and Agentic Audiences; and identity/disclosure via the Agent Registry, which overlaps with this site's 'identify' step). 'AAMP 2.3' is a marketing-level release label for the coalition's roadmap, not a single spec version that a probe can confirm end-to-end. This record is kept (per instructions, not withdrawn) but should be read as a program name whose most testable component (ARTF) already has its own row; readers wanting a single executable spec should look at ARTF, Agentic Direct or the Agent Registry individually."
     },
     "evidence": [
      {
       "claim": "IAB Tech Lab's AAMP standards page (last updated 2026-08-12) describes AAMP as an umbrella of three pillars -- Agent Foundations (ARTF), Agentic Protocols (Agentic Direct, Buyer/Seller Agent SDKs, Agentic Audiences fka UCP), and Trust and Transparency (the Agent Registry) -- and links five open-source GitHub repos plus the registry.",
       "date": "2026-08-12",
       "label": "VERIFIED",
       "url": "https://iabtechlab.com/standards/aamp-agentic-advertising-management-protocols/"
      },
      {
       "claim": "IAB Tech Lab's 2026-07-30 press release announces AAMP 2.3, adding Amazon Bedrock AgentCore deployment, Meta buying, Google Ad Manager reporting, an IAB Diligence Platform/SafeGuard Privacy integration, and open-source contributions (Deals Sync MCP Server from HyperMindZ, Content Taxonomy Parser from Mixpeek); quotes named executives from AWS, SafeGuard Privacy, HyperMindZ, Mixpeek and Adform describing integration work.",
       "date": "2026-07-30",
       "label": "VERIFIED",
       "url": "https://iabtechlab.com/press-releases/iab-tech-lab-releases-aamp-2-3-bringing-enterprise-grade-infrastructure-and-privacy-diligence-to-agentic-advertising/"
      },
      {
       "claim": "The AAMP GitHub hub repository lists five constituent repositories with independent semantic versioning per repo (Agentic Direct, Buyer Agent, Seller Agent, Registry Agent example, and ARTF), coordinated only via 'governance coordination' rather than a single version number.",
       "date": "2026-09-05",
       "label": "VERIFIED",
       "url": "https://github.com/IABTechLab/AAMP"
      }
     ],
     "form": "endpoint",
     "governance": "IAB Tech Lab (non-profit standards consortium); Agentic Task Force working group",
     "group": null,
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against iabtechlab.com/standards/aamp-agentic-advertising-management-protocols/, the 2026-07-30 AAMP 2.3 press release, and github.com/IABTechLab/AAMP; moved step from 'account' to 'coordinate'; flagged umbrella-program dispute and acronym collision with IETF AAP (Agent Authorization Profile)"
      }
     ],
     "id": "aamp",
     "implementation": "multi-implementation",
     "last_verified": "2026-09-06",
     "name": "Agentic Advertising Management Protocols",
     "native_status": "Active umbrella initiative, current release AAMP 2.3, described by its own authors as 'far more than a single framework'",
     "origin": {
      "date": "2025-10",
      "org": "IAB Tech Lab, Agentic Task Force"
     },
     "part_of": null,
     "parties": [
      "agent-agent"
     ],
     "phase": "living",
     "probe": {
      "method": "GET",
      "on_absent": "No registry entry for a company does not mean no AAMP deployment -- only that it has not self-registered.",
      "parse": "A response listing registered agents (buyer/seller/registry agents) indicates the IAB Tech Lab Agent Registry, AAMP's 'Trust and Transparency' pillar, is live; absence of a listing for a given company is not proof they lack an AAMP integration, since registration is voluntary.",
      "path": "https://registry.iabtechlab.ai/"
     },
     "question": "How do a buyer's agent and a seller's agent discover each other's inventory, negotiate terms and hand off a transaction inside the existing ad-tech stack?",
     "scope": "advertising",
     "spec_url": "https://github.com/IABTechLab/AAMP",
     "step": "coordinate",
     "summary_md": "AAMP is IAB Tech Lab's umbrella name for its agentic-advertising program: how a buyer's agent and a seller's agent (and the platforms behind them) discover inventory, negotiate, and execute an advertising transaction using agent-to-agent workflows layered on existing ad-tech standards (OpenRTB, OpenDirect, AdCOM, the Deals API) [1]. This record has been moved from the site's original 'account' placement to 'coordinate' because its core, distinguishing content -- beyond ARTF, which already has its own record under 'act' -- is agent-to-agent negotiation and deal-making (Agentic Direct, Agentic Audiences, buyer/seller agent SDKs), not post-hoc recording or judgment of what happened.\n\n**What it is.** Three pillars: Agent Foundations (high-performance execution -- this is ARTF), Agentic Protocols (schemas and reference SDKs for buyer/seller agent discovery, negotiation and transacting), and Trust and Transparency (the free, IAB-run Agent Registry for agent identity and disclosure) [1]. AAMP 2.3, released 2026-07-30, added enterprise deployment paths (Amazon Bedrock AgentCore, Databricks), Meta buying support, Google Ad Manager reporting integration, embedded privacy diligence (IAB Diligence Platform, SafeGuard Privacy) inside the reference Buyer Agent, and open-source contributions from named partners HyperMindZ (a Deals Sync MCP Server) and Mixpeek (a Content Taxonomy Parser) [2].\n\n**What it does not do.** AAMP is not itself a single wire protocol: it has no one spec document or version number that a probe can confirm end-to-end. Its GitHub hub instead points to five separately-versioned repositories -- Agentic Direct, Buyer Agent, Seller Agent, a Registry Agent example, and ARTF -- aligned only through 'governance coordination,' not a shared release [3]. It does not define payment settlement (that sits with card-network specs like Verifiable Intent) and does not provide an independent audit-trail format of its own.\n\n**Current state.** Governed by IAB Tech Lab's Agentic Task Force, an open working group any member or non-member can join; AAMP 2.3 (2026-07-30) is the current named release, with named-executive quotes from AWS, SafeGuard Privacy, HyperMindZ, Mixpeek and Adform describing production integration work, though none of the fetched sources gives an independently countable adoption figure [1][2].\n\n**Who implements it.** IAB Tech Lab publishes open-source reference implementations for each pillar (Agentic Direct, Buyer Agent, Seller Agent SDKs; ARTF's Go and Rust servers); AWS supports AAMP on Bedrock AgentCore; HyperMindZ and Mixpeek have contributed named components.\n\n**Disputed / unknown.** Because AAMP names a coordinated program rather than one spec, 'AAMP 2.3 adoption' is not a single measurable quantity; adoption claims here are attributed to IAB Tech Lab and the named partner quotes, not independently verified counts. Readers evaluating whether a given ad-tech company 'supports AAMP' should ask which constituent repo/version they mean.",
     "track": "industry-body",
     "version": {
      "date": "2026-07-30",
      "label": "AAMP 2.3"
     }
    }
   ],
   "cat": "coordinate"
  },
  {
   "date": "2026-07-28",
   "title": "Model Context Protocol 2026-07-28 specification revision",
   "url": "https://modelcontextprotocol.io/specification/2026-07-28/index",
   "summary": "MCP published a new dated specification revision, the current version of the protocol.",
   "related": [
    "mcp"
   ],
   "anchor": "2026-07-28-model-context-protocol-2026-07-28-specification-revision",
   "related_articles": [
    {
     "acronym": "MCP",
     "adoption": {
      "by": "Wikipedia (OpenAI, Google DeepMind adopted MCP by March 2025) and WorkOS ('adopted by OpenAI, Google DeepMind, Microsoft, and thousands of development teams')",
      "level": "claimed",
      "probe_run": null
     },
     "aliases": [],
     "analog": "Language Server Protocol",
     "collisions": [
      "Microsoft Cloud Partner",
      "Master Control Program"
     ],
     "discovery": {
      "mechanism": "Capability negotiation during the JSON-RPC initialize handshake over a streamable-HTTP or stdio transport; optional static Server Card for pre-connection discovery",
      "path": "GET {endpoint}/server-card (SEP-2127, experimental, not yet part of the accepted core spec)"
     },
     "dispute": null,
     "evidence": [
      {
       "claim": "Canonical dated specification is 2026-07-28; MCP is a JSON-RPC 2.0 protocol standardizing how hosts, clients, and servers share resources, prompts, and tools, with optional extensions (Tasks, Skills over MCP, MCP Apps).",
       "date": "2026-07-28",
       "label": "VERIFIED",
       "url": "https://modelcontextprotocol.io/specification/2026-07-28/index"
      },
      {
       "claim": "OpenAI officially adopted MCP in March 2025 (ChatGPT desktop app integration) and added MCP support to ChatGPT apps in September 2025; MCP integrates with Microsoft Semantic Kernel and Azure OpenAI.",
       "date": "2026",
       "label": "VERIFIED",
       "url": "https://en.wikipedia.org/wiki/Model_Context_Protocol"
      },
      {
       "claim": "MCP has become the de facto protocol for connecting AI to external tools and data, adopted by OpenAI, Google DeepMind, Microsoft, and thousands of development teams as of 2026.",
       "date": "2026",
       "label": "REPORTED",
       "url": "https://workos.com/blog/everything-your-team-needs-to-know-about-mcp-in-2026"
      },
      {
       "claim": "The MCP Server Card is defined by SEP-2127, tracked as an experimental extension (modelcontextprotocol/ext-server-card), reserving GET <streamable-http-url>/server-card as the recommended discovery location; it is explicitly NOT an accepted or official MCP extension as of this check, and discovery is intended to route through AI Catalog entries rather than a fixed /.well-known/ path.",
       "date": "2026-08-12",
       "label": "VERIFIED",
       "url": "https://github.com/modelcontextprotocol/experimental-ext-server-card"
      },
      {
       "claim": "The MCP GitHub org publishes ten official/community SDKs tiered 1-3 (TypeScript, Python, C#, Go, Rust = Tier 1; Java, Ruby = Tier 2; Swift, PHP, Kotlin = Tier 3); the Python SDK has 24.2k GitHub stars and the TypeScript SDK 13.3k, both far larger than any competing protocol's SDK repos checked in this pass.",
       "date": "2026",
       "label": "VERIFIED",
       "url": "https://modelcontextprotocol.io/docs/2026-07-28/sdk"
      },
      {
       "claim": "The MCP Registry (modelcontextprotocol/registry) is the official server registry, with 7.2k GitHub stars and 979 forks as of this check.",
       "date": "2026-09",
       "label": "VERIFIED",
       "url": "https://github.com/modelcontextprotocol/registry"
      },
      {
       "claim": "MCP Apps is an accepted extension (distinct from the experimental Server Card) letting servers return sandboxed-iframe interactive UI; it is supported by Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam, and Archestra.AI, and is also the standard OpenAI's ChatGPT plugin UI builds on.",
       "date": "2026",
       "label": "VERIFIED",
       "url": "https://modelcontextprotocol.io/docs/extensions/apps"
      }
     ],
     "form": "endpoint",
     "governance": "Agentic AI Foundation (Linux Foundation umbrella); day-to-day spec work in the modelcontextprotocol GitHub org via public SEPs (Specification Enhancement Proposals) and working groups",
     "group": null,
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against modelcontextprotocol.io/specification/2026-07-28, github.com/modelcontextprotocol/experimental-ext-server-card, github.com/modelcontextprotocol/registry, modelcontextprotocol.io/docs/2026-07-28/sdk, modelcontextprotocol.io/docs/extensions/apps, en.wikipedia.org/wiki/Model_Context_Protocol, workos.com MCP-2026 blog"
      }
     ],
     "id": "mcp",
     "implementation": "multi-implementation",
     "last_verified": "2026-09-06",
     "name": "Model Context Protocol",
     "native_status": "Active open specification, current dated release 2026-07-28",
     "origin": {
      "date": "2024-11",
      "org": "Anthropic"
     },
     "part_of": null,
     "parties": [
      "agent-site"
     ],
     "phase": "living",
     "probe": {
      "method": "POST",
      "on_absent": "connection refused, 404, or a non-JSON-RPC response means no MCP server is exposed at that endpoint; a Server Card GET at {endpoint}/server-card returning JSON is a weaker, static signal since Server Cards are still experimental (SEP-2127)",
      "parse": "JSON-RPC 2.0 request {\"method\":\"initialize\",...}; on success, response.result.protocolVersion (e.g. \"2026-07-28\") and response.result.serverInfo.name prove an MCP server is present",
      "path": "{endpoint}/mcp"
     },
     "question": "How does an AI application call tools and pull structured context, prompts, and data from an external server?",
     "scope": "general",
     "spec_url": "https://modelcontextprotocol.io/specification/2026-07-28/index",
     "step": "act",
     "summary_md": "The Model Context Protocol (MCP) is a JSON-RPC 2.0 based protocol that lets an AI \"host\" application (an IDE, a chat client) connect, through a \"client\" it embeds, to one or more \"servers\" that expose tools (functions the model can call), resources (data or content), and prompts (reusable templates) [1]. It also defines client-side elicitation (a server asking the user a question) and utilities for progress, cancellation, and structured errors. Anthropic published the first version in November 2024; the current dated release is 2026-07-28 [1].\n\nMCP solves the M×N integration problem: rather than every AI application writing bespoke connectors to every tool and data source, both sides implement one protocol once, similarly to how the Language Server Protocol standardized editor-to-language-server integration [1]. It is transport-agnostic (stdio for local processes, streamable HTTP for remote servers) and stateless per request, with capabilities negotiated during an `initialize` handshake.\n\nMCP does not itself define a stable, machine-readable way to discover a server before connecting to it, nor does it define an interactive-UI format — those live in separate, still-maturing extensions. The \"MCP Server Card\", meant to let a client learn a server's identity and remote endpoints via a well-known static document, is defined only by SEP-2127, tracked in an explicitly experimental repository (`modelcontextprotocol/ext-server-card`) that states plainly it is \"not an accepted or official MCP extension\" [4]. Its reserved discovery location is `GET <streamable-http-url>/server-card`, not `/.well-known/mcp` or `/.well-known/mcp.json` as some third-party guides describe for an earlier, now-superseded proposal (SEP-1649) — this row's probe uses the JSON-RPC `initialize` call instead, since that is the only mechanism guaranteed by the accepted spec. By contrast, MCP Apps — a separate extension for sandboxed-iframe interactive UI returned by tools — has graduated to accepted-extension status and has multi-vendor host support (Claude, VS Code Copilot, Microsoft 365 Copilot, Goose, Postman, and others) [7].\n\nAs of September 2026, MCP is implemented by ten official SDKs spanning three support tiers, with the Python SDK alone carrying 24,200+ GitHub stars, and by an official cross-language server registry (7,200+ stars) [5][6]. Adoption is broad but the strongest public claims are secondary, not counted: Wikipedia states OpenAI adopted MCP in ChatGPT's desktop app in March 2025 and extended support to ChatGPT apps in September 2025, and that Microsoft integrates it with Semantic Kernel and Azure OpenAI [2]; WorkOS separately describes MCP as adopted by \"OpenAI, Google DeepMind, Microsoft, and thousands of development teams\" [3]. No systematic, third-party-run census of live MCP servers was located in this pass, so adoption here is recorded as `claimed` (by those two secondary sources) rather than `measured`.\n\nGovernance sits with the Agentic AI Foundation under the Linux Foundation, with day-to-day specification work happening in public via SEPs (Specification Enhancement Proposals) and topic-specific working groups (e.g. the Server Card working group) in the `modelcontextprotocol` GitHub org — this is a materially more open, standards-body-adjacent process than the seed record's placeholder \"Agentic AI Foundation / Linux Foundation\" implied but did not source. What remains genuinely unsettled: whether Server Cards graduate from experimental status, and whether any independent org will publish a measured adoption count rather than vendor and press claims.",
     "track": "linux-foundation",
     "version": {
      "date": "2026-07-28",
      "label": "2026-07-28"
     }
    }
   ],
   "cat": "act"
  },
  {
   "date": "2026-07-14",
   "title": "x402 Foundation becomes operational under the Linux Foundation",
   "url": "https://x402.org/announcement",
   "summary": "The Linux Foundation announced the operational launch of the x402 Foundation to standardise internet-native payments for agents.",
   "related": [
    "x402"
   ],
   "anchor": "2026-07-14-x402-foundation-becomes-operational-under-the-linux-foundati",
   "related_articles": [
    {
     "acronym": "",
     "adoption": {
      "by": "x402 Foundation (x402.org live dashboard)",
      "level": "claimed",
      "probe_run": null
     },
     "aliases": [],
     "analog": "HTTP 402 Payment Required, finally implemented",
     "collisions": [],
     "discovery": {
      "mechanism": "HTTP 402 response carrying payment requirements in a header",
      "path": "none — signalled per-request via the 402 status code, not a fixed well-known path"
     },
     "dispute": null,
     "evidence": [
      {
       "claim": "x402's HTTP transport spec defines the 402 challenge as HTTP 402 status with a PAYMENT-REQUIRED header carrying a base64-encoded PaymentRequired object, and the client retry as a PAYMENT-SIGNATURE header carrying a base64-encoded PaymentPayload.",
       "date": null,
       "label": "VERIFIED",
       "url": "https://raw.githubusercontent.com/x402-foundation/x402/main/specs/transports-v2/http.md"
      },
      {
       "claim": "x402.org's footer identifies the project as 'x402 a Series of LF Projects, LLC', confirming Linux Foundation stewardship, and its Announcements page states the Linux Foundation announced the operational launch of the x402 Foundation on July 14, 2026.",
       "date": "2026-07-14",
       "label": "VERIFIED",
       "url": "https://x402.org/announcement"
      },
      {
       "claim": "x402.org's homepage displays a live self-reported dashboard: 75.41M transactions and $24.24M volume in the last 30 days, 94.06K buyers and 22K sellers, at time of check.",
       "date": "2026-09-06",
       "label": "VERIFIED",
       "url": "https://x402.org"
      }
     ],
     "form": "http-header",
     "governance": "x402 Foundation, a Series of LF Projects, LLC (Linux Foundation); operational launch announced 2026-07-14",
     "group": "HTTP 402 family",
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against x402.org (homepage, /announcement), x402-foundation/x402 specs/transports-v2/http.md"
      }
     ],
     "id": "x402",
     "implementation": "multi-implementation",
     "last_verified": "2026-09-06",
     "name": "x402",
     "native_status": "Open, neutral standard for internet-native payments",
     "origin": {
      "date": null,
      "org": "Coinbase"
     },
     "part_of": null,
     "parties": [
      "agent-site",
      "agent-payment"
     ],
     "phase": "living",
     "probe": {
      "method": "GET",
      "on_absent": "A 200 or a 402 without a PAYMENT-REQUIRED header means this specific path is not (or no longer) gated by x402 v2 over HTTP; the same origin could still use x402 over the MCP or other transports, or the legacy v1 header shape, so the probe only rules out v2/HTTP on the probed path.",
      "parse": "HTTP 402 status with a base64-encoded PaymentRequired object in the PAYMENT-REQUIRED response header (x402 v2 HTTP transport)",
      "path": "{origin}/{paid-path}"
     },
     "question": "How can an HTTP client pay per-request or per-resource, in stablecoins, without accounts, API keys, or signup?",
     "scope": "payments",
     "spec_url": "https://github.com/x402-foundation/x402/blob/main/specs/transports-v2/http.md",
     "step": "pay",
     "summary_md": "x402 is an open, HTTP-native payment protocol that activates the long-reserved (since 1999) HTTP 402 \"Payment Required\" status code: a server responds 402 with machine-readable payment requirements, the client pays (in practice, stablecoins over an EVM-compatible network) and retries the request with proof of payment attached [1]. It solves instant, account-free, per-request monetization for APIs and agentic consumers — no signup, no KYC, no stored API keys, no prepaid credit balance — collapsing what the project calls a five-step \"old way\" of API onboarding into three HTTP round trips [own site, x402.org homepage].\n\nIt does not itself define a payment network; it is a wire-format and challenge/response convention that networks and asset issuers plug into via a `scheme` and `network` field (the reference implementation targets EVM chains and USDC, per the transport spec's example payload) [1]. Version 2 of the specification moved the payment-required and payment-signature payloads into dedicated `PAYMENT-REQUIRED` and `PAYMENT-SIGNATURE` HTTP headers rather than embedding them in earlier v1 conventions, and the specification separately defines non-HTTP transports (the repository lists transports-v1 and transports-v2 directories) [1].\n\nAs of this verification, x402 is governed by the x402 Foundation, described in its own site footer as \"a Series of LF Projects, LLC\" — i.e., a Linux Foundation-hosted project — with an operational launch announced by the Linux Foundation on 2026-07-14 [2]. Coinbase originated the protocol; the Foundation now governs it independently of any single company, per the project's own framing [x402.org homepage]. The site's homepage displays a real-time usage dashboard claiming 75.41M transactions and $24.24M in volume over the trailing 30 days, with 94.06K buyers and 22K sellers, current as of this check [3] — but this figure is self-reported by the Foundation running the protocol, not measured by an independent index, so it is recorded here as claimed rather than observed or measured. What remains open: no independently operated adoption index (e.g. a third-party \"402 index\") was located and fetched during this verification to cross-check the Foundation's own dashboard number.",
     "track": "linux-foundation",
     "version": {
      "date": null,
      "label": "x402 protocol specification v2, transports-v2/http.md"
     }
    }
   ],
   "cat": "pay"
  },
  {
   "date": "2026-06-26",
   "title": "First Web Bot Auth HTTP signature draft published at the IETF",
   "url": "https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-protocol-00",
   "summary": "draft-meunier-webbotauth-httpsig-protocol-00 set out how a bot signs requests with RFC 9421 HTTP message signatures.",
   "related": [
    "webbotauth",
    "http-message-signatures"
   ],
   "anchor": "2026-06-26-first-web-bot-auth-http-signature-draft-published-at-the-iet",
   "related_articles": [
    {
     "acronym": "WebBotAuth",
     "adoption": {
      "by": "Cloudflare (edge verification, verified-bots program) and independent client/server implementations listed in the draft's own appendix",
      "level": "observed",
      "probe_run": null
     },
     "aliases": [
      "Web Bot Auth",
      "HTTP Message Signatures for automated traffic"
     ],
     "analog": "Signed User-Agent / client authentication",
     "collisions": [],
     "discovery": {
      "mechanism": "Signature-Agent HTTP header points to a key directory; the directory is fetched from a fixed well-known path",
      "path": "/.well-known/http-message-signatures-directory"
     },
     "dispute": null,
     "evidence": [
      {
       "claim": "The protocol defines the Signature-Agent header (profiling RFC 9421's Signature-Input/Signature fields) for in-band key discovery, and a well-known URI serving a JWKS-based key directory. The draft's own appendix lists independent public client implementations (Chrome MV3 and Cloudflare Workers/Rust libraries by Cloudflare, a Puppeteer example, a Guzzle/PHP middleware, Python scripts) and server implementations (Cloudflare Workers, a Caddy plugin, an Apache module).",
       "date": "2026-06-26",
       "label": "VERIFIED",
       "url": "https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-protocol-00"
      },
      {
       "claim": "As of 2026-09-01 the document was adopted by the IETF webbotauth Working Group as draft-ietf-webbotauth-httpsig-protocol-00, superseding the individual submission",
       "date": "2026-09-01",
       "label": "VERIFIED",
       "url": "https://datatracker.ietf.org/doc/draft-ietf-webbotauth-httpsig-protocol/"
      },
      {
       "claim": "Cloudflare verifies Web Bot Auth signatures at the edge as part of its Verified Bots program, requiring the key directory at /.well-known/http-message-signatures-directory and specific Signature-Input parameters (tag=web-bot-auth, keyid, created, expires)",
       "date": "2026-07-01",
       "label": "VERIFIED",
       "url": "https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/"
      }
     ],
     "form": "http-header",
     "governance": "IETF webbotauth Working Group (chartered; document adopted as a WG item 2026-09-01)",
     "group": "Web Bot Auth family",
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against draft-meunier-webbotauth-httpsig-protocol-00, its WG-adopted successor draft-ietf-webbotauth-httpsig-protocol-00 (2026-09-01), and Cloudflare's Web Bot Auth integration docs"
      }
     ],
     "id": "webbotauth",
     "implementation": "multi-implementation",
     "last_verified": "2026-09-06",
     "name": "Web Bot Auth HTTP Message Signatures",
     "native_status": "Active Internet-Draft, WG Document, Intended Status: Informational",
     "origin": {
      "date": "2025-04",
      "org": "Thibault Meunier (Cloudflare), Sandor Major (Google)"
     },
     "part_of": null,
     "parties": [
      "agent-site"
     ],
     "phase": "working-group",
     "probe": {
      "method": "GET",
      "on_absent": "No published key directory; the origin cannot verify Web Bot Auth signatures from this Signature-Agent identity",
      "parse": "200 response with Content-Type: application/http-message-signatures-directory+json and a JWKS body ({\"keys\":[...]}), itself signed with a Signature/Signature-Input pair tagged http-message-signatures-directory",
      "path": "https://{origin}/.well-known/http-message-signatures-directory"
     },
     "question": "Which automated client made this HTTP request, and can the origin verify it cryptographically?",
     "scope": "general",
     "spec_url": "https://datatracker.ietf.org/doc/draft-ietf-webbotauth-httpsig-protocol/",
     "step": "identify",
     "summary_md": "Web Bot Auth is an IETF specification that lets an automated HTTP client (a crawler, agent, or bot) cryptographically sign its outbound requests using RFC 9421 HTTP Message Signatures, so the receiving server can verify the client's identity and intent without relying on spoofable signals like the User-Agent string or source IP [1]. A client sends a Signature-Agent header naming where its public keys can be found; the origin resolves that to a JSON Web Key Set served at a fixed well-known path and verifies the request's Signature/Signature-Input fields against it [1].\n\nIt solves bot/agent attribution at the transport layer: an origin can distinguish a signed, identity-bearing automated client from unsigned traffic, and can grant differentiated treatment (rate limits, access, billing) based on a verified identity rather than heuristics [1][3]. It does not define what a client is *authorized* to do once verified (that is left to the origin's own policy), does not cover payment, and does not itself specify how a verifier should be told which identities to trust — that is the job of the companion Signature Agent Card / registry draft.\n\nCurrent state: originally an individual submission (draft-meunier-webbotauth-httpsig-protocol, first published 2025-04, reaching -00 of the current \"httpsig-protocol\" naming on 2026-06-26). On 2026-09-01 it was formally adopted as a document of the newly chartered IETF **webbotauth** Working Group, republished as draft-ietf-webbotauth-httpsig-protocol-00 [2]. Intended status is Informational, not yet a Working Group last call or RFC.\n\nWho implements it: Cloudflare verifies Web Bot Auth signatures at the edge for its Verified Bots program and publishes an integration guide with the exact required headers and the /.well-known/http-message-signatures-directory path [3]. The draft's own appendix lists further independent implementations: a Chrome MV3 extension and Rust/TypeScript libraries from Cloudflare, a Puppeteer-based client example, a PHP Guzzle middleware, Python scripts, and server-side modules for Caddy and Apache [1]. Cloudflare previously reported signing bots from OpenAI as an early adopter (2025-05-15, per the prior seed research; not independently re-verified in this pass).\n\nDisputed or unknown: the spec's naming and draft numbering have churned repeatedly (it replaces draft-meunier-web-bot-auth-architecture and draft-meunier-webbotauth-httpsig-directory), which makes citing a stable version number difficult; always resolve to the datatracker's \"current\" redirect rather than a pinned draft-NN URL. Adoption beyond Cloudflare's own edge and the listed open-source projects has not been independently counted.",
     "track": "ietf",
     "version": {
      "date": "2026-09-01",
      "label": "draft-ietf-webbotauth-httpsig-protocol-00, adopted by the webbotauth WG, last updated 2026-09-01 (supersedes the individual draft-meunier-webbotauth-httpsig-protocol-00 of 2026-06-26)"
     }
    },
    {
     "acronym": "",
     "adoption": {
      "by": "Multiple libraries and at least one profile in production use (Web Bot Auth / Cloudflare); RFC 9421 is a general-purpose base standard, not agent-specific",
      "level": "observed",
      "probe_run": null
     },
     "aliases": [],
     "analog": "JWS for HTTP components",
     "collisions": [],
     "discovery": {
      "mechanism": "Signature and Signature-Input HTTP fields carried directly on the message; no fixed discovery path of its own",
      "path": "none"
     },
     "dispute": null,
     "evidence": [
      {
       "claim": "RFC 9421 is a Proposed Standard published by the IETF (2024) defining a mechanism for creating, encoding and verifying signatures over HTTP message components, including a means to request that a signature be applied to a subsequent message",
       "date": "2024-02",
       "label": "VERIFIED",
       "url": "https://www.rfc-editor.org/info/rfc9421"
      },
      {
       "claim": "Web Bot Auth's protocol draft explicitly builds its Agent/Origin signature exchange on top of RFC 9421's Signature and Signature-Input fields, adding the Signature-Agent field as an RFC 9421 signature component",
       "date": "2026-06-26",
       "label": "VERIFIED",
       "url": "https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-protocol-00"
      }
     ],
     "form": "http-header",
     "governance": "IETF",
     "group": "Web Bot Auth family",
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against RFC 9421 primary source and confirmed as the base standard profiled by Web Bot Auth"
      }
     ],
     "id": "http-message-signatures",
     "implementation": "multi-implementation",
     "last_verified": "2026-09-06",
     "name": "HTTP Message Signatures",
     "native_status": "Proposed Standard",
     "origin": {
      "date": "2024-02",
      "org": "A. Backman, J. Richer, M. Sporny (IETF httpbis Working Group)"
     },
     "part_of": null,
     "parties": [
      "agent-site"
     ],
     "phase": "stable",
     "probe": {
      "method": "GET",
      "on_absent": "The message carries no RFC 9421 signature; any profile built on it (e.g. Web Bot Auth) cannot be verified",
      "parse": "Presence of Signature and Signature-Input HTTP fields (or their Content-Digest/Signature-related trailers) conforming to RFC 9421's structured-field syntax",
      "path": "n/a — inspect response/request headers on any HTTP exchange"
     },
     "question": "How can HTTP messages carry end-to-end component integrity and proof of possession, independent of transport-layer security?",
     "scope": "general",
     "spec_url": "https://www.rfc-editor.org/info/rfc9421",
     "step": "identify",
     "summary_md": "RFC 9421 (HTTP Message Signatures) is a general-purpose IETF Proposed Standard, not specific to agents. It defines how to create, encode and verify digital signatures or message authentication codes over selected components of an HTTP message (headers, derived components like @authority or @method, and optionally the body), so that a signature survives intermediaries that might otherwise alter or drop parts of the message [1]. It also defines how to request that a future message in an ongoing exchange be signed [1].\n\nIt solves message-level integrity and proof-of-possession for HTTP independent of transport security (TLS terminates at intermediaries; RFC 9421 signatures do not) [1]. It does not define identity discovery, key distribution, or any notion of \"bot\" or \"agent\" — those are added by profiles built on top of it. In this map, it is the base standard that Web Bot Auth (see the `webbotauth` record) profiles: Web Bot Auth adds the Signature-Agent header as a signed component and defines a specific key-discovery mechanism (a well-known JWKS directory), while RFC 9421 itself stays agnostic to what a signature proves or where keys come from [2].\n\nCurrent state: published as a Proposed Standard in February 2024 and stable since; it is not itself under active revision as far as this check found.\n\nWho implements it: general HTTP signing libraries exist across languages (this check did not re-survey the full ecosystem); its most visible agent-relevant use is as the substrate for Web Bot Auth, which Cloudflare verifies at the edge [2].\n\nDisputed or unknown: none specific to the base standard found in this pass. Because RFC 9421 is general and widely referenced, this record exists mainly to anchor the agent-specific profiles (Web Bot Auth, and potentially others) that depend on it; it should not be read as agent-specific adoption evidence on its own.",
     "track": "ietf",
     "version": {
      "date": "2024-02",
      "label": "RFC 9421, February 2024, Proposed Standard"
     }
    }
   ],
   "cat": "identify"
  },
  {
   "date": "2026-06-17",
   "title": "Google announces the Agentic Resource Discovery specification",
   "url": "https://developers.googleblog.com/en/announcing-the-agentic-resource-discovery-specification/",
   "summary": "Google's developer blog announced ARD, a well-known manifest listing the resources a site offers agents.",
   "related": [
    "ard"
   ],
   "anchor": "2026-06-17-google-announces-the-agentic-resource-discovery-specificatio",
   "related_articles": [
    {
     "acronym": "ARD",
     "adoption": {
      "by": "agenticresources.dev own probe, 2026-09-04",
      "level": "observed",
      "probe_run": {
       "origins_probed": 50,
       "origins_found": 6,
       "last": "2026-09-04"
      }
     },
     "aliases": [
      "AI Catalog",
      "ai-catalog.json (predecessor path)"
     ],
     "analog": "sitemap plus a search engine index",
     "collisions": [
      "ARDP (Agent Registration and Discovery Protocol, unrelated IETF draft)",
      "AIR (the urn:air: identifier namespace this spec defines is sometimes referred to standalone)"
     ],
     "discovery": {
      "mechanism": "well-known manifest, robots.txt Agentmap directive, HTML <link rel=\"ard\">, DNS SVCB, in-page JSON-LD",
      "path": "/.well-known/ard.json"
     },
     "dispute": {
      "claims": [
       "v0.91 text: /.well-known/ard.json is canonical; /.well-known/ai-catalog.json is an optional predecessor",
       "2026-09-04 probe: 100% of observed manifests are still at ai-catalog.json; only 19% also serve ard.json",
       "Identifier form is urn:air:<publisher>:<namespace>:<agent-name>, not urn:ard as some earlier notes assumed"
      ],
      "summary": "The path this specification calls canonical has changed between revisions and prior internal notes got this backwards: v0.91 (26 Aug 2026) makes /.well-known/ard.json canonical and demotes /.well-known/ai-catalog.json to an optional, non-required-to-consult predecessor path. Our own probe (2026-09-04, prior to this verification) found the entire observed deployment base still on the old ai-catalog.json path, with only 6 of 31 also serving the new path -- so real-world adoption lags the spec text by at least one full path rename. Adoption level is left as \"observed\" rather than \"measured\" here because no probe-run artifact exists inside this repository (data/) to cite by filename; the probe that produced the 31/50 figure lives in the sibling agenticresources.dev project."
     },
     "evidence": [
      {
       "claim": "ARD v0.91 (26 Aug 2026), authored by Google/Microsoft/Hugging Face individuals, defines the ARD entry as a JSON-LD node and moves the canonical manifest path to /.well-known/ard.json, explicitly naming /.well-known/ai-catalog.json as the deprecated predecessor path that consumers MAY but need not consult.",
       "date": "2026-08-26",
       "label": "VERIFIED",
       "url": "https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md"
      },
      {
       "claim": "Google announced the Agentic Resource Discovery Specification and directed publishers to a well-known catalog mechanism.",
       "date": "2026-06-17",
       "label": "REPORTED",
       "url": "https://developers.googleblog.com/en/announcing-the-agentic-resource-discovery-specification/"
      },
      {
       "claim": "AGNTCY's Agent Directory Service (ADS) implements AI Catalog interoperability, serving /.well-known/ai-catalog.json and exporting records to a2a/mcp/oasf formats -- one real implementation of the ARD manifest side.",
       "date": "2026-07-06",
       "label": "VERIFIED",
       "url": "https://datatracker.ietf.org/doc/html/draft-mp-agntcy-ads-02"
      },
      {
       "claim": "A probe of 50 domains run by this site's publisher (agenticresources) on 2026-09-04 found 31 serving a manifest, all 31 on the predecessor ai-catalog.json path, and only 6 of those also on the new ard.json path -- i.e. the ecosystem has not yet moved to the canonical path this v0.91 revision defines.",
       "date": "2026-09-04",
       "label": "REPORTED",
       "url": "https://agenticresources.dev/"
      }
     ],
     "form": "well-known-file",
     "governance": "Authored by individuals at Google, Microsoft and Hugging Face (Junjie Bu, R.V. Guha, Shaun Smith); published as an open GitHub project (ards-project/ard-spec) with no formal standards body yet; contributions acknowledged from AWS, Cisco, Databricks, GitHub, GoDaddy, Nvidia, Salesforce and Snowflake",
     "group": null,
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against ARD v0.91 spec text (raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md); corrected canonical path from ai-catalog.json to ard.json; folded ai-catalog-well-known-file into this record"
      }
     ],
     "id": "ard",
     "implementation": "shipping",
     "last_verified": "2026-09-06",
     "name": "Agentic Resource Discovery",
     "native_status": "Proposal",
     "origin": {
      "date": "2026-06-17",
      "org": "Google, Microsoft, Hugging Face"
     },
     "part_of": null,
     "parties": [
      "agent-site",
      "agent-registry"
     ],
     "phase": "draft",
     "probe": {
      "method": "GET",
      "on_absent": "Domain publishes no ARD manifest at the current canonical path; it may still publish at the deprecated predecessor path /.well-known/ai-catalog.json, which conformant consumers are not required to consult",
      "parse": "200 response is JSON with a top-level \"entries\" array of ARD entries (each with identifier/displayName/type/url-or-data); a consumer MAY also check the predecessor /.well-known/ai-catalog.json and an HTML <link rel=\"ard\"> tag",
      "path": "https://{origin}/.well-known/ard.json"
     },
     "question": "Where are an organization's discoverable agentic resources (MCP servers, A2A agents, skills, registries), and how can they be found by search rather than pre-installed one at a time?",
     "scope": "general",
     "spec_url": "https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md",
     "step": "discover",
     "summary_md": "Agentic Resource Discovery (ARD) is a specification for how agentic resources -- MCP servers, A2A agents, skills, and other callable services -- are described, discovered, and searched across a federated network of registries [1]. It is authored by individuals at Google, Microsoft and Hugging Face and published as an open GitHub project (ards-project/ard-spec) rather than through a formal standards body; the current text is version v0.91, dated 26 August 2026, and is explicitly labelled a \"Proposal\" [1].\n\nARD solves the problem of scaling tool selection beyond an LLM's context window: instead of injecting every possible tool description into a prompt, a client searches a registry's index using natural language plus structured filters, and the registry returns ranked entries [1]. Each entry is a JSON-LD node with a small set of required terms (identifier, displayName, type, and either url or data), and publishers can extend it with arbitrary namespaced terms without waiting for a spec revision [1]. Entries are advertised through a well-known manifest, robots.txt Agentmap directives, an HTML `<link rel=\"ard\">` tag, DNS SVCB records, or in-page markup; the manifest path is `/.well-known/ard.json` [1].\n\nA significant correction to earlier internal notes: the v0.91 text makes `/.well-known/ard.json` the canonical path and explicitly demotes the older `/.well-known/ai-catalog.json` path (and the `ai-catalog` link relation) to an optional predecessor that a conformant consumer is not required to consult [1]. Prior assumptions that ai-catalog.json was still canonical as of this version are wrong as of the text fetched 2026-09-06.\n\nARD does not define a signing or authentication scheme of its own (it defers to whatever trust framework a publisher's `trustManifest` declares), does not constrain artifact-specific schemas (MCP, A2A, etc. remain external), and does not define a normative way to fetch a full entry by identifier from a search result [1].\n\nImplementation exists: AGNTCY's Agent Directory Service explicitly serves `/.well-known/ai-catalog.json` and can export records into a2a, mcp, oasf and agent-skill formats, functioning as one real ARD-manifest-compatible implementation [3]. Beyond that, adoption is thin and lagging the spec's own migration: a probe of 50 domains run by this site's publisher (agenticresources) on 2026-09-04 found 31 serving some manifest, all 31 still on the deprecated ai-catalog.json path, and only 6 of those also serving the new ard.json path [4] -- meaning the observed deployment base predates this very revision's path rename. Because that probe artifact is not present in this repository, adoption here is recorded as \"observed\" rather than \"measured\".\n\nWhat is disputed or unknown: whether the ecosystem migrates to ard.json before a competing discovery mechanism (DNS-AID, AID, ADP) becomes the practical default; whether any registry beyond ADS has implemented the POST /search and POST /explore REST surface this spec mandates; and how the optional `trustManifest` verification step will be operationalized across publishers who have never coordinated on a trust framework.\n\nThe record `ai-catalog-well-known-file`, which previously modelled the manifest file as a separate entity, has been folded into this record: it described the same well-known artifact that this specification now supersedes with `ard.json`, and keeping it separate obscured that the two are one lineage, not two competing formats.",
     "track": "vendor-consortium",
     "version": {
      "date": "2026-08-26",
      "label": "v0.91"
     }
    }
   ],
   "cat": "discover"
  },
  {
   "date": "2026-04-17",
   "title": "Agentic Commerce Protocol dated specification 2026-04-17",
   "url": "https://github.com/agentic-commerce-protocol/agentic-commerce-protocol",
   "summary": "ACP published its 2026-04-17 dated specification, maintained by OpenAI, Stripe and Meta.",
   "related": [
    "agentic-commerce-protocol"
   ],
   "anchor": "2026-04-17-agentic-commerce-protocol-dated-specification-2026-04-17",
   "related_articles": [
    {
     "acronym": "ACP",
     "adoption": {
      "by": "OpenAI and Stripe (project README)",
      "level": "claimed",
      "probe_run": null
     },
     "aliases": [
      "ACP",
      "Agentic Commerce Protocol"
     ],
     "analog": "Checkout API",
     "collisions": [
      "Agent Client Protocol (Zed)",
      "Agent Communication Protocol (IBM)",
      "ERC-8183 (also informally called Agentic Commerce Protocol)",
      "Agent Connect Protocol (AGNTCY)"
     ],
     "discovery": {
      "mechanism": "Bilateral capability negotiation (per RFC: capability_negotiation) between agent platform and merchant; no fixed well-known path published",
      "path": null
     },
     "dispute": null,
     "evidence": [
      {
       "claim": "ACP is an interaction model and open standard maintained by OpenAI and Stripe, currently in beta, using date-based versioning; the 2026-04-17 release added Cart, Feed, Orders, authentication and MCP support.",
       "date": "2026-04-17",
       "label": "VERIFIED",
       "url": "https://github.com/agentic-commerce-protocol/agentic-commerce-protocol"
      },
      {
       "claim": "Governance: a Technical Steering Committee of up to 7 org seats; OpenAI and Stripe are Founding Maintainers with veto power exercised only against violations of five named principles (mission, neutrality, security, protocol integrity, considered decision-making).",
       "date": null,
       "label": "VERIFIED",
       "url": "https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/docs/governance.md"
      },
      {
       "claim": "Meta has joined OpenAI and Stripe as a lead maintainer of the project.",
       "date": null,
       "label": "VERIFIED",
       "url": "https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/MAINTAINERS.md"
      },
      {
       "claim": "OpenAI publishes ACP-based Commerce documentation for building checkout flows in ChatGPT.",
       "date": null,
       "label": "REPORTED",
       "url": "https://developers.openai.com/commerce/"
      },
      {
       "claim": "Stripe publishes Agentic Commerce documentation implementing ACP for merchants.",
       "date": null,
       "label": "REPORTED",
       "url": "https://docs.stripe.com/agentic-commerce"
      }
     ],
     "form": "endpoint",
     "governance": "Technical Steering Committee (up to 7 org seats); OpenAI, Stripe, and Meta are lead maintainers, with OpenAI and Stripe as Founding Maintainers holding last-resort veto over mission, neutrality, security, and fork-integrity decisions",
     "group": "Protocols called ACP",
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against agentic-commerce-protocol GitHub repo (README, docs/governance.md, MAINTAINERS.md, spec/2026-04-17), developers.openai.com/commerce, docs.stripe.com/agentic-commerce"
      },
      {
       "date": "2026-09-06",
       "note": "collisions updated to add Agent Connect Protocol (Cisco/AGNTCY), verified against github.com/agntcy/acp-spec, spec.acp.agntcy.org"
      }
     ],
     "id": "agentic-commerce-protocol",
     "implementation": "multi-implementation",
     "last_verified": "2026-09-06",
     "name": "Agentic Commerce Protocol",
     "native_status": "Beta open standard, interaction model for connecting buyers, agents, and businesses",
     "origin": {
      "date": "2025-09-29",
      "org": "OpenAI and Stripe"
     },
     "part_of": null,
     "parties": [
      "agent-site"
     ],
     "phase": "living",
     "probe": {
      "method": "POST",
      "on_absent": "Absence proves nothing generalizable: ACP endpoints and auth are negotiated per integration and not advertised at a fixed public path, so a failed probe only shows this origin/path pair is not configured, not that ACP is unsupported.",
      "parse": "Response includes an API-Version response/negotiation and a CheckoutSession object per the 2026-04-17 OpenAPI schema",
      "path": "{origin}/checkout_sessions"
     },
     "question": "How do a buyer's agent and a merchant complete a deterministic, programmatic checkout without the agent becoming the merchant of record?",
     "scope": "commerce",
     "spec_url": "https://github.com/agentic-commerce-protocol/agentic-commerce-protocol",
     "step": "pay",
     "summary_md": "The Agentic Commerce Protocol (ACP) is an open, REST-based interaction model that lets a buyer's AI agent (a \"platform\" such as ChatGPT) complete a checkout with a merchant's existing commerce stack, while the merchant remains the system of record for orders, payments, tax, and compliance [1]. It solves the discovery-to-checkout hand-off for conversational and agentic shopping: a client negotiates capabilities, creates and updates a `CheckoutSession`, and completes or cancels it, with optional delegated-payment tokens (`/agentic_commerce/delegate_payment`) so an agent platform can pass a payment method to a merchant without becoming a payment processor [1].\n\nIt does not define blockchain settlement, on-chain escrow, or a payment rail of its own — payments continue to run over the merchant's existing PSP relationship, and ACP is scoped explicitly to checkout session lifecycle, feed ingestion, and payment-handler negotiation, not returns, tax computation, or fraud modeling [1]. It is also not a discovery protocol: there is no published well-known path for finding ACP support at an origin; capability negotiation is bilateral and appears to be arranged per integration (RFC: capability_negotiation), so it cannot be probed generically the way UCP's `/.well-known/ucp` can.\n\nAs of the current state (2026-09), the specification uses date-based versioning with a complete snapshot per release; the latest stable release is 2026-04-17, adding a push-model Feed API, multi-item checkout examples, and 3-D Secure authentication flows, with active development continuing in an `unreleased/` branch [1]. Governance sits with a Technical Steering Committee of up to seven organization seats, appointed by Founding Maintainers OpenAI and Stripe, who retain veto power scoped narrowly to five stated principles (mission, neutrality, security, protocol integrity, and considered decision-making) [2]. Meta has since joined as a third lead maintainer alongside OpenAI and Stripe [3].\n\nReference implementations exist from both founding maintainers: OpenAI's ChatGPT commerce surface and Stripe's Agentic Commerce integration, both documented on their respective developer sites [4][5]. Because the only adoption figures available come from the maintaining organizations' own materials, adoption here is recorded as claimed rather than independently measured. What remains unresolved: how \"beta\" status maps to production risk for merchants going live today, and whether the TSC's veto mechanism has ever been invoked in a real dispute.",
     "track": "vendor-consortium",
     "version": {
      "date": "2026-04-17",
      "label": "2026-04-17 (date-versioned spec; unreleased/ tracks current development)"
     }
    }
   ],
   "cat": "pay"
  },
  {
   "date": "2026-03-05",
   "title": "Mastercard announces Verifiable Intent",
   "url": "https://www.mastercard.com/global/en/news-and-trends/stories/2026/verifiable-intent.html",
   "summary": "Mastercard set out Verifiable Intent, a credential format for proving what a user asked an agent to buy.",
   "related": [
    "vi"
   ],
   "anchor": "2026-03-05-mastercard-announces-verifiable-intent",
   "related_articles": [
    {
     "acronym": "VI",
     "adoption": {
      "by": null,
      "level": "unmeasured",
      "probe_run": null
     },
     "aliases": [],
     "analog": "a verifiable-credential audit trail for a single transaction's chain of consent -- closest classic-web analog is a signed receipt plus consent log",
     "collisions": [],
     "discovery": {
      "mechanism": "none",
      "path": null
     },
     "dispute": null,
     "evidence": [
      {
       "claim": "Mastercard's 2026-03-05 story, co-authored with a Google Payments VP quote, introduces Verifiable Intent as a standards-based trust layer for agentic commerce, aligned with Google's AP2 and UCP, and says Mastercard is 'open-sourcing the Verifiable Intent specification and an initial reference implementation' on GitHub and at verifiableintent.dev; integration into Mastercard Agent Pay's intent APIs is described as forthcoming, not live.",
       "date": "2026-03-05",
       "label": "VERIFIED",
       "url": "https://www.mastercard.com/global/en/news-and-trends/stories/2026/verifiable-intent.html"
      },
      {
       "claim": "The public specification (version 0.1-draft, dated 2026-02-18) defines a layered SD-JWT credential format binding credential provider, user and agent through key-confirmation claims, with Immediate and Autonomous execution modes and selective disclosure per role.",
       "date": "2026-02-18",
       "label": "VERIFIED",
       "url": "https://verifiableintent.dev/spec/"
      },
      {
       "claim": "The GitHub repository README describes VI's status as 'Draft (v0.1). Maintained by Mastercard; open to multi-stakeholder contribution,' and lists transport protocols, key management, credential-provider enrollment, agent-platform APIs and dispute resolution as explicitly out of scope for the spec.",
       "date": "2026-09-05",
       "label": "VERIFIED",
       "url": "https://github.com/agent-intent/verifiable-intent"
      }
     ],
     "form": "document-format",
     "governance": "Maintained by Mastercard; open to multi-stakeholder contribution per the project's CONTRIBUTING.md; built on FIDO Alliance, EMVCo, IETF and W3C primitives (SD-JWT/RFC 9901, key confirmation/RFC 7800)",
     "group": null,
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against mastercard.com/.../verifiable-intent.html (via firecrawl, curl 403s), verifiableintent.dev/spec/, and github.com/agent-intent/verifiable-intent README and spec/credential-format.md; corrected version date to 2026-02-18, origin.date to 2026-03-05, governance and scope; kept step=account"
      }
     ],
     "id": "vi",
     "implementation": "prototype",
     "last_verified": "2026-09-06",
     "name": "Verifiable Intent",
     "native_status": "Draft (v0.1); open-sourced specification and reference implementation",
     "origin": {
      "date": "2026-03-05",
      "org": "Mastercard, co-developed with Google"
     },
     "part_of": null,
     "parties": [
      "agent-payment"
     ],
     "phase": "draft",
     "probe": {
      "method": "GET",
      "on_absent": "Expected in nearly all cases today: VI has not defined a well-known discovery path, and Mastercard states integration into Mastercard Agent Pay's intent APIs is still 'in the coming months' as of the 2026-03-05 announcement.",
      "parse": "Non-normative: the VI specification does not define a discovery mechanism (transport, agent-platform APIs and credential-provider enrollment are explicitly out of scope). This checks a plausible-but-unofficial convention only; a real signal of VI usage is the presence of an SD-JWT credential in a checkout flow with header typ 'kb-sd-jwt' (Immediate/Autonomous modes) or 'sd+jwt' (L1), and vct 'https://credentials.mastercard.com/card' for the Mastercard reference profile.",
      "path": "{merchant_origin}/.well-known/verifiable-intent"
     },
     "question": "After an agent completes a purchase on a user's behalf, can the merchant, issuer and consumer all point to the same cryptographic record of what the user actually authorized?",
     "scope": "payments",
     "spec_url": "https://verifiableintent.dev/spec/",
     "step": "account",
     "summary_md": "Verifiable Intent (VI) is a credential format -- not a network protocol -- that creates a tamper-evident, cryptographic chain of who authorized what when an AI agent makes a purchase on a person's behalf: a credential provider (bank or card network) signs an identity layer (L1), the user's wallet signs a layer binding specific constraints such as amount range, allowed merchants or line items (L2), and, in 'Autonomous' mode, the agent's own key is bound into a further layer (L3) before it acts without the user present [2][3]. Selective disclosure (SD-JWT, per IETF RFC 9901) means a merchant, issuer or agent platform each sees only the claims relevant to their role. This is squarely an 'account' spec in this site's sense: its entire purpose is producing a record that can be checked after the fact -- if a dispute arises, all parties can point to the same signed chain rather than reconstructing intent from logs [1].\n\n**What it solves.** Before VI, a merchant accepting an agent-initiated purchase has no standard way to prove the user actually authorized that specific transaction, and issuers cannot cleanly separate legitimate agent purchases from fraud. VI gives all parties a shared, privacy-preserving evidence trail [1].\n\n**What it does not do.** VI does not define transport protocols, key management/provisioning, credential-provider enrollment, agent-platform APIs, dispute-resolution process, or regulatory-compliance mapping -- all explicitly out of scope in the spec itself [3]. It has no discovery mechanism (no well-known path, no registry); a merchant currently has to know out-of-band that a given credential provider or agent supports it.\n\n**Current state.** Announced 2026-03-05 by Mastercard with a co-authorship/quote from Google's VP of Payments, positioned as complementary to Google's Agent Payments Protocol (AP2) and Universal Commerce Protocol (UCP) [1]. The public specification is version 0.1-draft, dated 2026-02-18 [2]. As of the announcement, Mastercard describes integration into its own Agent Pay intent APIs as forthcoming ('in the coming months'), not yet live, and the GitHub repository is explicitly labelled Draft (v0.1) [1][3].\n\n**Who implements it.** Mastercard has published an initial reference implementation alongside the specification. Quoted partners in the launch material -- Google, Adyen, Basis Theory, Checkout.com, Getnet, Fiserv, IBM and Worldpay/Global Payments -- describe alignment or planned integration, but none of the fetched sources documents a live, independent production implementation outside Mastercard's own reference code, so implementation is marked 'prototype' rather than 'shipping' or 'multi-implementation.'\n\n**Disputed / unknown.** No adoption count exists; this record marks adoption 'unmeasured' rather than 'claimed' because no single source stated a specific number of live integrations. Whether VI becomes a true multi-network standard or remains Mastercard-centric (the Mastercard reference credential profile, vct 'https://credentials.mastercard.com/card,' is the only concretely specified profile) is unresolved.",
     "track": "vendor-consortium",
     "version": {
      "date": "2026-02-18",
      "label": "0.1-draft"
     }
    }
   ],
   "cat": "account"
  },
  {
   "date": "2026-01-27",
   "title": "Open Semantic Interchange specifications finalised",
   "url": "https://www.snowflake.com/en/blog/open-semantic-interchanges-specs-finalized/",
   "summary": "Snowflake reported that the Open Semantic Interchange specifications had been finalised by the initiative's partners.",
   "related": [
    "osi"
   ],
   "anchor": "2026-01-27-open-semantic-interchange-specifications-finalised",
   "related_articles": [
    {
     "acronym": "OSI",
     "adoption": {
      "by": null,
      "level": "unmeasured",
      "probe_run": null
     },
     "aliases": [
      "Open Semantic Interchange",
      "Apache Ossie"
     ],
     "analog": "a shared data dictionary made machine-readable, distributed like a schema file rather than an API",
     "collisions": [
      "Open Source Initiative (osi.org)"
     ],
     "discovery": {
      "mechanism": "none",
      "path": null
     },
     "dispute": {
      "claims": [
       "Marketing claims the spec is 'finalized'; the repository's own version marker says draft/unreleased.",
       "track=community is a placeholder; the real governance is 'ASF Incubator podling,' which the current vocab does not model."
      ],
      "summary": "Snowflake's January 2026 post is titled 'OSI Specification Finalized,' but the specification text in the repository is versioned 0.2.0.dev0 and explicitly marked DRAFT, with the only tagged release a release-candidate (osi-0.1.1-rc1). 'Finalized' appears to describe the *initial publication* of a spec document, not a stable/final version number. Separately, vocab.json has no track value for 'Apache Software Foundation incubator project' distinct from 'linux-foundation' (LF-specific) or 'industry-body' (trade association); 'community' was chosen as the least-wrong fit but understates that Ossie now has ASF Incubator governance (mentors, PPMC, a defined graduation process) rather than no formal governance."
     },
     "evidence": [
      {
       "claim": "Snowflake announced the Open Semantic Interchange initiative on 2025-09-23 with Salesforce, BlackRock, dbt Labs and RelationalAI as co-leading partners, plus a wider coalition (Alation, Atlan, Tableau, ThoughtSpot, Sigma, Omni and others).",
       "date": "2025-09-23",
       "label": "VERIFIED",
       "url": "https://www.snowflake.com/en/news/press-releases/snowflake-salesforce-dbt-labs-and-more-revolutionize-data-readiness-for-ai-with-open-semantic-interchange-initiative/"
      },
      {
       "claim": "Snowflake's 2026-01-27 post says 'the first version of the OSI specification is now available' via an Apache-2.0 licensed repo at github.com/open-semantic-interchange/OSI, and that OSI would later move to 'a neutral, foundation-led governance model.'",
       "date": "2026-01-27",
       "label": "VERIFIED",
       "url": "https://www.snowflake.com/en/blog/open-semantic-interchanges-specs-finalized/"
      },
      {
       "claim": "The project entered the Apache Incubator on 2026-06-22 as 'Apache Ossie (incubating)'; the original open-semantic-interchange GitHub org now shows 0 public repositories and github.com/open-semantic-interchange/OSI redirects to github.com/apache/ossie.",
       "date": "2026-06-22",
       "label": "VERIFIED",
       "url": "https://incubator.apache.org/projects/ossie.html"
      },
      {
       "claim": "The current core specification file (core-spec/spec.md) is headed 'DRAFT version -- in development, schema may change before 0.2.0 is released' and labelled Version 0.2.0.dev0; the repository's only Git tag is osi-0.1.1-rc1, not a v1.0 -- contradicting the 'specification finalized' framing of the January 2026 announcement.",
       "date": "2026-09-05",
       "label": "VERIFIED",
       "url": "https://raw.githubusercontent.com/apache/ossie/main/core-spec/spec.md"
      }
     ],
     "form": "document-format",
     "governance": "Apache Software Foundation, Apache Incubator (Ossie Podling Project Management Committee); formerly a Snowflake-led multi-vendor working group",
     "group": null,
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against github.com/apache/ossie (README, core-spec/spec.md), incubator.apache.org/projects/ossie.html, and Snowflake's 2025-09-23 and 2026-01-27 posts; moved step from 'account' to 'read', corrected spec_url, name, governance, and version; flagged draft-vs-finalized dispute"
      }
     ],
     "id": "osi",
     "implementation": "prototype",
     "last_verified": "2026-09-06",
     "name": "Apache Ossie (formerly Open Semantic Interchange)",
     "native_status": "Undergoing incubation at the Apache Software Foundation ('Apache Ossie (incubating)'); not yet a top-level ASF project. Core spec is marked DRAFT.",
     "origin": {
      "date": "2025-09-23",
      "org": "Snowflake, with Salesforce, dbt Labs, BlackRock and RelationalAI as founding partners"
     },
     "part_of": null,
     "parties": [
      "agent-site"
     ],
     "phase": "draft",
     "probe": {
      "method": "GET",
      "on_absent": "If a tool claims 'OSI' or 'Ossie compatibility' but cannot produce a document that validates against this schema, the claim cannot be confirmed.",
      "parse": "Fetch the JSON Schema, then validate a candidate semantic-model file (dataset/metric/dimension document) against it; a pass confirms the file is Ossie/OSI-conformant. There is no fixed well-known path or origin endpoint — OSI/Ossie is an exchanged document format, not a runtime discovery protocol.",
      "path": "https://raw.githubusercontent.com/apache/ossie/main/core-spec/ossie-schema.json"
     },
     "question": "How can an AI agent or BI tool read a metric or data-model definition and get the same meaning another tool intended?",
     "scope": "general",
     "spec_url": "https://github.com/apache/ossie",
     "step": "read",
     "summary_md": "OSI/Apache Ossie is a JSON- and YAML-based specification for representing semantic-layer objects (datasets, metrics, dimensions, relationships) so that BI tools, data catalogs and AI/agentic applications compute a term like \"churn rate\" the same way regardless of which vendor's tool wrote the definition [1]. It is a document/interchange format, not a network protocol: there is no discovery endpoint or well-known path, and no runtime negotiation. Consumption happens by reading (or generating) a semantic-model file against the published JSON Schema -- which is why this record has been moved from the site's original 'account' placement to 'read': OSI is squarely about machine-readable representations of content (metric/data definitions) for consumption by BI and agent tooling, not about recording or attributing actions after the fact.\n\n**What it does not do:** OSI/Ossie does not define an API, an audit trail, an authentication scheme, or a discovery mechanism. It says nothing about who is allowed to read or write a given semantic model, and it does not itself measure or certify adoption.\n\n**Current state.** Snowflake announced OSI on 2025-09-23 with Salesforce, BlackRock, dbt Labs and RelationalAI as co-leads, alongside a larger coalition of BI/data vendors [1]. On 2026-01-27 Snowflake published \"the first version of the OSI specification\" as an Apache-2.0 repository and said governance would eventually move to a neutral foundation [2]. That move happened on 2026-06-22, when the project entered the Apache Incubator as \"Apache Ossie (incubating)\"; the original open-semantic-interchange GitHub organization now has zero public repositories, and its old repo URL redirects to github.com/apache/ossie [3]. As of this verification, the live core specification is versioned 0.2.0.dev0 and is explicitly marked DRAFT -- \"schema may change before 0.2.0 is released\" -- and the only Git tag in the history is a release-candidate, osi-0.1.1-rc1, not a 1.0 [4]. This means the January 2026 \"specification finalized\" headline describes the spec's first public release, not a stable/versioned final; readers should not assume OSI has reached a frozen v1.0.\n\n**Who implements it.** The repository ships reference converters for a dozen vendor ecosystems -- Snowflake, Databricks, Salesforce, dbt, GoodData, NVIDIA, Omni, Polaris, Honeydew, Wisdom, OrionBelt and an ontology bridge -- but these live in a converters/ directory of a repo whose core spec is still draft, so they read as reference/example integrations rather than confirmed production deployments; this record conservatively marks implementation as 'prototype' rather than 'multi-implementation.'\n\n**Disputed / unknown.** Whether OSI's broad vendor coalition (dbt Labs, Salesforce, BlackRock, Databricks, Mistral AI and ~30 others) reflects production adoption of the spec itself, or membership in a working group around a still-drafting spec, is not independently measurable from public sources. No probe has been run; adoption is marked unmeasured rather than claimed, because no single party made a countable claim we could cite. The vocabulary used by this site for 'track' does not have a category for an ASF Incubator podling, which is a materially different governance state from an informal community project.",
     "track": "community",
     "version": {
      "date": null,
      "label": "0.2.0.dev0 (draft, in development); last tagged pre-release osi-0.1.1-rc1"
     }
    }
   ],
   "cat": "read"
  },
  {
   "date": "2025-10-14",
   "title": "Visa introduces the Trusted Agent Protocol",
   "url": "https://investor.visa.com/news/news-details/2025/Visa-Introduces-Trusted-Agent-Protocol-An-Ecosystem-Led-Framework-for-AI-Commerce/default.aspx",
   "summary": "Visa announced the Trusted Agent Protocol, a framework for merchants to recognise and trust shopping agents.",
   "related": [
    "tap"
   ],
   "anchor": "2025-10-14-visa-introduces-the-trusted-agent-protocol",
   "related_articles": [
    {
     "acronym": "TAP",
     "adoption": {
      "by": "Visa's own launch announcement, naming ecosystem participants including Cloudflare",
      "level": "claimed",
      "probe_run": null
     },
     "aliases": [
      "Trusted Agent Protocol"
     ],
     "analog": "Signed merchant/client verification layered on card-network trust",
     "collisions": [],
     "discovery": {
      "mechanism": "Signed HTTP headers/body during browsing and payment interactions, verified against Visa's Public Keys Retrieval Service",
      "path": "/keys"
     },
     "dispute": {
      "claims": [
       "Visa's own text frames TAP as complementary to, not a replacement for, bilateral merchant-agent agreements and other bot-detection signals (user-agent headers, IP allow-listing, registries)."
      ],
      "summary": "TAP is a single-vendor (Visa) specification, not an open standard; it is designed for the two-sided scenario where the agent is initially unknown to the merchant, and is explicitly scoped to commerce (browsing and payment interactions), unlike the general-purpose Web Bot Auth."
     },
     "evidence": [
      {
       "claim": "Visa's launch announcement introduces the Trusted Agent Protocol as an ecosystem-led framework for AI commerce, naming participating partners",
       "date": "2025-10-14",
       "label": "VERIFIED",
       "url": "https://investor.visa.com/news/news-details/2025/Visa-Introduces-Trusted-Agent-Protocol-An-Ecosystem-Led-Framework-for-AI-Commerce/default.aspx"
      },
      {
       "claim": "Visa's merchant specification defines a Public Key Retrieval operation (GET /keys with a keyID parameter, returning a JWK) used to verify agent-recognition signatures and a Visa-signed ID Token compliant with RFC 7519/7515",
       "date": "2026-09-06",
       "label": "VERIFIED",
       "url": "https://developer.visa.com/capabilities/trusted-agent-protocol/trusted-agent-protocol-specifications"
      }
     ],
     "form": "http-header",
     "governance": "Visa (single-vendor specification, published for merchant/developer adoption)",
     "group": null,
     "history": [
      {
       "date": "2026-09-05",
       "note": "seeded from Exa Agent research run"
      },
      {
       "date": "2026-09-06",
       "note": "verified against Visa's live merchant specification page and the 2025-10-14 launch announcement"
      }
     ],
     "id": "tap",
     "implementation": "prototype",
     "last_verified": "2026-09-06",
     "name": "Visa Trusted Agent Protocol",
     "native_status": "Active vendor-led merchant specification",
     "origin": {
      "date": "2025-10",
      "org": "Visa (with Cloudflare as an early ecosystem participant)"
     },
     "part_of": null,
     "parties": [
      "agent-site",
      "agent-payment"
     ],
     "phase": "candidate",
     "probe": {
      "method": "GET",
      "on_absent": "The referenced key cannot be retrieved, so the agent-recognition signature or Visa ID Token cannot be verified",
      "parse": "200 response body is a JWK object (kty, kid, use, alg, and RSA/EC key material) matching the keyID used to sign the agent's request or the Visa-issued ID Token",
      "path": "https://{tap-key-service}/keys?keyID={kid}"
     },
     "question": "How does a merchant recognize that an approved commerce agent, rather than a crawler or fraudulent bot, is interacting with its site or API?",
     "scope": "commerce",
     "spec_url": "https://developer.visa.com/capabilities/trusted-agent-protocol/trusted-agent-protocol-specifications",
     "step": "identify",
     "summary_md": "Visa's Trusted Agent Protocol (TAP) lets a merchant recognize that an \"approved agent with commerce intent\" — rather than a scraper, reseller bot, or attacker — is interacting with its website or API, and lets the merchant request additional information (payment, consumer email) back from that agent [1]. It is designed specifically for the case where the agent is not already known to the merchant through a bilateral agreement: instead of user-agent strings, IP allow-lists, approved-agent registries, or shared keys, TAP carries linked, verifiable, purpose-identifying, time-bound signed credentials in the request headers or body [2].\n\nIt solves agent recognition across two specific interaction types: a browsing interaction (an agent, acting for a consumer with commerce intent, checks product availability, size/color and final cost) and a payment interaction (the agent supplies everything needed to complete a purchase or gain paid access to a merchant resource) [2]. Verification relies on a Visa-run Public Keys Retrieval Service (`GET /keys`, returning a JWK by keyID) and a Visa-issued ID Token — a JWT compliant with RFC 7519, signed per RFC 7515, carrying standard and Visa-private claims [2]. It does not replace existing bot-detection signals — Visa's own text frames it as one more, more efficient, signal merchants can choose to check, and any of these signatures can simply be ignored by merchants that have not adopted TAP [2]. It is also explicitly scoped to commerce, unlike the general-purpose Web Bot Auth; the two overlap conceptually (both sign HTTP requests to prove client identity) but serve different scopes and are governed by different parties.\n\nCurrent state: launched by Visa on 2025-10-14 as an \"ecosystem-led framework for AI commerce,\" naming early partners [1]. As of this check (2026-09-06) Visa Developer publishes a full merchant specification covering the trust model, agent recognition signature, consumer recognition, contextual data, payment object, card metadata, credential hashing, and the ID Token format [2] — this is a live, vendor-maintained document rather than a versioned, dated standard.\n\nWho implements it: Visa (issuer of the ID Token and key service) and named ecosystem participants from the 2025 launch, including Cloudflare per the earlier seed research (not independently re-verified as an implementer of this exact spec in this pass). No independent, non-Visa implementation was confirmed here.\n\nDisputed or unknown: because this is a single-vendor specification without a formal versioning scheme visible on the page, dating a specific \"current version\" is not possible from the page alone; whether other card networks will adopt a compatible or competing scheme is unresolved.",
     "track": "single-vendor",
     "version": {
      "date": null,
      "label": "Current merchant specification, 2026, published on Visa Developer"
     }
    }
   ],
   "cat": "identify"
  }
 ]
}