ucp 1.0.0

UCP Check v1.0.0

Status

• Version: 1.0.0
• Check identifier: ucp
• Input contract: agent-page-scan-input@1.0.0
• Output contract: agent-check-result@1.0.0
• Scope: site-level Universal Commerce Protocol business profile discovery

Abstract

This check validates the public UCP business profile at /.well-known/ucp. It inspects profile shape, services, capabilities, payment handlers, signing keys, and metadata safety. It does not execute checkout, acquire payment credentials, assert a UCP-Agent profile, or verify live HTTP signatures.

Motivation

UCP lets commerce businesses publish machine-readable capabilities and transport bindings for agentic commerce. A valid profile lets agents discover supported services, payment handlers, and verification keys without scraping human checkout flows.

Normative Model

A UCP business profile is JSON served from /.well-known/ucp.

The document should include a top-level ucp object. The profile model includes:

• ucp.version
• ucp.supported_versions
• ucp.services
• ucp.capabilities
• ucp.payment_handlers
• top-level signing_keys

The draft profile shape requires ucp.version, ucp.services, and ucp.payment_handlers. ucp.capabilities is optional unless the site claims specific UCP capabilities, extensions, or agentic commerce workflows that should be represented there.

Applicability

The check applies when:

• /.well-known/ucp exists.
• the page, headers, docs, or metadata mention Universal Commerce Protocol, UCP, /.well-known/ucp, UCP-Agent, or dev.ucp.*.
• the site advertises agentic commerce, autonomous checkout, UCP checkout/cart/catalog/order workflows, or UCP payment handlers.

The check is not applicable when no UCP or agentic-commerce signal is visible. Ordinary human checkout or unrelated payment metadata is not enough by itself.

Pass Criteria

The check passes when:

• /.well-known/ucp returns HTTP 2xx.
• the response is JSON-compatible and parseable.
• the profile has a top-level ucp object.
• ucp.version is present.
• ucp.services is object-shaped.
• ucp.payment_handlers is object-shaped.
• service entries use reverse-domain namespaces.
• service entries declare version, spec, and recognized transport.
• REST, MCP, and A2A service entries declare an HTTPS endpoint.
• embedded service entries may omit endpoint because the callable surface is embedded in the profile or schema.
• REST, MCP, and embedded services declare schema metadata.
• declared URLs use HTTPS.
• capability entries, when present, declare version, spec, and schema.
• dev.ucp.* capability spec and schema URLs point to ucp.dev.
• signing keys, when present, are public JWK-like entries without private material.
• public profile metadata does not expose secrets, raw payment data, or private endpoints.

Warning Criteria

The check warns when:

• UCP-like or agentic-commerce signals exist, but active UCP support is not clearly claimed and /.well-known/ucp is missing.
• ucp.capabilities is absent even though the site claims specific UCP capabilities, extensions, or agentic commerce workflows.
• an endpoint has a trailing slash.
• a stable deployment uses "draft" as the profile version.
• payment handler entries omit useful optional metadata such as available instruments or config.
• payment handler available_instruments entries are present but not string or object-shaped declarations.
• signing keys are absent from a published UCP profile.

A valid minimal profile is not warned solely because ucp.capabilities is absent.

Failure Criteria

The check fails when:

• active UCP support is explicitly claimed, but /.well-known/ucp is missing, unreachable, non-JSON, or malformed.
• the profile lacks a top-level ucp object.
• ucp.version is missing.
• ucp.services is missing or not an object.
• ucp.payment_handlers is missing or not an object.
• service entries omit required fields.
• service transports are outside rest, mcp, a2a, or embedded.
• REST, MCP, or A2A service entries omit endpoint.
• REST, MCP, or embedded service entries omit required schema metadata.
• profile URLs use non-HTTPS schemes.
• capability names do not use reverse-domain naming.
• dev.ucp.* capability spec or schema URLs do not point to ucp.dev.
• public metadata leaks credentials, private keys, raw payment card-like data, bearer tokens, localhost/private-network URLs, or unsafe endpoints.

Evidence Model

Evidence includes:

