UCPReady — spec-complete WooCommerce implementation, live on 40k+ SKU store

[zologic]

Hi UCP team,

Sharing what we've built: UCPReady is a WooCommerce plugin that implements the full UCP spec. It's live in production at [houseofparfum.nl](https://houseofparfum.nl) — 40,000+ SKUs.

Live discovery endpoint: https://houseofparfum.nl/.well-known/ucp

---

What's implemented

• REST, MCP (14 tools), and Embedded Checkout transports
• Full checkout state machine with session layer (no order pollution on explore)
• Idempotency store with 24h TTL, 409 on key reuse — complete_checkout / cancel_checkout enforce idempotency-key via MCP
• dev.ucp.common.identity_linking — full OAuth 2.0 Authorization Code + PKCE S256, RFC 7591 dynamic client registration, RFC 7009 cascade revocation, RFC 8414 /.well-known/oauth-authorization-server
• Ed25519 detached JWT webhook signing (RFC 7797), signing_keys at root level
• Server-side wallet payment via ucpready_process_payment — complete purchase with no browser redirect
• Eight capabilities in the live manifest including fulfillment with machine-readable config block (allows_multi_destination, allows_method_combinations)

---

Validation

UCP Playground (Ben Fisher): Schema Quality score A (98). During interop testing we also surfaced 4 edge-case bugs in Playground's embedded checkout implementation — all fixed same day.

---

Full write-up

Screenshots of the complete autonomous purchase flow — OAuth consent screen → identity-linked buyer pre-population → wallet debit → WooCommerce order paid, zero human interaction after initial consent:

👉 https://dev.to/zologic/how-i-built-autonomous-ai-purchasing-on-woocommerce-oauth-20-identity-linking-and-wallet-5148

---

Why WooCommerce matters for UCP adoption

WooCommerce powers ~6.5 million active stores. Shopify is already a co-developer of UCP. UCPReady is the path for the other half of the ecommerce long tail — SMBs, independent retailers, niche stores — to become UCP-compatible without custom builds.

Happy to contribute WooCommerce-specific feedback to the TC. Variable product handling, partial payment flows, and multi-destination constraints are areas where real-world implementation at scale reveals gaps worth addressing in the spec.

— Almin Zolotic, [Zologic](https://zologic.nl)

[douglasborthwick-crypto]

Great write-up, Almin — and congrats on the 98 schema quality score.

We built SkyeWoo, a WooCommerce plugin for token-gating and wallet-verified discounts. Merchants set conditions per product (chain, contract address, threshold), customers connect their wallet, and the plugin verifies holdings server-side using cryptographically signed attestations (ES256 JWTs, verifiable offline via JWKS). 30+ chains, multiple wallet types.

Reading your post, the use case that jumped out immediately: token-gated products + autonomous AI agents. A few real scenarios where this matters:

• Wholesale pricing — only show bulk rates to wallets holding ≥$500 in stablecoins. Proof of funds without exposing balances.
• Membership catalogs — gate products behind an NFT access pass. An AI agent with a delegated wallet proves membership automatically.
• Regulated goods — products that require an on-chain credential before they can even be displayed to the buyer.

Right now SkyeWoo's gating is human-interactive — a person clicks "Connect Wallet" in their browser. But gating conditions are already structured data (chain ID, contract, threshold, decimals). If UCPReady exposed extension points for product-level capabilities and checkout preconditions, SkyeWoo could:

1. Publish gating conditions in the UCP manifest — so an AI agent discovers "this product requires ≥100 USDC on Ethereum" in machine-readable form
2. Accept a signed attestation JWT as a checkout precondition — the agent obtains the attestation, presents it at checkout, UCPReady validates it and unlocks the purchase

The agent gets the full loop: discover → verify eligibility → purchase. No human in the middle.

On our side, the verification and JWT validation logic already exists. The bridge would be SkyeWoo hooking into UCPReady's manifest generation and checkout flow — which means the integration depends on UCPReady exposing WordPress filter hooks for other plugins to extend.

Would you be open to collaborating on this? Happy to share more about how the attestation format works and sketch out what the capability definition could look like. If the pattern generalizes, it could be worth proposing as a UCP capability so any commerce plugin can declare eligibility preconditions that AI agents can satisfy programmatically.

[zologic]

I'm actively engaged with the UCP TC right now (submitted a nomination for the TC organisational seat today, nomination window closes April 3). If we sketch a joint capability definition, I can bring it to the TC as a formal proposal. That gives SkyeWoo protocol-level standing, not just a WooCommerce integration.

Two things I'd want to understand from your side:

1. How does the attestation JWT bind to a specific checkout session or buyer identity? If the agent obtains an attestation for wallet X, we need to ensure it can only be used for a checkout linked to that identity — replay attack prevention.
2. Is the gating condition evaluated at create_checkout time, update_checkout, or complete_checkout? The right answer probably depends on whether the condition gates discovery (is this product visible at all?) vs purchase (can this specific buyer complete?).

Happy to jump on a call or continue async. If you can share the attestation JWT format and a sample gating condition object, I can draft what the capability declaration and filter hook interface would look like.

[zologic]

One practical question on the merchant side: POST /v1/ucp/discount requires a merchantId from your registry. Does SkyeWoo handle that registration automatically on plugin activation, or does the merchant need to create an InsumerModel account separately? The answer determines how we surface this in UCPReady's onboarding — ideally it's zero extra steps for the merchant.

[douglasborthwick-crypto]

Absolutely — here's the detail on both questions.

1. JWT binding + replay prevention

The attestation JWT includes these claims (all set server-side, ES256-signed):

Claim	Value	Purpose
sub	wallet address	Binds attestation to a specific wallet
jti	ATST-{random hex}	Unique per attestation — one-time use
iat / exp	issued + 30 min	Time-bounded validity window
conditionHash	SHA-256 of canonical condition JSON	Tamper detection — proves which conditions were evaluated
pass	boolean	Overall result
results[]	per-condition met, chainId, type, label	Granular breakdown

For checkout binding: the sub claim is the wallet address. UCPReady's identity-linking flow already ties a buyer identity to a wallet via OAuth/PKCE. The check would be: does the JWT's sub match the checkout session's linked wallet? If not, reject. The jti prevents replay — each attestation call generates a new random ID, so a JWT can't be reused across sessions. And exp means even a captured JWT is dead after 30 minutes.

Verification is offline — fetch the JWKS from https://api.insumermodel.com/.well-known/jwks.json (cacheable, kid: "insumer-attest-v1", P-256 curve), verify the ES256 signature, check exp and sub. No network call to us at verification time.

2. When is the gate evaluated?

SkyeWoo supports both levels, configurable per product:

• Discovery-level (gate_hide=yes): Product is excluded from catalog queries entirely. Unverified visitors don't see it. In UCP terms, this would mean the product doesn't appear in the manifest until the agent presents a valid attestation.
• Purchase-level (gate_enabled=yes, hide off): Product is visible but unpurchasable. check_purchasable() returns false until the session is verified. In UCP terms, the product appears in the manifest with its gating conditions declared, but create_checkout rejects unless a valid attestation JWT is included.

Most merchants will want the second model for AI agents — the agent needs to see the conditions to know what attestation to obtain. Hidden products are useful for exclusive drops where even the existence of the product is gated.

Sample gating condition object (as stored per product):

{
  "type": "token_balance",
  "contractAddress": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
  "chainId": 1,
  "threshold": 500,
  "decimals": 6,
  "label": "Hold ≥500 USDC on Ethereum"
}

Happy to continue async — this thread is probably the best place to iterate on the capability definition where others can see and contribute.

[douglasborthwick-crypto]

The canonicalization is straightforward:

1. Build the evaluatedCondition object — the exact fields depend on condition type
2. Get keys, sort alphabetically (JavaScript Object.keys().sort() — Unicode code point order)
3. JSON.stringify(evaluatedCondition, sortedKeys) — compact, no whitespace
4. SHA-256 → hex → prefix with 0x

For a token_balance condition, the evaluatedCondition fields are: type, chainId, contractAddress, operator (always "gte" for token_balance), threshold, decimals. For nft_ownership: same but operator is "gt" and threshold is 0 (no decimals).

So the USDC example from earlier canonicalizes to:

{"chainId":1,"contractAddress":"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48","decimals":6,"operator":"gte","threshold":500,"type":"token_balance"}

In PHP that's: hash('sha256', json_encode($evaluatedCondition, JSON_UNESCAPED_SLASHES)) after ksort($evaluatedCondition). Prefix the result with 0x and compare.

The evaluatedCondition is also returned in the API response alongside the conditionHash (inside each results[] entry), so you can cross-check both sides during development.

Your capability definition looks right. The eligibility block on catalog items with gate_level + conditions + attestation_provider is exactly how we'd want this surfaced. Happy to review the filter hook interface whenever you have a draft.

[zologic]

Perfect — that's exactly what's needed. The PHP implementation is straightforward:

/**
 * Verify conditionHash claim from InsumerAPI attestation JWT.
 *
 * @param array $evaluated_condition The evaluatedCondition from results[].
 * @param string $claimed_hash       The conditionHash claim from the JWT payload.
 * @return bool True if hash matches.
 */
private function verify_condition_hash( array $evaluated_condition, string $claimed_hash ): bool {
    ksort( $evaluated_condition ); // alphabetical key sort, Unicode code point order
    $canonical = wp_json_encode( $evaluated_condition, JSON_UNESCAPED_SLASHES );
    $computed  = '0x' . hash( 'sha256', $canonical );
    return hash_equals( $computed, $claimed_hash ); // timing-safe
}

hash_equals for timing-safe comparison — standard practice for any credential validation in WordPress. The evaluatedCondition cross-check from results[] during development is a useful sanity check, noted.

---

I have everything needed to draft the full integration now:

1. ucpready_checkout_preconditions filter — validates sub, jti, exp, conditionHash offline via cached JWKS
2. ucpready_manifest_capabilities filter — SkyeWoo publishes dev.ucp.shopping.eligibility into /.well-known/ucp
3. ProductAdapter — surfaces eligibility block on products with SkyeWoo conditions configured
4. JWKS cache — WP transient, 24h TTL, keyed by kid

Ready to write the joint Ideas post for the TC. Given the TC nomination window closes April 3 and review is April 10, posting this week gives it maximum visibility during the review period.

Proposed title: Proposal: dev.ucp.shopping.eligibility — Machine-Readable Product Preconditions for Agent Commerce

I'll draft it and share here for your review before posting. Should take a day or two. The proposal will reference your KCP RFC-0004 attestation_url contribution as prior art — same pattern, different protocol surface.

One last thing to confirm for the proposal: are you happy to be credited as co-author on the Ideas post, and should it reference InsumerAPI/SkyeWoo by name as the reference implementation?

[douglasborthwick-crypto]

Yes to both — happy to be co-author, and reference InsumerAPI/SkyeWoo by name as the reference implementation. Looking forward to the draft.

[douglasborthwick-crypto]

Small implementation note on the PHP canonicalization: the one-liner shorthand in #298 — json_encode(ksort($condition), ...) — would hash the string "true" since ksort() returns bool and sorts in place. Your full implementation here in #297 is correct (two statements). Just flagging in case anyone copies the shorthand from the proposal.

[zologic]

Good catch — and thanks for flagging it publicly where anyone reading the proposal will see it.

ksort() sorts the array in place and returns bool, so json_encode(ksort($condition), ...) encodes true not the sorted array. Silent wrong-hash bug. The correct PHP is two statements:

ksort( $evaluated_condition );
$canonical = wp_json_encode( $evaluated_condition, JSON_UNESCAPED_SLASHES );
$computed  = '0x' . hash( 'sha256', $canonical );

Updating the proposal body now.

[douglasborthwick-crypto]

Good question — and the answer is simpler than you might expect: there's no merchant registration step.

SkyeWoo doesn't use POST /v1/ucp/discount or the merchant registry. It uses a different path: conditions are defined per product in WooCommerce (the product editor has a SkyeWoo tab where merchants configure chain, contract, threshold, etc.), and those conditions are sent directly with each verification call. The API evaluates whatever conditions it receives — it doesn't need to know who the merchant is.

So the onboarding is: install plugin → activate license → configure conditions on products. Zero accounts to create on our side, zero registry entries. The SkyeWoo license handles auth and metering at the plugin layer.

For the UCP capability, the same model applies. The gating conditions would live in the WooCommerce product metadata (where they already are) and get surfaced in the UCP manifest. No extra registration, no merchant ID to manage.

[zologic]

That's the right architecture for a WordPress plugin — conditions live in WooCommerce product meta, surfaced dynamically, no external account required. This removes the last adoption friction point.

It also means the capability config in /.well-known/ucp doesn't need a merchantId or registry reference. The attestation_provider URL is sufficient — platforms and agents discover the endpoint from the manifest, read the conditions from the product's eligibility block, call the endpoint with those conditions, and get back a signed JWT. The merchant never leaves WooCommerce.

Revised capability definition:

"dev.ucp.shopping.eligibility": [{
  "version": "2026-03-14",
  "extends": "dev.ucp.shopping.checkout",
  "config": {
    "jwks_uri": "https://api.insumermodel.com/.well-known/jwks.json",
    "supported_condition_types": [
      "token_balance",
      "nft_ownership",
      "eas_attestation",
      "farcaster_id"
    ],
    "precondition_field": "meta.attestation_jwt"
  }
}]

No attestation_endpoint in the manifest-level config — that belongs on the product's eligibility block, since different products could in principle use different attestation providers. The manifest declares the capability exists and how to validate JWTs. The product declares where to get them.

---

Still need the conditionHash canonicalisation method to complete the PHP verification side. Once that's confirmed I'll draft:

1. ucpready_checkout_preconditions filter hook interface
2. ucpready_manifest_capabilities filter hook interface
3. The eligibility block structure in ProductAdapter::to_ucp_format()
4. Joint Ideas post for the TC

That last point — I submitted a TC organisational seat nomination today (window closes April 3: #292). If we can get the Ideas post up before April 3 with both our names on it, it strengthens both the nomination and the proposal's visibility during the review period.