When an AI agent lands on a store and reads its UCP manifest, it sees a list of capabilities — checkout, catalog, identity linking — and, increasingly, extensions published by third parties: a buy-now-pay-later flow, a loyalty program, a returns handler. Each one is a promise about what the agent can do and who is standing behind it.

Which raises a question that gets more important the moment real money moves: how does the agent know an extension is actually from who it claims to be?

The Universal Commerce Protocol has a clean, decentralised answer to that, formalised in the spec's namespace governance rules (#530). It's called authority binding, and it's quietly one of the most important trust primitives in the whole protocol.

#Names that carry their own authority

UCP identifies everything — capabilities, services, payment handlers, extensions — with a reverse-DNS namespace:

• dev.ucp.shopping.checkout — governed by ucp.dev, the protocol's own namespace
• com.example.loyalty_gold — a loyalty program governed by example.com
• com.acme-pay.installments — an installment product governed by acme-pay.com

The pattern is {reverse-domain}.{service}.{capability}, and it's doing something subtle: the name encodes who governs it. Reverse the leading domain labels and you get the authority domain — dev.ucp → ucp.dev, com.acme-pay → acme-pay.com. The dev.ucp.* namespace is reserved for capabilities sanctioned by the UCP Tech Council; every other vendor uses their own reverse-domain namespace for whatever they define.

The elegant part: there's no central registry. Nobody has to approve a new extension or hand out identifiers. A vendor can define and publish a capability under their own domain, and the name itself says who owns it. (The recent grammar update even broadened what a valid namespace looks like — interior hyphens like com.example-shop.*, digit-leading labels like com.2example.*, and internationalised domains — so the naming keeps up with real-world domains.)

For a fuller tour of how these names work and who's allowed to claim one, see What Is a UCP Namespace?. Here we're interested in the next question: once a name claims an authority, how do you prove it?

#The binding: a name has to prove it owns itself

A name that claims to belong to acme-pay.com isn't worth much on its own — anyone can type a string. So the spec adds one rule that turns the claim into something checkable.

Every capability and extension ships a machine-fetchable schema URL that defines its contract. Authority binding says, in normative terms:

An entity's schema URL must originate from its namespace authority domain. Platforms must validate this binding, and must reject entities that fail it — before fetching anything.

So dev.ucp.* schemas must be served from ucp.dev; a com.acme-pay.* extension must serve its schema from acme-pay.com (or a subdomain of it). If a namespace claims one authority but hosts its schema somewhere else entirely — a shared CDN, a code-hosting domain, someone else's site — the binding fails, and a conforming platform rejects the entity.

Two things worth being precise about:

• It proves provenance, not trustworthiness. Authority binding guarantees that the reverse-domain name is controlled by the domain owner. It does not claim the extension is safe, well-built, or a good idea — only that it honestly belongs to who it says. That's the right scope for a foundational check: provenance first, judgement separately.
• Only the schema URL is bound. The spec URL — human-readable documentation — is deliberately not authority-bound and can live on any https origin. It's documentation, not part of the machine trust path.

#Why this matters for agentic commerce

Agents are going to compose behaviour from capabilities they've never seen before, published by parties they've never heard of. In a world with no central gatekeeper, provenance has to be built into the format itself — something an agent (or a neutral third party) can verify from the outside, deterministically, without asking anyone's permission.

Authority binding delivers exactly that. It's:

• Deterministic — a name either binds to its authority or it doesn't. Binary, not a judgement call.
• Outside-in — anything an agent can see, anyone can check. No privileged access required.
• Decentralised — provenance without a registry, so the ecosystem can grow without a bottleneck.

It's the executable brick under a lot of what comes next: if you can prove who published a capability, you can start reasoning about the ecosystem as a graph of vendors and the extensions they layer onto the core protocol.

#Two signals from one check

Once you run authority binding across a whole population of stores, it produces two complementary signals.

The first is trust: which extensions are honestly bound to the party that claims them. A vendor serving com.vendor.* schemas from vendor.com has proven provenance; one hosting them elsewhere hasn't — yet.

The second is adoption: because every capability's name resolves to a governing domain, you can group the entire ecosystem by vendor — the core protocol (ucp.dev) on one side, and every third party publishing their own capabilities and extensions on the other. That's a live map of who is building on UCP and what they're extending.

We put both on the vendor & extension map: capabilities and extensions grouped by their namespace authority, each carrying a plain provenance verdict. It's the same data seen two ways — a trust signal and an adoption signal — over the capabilities directory you already know.

#What the ecosystem actually looks like

When we run the check across the thousands of stores we observe, the picture is reassuring: more than 99% of declared capabilities are authority-bound. Provenance is already the norm, not the exception — which makes sense, because the core dev.ucp.* capabilities that dominate every manifest point at ucp.dev schemas by default. Genuine binding failures are rare, numbering in the dozens across the whole fleet. And that's exactly the point of surfacing them: the rare miss is almost always a third-party namespace claiming one authority while its schema is served from somewhere else — a generic host, a code repository, another company's domain. Those are the entries worth a second look, and they're the ones the map is built to make visible.

#If you publish a UCP extension

Authority binding is easy to pass — you just have to mean it:

1. Use your own reverse-DNS namespace for anything you define. com.yourcompany.*, not dev.ucp.* (that's reserved) and not someone else's domain.
2. Serve your schema URL from your own authority domain. If your namespace is com.yourcompany.rewards, host the schema on yourcompany.com (or a subdomain). This is the single most common thing to get right — a schema published on a generic host will fail the binding even when everything else is perfect.
3. Declare a schema on every capability. The spec now makes it mandatory on business-profile capability declarations; it's what lets agents — and validators — reason about your contract at all.

You can check all of this in seconds by pasting your manifest into the UCP Validator, which now flags each capability as authority-bound or off-authority as you go.

#Measurement, not gatekeeping

A closing note on where we sit. Authority binding is a rule the spec defines — we didn't invent it, and we don't enforce it. What we do is run it, neutrally and deterministically, across the ecosystem, and publish what we see in aggregate. Validate what exists against the published rules; index it completely; don't pick winners. Provenance is precisely what lets a neutral party do that trustworthily — you can verify a name belongs to its owner without making any claim about whether you like the owner.

As UCP grows and more of agentic commerce gets built inside it, that outside-in conformance layer grows with it — and authority binding is the foundation the whole thing rests on. Explore it on the vendor & extension map, or read the rest of the protocol data.

#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 and live adoption stats, and track the spec as it evolves so you don't have to. Authority binding is exactly the kind of deterministic, outside-in check that proves an extension is honestly bound to the party that claims it — and lets a neutral third party say so without picking winners.

• Check your store: ucpchecker.com/check
• Grade it (UCP Score): ucpchecker.com/score
• See the map: ucpchecker.com/vendors
• Get notified on changes: ucpchecker.com/alerts

#Sources

• The rule: PR #530 — Define namespace authority binding + broaden RDNS grammar
• Core concepts: Namespace Governance in the UCP specification
• The grammar: reverse_domain_name schema
• Related: What Is a UCP Namespace? · The UCP Location capability