A UCP profile tells an agent what a business can do. It doesn't say who the business is, and an agent can only find it if it already knows the right domain. On 12 and 13 October, Greg Smith, Amazon's member of the UCP Tech Council, filed three linked RFCs to fix that: a Hosted Business Directory (#937), Business Identity (#939) and Capability Event Webhooks (#938).

All three are proposals, labelled for Tech Council review, with no comments yet. Together they answer a question every agent builder hits sooner or later: when a barber's website is on one domain and its booking runs on a platform, how does an agent find the right profile, and how does it know the two belong together? This post covers what each RFC proposes and what it would mean for platforms, businesses and agents.

#The problem: a profile can only be found from its own domain

Today a UCP profile lives at /.well-known/ucp on a business's origin. That works for a retailer with one domain. It breaks down in three common cases the directory RFC sets out:

• Small businesses on a platform. Most keep a marketing site on their own domain, while "appointments, online ordering, menus, and card processing" run on a platform such as Square or Incentivio. The platform can host a profile on a tenant address it manages, but "outside platforms have no way to discover or enumerate these tenant origins".
• Multi-brand groups. A parent company running several brands publishes a profile per brand, with nothing linking them to the parent.
• Multi-region storefronts. A site with /us and /ca paths can't publish a profile on a path, because well-known URIs only exist at an origin's root (RFC 8615). Each region needs its own origin.

There's a second gap. A profile's services[].endpoint can point at any HTTPS URL, including on another domain. In the RFC's words, nothing proves "the operator of api.pos-host.example authorized brand.example to route traffic to that store endpoint."

That isn't an edge case. In a light check of ten profiles from our census on the two most common platforms, every one that loaded (nine) pointed its service endpoints at the platform's own domain (myshopify.com or wixapis.com), not the store's. That's how hosted UCP works today, and it works. What the protocol lacks is a standard way for the platform to confirm the relationship.

#RFC #937: Hosted Business Directory

A UCP business directory is a capability, dev.ucp.common.directory, that lets a platform or parent company publish an authenticated list of the business profiles it serves. There's no new kind of profile: any origin becomes a host by declaring the capability in its normal /.well-known/ucp.

A consumer, such as an agent platform, calls list_profiles (POST /profiles/list over REST). The first call returns a paged snapshot. The last page carries a sync_cursor, and later calls with it return only what changed, including removals:

{
  "profiles": [
    { "profile": "https://joes-pizza.pos-host.example/.well-known/ucp", "status": "active", "updated_at": "2026-09-20T18:00:00Z" },
    { "profile": "https://old-bakery.pos-host.example/.well-known/ucp", "status": "removed", "updated_at": "2026-09-21T09:30:00Z" }
  ],
  "pagination": { "has_next_page": false },
  "sync_cursor": "s_9c41"
}

Entries are pointers. The consumer still fetches each profile, and the profile stays the source of truth. A host must honour a cursor for at least seven days; after that the consumer starts again from a snapshot.

#Not a public list

The directory is deliberately private. A host "MUST authenticate the consumer, using signed UCP requests" and applies each merchant's opt-in choices about who may list it. The RFC is direct about why: platforms "will not publish an unauthenticated, public list of their entire merchant base", which would expose client lists to competitors and signal churn. It rejects a static /.well-known/ucp-directory file and a shared central registry for the same reasons.

So the directory is a commercial channel between a platform and the agent surfaces it chooses to work with, not a public index.

#Two-way binding

The core security idea is that both sides must name each other. A business profile gains an optional directories[] list next to keys[]:

"directories": [
  "https://pos-host.example/.well-known/ucp",
  "https://downtown-merchants.example/.well-known/ucp"
]

A listing only counts if the business names the host there and the host lists the business as active. That blocks a host from claiming businesses it doesn't serve, and a stray domain from pointing its endpoints at another merchant's store. The RFC compares it to ads.txt and sellers.json, and Digital Asset Links, where both parties also vouch for each other.

The directory also fills a gap the catalog feed draft left open. The Bulk Product Discovery charter (#682) listed "business discovery (which businesses exist / seller directory)" as out of scope and "deferred to a future RFC". This is that RFC.

#RFC #939: Business Identity

UCP Business Identity is a proposed capability, dev.ucp.common.business, that says who a business is: its name, logo, website and business category. As the RFC puts it, the profile states what a business can do and how to check its signatures, "but nothing in the profile states who the business is."

"dev.ucp.common.business": [{
  "version": "2026-08-25",
  "config": {
    "name": "Joe's Pizza",
    "media": [
      { "type": "image", "role": "logo", "url": "https://cdn.pos-host.example/joes/logo.png" }
    ],
    "links": [
      { "type": "website", "url": "https://joespizza.example" }
    ],
    "categories": [
      { "taxonomy": "mcc", "value": "5812" },
      { "taxonomy": "merchant", "value": "Pizza restaurant" }
    ]
  }
}]

The details:

• It reuses existing types. media gains an optional role (logo, cover), building on the media type that recently gained video and 3D. links gains a website type alongside the existing policy links.
• Categories use standard taxonomies: merchant category codes (ISO 18245), NAICS, ISIC, or a free-text label.
• The website link binds a profile to its storefront. A profile on joes-pizza.pos-host.example can say its customer-facing site is joespizza.example. The directory RFC says that link is trusted only if its origin matches the profile's own, or a verified directory's.
• It's separate from Location. Business identity describes the brand; dev.ucp.common.location.* describes physical branches, their hours and addresses. An online-only shop uses the first without the second.
• Verticals can extend it. Because it's a capability, a dining or services spec could add cuisines or service types through extends. That links it to the proposed Local Services council and the Food council's work.

Open questions for the council include the name (business, business_identity or organization) and whether to add a description field now.

#RFC #938: Capability Event Webhooks

Today only orders can push updates in UCP; everything else is polled. The third RFC lets any capability declare events named {capability}:{name}, such as dev.ucp.common.location.lookup:updated. A platform subscribes in its own profile by adding a webhook block (a URL and the events it wants) to that capability's config.

The first use is store hours. When a restaurant adds an emergency closure, platforms listing it currently keep showing it open until they next poll. With the RFC, the business sends a short signed notice ("location castro changed: exception_hours") and the platform reads the current state. For shared data like locations, events stay "thin": identifiers and a hint, never the content, so access checks still apply.

It ties the three together. Directory changes (dev.ucp.common.directory:added and :removed) are events of this kind. A host may also treat a signed list_profiles call as the request that subscribes a consumer to events from every business it lists, so nobody has to subscribe to 100,000 tenants one by one. Order webhooks would move onto the same scheme, with the old webhook_url deprecated.

#What it means

For commerce platforms (POS, booking, ordering, store builders): the directory is a way to make every opted-in merchant discoverable to chosen agent platforms through one endpoint, while keeping control of who sees the list. The cost is running a signed endpoint and a changefeed.

For businesses on a platform: nothing to build yourself. If these land, your platform would handle the directory entry and the binding, and you'd mainly choose which agent platforms can list you. Your name, logo and website would travel with your profile.

For multi-brand and multi-region companies: a standard way to group brand and country profiles under one parent, and to say which storefront each profile represents.

For agent builders: a way to find businesses beyond the domains you already know, check that endpoints really belong to the business, show a name and logo, and get pushed updates instead of polling.

#What we'll watch

• The Tech Council's reaction, starting with the RFCs' own open questions: a dedicated host profile versus a capability, a fixed seven-day cursor, and bulk webhook subscriptions.
• How two-way binding applies to the many profiles that already point endpoints at their platform's domain without naming a directory. The RFCs don't spell out a migration path, so we'll watch the review.
• Whether the platforms that host most UCP profiles today take part in the review.
• Whether business identity merges first. It's the smallest of the three and stands on its own.

Nothing in the RFCs says when, or whether, Amazon itself would implement them.

#FAQ

What is a UCP business directory? A proposed capability, dev.ucp.common.directory, that lets a platform or parent company publish an authenticated, per-consumer list of the UCP profiles it hosts, with a feed of changes. It was proposed in RFC #937 on 12 October 2026.

Is the UCP business directory public? No. The host must authenticate each consumer with signed requests and respects each merchant's choices about who can list it. The RFC rules out a public file or a shared central registry.

What is UCP Business Identity? A proposed capability, dev.ucp.common.business, that adds a business's name, logo, website and categories (such as merchant category codes) to its UCP profile. It's RFC #939.

Who proposed these RFCs? Greg Smith, Amazon's member of the UCP Tech Council, filed all three on 12 and 13 October 2026.

How does a UCP agent find a business today? By fetching /.well-known/ucp on a domain it already knows. There's no standard way to list the businesses a platform hosts; the directory RFC proposes one.

Can UCP send webhooks for anything other than orders? Not yet. RFC #938 proposes capability events for any capability, starting with store locations and hours.

Do businesses need to do anything now? No. All three are proposals under review and could change.

#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.

#Sources

• Issue #937: [RFC] Hosted Business Directory, UCP GitHub, filed 12 October 2026, open (Tech Council review)
• PR #938: [RFC] Capability Event Webhooks, UCP GitHub, opened 13 October 2026, open
• PR #939: [RFC] Business Identity, UCP GitHub, opened 13 October 2026, open
• Issue #682: Bulk Product Discovery DWG charter, UCP GitHub
• UCP announcements: Technical Committee Expansion, UCP GitHub, 24 April 2026 (lists Greg Smith, Amazon)
• RFC 8615: Well-Known URIs, IETF
• UCP Checker light check of ten profiles on the two most common platforms, 13 October 2026

Related coverage: UCP Tech Council Expands · UCP Gets a Product Feed · UCP Local Services · Video, 3D and Image Variants in UCP