Business Verification Extension - Trust Signals for Agentic Commerce

[captjt]

I have been thinking about how best to leverage UCP as it would help facilitate agentic commerce between buyers and sellers. One core foundation I feel is still lacking in e-commerce as a whole is: as a buyer, how do I trust that I am buying from a reputable merchant/brand/etc.?

Today, trust signals are fragmented—marketplaces have their own seller verification badges, payment processors do their own KYB checks, and none of this information flows to the buyer or their agent in a standardized way. When an AI agent is shopping on my behalf, it has no protocol-level way to answer "should I trust this merchant?"

I believe UCP is well-positioned to solve this with a Business Verification extension, and I'd like to propose one for discussion.

Summary

This proposal introduces a Business Verification Extension for UCP that enables platforms and AI agents to evaluate merchant legitimacy through standardized trust signals. The extension provides:

• Assertion-based trust signals that convey verified facts without exposing PII
• Trust framework model with defined assurance levels
• Optional cryptographic credentials (SD-JWT Verifiable Credentials)
• Optional immutable anchoring (blockchain or other mechanisms)
• Pluggable architecture for verification providers, anchor types, and proof mechanisms

Problem Statement

As agentic commerce grows, AI agents need to make autonomous purchasing decisions on behalf of users. A critical question these agents must answer is: "Can I trust this merchant?"

Current approaches have limitations:

1. No standardized trust signals: Agents have no protocol-level way to evaluate merchant legitimacy
2. PII exposure risks: Transmitting legal names, tax IDs, and registration numbers through commerce flows creates privacy and compliance concerns
3. Platform-specific verification: Each marketplace implements its own verification, creating fragmentation
4. No cryptographic verifiability: Claims about verification status cannot be independently verified
5. No immutable audit trail: Verification claims can be disputed without tamper-evident proof

Proposed Solution

A comprehensive Business Verification extension with the following components:

1. Assertion-Based Trust Model

Instead of transmitting PII, the protocol transmits assertions (verified facts):

{
    "assertions": [
        "legal_entity_exists",
        "registration_valid",
        "registration_jurisdiction:US",
        "address_verified",
        "principals_verified",
        "operational_years:3+"
    ]
}

Core Assertions:

Assertion	Description
legal_entity_exists	Business is a verified legal entity
registration_valid	Business registration is current and valid
address_verified	Physical/registered address was verified
website_verified	Domain ownership confirmed
email_verified	Business email domain verified
phone_verified	Business phone number verified
principals_verified	Officers/directors identity verified

Parameterized Assertions: registration_jurisdiction:US, operational_years:3+, compliance:pci_dss

Custom Assertions: Provider-specific using reverse-domain naming (e.g., com.dnb.paydex:80+)

2. Trust Framework & Assurance Levels

Verifications operate under explicit trust frameworks with defined assurance levels:

{
    "trust_framework": "dev.ucp.kyb_v1",
    "assurance_level": "enhanced"
}

Proposed dev.ucp.kyb_v1 Levels:

Level	Required Assertions	Use Case
basic	legal_entity_exists, website_verified	Low-value transactions
standard	+ registration_valid, address_verified	Standard e-commerce
enhanced	+ principals_verified	High-value, B2B
premium	+ ongoing monitoring	Regulated industries

3. Verification Providers

Third-party providers issue verification credentials:

{
    "provider": {
        "id": "com.trustplatform",
        "name": "TrustPlatform Inc.",
        "did": "did:web:trustplatform.example.com"
    }
}

Platforms decide which providers they trust, similar to payment handlers.

4. Optional Cryptographic Credentials

SD-JWT Verifiable Credentials provide cryptographic proof of assertions:

• Contains assertions (not PII)
• Cryptographically signed by provider
• Supports selective disclosure
• Supports key binding for holder authentication

5. Optional Immutable Anchoring

For high-trust scenarios, verification can be anchored to immutable stores:

Proposed Anchor Types:

Type	Description	Use Case
hedera_hcs	Hedera Consensus Service	Enterprise, regulated industries
ethereum	Ethereum/EVM blockchain	Web3-native businesses
bitcoin_ots	Bitcoin via OpenTimestamps	Maximum decentralization
signature_only	No external anchor	Quick verification, low-risk
Custom	Reverse-domain naming	Proprietary systems

Anchors can include Merkle proofs for batched verification scenarios.

Example

Checkout Response with Business Verification:

{
    "id": "chk_abc123",
    "status": "ready_for_complete",
    "business_verification": {
        "status": "verified",
        "trust_framework": "dev.ucp.kyb_v1",
        "assurance_level": "enhanced",
        "provider": {
            "id": "com.trustplatform",
            "name": "TrustPlatform Inc."
        },
        "assertions": [
            "legal_entity_exists",
            "registration_valid",
            "registration_jurisdiction:US",
            "address_verified",
            "website_verified",
            "principals_verified",
            "operational_years:3+"
        ],
        "verified_at": "2024-01-15T10:30:00Z",
        "expires_at": "2025-01-15T10:30:00Z"
    }
}

Design Principles

Principle	Rationale
Privacy by default	Assertions convey trust without exposing PII
Progressive enhancement	Credentials and anchors optional; low barrier to entry
Provider agnostic	Multiple verification providers can participate
Anchor agnostic	Pluggable anchor types via reverse-domain naming
Trust framework model	Aligns with OpenID Identity Assurance patterns
Agent optimized	Designed for programmatic trust evaluation

