index

Resolver and Actions

The resolver package is intentionally small. resolveVerifiedPayload assumes the signed payload has already passed signature verification and any app policy checks. Its job is to map a known signed payload shape into a demo action result.

Action model

The protocol type allows experience.open, campaign.attribute, offer.claim, and ticket.verify. The current resolver has explicit demo behavior for experience.open, ticket.verify, and titled custom payloads. Other actions can still be represented in signed payloads, but unsupported bodies return an explicit unsupported result.

Resolution flow

yes yes no no yes no yes no Already-verified signed payload ticket.verify? Known ticket fixture? Known or custom experience? Has title? Return action result Return unsupported reason

Product integration

@lss/resolver exposes boring, explicit outcomes: experience.open, ticket.verify, manifest.resolve, or unsupported. It does not perform network lookup, signature verification, expiry checks, issuer registry checks, or replay prevention. Those checks must happen before or around resolver usage.

Future production controls

Production needs issuer registry, key rotation, revocation, replay policy, rate limits, and abuse controls. The docs should keep those future controls visible without pretending the prototype already solves every operational problem.