Agent identity became the agentic commerce story of the week. On 20 September Amazon blocked Meta's Muse assistant from browsing and buying on its site, saying the agent "fails to identify itself while browsing" (The Register). That dispute is about an agent driving a website, not about UCP. But the question underneath it, how a store knows which agent is knocking, is one the protocol has already answered in part, and an open pull request would extend that answer to the UCP version a third of stores still declare.

This post explains what Web Bot Auth is, what UCP's current release says about it, what the backport in #829 would change, and what our crawl says about who it would reach.

#What is Web Bot Auth?

Web Bot Auth (WBA) is an IETF draft, draft-meunier-webbotauth-httpsig-protocol, for bots and agents to prove who they are on every request. The agent signs each HTTP request with RFC 9421 HTTP Message Signatures and publishes its public keys at a well-known address. A verifier, typically the CDN or bot-management layer in front of a website, fetches the keys and checks the signature. A valid signature says "this request came from the holder of this key". It does not say the request should be allowed; that stays the site's decision.

User-agent strings can be copied by anyone. A signature can't be forged without the private key. That's the difference that matters for stores deciding which agents to serve.

#What does UCP say about it today?

UCP has its own request signing, also built on RFC 9421. Every UCP implementation MUST support verifying ES256 (ECDSA P-256) signatures, and a platform's keys are discovered through its UCP profile, resolved via the UCP-Agent header.

The current release, v2026-08-25, added a bridge between the two. It came from #483, Shopify's Ilya Grigorik's "Web Bot Auth (WBA) interop", merged on 3 July. Under it, a UCP integrator MAY shape its primary signature so that both a UCP verifier and a WBA verifier accept it. The spec calls this the recommended path for integrators who want interop with WBA-conformant verifiers.

A WBA-shape UCP signature:

• MUST send a Signature-Agent header alongside UCP-Agent, not instead of it. By default it points at the same /.well-known/ucp profile, so WBA verifiers read the profile's keys[] as the key directory.
• MUST set keyid to the key's JWK SHA-256 thumbprint, so both lookups find the same key.
• MUST include created and expires; the window SHOULD be at most 24 hours. It SHOULD include a nonce against replay.
• MUST carry tag="web-bot-auth", which is how WBA verifiers pick it out.
• MUST still cover every component a normal UCP signature covers. Opting in never widens what UCP authenticates.

The example in the spec shows the shape:

Signature-Agent: sig1="https://platform.example/.well-known/ucp";type=jwks_uri
Signature-Input: sig1=("@method" "@authority" "@path" "signature-agent";key="sig1" "ucp-agent" "idempotency-key" "content-digest" "content-type");keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U";created=1738617600;expires=1738621200;tag="web-bot-auth"

Two details are easy to miss. Interop is one-way: a UCP signer satisfies a WBA verifier, but a UCP verifier does not accept any minimal WBA signature; the aim is to be verifiable by WBA verifiers. And Ed25519 is optional: the release adds OKP keys (Ed25519, the most common algorithm among WBA signers today), but a verifier that doesn't support a published key MUST NOT reject the whole key set.

The practical effect: an agent can use one key, published once, and be verifiable both by the store's UCP endpoint and by the web edge in front of the store.

#What would the backport change?

Version 2026-04-08 has none of this. Its signature spec has no WBA shape, no Signature-Agent and no Ed25519 keys.

#829, opened on 17 September, backports #483 to the release/2026-04-08 branch. It adds the Ed25519 (OKP) key support, the curve and algorithm constraints and the top-level keys[] array to the 2026-04-08 profile schema, and carries the WBA sections into that version's signature and overview docs. It is marked as a Core Protocol change, which needs Tech Council approval. As of today it is open and has had no review.

It sits alongside another backport opened the same day, #828 (shopping permalinks, also open), and follows #813, which carried the loyalty extension into 2026-04-08 and was merged on 9 September: selected features reaching the older version without every store having to move.

#Who would it reach? What our crawl shows

UCP versions are negotiated per business, so the version a store declares decides which rules apply when an agent talks to it. Of the 17,896 verified UCP stores we checked on 24 September:

The 2026-04-08 group is almost one platform. 5,895 of the 6,002 are Wix stores (98%). Shopify stores are on 2026-08-25 almost entirely (10,640), as are 1,151 Wix stores. So in practice, the backport decides whether the WBA shape has a spec basis for most Wix storefronts, unless they move to 2026-08-25 first.

The signing machinery on the business side is also early. Businesses publish keys too (to sign their own messages, such as webhooks), and few do: 71 stores publish signing keys, 21 publish the newer top-level keys[] array, and 11 publish an Ed25519 (OKP) key. Most of the 71 are BigCommerce and custom builds on 2026-04-08.

#What it does not do

Signing identifies an agent. It doesn't authorise it: a store or a CDN can still refuse a signed agent, and many will want to know more than a key before they allow a purchase. UCP also doesn't govern agents that browse a website as if they were a person, which is what the Amazon dispute is about. What the interop gives is narrower and useful: an agent that already signs for UCP can present the same verifiable identity at the web edge, with no second key or registration.

#Identity elsewhere in the council's work

Identity is on the Shopping Tech Council's agenda beyond this PR:

• Roadmap. Identity linking is one of the four roadmap pillars drafted on 4 September, with fulfilment, returns and location, for a release targeted at early December or January.
• Shopify's backlog. "Identity linking and privacy hardening for agent runtimes" was on the list of high-demand items presented on 11 September, where identity-linked buyer data was also raised as a gap. The minutes record Ilya Grigorik confirming it is underspecified and needs explicitly defined behaviour.
• Who is asking. On 18 September, discussing whether feeds should expose stock counts, the council noted that malicious bots binary-search checkouts to track sales velocity. One option discussed was authenticated feeds for specific channels, which depends on knowing which agent is on the other end.
• This week's issues. Three identity-linking threads opened: #850 anchors identity-provider selection to a recognised issuer, #852 asks how a platform authenticates at a business's token endpoint on first contact, and #855 asks what "subject to the scopes that gate the operation" constrains.

The council has discussed WBA's footing before. When #483 was reviewed on 26 June, Amit Handa raised concerns about relying on an unreleased IETF draft that might change and lacked broad adoption; the PR was merged a week later as an optional path.

#How we use it

UCP Checker's crawler, UCPCheckerBot, signs its requests with Web Bot Auth and publishes its keys at /.well-known/http-message-signatures-directory. We did it for the reason this post describes: a store should be able to tell a measurement crawler from anything pretending to be one. More on the bot is on its page.

#What to watch

• Review of #829. Whether the council takes WBA into 2026-04-08, and whether Wix stores move to 2026-08-25 first.
• Who signs. How many agents send tag="web-bot-auth" signatures to UCP endpoints, and how many stores publish Ed25519 keys. We'll report the business-side key counts as they change.
• The next release. Identity linking is a roadmap pillar for December or January; the three open threads above are the early shape of it.

#About UCP Checker

UCP Checker is the independent validation and observability layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score, live adoption stats, the vertical guides and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.