Universal Commerce Protocol: signing keys invalid
UCP_SIGNING_KEYS_INVALID · v2.0
Computed by Scovant Core ≥ 0.10.0 (open source) — pin that version and you get the same verdict.
What it detects
The UCP profile publishes signing keys (the optional top-level keys array) that are not valid public JWKs — an entry lacks kid/kty or its curve members, or carries a private member.
Why it matters
Signing keys are what let an agent verify that a UCP checkout response actually came from the merchant; without valid keys, secure agent-initiated checkout cannot be trusted.
How to fix
- Check the top-level `keys` array of the UCP profile. `keys` is optional; when present, every entry must be a public JWK with `kid` and `kty` — plus `crv`, `x` and `y` for EC keys, `crv` and `x` for OKP keys — and none of the private members (`d`, `p`, `q`, `dp`, `dq`, `qi`, `oth`, `k`). - Generate the signing keypair server-side, publish only the public half in `keys`, and never commit the private key to source control; if a private member was ever published, rotate that key. The older `signing_keys` field is not part of the v2026-08-25 schema. - To rotate, append a new entry with a fresh `kid` and remove the old one only after the rollout window closes, so in-flight verifications don't break. - Verify: parse `/.well-known/ucp`'s `keys` array and confirm every entry is a public JWK as above (RFC 7517 §4 for the full JWK spec; ucp.dev/specification/overview for UCP's usage).
References
Last reviewed: 2026-09-01 · rule v2.0