Skip to content

PLAN — P11A Visa TAP Intent Verification Evidence Interop (2026 Q2)

  • Date: 2026-04-08
  • Owner: Evidence / Product
  • Status: Planning
  • Scope (this PR): Define the first P11 commerce / trust-proof lane around Visa Trusted Agent Protocol. No sample implementation, no outward issue, no contract freeze in this slice.

1. Why this plan exists

After the current wave, the next frontier lane should still pass the same three tests:

  1. the upstream protocol already exposes one bounded surface,
  2. Assay can consume that surface without inheriting upstream commerce or identity semantics as truth,
  3. the maintainers have at least one natural place for one small sample-backed boundary question.

visa/trusted-agent-protocol fits that pattern well enough to justify a formal plan:

  • the protocol is explicitly about trust between agents and merchants in agentic commerce
  • the repo documents a concrete verification story rather than a vague observability story
  • the public README calls out timestamps, session identifiers, key identifiers, algorithm identifiers, domain binding, operation binding, and replay prevention
  • issues are enabled, even though Discussions are not

This is the strongest current frontier candidate because it opens a new protocol class without collapsing back into another framework runtime or eval lane.

This is not a payment-truth plan.

This is not a checkout-success plan.

This is not a user-identity import plan.

This is a plan for a bounded TAP signature-verification outcome seam.

2. Hard positioning rule

This lane must not overclaim what the sample actually observes.

Normative framing:

This sample targets the smallest honest TAP verification-outcome surface, not a payment settlement record, merchant decision record, or customer-identity truth surface.

That means:

  • TAP is the upstream protocol context, not the truth source for payment or identity claims inside Assay
  • signature verification is the first seam, not merchant outcome semantics
  • Assay stays an external evidence consumer, not a verifier of economic correctness, merchant correctness, or consumer authorization correctness beyond the observed artifact

3. Why verification-first, not payment-first

The TAP README makes it very tempting to talk about payments because it mentions payment identifiers, streamlined checkout, and reduced fraud.

That would be the wrong first wedge.

Why:

  • it would drag the lane immediately into payment and merchant semantics
  • it would make overclaiming much easier
  • it would blur the difference between observed verification data and business outcome truth
  • it would skip the smaller surface already documented in TAP itself: a cryptographic verification path bound to time, session, key, domain, and operation

The cleaner first wedge is:

  • one artifact derived from the documented TAP verification path
  • bounded verification result
  • bounded signature metadata
  • bounded domain and operation binding
  • no user identifiers
  • no payment identifiers
  • no merchant outcome semantics

This keeps P11A aligned with Assay’s trust-compiler direction without turning the sample into a commerce demo.

Use one frozen serialized artifact derived from the documented TAP signature-verification surface as the first external-consumer seam.

The publicly documented ingredients of that seam include:

  • timestamp
  • unique session identifier
  • key identifier
  • algorithm identifier
  • merchant domain binding
  • operation binding
  • verification result

This is intentionally not:

  • checkout result export
  • settlement export
  • consumer identity export
  • PAR or loyalty identifier import
  • merchant fraud decision export

Important framing rule:

The sample uses a frozen serialized artifact derived from the documented TAP signature-verification surface, not a claim that TAP already guarantees one fixed wire-export contract for external evidence consumers.

5. v1 artifact contract

5.1 Required fields

The first sample should require:

  • schema
  • protocol
  • surface
  • timestamp
  • session_id
  • key_id
  • algorithm
  • merchant_domain_ref
  • operation_type
  • verification_result

5.2 Optional fields

The first sample may include:

  • agent_ref
  • registry_ref
  • verification_reason
  • request_ref

5.3 Important field boundaries

verification_result

This field is required in the frozen sample shape.

It should stay small and bounded:

  • verified
  • rejected

If the chosen sample shape needs a little more texture, use a short verification_reason, not a large verifier transcript.

This requirement belongs to the sample shape, not to an upstream claim that TAP guarantees one universal serialized verification contract.

The safest internal wording for the sample remains:

  • verification outcome
  • not verified intent
  • not verified customer action truth

verification_reason

This field is optional in v1.

If present, it must stay extremely small:

  • bounded enum
  • or one short classifier label

Not allowed in v1:

  • free-text verifier narrative
  • verifier transcript
  • debug trace
  • raw cryptographic error detail beyond a short classifier

This field must remain a small sample-level explanation aid, not a secondary channel for richer identity, authorization, or merchant semantics.

Signature metadata

timestamp, session_id, key_id, and algorithm are required because they are exactly what make the TAP verification story bounded and reviewable.

In v1, these fields must remain:

  • observed metadata
  • replay-defense context
  • verification context

They must not become:

  • customer identity truth
  • merchant authorization truth
  • payment truth

session_id must remain an opaque identifier only.

Not allowed in v1:

  • browser session semantics
  • cookie semantics
  • request-correlation semantics beyond the bounded id itself