Relationship to Existing Standards

Standard	Relationship
OpenID Connect Identity Assurance	Adopts trust_framework + assurance_level pattern; focuses on entity (not individual) verification
GLEIF vLEI	Complementary; vLEI can be expressed as assertion (org.gleif.lei:verified)
W3C Verifiable Credentials	SD-JWT format aligns with VC ecosystem
ISO/IEC 29115	Assurance levels loosely map to LoA1-4

Use Cases

1. Agentic Commerce: AI agent evaluates assertions to decide whether to proceed with purchase
2. Marketplace Onboarding: Platform requires minimum assurance level for sellers
3. High-Value B2B: Procurement system requires enhanced verification with credential proof
4. Regulatory Compliance: Financial platform requires anchored proof for. audit trails

Open Questions

1. Assertion vocabulary: Are the proposed core assertions sufficient? What's missing?
2. Trust framework governance: Should UCP formally define dev.ucp.kyb_v1 requirements, or allow providers to define frameworks?
3. Cross-framework interoperability: How should we handle merchants verified under different frameworks (eIDAS, GLEIF)?
4. Credential format: Is SD-JWT the right default? Should we support multiple formats?
5. Anchor types: Which anchor types should be standardized vs. left as extensions?
6. Discovery: How should businesses advertise verification capabilities and status?
7. Platform requirements: How should platforms express their verification requirements to merchants?

---

I would love to get feedback on the overall potential architecture and how this might fit into existing UCP capabilities.

If there's interest, I'm happy to collaborate on developing a detailed specification.

[douglasborthwick-crypto]

Great proposal. The assertion-based model and pluggable anchor architecture align well with what we've been building at InsumerAPI.

We provide on-chain verification across 31 EVM chains (Ethereum, Base, Polygon, Arbitrum, etc.) through a single REST endpoint (POST /v1/attest) that returns ECDSA-signed boolean attestations, e.g. "this wallet holds merchant X's loyalty token." No PII is exposed, just a cryptographic proof of on-chain state.

In the context of this extension, InsumerAPI could function as a verification provider for token-based trust signals. For example, a merchant could issue loyalty or membership tokens on-chain, and an AI agent could verify a customer's holdings at checkout via our API before applying a discount, fitting naturally into the assertions model you've described.

We already have an MCP server (16 tools, published to the Official MCP Registry), a LangChain integration, and an OpenAPI spec, so agent integration is straightforward.

Happy to collaborate on how on-chain token verification could map to the assertion vocabulary and trust framework model here. Specifically re: Open Question #1, we'd suggest adding assertions like token_holder_verified and on_chain_attestation to the core set for Web3-native trust signals.

[realpercivallabs]

Strong proposal. The assertion-based model is the right architecture for merchant verification. I want to raise a related problem from the other direction: agent verification.

Your proposal answers "Can I trust this merchant?" for the agent. The inverse question is equally important: "Can I trust this agent?" for the merchant.

As agentic commerce scales, merchants will receive requests from thousands of agents with varying levels of reliability. A merchant needs to distinguish between an agent with a proven track record of completing transactions cleanly and one that was created yesterday, has no history, and is accessing data it didn't declare it would need.

We've built an open spec for this called MCP-T (Model Context Protocol, Trust Extension) that approaches agent trust with a similar philosophy to what you're proposing for merchants:

Shared design principles:

• Assertion-based (trust scores are dimensional, not binary)
• Provider-agnostic (any trust provider can compute scores using any methodology)
• Cryptographically signed (Ed25519, ES256, ES384)
• Progressive enhancement (4 conformance levels, from read-only queries to zero-knowledge proofs)
• Privacy-aware (zero-knowledge trust proofs let agents prove they meet a threshold without revealing their score)

Where MCP-T adds to the picture:

Your Proposal (Merchant Trust)	MCP-T (Agent Trust)
Assertions: legal_entity_exists, registration_valid	Dimensions: verification, tenure, commitment
Assurance levels: basic, standard, enhanced, premium	Composite scores: 0-1000 with per-dimension breakdown
Verification providers issue credentials	Trust providers compute and publish scores
SD-JWT Verifiable Credentials	Signed trust scores + trust events (compatible with W3C VC wrapping)

v0.2.0 additions particularly relevant to commerce:

• behavioral_fidelity dimension: does the agent do what it says it does? Scored from runtime behavioral traces.
• Bid events: agents submit bids on contracts with optional simulation evidence, creating an auditable record.
• Trust-tiered checkout: merchants set thresholds per action (browse, cart, checkout, high-value) in their UCP profile.

The two extensions would work together naturally. A merchant's UCP profile could express both: "I require enhanced business verification for my own credibility" (your extension) AND "I require agents with composite >= 600 and behavioral_fidelity >= 700 to reach checkout" (MCP-T).

Integration guide for UCP: MCP-T + UCP Integration Guide

Full spec (CC-BY-4.0): https://github.com/Percival-Labs/mcp-t

Re: your Open Question #7 (how should platforms express verification requirements to merchants), MCP-T's threshold model in the UCP profile extension might be a useful pattern. Happy to discuss further.