• applicability signals
• /.well-known/ucp status, content type, and parse state
• ucp.version
• stable or draft version classification
• supported_versions count and URL validation
• service count and transport counts
• service namespace, entry path, transport, endpoint, spec, and schema summaries
• capability count, entry paths, and extension counts
• payment handler count, entry paths, available instrument counts, and declared instrument types
• signing key count, entry paths, and public JWK shape summary
• security flags for secrets, raw payment data, private endpoints, or unsafe URLs

Validation issues and warnings should name the exact entry path, such as ucp.services.dev.ucp.shopping[0], ucp.capabilities.dev.ucp.shopping.checkout[1], ucp.payment_handlers.com.example.processor[0], or signing_keys[0], so profiles with multiple entries can be repaired precisely.

Evidence must not include full profile bodies, payment credentials, raw card data, bearer tokens, private keys, cookies, or full signing key coordinates.

Validation And Scoring Steps

• applicability (0.10): detect UCP or agentic-commerce signals.
• profile-fetch (0.15): fetch /.well-known/ucp and validate status, content type, and JSON parseability.
• profile-shape (0.20): validate top-level ucp, version, services, payment handlers, and supported versions.
• services (0.15): validate service namespaces, required fields, transports, non-embedded endpoints, and schema URLs.
• capabilities (0.15): validate capability namespaces, required fields, URLs, and extension references.
• payment-handlers (0.10): validate payment handler metadata and declared available instruments or config.
• signing-keys (0.05): validate public JWK-like signing keys when present.
• security-review (0.10): flag credentials, raw payment data, private endpoints, and unsafe URL schemes.

Standard Behavior

If no UCP or agentic-commerce signal is visible, the result is not_applicable.

If UCP-like signals are visible but active UCP support is not clearly claimed and /.well-known/ucp is missing, the result is warning.

If active UCP support is explicitly claimed and /.well-known/ucp is missing, unreachable, non-JSON, or malformed, the result is fail.

If /.well-known/ucp exists and has a valid UCP profile shape, the result passes discovery validation.

If the profile is valid but incomplete for claimed workflows, the result warns.

If a published UCP profile omits signing_keys, the signing-key step warns rather than becoming not_applicable.

If the profile is malformed or unsafe, the result fails.

Non-Standard And Real-World Behavior

Stable UCP profiles use date-based versions such as YYYY-MM-DD. Draft deployments may use "draft" while testing draft capabilities.

Deployments may expose only one transport family, such as REST, MCP, A2A, or embedded. A single-transport profile can pass when its declarations are internally consistent. Embedded service transports do not need an endpoint; REST, MCP, and A2A transports do.

Some UCP behavior happens during runtime negotiation. This check validates public discovery only.

Payment handler validation is static. It records declared payment forms from available_instruments and handler metadata, but it does not prove the business can complete a live payment or that a handler will authorize a real checkout.

Non-Goals And Limitations

This check does not:

• execute checkout
• acquire or submit payment credentials
• prove live payment acceptance or settlement
• send UCP-Agent
• verify live HTTP signatures
• fetch every schema
• validate every OpenAPI, OpenRPC, A2A, or MCP detail
• validate AP2 mandates or payment provider token formats
• treat ordinary human checkout as UCP support
• treat x402, MPP, ACP, or generic payment metadata as UCP support

References

• ucp.dev/specification/overview
• ucp.dev/draft/specification/overview
• ucp.dev/specification/signatures
• www.rfc-editor.org/rfc/rfc9421
• www.rfc-editor.org/rfc/rfc9530
• www.rfc-editor.org/rfc/rfc8941
• www.rfc-editor.org/rfc/rfc7517

ucp v1.0.0 Changelog

• Validates /.well-known/ucp as a UCP business profile with a top-level ucp object.
• Checks profile version, services, payment handlers, optional capabilities, supported versions, and signing keys.
• Treats absent optional capabilities as acceptable unless specific UCP workflows or extensions are claimed.
• Distinguishes UCP evidence from ordinary human checkout and unrelated payment protocol metadata.
• Flags unsafe public profile metadata such as secrets, private endpoints, private key material, and raw payment card-like data.
• Adds exact entry paths to service, capability, payment-handler, and signing-key validation issues.
• Allows embedded service transports to omit endpoint; requires endpoints for REST, MCP, and A2A service transports.
• Warns when a published UCP profile does not include public signing_keys.