@integraledger/lcp-placement-visa-tap 0.9.0

package/CHANGELOG.md

@@ -0,0 +1,13 @@
+# @integraledger/lcp-placement-visa-tap
+
+## 0.9.0
+
+First public release.
+
+`0.9.0` is deliberate: this is a release candidate for 1.0, not a preview. The implementation is complete
+against LCP v1.38 and certified by the conformance corpus, and the remaining distance to 1.0 is the
+specification's own — the standard is still moving through its steering committee, and this package will not
+claim a stability its protocol has not yet promised.
+
+Development before this release happened in a private repository and is not reproduced here; no earlier
+version was ever available to install.

package/LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/NOTICE

@@ -0,0 +1,14 @@
+Integra Protocol
+Copyright 2026 Integra Ledger
+
+This product includes software developed by Integra Ledger (https://integraledger.com).
+
+"Integra", "Integra Ledger", and the Integra logo are trademarks of Integra Ledger.
+Trademark use is not granted by the Apache License 2.0 (see Section 6).
+
+The Legal Context Protocol is co-stewarded by Integra Ledger and AAA-ICDR. This repository is a
+reference implementation of the standard's open layer; the specification itself is published at
+https://legalcontextprotocol.org/standard and is not part of this distribution.
+
+The vendored submodule under lib/commerce-payments is Coinbase's AuthCaptureEscrow and carries its own
+MIT licence at lib/commerce-payments/LICENSE.md. It is not covered by the Apache License above.

package/README.md

@@ -0,0 +1,149 @@
+# @integraledger/lcp-placement-visa-tap
+
+**The header this package writes is not covered by any Visa TAP signature, and that is the first thing to
+know about it.** TAP's agent recognition signature covers exactly two derived components — `@authority` and
+`@path` — and RFC 9421 puts only the components enumerated in `Signature-Input` into the signature base.
+A custom header sits outside that base, so any party in the request path may replace it and every TAP
+signature still verifies. This placement makes an ATR reference **available** on a TAP request. It proves
+nothing about integrity of the transport, and `verify` treats it as a placement — it never raises the class
+ladder, so an unbound header can never be mistaken for evidence of a weld.
+
+```bash
+npm install @integraledger/lcp-placement-visa-tap
+```
+
+| | |
+|---|---|
+| **Chain** | none — TAP authorizes a payment, it settles nothing on-chain |
+| **Pattern** | `http-advisory` (LCP §8.3.7, Tier A) |
+| **Field** | `headers.x-lcp-hash` — the only `header-map` container in the placement set |
+| **Carrier types** | `sha256` only |
+| **Signature coverage** | **none** — the header is outside `Signature-Input`'s covered components |
+| **Spec** | Visa TAP specifications (Visa Developer) + RFC 9421, gate discharged **2026-07-30** |
+
+## Use
+
+```ts
+import { VISA_TAP_PLACEMENT_TIER_A, visaTapPlacement } from "@integraledger/lcp-placement-visa-tap";
+
+declare const request: { headers: Record<string, string> }; // the TAP request, as received
+
+const placed = visaTapPlacement.place({ type: "sha256", value: "0x…" }, { headers: {} });
+const ref = visaTapPlacement.extract(request);
+```
+
+## Specification provenance — verified against the live host, 2026-07-30
+
+Read against the live Visa TAP specification published at Visa Developer
+(`developer.visa.com/capabilities/trusted-agent-protocol/trusted-agent-protocol-specifications`), the
+`visa/trusted-agent-protocol` reference implementation's RFC 9421 documentation, and RFC 9421 itself. Three
+claims were put to the spec, and all three hold:
+
+1. **The three-signature model is real, and its shapes differ.** TAP carries an *Agent Recognition
+   Signature* "provided in the message header (HTTP header, REST API header or similar message header)", a
+   *Consumer/Device Identity Signature* "provided in the message request body", and a *Payment Container
+   Signature* also in the request body. Two of the three are body objects — the Agentic Consumer Recognition
+   Object and the Agentic Payment Container.
+
+2. **`Signature-Input` names the covered components, and TAP names two of them.** The agent recognition
+   signature covers `@authority` (the target URI authority) and `@path` (the absolute path), plus the
+   signature parameters `created`, `expires`, `keyid`, `alg`, `nonce` and `tag` (`agent-browser-auth` or
+   `agent-payer-auth`). RFC 9421 §1.1 defines covered components as "an ordered set of HTTP message
+   component identifiers … that indicates the set of message components covered by the signature", and §2.5
+   builds the signature base from exactly that set. **A header absent from the enumeration is not in the
+   signature base**, which is what makes `x-lcp-hash` replaceable in transit without invalidating anything.
+   The reference implementation's documentation records the same two derived components.
+
+3. **A sibling body object lacking its own `nonce`/`kid`/`alg`/`signature` quartet is genuinely unbound.**
+   Both existing body objects carry that quartet, with the object's `nonce` **matching the message
+   signature's nonce** — so a nonce mismatch invalidates the binding even where the object's own signature
+   verifies. An LCP reference dropped into the body as a bare `{ type, value }` sibling inherits nothing
+   from that chain: no key identifier, no algorithm, no signature, no nonce to mismatch. It would be
+   silently replaceable while *looking* bound to a reader, which is strictly worse than an honestly
+   advertised header.
+
+**Drift against LCP v1.37 §C.6: none material.** The appendix is an illustration; the host spec is binding
+— the host's live specification is what binds. §C.6's description of the covered components, the body-object quartet and the nonce-match rule all
+survive the live read. Two notes for the record: the covered-component limitation is stated for the agent
+recognition signature in the specification and repeated for the reference implementation, so it is the
+protocol's shape and not one demo's shortcut; and no TAP extension registry or change-management process
+surfaced anywhere in the specification index, matching §C.6's own finding. TAP's only extensibility language
+is that "an Agent or a Payment Scheme may optionally define additional fields that could be part of the
+signature" — a coordinated arrangement, not a filing.
+
+## What is Tier B here, and why no manifest declares it
+
+Two integration points would actually be **bound**, and both need TAP's stewards or a payment scheme:
+
+- the reference inside one of the existing signed body objects, under the extensibility clause above; or
+- a new sibling object carrying its own `nonce`/`kid`/`alg`/`signature` quartet, mirroring the pattern the
+  two existing objects follow.
+
+A third path binds the header itself: add `x-lcp-hash` to the `Signature-Input` covered components. That is
+also a coordinated change, and therefore also Tier B.
+
+None of the three is declared as a manifest. A manifest asserting a field shape whose owner has not defined
+it asserts a shape the host has not defined, and a manifest is the thing a stranger acts on. The forward
+path lives here in prose, honestly, and the stewards are invited to define the placement.
+
+## Not `sidecar-attestation`
+
+LCP §8.3.3 is a separate on-chain transaction anchored to a settlement. **TAP settles nothing on-chain** —
+it authorizes a payment that some rail later settles — so there is no settlement transaction to anchor to.
+An earlier plan draft assigned that pattern token to this package and it was wrong. The pattern is §8.3.7
+HTTP-Layer Advisory, which is exactly what an uncovered header is.
+
+## The surface is deliberately two exports
+
+`visaTapPlacement` is `makePlacement(VISA_TAP_PLACEMENT_TIER_A)` — `makePlacement` comes from
+[`@integraledger/lcp-binding-core`](../binding-core#readme) — and nothing else — the manifest *is* the
+adapter (S7). Both members are total: a refusal is a returned value, never a thrown exception.
+
+**There is no helper here that builds an unsigned sibling body object, and a test pins the export set so
+there never is.** That helper is the single worst thing this package could ship: a body sibling carrying the
+reference without the quartet does not inherit TAP's signature chain, is silently replaceable, and would
+look bound to a reader. The anti-pattern is unbuildable from this surface rather than discouraged in a
+comment.
+
+## Reading the header is case-insensitive; writing preserves the counterparty's spelling
+
+RFC 9110 makes `X-LCP-Hash` and `x-lcp-hash` the same field, so `extract` folds case — that is what reading
+this container correctly means, not a heuristic. `place` writes the manifest's own lowercase spelling on a
+fresh header and **reuses an existing key's casing** when one folds to a match, because emitting a second
+spelling would produce two headers RFC 9110 considers one. Only the declared name is read: a header named
+anything else does not exist to this package.
+
+What `place` does **not** do is repair a document that arrives already carrying two spellings of this one
+field. The write updates the first key that folds to a match and leaves the other exactly as the counterparty
+sent it, stale — and a stack that canonicalizes field names would then collapse the two JSON keys into one
+field with two values. That input is malformed at the HTTP layer before this placement ever sees it, and
+repairing it would change the kit's header-map rule for every protocol using it, so the state is pinned in
+this package's tests rather than fixed here.
+
+## Carrier types are `["sha256"]`, and the list is exactly one on purpose
+
+A header holds a scalar, so the encoding is `bare-value` and the field's own name fixes the type — a bare
+value carries no type tag, so a second permitted type would leave a reader unable to tell a hash from a
+URL. `url` is absent for the further reason that this carrier is already the weakest one in the set;
+offering discovery-grade content through it would compound an uncovered header with an unattested target.
+
+## A placement, not a binding
+
+TAP describes an authorization, not a settlement. This package is a `ReferencePlacementAdapter` — two pure
+functions and a manifest, no ports, no chain, no lifecycle. Where the payment TAP authorizes settles on a
+bound rail, that rail's binding welds the record; otherwise this placement is the record's whole protocol
+reach and reads with an honest `not-attempted` at settlement-enumeration.
+
+## Provenance
+
+Cut against the Visa TAP specification at Visa Developer and RFC 9421, gate discharged **2026-07-30**, and
+reconciled against LCP v1.37 §C.6 the same day.
+
+---
+
+**Requires Node >= 24.** Part of the
+[Legal Context Protocol open layer](https://github.com/IntegraLedger/integra-protocol) — see the
+[documentation](https://github.com/IntegraLedger/integra-protocol/blob/main/docs/developer/index.md)
+and the
+[package index](https://github.com/IntegraLedger/integra-protocol/blob/main/docs/developer/reference.md).
+Apache-2.0.

package/dist/index.d.ts

@@ -0,0 +1,3 @@
+export { VISA_TAP_PLACEMENT_TIER_A } from "./manifest.js";
+export { visaTapPlacement } from "./placement.js";
+//# sourceMappingURL=index.d.ts.map

package/dist/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,yBAAyB,EAAE,MAAM,eAAe,CAAC;AAC1D,OAAO,EAAE,gBAAgB,EAAE,MAAM,gBAAgB,CAAC"}

package/dist/index.js

@@ -0,0 +1,3 @@
+export { VISA_TAP_PLACEMENT_TIER_A } from "./manifest.js";
+export { visaTapPlacement } from "./placement.js";
+//# sourceMappingURL=index.js.map

package/dist/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,yBAAyB,EAAE,MAAM,eAAe,CAAC;AAC1D,OAAO,EAAE,gBAAgB,EAAE,MAAM,gBAAgB,CAAC"}

package/dist/manifest.d.ts

@@ -0,0 +1,52 @@
+import type { PlacementManifest } from "@integraledger/lcp-binding-core";
+/**
+ * Visa TAP (Trusted Agent Protocol) reference placement — Tier A, and UNBOUND.
+ *
+ * Cut against the LIVE TAP specification published at Visa Developer
+ * (`developer.visa.com/capabilities/trusted-agent-protocol/trusted-agent-protocol-specifications`), the
+ * `visa/trusted-agent-protocol` reference implementation's RFC 9421 documentation, and RFC 9421 itself —
+ * gate discharged 2026-07-30 against LCP v1.37 §C.6, re-checked against v1.38 §C.6 on 2026-08-08 — no
+ * material drift either time.
+ *
+ * TAP is built on HTTP Message Signatures [RFC 9421] with a three-signature model establishing agent
+ * identity (a header signature), consumer identity and payment authorization (two signed body objects). A
+ * custom header carrying the reference is available today with no coordination — and it is **not covered by
+ * any signature**: TAP's agent recognition signature covers exactly `@authority` and `@path`, and RFC 9421
+ * §2.5 builds the signature base from only the components `Signature-Input` enumerates. Anything on the path
+ * can therefore replace `x-lcp-hash` while every TAP signature still verifies. Binding it means adding the
+ * header to the covered components, which is itself a coordinated change and therefore Tier B.
+ *
+ * This manifest declares the unbound header because it is what is honestly available. The README leads with
+ * the limitation rather than burying it, and `verify` treats the result as a placement — it never raises the
+ * class ladder through the reference-placement step, so an unbound header can never be mistaken for
+ * evidence of a weld.
+ *
+ * **NOT `sidecar-attestation`.** §8.3.3 is a separate on-chain transaction anchored to a settlement. TAP
+ * settles nothing on-chain; there is no settlement transaction to anchor to. An earlier plan draft assigned
+ * that token and it was wrong. §8.3.7 HTTP-Layer Advisory is what an uncovered header actually is.
+ *
+ * **The `_TIER_A` in the name is load-bearing here**, unlike in `placement-ucp` where the re-cut collapsed
+ * the two-manifest design into one: TAP genuinely has Tier B integration points (inside one of the signed
+ * body objects under the spec's extensibility clause, a new sibling object carrying its own
+ * `nonce`/`kid`/`alg`/`signature` quartet, or naming this header in `Signature-Input`). None is declared as
+ *
+ * (`kid` here is the BODY OBJECT's quartet field, not RFC 9421's `keyid` signature parameter — the two
+ * spellings sit side by side in this package and are two different structures, not a contradiction to
+ * reconcile. RFC 9421 §2.3 names the parameter `keyid`; the body objects follow JOSE's `kid`. Neither is
+ * verifiable from the reference implementation, which mentions neither, so both are left as read.)
+ * a manifest — a manifest asserting a shape whose owner has not defined it is the asserting-a-shape defect,
+ * and a manifest is the thing a stranger acts on — so the forward path lives in the README's prose and this
+ * name says which tier the shipped thing is.
+ *
+ * `encoding` is `bare-value` with `carrierTypes: ["sha256"]`: a header holds a scalar and the field's own
+ * name fixes the type. That is also why the type list is exactly one — a bare value carries no type tag, so
+ * a second permitted type would leave a reader unable to tell a hash from a URL. `url` is excluded for the
+ * further reason that this carrier is already the weakest in the set; pairing an uncovered header with an
+ * unattested target would compound two weaknesses into something a reader could easily overread.
+ *
+ * The container is `header-map`, the only one in the placement set: RFC 9110 field names compare
+ * case-insensitively, so the kit folds case on read and reuses an existing key's casing on write. Neither is
+ * a heuristic — it is what reading and writing an HTTP field map correctly means.
+ */
+export declare const VISA_TAP_PLACEMENT_TIER_A: PlacementManifest;
+//# sourceMappingURL=manifest.d.ts.map

package/dist/manifest.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"manifest.d.ts","sourceRoot":"","sources":["../src/manifest.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,iCAAiC,CAAC;AAEzE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgDG;AACH,eAAO,MAAM,yBAAyB,EAAE,iBAUvC,CAAC"}

package/dist/manifest.js

@@ -0,0 +1,60 @@
+/**
+ * Visa TAP (Trusted Agent Protocol) reference placement — Tier A, and UNBOUND.
+ *
+ * Cut against the LIVE TAP specification published at Visa Developer
+ * (`developer.visa.com/capabilities/trusted-agent-protocol/trusted-agent-protocol-specifications`), the
+ * `visa/trusted-agent-protocol` reference implementation's RFC 9421 documentation, and RFC 9421 itself —
+ * gate discharged 2026-07-30 against LCP v1.37 §C.6, re-checked against v1.38 §C.6 on 2026-08-08 — no
+ * material drift either time.
+ *
+ * TAP is built on HTTP Message Signatures [RFC 9421] with a three-signature model establishing agent
+ * identity (a header signature), consumer identity and payment authorization (two signed body objects). A
+ * custom header carrying the reference is available today with no coordination — and it is **not covered by
+ * any signature**: TAP's agent recognition signature covers exactly `@authority` and `@path`, and RFC 9421
+ * §2.5 builds the signature base from only the components `Signature-Input` enumerates. Anything on the path
+ * can therefore replace `x-lcp-hash` while every TAP signature still verifies. Binding it means adding the
+ * header to the covered components, which is itself a coordinated change and therefore Tier B.
+ *
+ * This manifest declares the unbound header because it is what is honestly available. The README leads with
+ * the limitation rather than burying it, and `verify` treats the result as a placement — it never raises the
+ * class ladder through the reference-placement step, so an unbound header can never be mistaken for
+ * evidence of a weld.
+ *
+ * **NOT `sidecar-attestation`.** §8.3.3 is a separate on-chain transaction anchored to a settlement. TAP
+ * settles nothing on-chain; there is no settlement transaction to anchor to. An earlier plan draft assigned
+ * that token and it was wrong. §8.3.7 HTTP-Layer Advisory is what an uncovered header actually is.
+ *
+ * **The `_TIER_A` in the name is load-bearing here**, unlike in `placement-ucp` where the re-cut collapsed
+ * the two-manifest design into one: TAP genuinely has Tier B integration points (inside one of the signed
+ * body objects under the spec's extensibility clause, a new sibling object carrying its own
+ * `nonce`/`kid`/`alg`/`signature` quartet, or naming this header in `Signature-Input`). None is declared as
+ *
+ * (`kid` here is the BODY OBJECT's quartet field, not RFC 9421's `keyid` signature parameter — the two
+ * spellings sit side by side in this package and are two different structures, not a contradiction to
+ * reconcile. RFC 9421 §2.3 names the parameter `keyid`; the body objects follow JOSE's `kid`. Neither is
+ * verifiable from the reference implementation, which mentions neither, so both are left as read.)
+ * a manifest — a manifest asserting a shape whose owner has not defined it is the asserting-a-shape defect,
+ * and a manifest is the thing a stranger acts on — so the forward path lives in the README's prose and this
+ * name says which tier the shipped thing is.
+ *
+ * `encoding` is `bare-value` with `carrierTypes: ["sha256"]`: a header holds a scalar and the field's own
+ * name fixes the type. That is also why the type list is exactly one — a bare value carries no type tag, so
+ * a second permitted type would leave a reader unable to tell a hash from a URL. `url` is excluded for the
+ * further reason that this carrier is already the weakest in the set; pairing an uncovered header with an
+ * unattested target would compound two weaknesses into something a reader could easily overread.
+ *
+ * The container is `header-map`, the only one in the placement set: RFC 9110 field names compare
+ * case-insensitively, so the kit folds case on read and reuses an existing key's casing on write. Neither is
+ * a heuristic — it is what reading and writing an HTTP field map correctly means.
+ */
+export const VISA_TAP_PLACEMENT_TIER_A = {
+    protocol: "visa-tap",
+    pattern: "http-advisory",
+    tier: "A",
+    encoding: "bare-value",
+    container: { kind: "header-map" },
+    field: "headers.x-lcp-hash",
+    carrierTypes: ["sha256"],
+    specRef: "Visa TAP — custom HTTP header outside the Signature-Input covered set (@authority, @path); RFC 9421 §1.1/§2.5 (gate discharged 2026-07-30: see README)",
+};
+//# sourceMappingURL=manifest.js.map

package/dist/manifest.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"manifest.js","sourceRoot":"","sources":["../src/manifest.ts"],"names":[],"mappings":"AAEA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgDG;AACH,MAAM,CAAC,MAAM,yBAAyB,GAAsB;IAC1D,QAAQ,EAAE,UAAU;IACpB,OAAO,EAAE,eAAe;IACxB,IAAI,EAAE,GAAG;IACT,QAAQ,EAAE,YAAY;IACtB,SAAS,EAAE,EAAE,IAAI,EAAE,YAAY,EAAE;IACjC,KAAK,EAAE,oBAAoB;IAC3B,YAAY,EAAE,CAAC,QAAQ,CAAC;IACxB,OAAO,EACL,wJAAwJ;CAC3J,CAAC"}

package/dist/placement.d.ts

@@ -0,0 +1,20 @@
+import { type ReferencePlacementAdapter } from "@integraledger/lcp-binding-core";
+/**
+ * The Visa TAP reference placement. The manifest IS the adapter (S7) — there is nothing else here, and that
+ * is a claim about the protocol, not brevity for its own sake.
+ *
+ * `header-map` supplies every mechanic this placement needs: the RFC 9110 case fold on read, the
+ * existing-key-casing reuse on write so this placement never ADDS a second spelling of one HTTP field
+ * (a document that arrived with two is not repaired either — README), creation of an absent header map,
+ * replacement of an unmergeable one, purity, and every refusal the vectors pin. TAP adds no
+ * semantic rule on top — unlike UCP, whose terms link must be HTTPS, the only thing this header can hold is
+ * an atrHash, and the §8.1 codec already rules on that. A wrap here would be a third override of the kit
+ * with nothing to justify it.
+ *
+ * **A CONSTANT, not a factory.** The header name is fixed by this package, not by the deployment: it is an
+ * ordinary custom HTTP field, so there is no namespace to parameterize and nothing a caller could supply that
+ * would make the header any more bound than it is. The export set is pinned by a test for the related
+ * reason — no helper here may build an unsigned sibling body object.
+ */
+export declare const visaTapPlacement: ReferencePlacementAdapter;
+//# sourceMappingURL=placement.d.ts.map

package/dist/placement.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"placement.d.ts","sourceRoot":"","sources":["../src/placement.ts"],"names":[],"mappings":"AAAA,OAAO,EAEL,KAAK,yBAAyB,EAC/B,MAAM,iCAAiC,CAAC;AAGzC;;;;;;;;;;;;;;;;GAgBG;AACH,eAAO,MAAM,gBAAgB,EAAE,yBAE9B,CAAC"}

package/dist/placement.js

@@ -0,0 +1,21 @@
+import { makePlacement, } from "@integraledger/lcp-binding-core";
+import { VISA_TAP_PLACEMENT_TIER_A } from "./manifest.js";
+/**
+ * The Visa TAP reference placement. The manifest IS the adapter (S7) — there is nothing else here, and that
+ * is a claim about the protocol, not brevity for its own sake.
+ *
+ * `header-map` supplies every mechanic this placement needs: the RFC 9110 case fold on read, the
+ * existing-key-casing reuse on write so this placement never ADDS a second spelling of one HTTP field
+ * (a document that arrived with two is not repaired either — README), creation of an absent header map,
+ * replacement of an unmergeable one, purity, and every refusal the vectors pin. TAP adds no
+ * semantic rule on top — unlike UCP, whose terms link must be HTTPS, the only thing this header can hold is
+ * an atrHash, and the §8.1 codec already rules on that. A wrap here would be a third override of the kit
+ * with nothing to justify it.
+ *
+ * **A CONSTANT, not a factory.** The header name is fixed by this package, not by the deployment: it is an
+ * ordinary custom HTTP field, so there is no namespace to parameterize and nothing a caller could supply that
+ * would make the header any more bound than it is. The export set is pinned by a test for the related
+ * reason — no helper here may build an unsigned sibling body object.
+ */
+export const visaTapPlacement = makePlacement(VISA_TAP_PLACEMENT_TIER_A);
+//# sourceMappingURL=placement.js.map

package/dist/placement.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"placement.js","sourceRoot":"","sources":["../src/placement.ts"],"names":[],"mappings":"AAAA,OAAO,EACL,aAAa,GAEd,MAAM,iCAAiC,CAAC;AACzC,OAAO,EAAE,yBAAyB,EAAE,MAAM,eAAe,CAAC;AAE1D;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,CAAC,MAAM,gBAAgB,GAA8B,aAAa,CACtE,yBAAyB,CAC1B,CAAC"}

package/package.json

@@ -0,0 +1,60 @@
+{
+  "name": "@integraledger/lcp-placement-visa-tap",
+  "version": "0.9.0",
+  "description": "Places an LCP reference into a Visa TAP request. The header sits outside TAP's signature.",
+  "keywords": [
+    "lcp",
+    "legal-context-protocol",
+    "legal-terms",
+    "agentic-commerce",
+    "placement",
+    "visa",
+    "tap"
+  ],
+  "type": "module",
+  "sideEffects": false,
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "default": "./dist/index.js"
+    },
+    "./package.json": "./package.json"
+  },
+  "files": [
+    "dist",
+    "src",
+    "CHANGELOG.md",
+    "LICENSE",
+    "NOTICE"
+  ],
+  "publishConfig": {
+    "registry": "https://registry.npmjs.org",
+    "access": "public"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/IntegraLedger/integra-protocol.git",
+    "directory": "packages/placement-visa-tap"
+  },
+  "bugs": {
+    "url": "https://github.com/IntegraLedger/integra-protocol/issues"
+  },
+  "homepage": "https://github.com/IntegraLedger/integra-protocol/tree/main/packages/placement-visa-tap#readme",
+  "dependencies": {
+    "@integraledger/lcp-binding-core": "0.9.0"
+  },
+  "devDependencies": {
+    "@cfworker/json-schema": "4.1.1",
+    "@types/node": "24.13.3",
+    "vitest": "4.1.10"
+  },
+  "license": "Apache-2.0",
+  "engines": {
+    "node": ">=24"
+  },
+  "scripts": {
+    "build": "tsc -p tsconfig.build.json",
+    "typecheck": "tsc -p tsconfig.json --noEmit",
+    "test": "vitest run"
+  }
+}

