WebTigers/TigerVendor

The vendor trust anchor for WebTigers as a paid-module seller (see tiger-core MARKETPLACE.md §3). A buyer's Module Manager reads tigervendor.json to pin the Ed25519 public key that WebTigers signs its released artifacts + license verdicts with, and the api_base (license authority) where verify + download happen. Distinct from WebTigers/TigerVendors (plural) — that's the free Directory catalog.

What a buyer does with this

1. Fetches this manifest and validates it — an https api_base and a real 32-byte Ed25519 key are both required, or the anchor is refused outright.
2. Shows a consent gate with the owner, the repo, and the key fingerprint — "this can serve code that runs on your server; add only if you trust it."
3. Pins the key on confirm. From then on, artifacts and license verdicts are verified against it.

Why the key must not change casually

A silent public_key change is indistinguishable from a repo takeover, so the client treats it as one: Tiger_License_Vendor::connect() returns changed: true against an existing pin, and the buyer is asked to re-consent. Rotating the key is therefore a deliberate, announced act — not routine maintenance — and it invalidates the signatures on every already-published artifact until they are re-signed.

Current anchor

Production, live since 2026-09-07:

Authority	https://webtigers.com/shop/authority
Catalog	https://webtigers.com/marketplace/feed
Key	the tigerpass-authority-prod public half

The authority answers POST /verify (a signed, short-TTL verdict) and POST /download (a short-lived signed CDN URL for an entitled buyer; 402 otherwise). It never proxies artifact bytes, and the seller's GitHub token never leaves that box.

(Previously this pointed at the dev-com bring-up instance with that host's signing key. Anyone who pinned the old anchor will be asked to re-consent — that is the takeover check working, not a fault.)