merchant_domain_ref

This field is required because domain binding is part of the documented TAP story.

It should stay a bounded reference only:

  • hostname
  • short domain label
  • normalized merchant domain only

Not allowed in v1:

  • full merchant session payload
  • full request headers
  • checkout body payloads
  • merchant account or tenant metadata

operation_type

This field is required because TAP explicitly distinguishes the specific action being authorized, including browsing or payment.

In v1, keep it small:

  • browsing
  • payment

It must remain an observed upstream operation label, not a claim that Assay independently validated the action.

It should also be framed as a sample-level bounded label, not as a claim that TAP already guarantees one universal serialized enum contract for all external consumers.

Optional references

The optional reference fields must stay bounded:

  • small label
  • opaque id
  • short reference string

If agent_ref is present, it must remain an opaque, non-user, non-accountable reference only. It must not encode or imply a user, account, or stable personal identity.

Not allowed in v1:

  • verifiable consumer identifiers
  • payment account references
  • loyalty numbers
  • email addresses
  • phone numbers
  • raw signed request payloads

6. Assay-side meaning

The sample may only claim bounded verification-outcome observation.

Assay must not treat as truth:

  • payment completion
  • settlement success
  • merchant acceptance
  • user identity correctness
  • consumer consent correctness beyond the observed verification artifact
  • fraud outcome semantics

Common anti-overclaim sentence:

We are not asking Assay to inherit TAP payment semantics, merchant decision semantics, customer identity semantics, or commerce outcomes as truth.

7. Concrete repo deliverable

If this plan is accepted, the next implementation PR should add:

  • examples/tap-intent-evidence/README.md
  • examples/tap-intent-evidence/requirements.txt only if a tiny local verifier truly needs it
  • examples/tap-intent-evidence/generate_synthetic_result.py only if a clean local verification generator is viable
  • examples/tap-intent-evidence/map_to_assay.py
  • examples/tap-intent-evidence/fixtures/valid.tap.json
  • examples/tap-intent-evidence/fixtures/invalid.tap.json
  • examples/tap-intent-evidence/fixtures/malformed.tap.json
  • examples/tap-intent-evidence/fixtures/valid.assay.ndjson
  • examples/tap-intent-evidence/fixtures/invalid.assay.ndjson

Fixture boundary notes:

  • v1 fixtures may omit every optional reference field
  • v1 fixtures must not include user or payment identifiers
  • v1 fixtures must not include raw signed payload bodies
  • v1 fixtures should keep the export shape obviously verification-first rather than checkout-first

8. Generator policy

The implementation should prefer a real local generator only if it stays small and deterministic.

8.1 Preferred path

Preferred:

  • a local verifier path that exercises the signature-verification seam only
  • no merchant frontend dependency
  • no full checkout dependency
  • no registry or CDN stack heavy enough to overshadow the sample

8.2 Hard fallback rule

If a real local generator would require:

  • multiple long-running services
  • merchant frontend + backend + proxy + registry orchestration
  • cloud dependencies
  • consumer or payment test identifiers
  • a demo setup heavy enough to dominate the evidence seam

then the sample should fall back to a docs-backed frozen verification artifact shape.

That fallback is especially appropriate here because the public TAP sample is a multi-component demo. The goal of this lane is to isolate the smallest honest verification seam, not to recreate the whole commerce stack in this repo.

9. Valid, invalid, malformed corpus

The first sample should follow the established corpus pattern.

9.1 Valid

One successful verification artifact with:

  • bounded signature metadata
  • bounded domain and operation binding
  • verification_result=verified

9.2 Invalid

One rejected verification artifact with:

  • bounded signature metadata
  • bounded domain and operation binding
  • verification_result=rejected
  • one short verification reason if needed

This is not a merchant business denial record. It is only a verification failure artifact.

9.3 Malformed

One malformed artifact that fails fast, for example:

  • missing session_id
  • missing verification_result
  • unsupported operation_type

10. Outward strategy

Do not open an outward TAP issue until the sample is on main.

After that:

  • one small GitHub issue
  • one link
  • one boundary question
  • no broad commerce pitch
  • no settlement or identity pitch

Suggested outward question:

If an external evidence consumer wants the smallest honest TAP surface, is a verification-result artifact derived from the signature-verification path roughly the right place to start, or is there a thinner verification surface you would rather point them at?

11. Sequencing rule

P11A is strategically above Browser Use in the broader queue, but Browser Use is still the active adjacent lane already in flight.

Meaning:

  1. formalize P11A now
  2. keep Browser Use on its current finish-and-breathe path
  3. decide deliberately whether the next new implementation lane is P11A or a later adjacent lane after Browser Use settles

12. Non-goals

This plan does not:

  • define a payment-settlement evidence contract
  • define a customer-identity evidence contract
  • define a merchant fraud-decision contract
  • define a checkout-success contract
  • define TAP as Assay truth for commerce outcomes

References