package/src/index.ts

@@ -0,0 +1,2 @@
+export { VISA_TAP_PLACEMENT_TIER_A } from "./manifest.js";
+export { visaTapPlacement } from "./placement.js";

package/src/manifest.ts

@@ -0,0 +1,62 @@
+import type { PlacementManifest } from "@integraledger/lcp-binding-core";
+
+/**
+ * Visa TAP (Trusted Agent Protocol) reference placement — Tier A, and UNBOUND.
+ *
+ * Cut against the LIVE TAP specification published at Visa Developer
+ * (`developer.visa.com/capabilities/trusted-agent-protocol/trusted-agent-protocol-specifications`), the
+ * `visa/trusted-agent-protocol` reference implementation's RFC 9421 documentation, and RFC 9421 itself —
+ * gate discharged 2026-07-30 against LCP v1.37 §C.6, re-checked against v1.38 §C.6 on 2026-08-08 — no
+ * material drift either time.
+ *
+ * TAP is built on HTTP Message Signatures [RFC 9421] with a three-signature model establishing agent
+ * identity (a header signature), consumer identity and payment authorization (two signed body objects). A
+ * custom header carrying the reference is available today with no coordination — and it is **not covered by
+ * any signature**: TAP's agent recognition signature covers exactly `@authority` and `@path`, and RFC 9421
+ * §2.5 builds the signature base from only the components `Signature-Input` enumerates. Anything on the path
+ * can therefore replace `x-lcp-hash` while every TAP signature still verifies. Binding it means adding the
+ * header to the covered components, which is itself a coordinated change and therefore Tier B.
+ *
+ * This manifest declares the unbound header because it is what is honestly available. The README leads with
+ * the limitation rather than burying it, and `verify` treats the result as a placement — it never raises the
+ * class ladder through the reference-placement step, so an unbound header can never be mistaken for
+ * evidence of a weld.
+ *
+ * **NOT `sidecar-attestation`.** §8.3.3 is a separate on-chain transaction anchored to a settlement. TAP
+ * settles nothing on-chain; there is no settlement transaction to anchor to. An earlier plan draft assigned
+ * that token and it was wrong. §8.3.7 HTTP-Layer Advisory is what an uncovered header actually is.
+ *
+ * **The `_TIER_A` in the name is load-bearing here**, unlike in `placement-ucp` where the re-cut collapsed
+ * the two-manifest design into one: TAP genuinely has Tier B integration points (inside one of the signed
+ * body objects under the spec's extensibility clause, a new sibling object carrying its own
+ * `nonce`/`kid`/`alg`/`signature` quartet, or naming this header in `Signature-Input`). None is declared as
+ *
+ * (`kid` here is the BODY OBJECT's quartet field, not RFC 9421's `keyid` signature parameter — the two
+ * spellings sit side by side in this package and are two different structures, not a contradiction to
+ * reconcile. RFC 9421 §2.3 names the parameter `keyid`; the body objects follow JOSE's `kid`. Neither is
+ * verifiable from the reference implementation, which mentions neither, so both are left as read.)
+ * a manifest — a manifest asserting a shape whose owner has not defined it is the asserting-a-shape defect,
+ * and a manifest is the thing a stranger acts on — so the forward path lives in the README's prose and this
+ * name says which tier the shipped thing is.
+ *
+ * `encoding` is `bare-value` with `carrierTypes: ["sha256"]`: a header holds a scalar and the field's own
+ * name fixes the type. That is also why the type list is exactly one — a bare value carries no type tag, so
+ * a second permitted type would leave a reader unable to tell a hash from a URL. `url` is excluded for the
+ * further reason that this carrier is already the weakest in the set; pairing an uncovered header with an
+ * unattested target would compound two weaknesses into something a reader could easily overread.
+ *
+ * The container is `header-map`, the only one in the placement set: RFC 9110 field names compare
+ * case-insensitively, so the kit folds case on read and reuses an existing key's casing on write. Neither is
+ * a heuristic — it is what reading and writing an HTTP field map correctly means.
+ */
+export const VISA_TAP_PLACEMENT_TIER_A: PlacementManifest = {
+  protocol: "visa-tap",
+  pattern: "http-advisory",
+  tier: "A",
+  encoding: "bare-value",
+  container: { kind: "header-map" },
+  field: "headers.x-lcp-hash",
+  carrierTypes: ["sha256"],
+  specRef:
+    "Visa TAP — custom HTTP header outside the Signature-Input covered set (@authority, @path); RFC 9421 §1.1/§2.5 (gate discharged 2026-07-30: see README)",
+};

