feat: attestation extension for eligibility claims

[douglasborthwick-crypto]

Description

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

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."
  and specified the sibling map
  pattern
  — attestations keyed by eligibility claim, on the cart/checkout object
  similar to the discount extension

How it works

• 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).

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.

Relationship to #280

This PR and #280 (wallet attestation mechanism type) are complementary but
independent:

• This PR adds an extension to shopping capabilities — where attestation
  data appears in cart/checkout wire format.
• feat: add wallet_attestation mechanism type to identity linking registry #280 adds a mechanism type to identity_linking — how a business
  establishes identity via wallet attestation.

Neither PR depends on the other. When both are present, the mechanism provides
the signed attestation and the extension provides the wire format for attaching
it.

---

Files Changed

File	Change
source/schemas/shopping/attestation.json	New extension schema — attestation map on Cart and Checkout via allOf

Type of change

• New feature (non-breaking change which adds functionality)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• New and existing unit tests pass locally with my changes

[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!

[douglasborthwick-crypto]

Hi @amithanda — just checking in on this one. Is there anything blocking review, or would adding the "TC review" label help get it into the queue? Happy to address any feedback.