feat(payment): carry token issuance context through checkout

[prasad-stripe]

Description

TokenCredential currently carries only type and token. That leaves no
standard way to carry the resource binding and participant identity established
during tokenization into checkout.

This change adds optional binding and identity members to
TokenCredential. Existing credentials remain valid. A concrete handler can
require either member when its flow needs it.

The guidance requires Platforms to preserve carried values unchanged,
Businesses to validate binding according to the handler's policy, and
Processors to compare a presented binding with their issuance record. Caller
authentication remains separate and handler-defined. identity continues to be
a participant identifier and must not be accepted as authentication.

Category (Required)

• Core Protocol: Changes to the base communication layer, global context, or breaking refactors. (Requires Technical Council approval)
• Governance/Contributing: Updates to GOVERNANCE.md, CONTRIBUTING.md, or CODEOWNERS. (Requires Governance Council approval)
• Capability: New schemas (Discovery, Cart, etc.) or extensions. (Requires Maintainer approval)
• Documentation: Updates to README, or documentations regarding schema or capabilities. (Requires Maintainer approval)
• Infrastructure: CI/CD, Linters, or build scripts. (Requires DevOps Maintainer approval)
• Maintenance: Version bumps, lockfile updates, or minor bug fixes. (Requires DevOps Maintainer approval)
• SDK: Language-specific SDK updates and releases. (Requires DevOps Maintainer approval)
• Samples / Conformance: Maintaining samples and the conformance suite. (Requires Maintainer approval)
• UCP Schema: Changes to the ucp-schema tool (resolver, linter, validator). (Requires Maintainer approval)
• Community Health (.github): Updates to templates, workflows, or org-level configs. (Requires DevOps Maintainer approval)

Related Issues

• Enhancement Proposal: [Proposal]: Carry token issuance context in token credentials #790
• Follow-up to refactor!: make token binding vertical-agnostic #746
• Participant-identity documentation cleanup: docs: clarify participant identifier in payment handler examples #791

Checklist

• I have followed the Contributing Guide. Enhancement Proposal [Proposal]: Carry token issuance context in token credentials #790 is awaiting approval.
• I have updated the documentation.
• My changes pass all available local linting and formatting checks.
• I have added schema-annotated examples that exercise the new credential shape in CI.
• New and existing unit tests pass locally. The validator contract suite passes 42 tests; two integration cases require the unavailable ucp-schema binary.
• I have updated the relevant JSON schema.
• Pydantic model regeneration is not applicable; this repository has no python_sdk directory or generate_models.sh script.

Screenshots / Logs

No visual change requiring a screenshot.

Local checks:

• git diff --check
• JSON parsing
• markdownlint
• cspell
• validator contract tests: 42 passed; 2 ucp-schema integration cases skipped

[karangoel16]

I think we should separate caller authentication from token binding identity here.

For authentication, access tokens should be sent via Authorization: Bearer <token> at the transport layer. This matches the existing REST auth model and identity-linking guidance.

The identity.access_token field in the tokenization payload appears to mean “the participant/business this payment token is issued to,” not “the caller credential used to authenticate this request.” If so, calling it access_token is confusing and potentially unsafe, because consumers may treat it as an auth credential or copy it into checkout/payment payloads.

Recommendation:

• Keep caller auth in the HTTP Authorization header.
• Keep token/resource binding in the body.
• Rename identity.access_token to a non-secret subject identifier, e.g. business_id, merchant_id, participant_id, or subject.
• If this value is actually secret/auth-bearing, it should not be part of the credential/body model.

[prasad-stripe]

@googlebot I signed the CLA; please recheck the updated commit.

[prasad-stripe]

Thanks for raising this. Caller authentication and participant identity are
already separate in this proposal. #792 does not treat
identity.access_token as an authentication credential. It reuses the existing
PaymentIdentity schema, which defines that field as the identifier of the
participant the token was issued to. The caller is authenticated independently
using the handler-defined transport mechanism, such as Authorization.

Carrying identity in the checkout credential preserves the token's issuance
context for downstream verification; it does not turn the value into a bearer
credential or replace caller authentication.