feat: attestation extension for eligibility claims

[douglasborthwick-crypto]

Summary

Adds a capability extension that complements eligibility (#250) with cryptographic attestation proofs for non-instrument claims (token holdings, on-chain credentials, membership status).

• Platforms relay signed attestations from third-party verifiers alongside context.eligibility claims
• Businesses verify offline: fetch JWKS from provider_jwks, select key by kid, verify sig over payload
• payload is an opaque passthrough of the provider's signed object — no transformation, so signature verification works end-to-end
• expires_at lives outside payload because it is not covered by the signature — the Business checks this independently

Follows the discount extension pattern (allOf on Cart and Checkout, sibling map keyed by reverse-domain eligibility claims).

Context

Discussed and invited in #203 and #250:

• feat!: signals for authorization & abuse  #203: igrigorik established the provider_jwks / kid / payload / sig attestation pattern in the signals spec
• feat: eligibility claims & verification contract #250: igrigorik confirmed attestation as "a great candidate for a capability extension that complements eligibility. Additive and non-breaking." He also specified the sibling map pattern — attestations keyed by eligibility claim, on the cart/checkout object similar to the discount extension

Wire format example

{
  "context": {
    "eligibility": ["com.example.token_holder"]
  },
  "attestations": {
    "com.example.token_holder": {
      "provider_jwks": "https://example.com/.well-known/jwks.json",
      "kid": "example-key-2026-01",
      "payload": {
        "id": "att-7c3e9f",
        "pass": true,
        "results": ["..."],
        "attestedAt": "2026-03-13T19:20:32.530Z"
      },
      "sig": "base64...",
      "expires_at": "2026-03-13T19:50:32.530Z"
    }
  }
}

Verification flow

1. Business receives checkout with context.eligibility claim + matching attestations entry
2. Fetches JWKS from provider_jwks, selects key matching kid
3. Verifies sig over the payload (platforms must preserve the provider's original serialization)
4. Checks expires_at hasn't passed
5. Reads payload.pass to confirm the claim is met

No callback to the Platform or attestation provider required — fully offline.

Test plan

• Schema validates against JSON Schema Draft 2020-12
• $ref to types/reverse_domain_name.json resolves correctly
• allOf composition with cart.json and checkout.json produces valid combined schemas
• Extension is additive — removing it leaves Cart/Checkout unchanged

🤖 Generated with Claude Code

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[douglasborthwick-crypto]

@googlebot I signed it!