Opening this as a question rather than a proposal — I think there's a real gap here, but it fails part of the bar in CONTRIBUTING and I'd rather you weigh it than have me guess.
Topic
Agentic commerce discovery — /.well-known/ucp and /.well-known/acp.json
Category
agent-readiness
Proposed status
optional
One-paragraph summary
Two agentic commerce protocols now ask a business to serve a static discovery document from its own origin, so an agent can answer "does this site sell to agents, over what transport, with what capabilities" before starting a session. The Universal Commerce Protocol (Google-led, with Shopify and others) uses /.well-known/ucp; the Agentic Commerce Protocol (OpenAI and Stripe) uses /.well-known/acp.json. Both are unauthenticated, cacheable JSON at a fixed path — the same shape as the discovery documents already covered here. Neither path is registered with IANA, and the two are not interoperable, so a merchant serving one is invisible to agents looking for the other.
Sources
Why this might belong
The spec currently has no commerce coverage beyond incidental mentions — Product/Offer in one bullet of structured data, e-commerce as a use case in IndexNow, checkout as the recurring failure page in consistent help. That's fine; commerce as a vertical isn't what this spec does.
But this particular item is a file a website serves, which is the test considered/dpp-link-relation applies and the reason DPP was turned down: the dpp relation lives in a resolver's linkset, not on the product page, so it isn't a property of a website. /.well-known/ucp is. It's served from the merchant's own origin, by the merchant, for any agent that fetches it.
The closest precedent for how to handle it is Agent Skills discovery — an unregistered, draft, vendor-led well-known URI, filed under agent-readiness rather than well-known, honest in the summary about being emerging. That page's existence is most of my argument.
Why it might not
Three reasons to say no, or not yet:
- Adoption is the part I can't evidence. CONTRIBUTING is explicit that a topic has to be used, not merely standardised, and I have no measurement of how many origins actually serve either document. I've verified the specs define them; I haven't verified anyone ships them. If you want that number before deciding, that's fair, and I'd rather someone gather it than have the page assert adoption it can't back.
- The standard isn't settled. Two consortia, two paths, no convergence signal I can find. A page would have to say "there are two, pick by which agents you care about," which is honest but thin advice.
- It can't go in Well-Known URIs. The overview says "do not invent new names" and lists using an unregistered name as a common mistake. Documenting two unregistered paths in that category would contradict it. Agent-readiness avoids that, but it's worth naming the tension rather than routing around it quietly.
What I'm asking
Does this clear the bar, and if not, is it worth a /considered/ entry instead? A too-early entry with a revisit of "either path accepted into the IANA registry, or one protocol demonstrably winning merchant adoption" would capture it without the spec having to pick a side.
Happy to write either one if you decide which. I checked /considered/ and the open issues first; nothing covers this yet.
Opening this as a question rather than a proposal — I think there's a real gap here, but it fails part of the bar in CONTRIBUTING and I'd rather you weigh it than have me guess.
Topic
Agentic commerce discovery —
/.well-known/ucpand/.well-known/acp.jsonCategory
agent-readinessProposed status
optionalOne-paragraph summary
Two agentic commerce protocols now ask a business to serve a static discovery document from its own origin, so an agent can answer "does this site sell to agents, over what transport, with what capabilities" before starting a session. The Universal Commerce Protocol (Google-led, with Shopify and others) uses
/.well-known/ucp; the Agentic Commerce Protocol (OpenAI and Stripe) uses/.well-known/acp.json. Both are unauthenticated, cacheable JSON at a fixed path — the same shape as the discovery documents already covered here. Neither path is registered with IANA, and the two are not interoperable, so a merchant serving one is invisible to agents looking for the other.Sources
source/schemas/profile.json:108describes the "Profile document hosted by a business at/.well-known/ucp";docs/documentation/core-concepts.md:227covers the discovery flowrfcs/rfc.discovery.md, still marked Status: Proposal; the document shipped in the2026-04-17spec release (changelog/2026-04-17.md:198)ucpnoracp.jsonis registeredWhy this might belong
The spec currently has no commerce coverage beyond incidental mentions —
Product/Offerin one bullet of structured data, e-commerce as a use case in IndexNow, checkout as the recurring failure page in consistent help. That's fine; commerce as a vertical isn't what this spec does.But this particular item is a file a website serves, which is the test
considered/dpp-link-relationapplies and the reason DPP was turned down: thedpprelation lives in a resolver's linkset, not on the product page, so it isn't a property of a website./.well-known/ucpis. It's served from the merchant's own origin, by the merchant, for any agent that fetches it.The closest precedent for how to handle it is Agent Skills discovery — an unregistered, draft, vendor-led well-known URI, filed under agent-readiness rather than well-known, honest in the summary about being emerging. That page's existence is most of my argument.
Why it might not
Three reasons to say no, or not yet:
What I'm asking
Does this clear the bar, and if not, is it worth a
/considered/entry instead? Atoo-earlyentry with arevisitof "either path accepted into the IANA registry, or one protocol demonstrably winning merchant adoption" would capture it without the spec having to pick a side.Happy to write either one if you decide which. I checked
/considered/and the open issues first; nothing covers this yet.