package/src/placement.ts

@@ -0,0 +1,26 @@
+import {
+  makePlacement,
+  type ReferencePlacementAdapter,
+} from "@integraledger/lcp-binding-core";
+import { VISA_TAP_PLACEMENT_TIER_A } from "./manifest.js";
+
+/**
+ * The Visa TAP reference placement. The manifest IS the adapter (S7) — there is nothing else here, and that
+ * is a claim about the protocol, not brevity for its own sake.
+ *
+ * `header-map` supplies every mechanic this placement needs: the RFC 9110 case fold on read, the
+ * existing-key-casing reuse on write so this placement never ADDS a second spelling of one HTTP field
+ * (a document that arrived with two is not repaired either — README), creation of an absent header map,
+ * replacement of an unmergeable one, purity, and every refusal the vectors pin. TAP adds no
+ * semantic rule on top — unlike UCP, whose terms link must be HTTPS, the only thing this header can hold is
+ * an atrHash, and the §8.1 codec already rules on that. A wrap here would be a third override of the kit
+ * with nothing to justify it.
+ *
+ * **A CONSTANT, not a factory.** The header name is fixed by this package, not by the deployment: it is an
+ * ordinary custom HTTP field, so there is no namespace to parameterize and nothing a caller could supply that
+ * would make the header any more bound than it is. The export set is pinned by a test for the related
+ * reason — no helper here may build an unsigned sibling body object.
+ */
+export const visaTapPlacement: ReferencePlacementAdapter = makePlacement(
+  VISA_TAP_PLACEMENT_TIER_A,
+);