@zkp2p/zkp2p-attestation 3.0.1 → 4.0.0-rc.0

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # Changelog
 
+## 4.0.0-rc.0
+
+- Add X Money seller credential uploads and receipt-gated `register_xmoney` seller identity types. Mailbox credentials support Google OAuth, Microsoft OAuth, and iCloud Mail; standalone X Money identity requests remain unavailable.
+
+- BREAKING: Monobank buyer TEE now uses entrepreneur business portal `gatewayState`/`browserId` credentials and `CLIENT_ID`/`TRANSACTION_ID` params. Retire the buyer Open API token shape; enforce settled UAH transfers and a service-owned 14-day timestamp buffer.
+
+- Add typed X Money Buyer TEE requests with encrypted captured `url` and headers, and no public params. Replay the captured GraphQL operation ID and derive the transaction ID from the URL instead of accepting duplicate input.
+
+- BREAKING: remove the retired HDFC Gmail buyer proof types and action. Amazon
+  Pay is the supported UPI buyer and seller verification path.
+
+## 3.1.0
+
+- Remove the retired preproduction hostname and PCR8 from bundled trust pins.
+- Add typed Venmo and PayPal dispute helpers for attested session encryption, `POST /dispute/verify`, and local `DisputeAttestation` verification. The helpers use the `ZKP2P DisputeVerifier` EIP-712 domain and `DisputeDetails` wire fields while keeping all extracted identifiers out of public params.
+
 ## 3.0.1
 
 - Restore the generic Buyer TEE compact JWE for standalone identity capture while retaining the Alipay types added in 3.0.0. `callerAddress` remains required on `POST /identity` and in the signed typed data, but is no longer required by identity encryption helpers or nested inside encrypted session material.

package/README.md

@@ -1,6 +1,6 @@
 # @zkp2p/zkp2p-attestation
 
-Client-side verifier and encryptor for ZKP2P Nitro identity attestations, seller credential uploads, and buyer TEE session-material requests.
+Client-side verifier and encryptor for ZKP2P Nitro payment, dispute, identity, and seller-credential flows.
 
 The package runs in Chrome MV3 service workers, browser DOM contexts, React Native with a Web Crypto polyfill, and Node >= 20. Library entrypoints use `fetch`, `SubtleCrypto`, `crypto.getRandomValues`, and `Uint8Array`; they do not import `node:*` modules or use `Buffer`.
 
@@ -33,7 +33,7 @@ Environment defaults:
 | `staging` | `https://attestation-service-staging.zkp2p.xyz` | bundled staging pin |
 | `production` | `https://attestation-service.zkp2p.xyz` | bundled production pin |
 
-Callers can still pass `attestationServiceUrl` and `trust.expectedPcr8Hex` directly. Explicit trust pins always win. The preprod hostname is pinned to the isolated preprod enclave; it is not a production alias.
+Callers can still pass `attestationServiceUrl` and `trust.expectedPcr8Hex` directly. Explicit trust pins always win. Bundled trust is limited to the canonical staging and production hostnames.
 
 ## Fast Path
 
@@ -86,15 +86,17 @@ const encryptedUpload = await nitro.createEncryptedSellerCredentialUpload({
 });
 ```
 
+Venmo Gmail OAuth uploads use the same encryption helper with numeric Venmo account id as `payeeId` and `sessionMaterial: { credentialSource: "google_oauth", authorizationCode, redirectUri, oauthClient? }`. The service binds a DKIM-verified receipt recipient to that account through Venmo's public profile API. The optional partner app secret and refresh token remain inside the encrypted seller bundle. Existing Venmo session-cookie uploads remain an independently supported credential type.
+
 PayPal Gmail OAuth seller uploads use the same app-selection model. Pass the seller PayPal email as `payeeId` and use `sessionMaterial: { credentialSource: "google_oauth", authorizationCode, redirectUri }`; the service validates Gmail access against paypal.com DKIM-signed payment receipts. To onboard through a partner-owned Google OAuth app, include `oauthClient: { clientId, clientSecret }` inside the encrypted `sessionMaterial`. The PayPal partner client secret is handled as seller credential material: it rides only in the compact JWE upload plaintext, is sealed with the Gmail refresh token in the KMS-envelope seller credential bundle, and is reused only to refresh that seller's Gmail access token.
 
 Buyer TEE requests use the same attested upload key and compact JWE envelope. The typed helper encrypts the captured
 session material, posts `{ encryptedSessionMaterial, params, chainId, intent }` to
 `POST /buyer/verify/:platform/:actionType`, unwraps the service envelope, and returns a typed `AttestationOutput`.
-The service does not enforce capture-age or one-use replay limits for buyer TEE session material; verification depends
-on the upstream session still being active. A leaked encrypted JWE is therefore valid for the upstream session
-lifetime — treat any accidental disclosure as equivalent to leaking the underlying upstream credential (cookies, PAT,
-etc.) and rotate the upstream session.
+The service does not enforce capture-age or one-use replay limits for reusable
+buyer TEE session material; verification depends on the upstream session still
+being active. Treat any accidental JWE disclosure as equivalent to leaking its
+underlying private evidence.
 
 ```ts
 const attestation = await nitro.verifyBuyerTeePayment({
@@ -153,19 +155,76 @@ Buyer TEE platform matrix:
 | `zelle` | `transfer_zelle_chase` | `Cookie`, `x-jpmc-channel`, `x-jpmc-csrf-token`, `Referer`, `Origin` | `index` |
 | `zelle` | `transfer_zelle_citi` | `Cookie` | `index` |
 | `paypal` | `transfer_paypal` | `Cookie` | `PAYMENT_ID` |
+| `monobank` | `transfer_monobank` | `gatewayState`, `browserId` | `CLIENT_ID`, `TRANSACTION_ID` |
 | `alipay` | `transfer_alipay` | `Cookie` | `TRADE_NO` |
+| `upi` | `transfer_upi_amazonpay` | `Cookie`, `User-Agent`, `body` | `TRANSACTION_URL` |
+| `xmoney` | `transfer_xmoney` | `url`, `Cookie` and other captured session headers | `{}` |
+
+Monobank buyer verification uses the entrepreneur business portal session. Capture
+`localStorage.gateway` as `gatewayState`, and encode the raw P-256 public key from
+`localStorage.browserId.publicKey` as unpadded base64url `browserId`. Encrypt both
+inside the normal buyer JWE. `CLIENT_ID` selects the business profile and
+`TRANSACTION_ID` selects its payment detail. The attestor constructs and encrypts
+the bank request itself; caller-supplied payment JSON or encrypted request bodies
+are rejected. It accepts settled outgoing UAH transfers (bank currency code 980),
+hashes the recipient IBAN and bank payment ID, and signs a service-owned 14-day
+buffer. The previous buyer Open API token shape is no longer accepted.
+
+X Money replays the captured `url`, including X's current GraphQL operation ID,
+just as Chime replays its captured `body`. Both stay inside encrypted session
+material. The attestor owns endpoint and operation validation; X Money remains
+GET-only on `https://x.com`, derives the transaction ID from the captured URL,
+and requires the response ID to match. Ship the X Money extension capture and attestor changes
+together; captures without `url` are rejected. Chime's contract is unchanged.
 
 Zelle buyer verification uses only `platform: "zelle"` with bank-specific action types. Every Zelle action attests
 `intent.paymentMethod = hashUtf8("zelle")`; direct bank-specific platforms are unsupported.
 
+Amazon Pay uses `platform: "upi"` and `actionType: "transfer_upi_amazonpay"`.
+Capture the `getTransactionHistory` GraphQL request after signing into Amazon
+Pay and applying a transaction-history filter. Send its headers and exact request
+body as encrypted session material, with only the selected history row's
+`transactionDetailPageURL` as `params.TRANSACTION_URL`. The service rebuilds the
+history query, confirms the selected outgoing payment, and fetches its receipt;
+receipt URL labels alone do not establish payment direction. Both UPI actions use
+the same `upi:<UPI reference>` payment-id preimage. Amazon session cookies remain
+subject to server-side expiry or revocation; the package does not refresh them.
+
 Per-platform session-material types require these headers using the canonical names shown above while still allowing
 additional captured headers. Captured request bodies are session material because they can contain sensitive data and
 are encrypted before being sent to the service.
 
-Identity requests use the same generic attested upload envelope as buyer TEE. The typed request helper encrypts the
-captured session material, normalizes the outer `callerAddress`, posts
-`{ platform, actionType, callerAddress, encryptedSessionMaterial, params }` to the public `POST /identity` endpoint,
-unwraps the service response, and returns an `IdentityAttestationOutput`. `verifyIdentityAttestation` checks the EIP-712 signature, trusted signer,
+Dispute verification uses the same attested key and compact JWE shape. The complete raw email stays encrypted, and all
+payment, dispute, and amount fields come from its authenticated contents rather than public params.
+
+```ts
+const dispute = await nitro.verifyDispute({
+  platform: "venmo",
+  actionType: "dispute_venmo",
+  sessionMaterial: { rawEmail: completeRfc5322Email },
+  params: {},
+  chainId,
+  intentHash,
+});
+
+const verifiedDispute = verifyDisputeAttestation(dispute, {
+  trustedSigners,
+  expectedPlatform: "venmo",
+  expectedActionType: "dispute_venmo",
+  expectedDomain: { chainId, verifyingContract: disputeVerifier },
+  expectedIntentHash: intentHash,
+});
+```
+
+Venmo uses `dispute_venmo`; PayPal uses `dispute_paypal`. Both accept only `{ rawEmail }` encrypted session material
+and `{}` public params. `verifyDisputeAttestation` checks the DisputeVerifier EIP-712 domain, the same trusted
+attestation-service witnesses used by payment and identity, the request intent, the signed data hash, and exact parity
+between `disputeDetails` and `encodedDisputeDetails`.
+
+Identity requests use the same attested upload key and compact JWE plaintext shape as buyer TEE, but with a narrower
+platform/action matrix. The typed helper encrypts captured session material, posts
+`{ platform, actionType, callerAddress, encryptedSessionMaterial, params }` to `POST /identity`, unwraps the service response, and
+returns an `IdentityAttestationOutput`. `verifyIdentityAttestation` checks the EIP-712 signature, trusted signer,
 platform/action binding, expected caller address, expected payee hash, canonical identity `dataHash`, and `validUntil`,
 then returns normalized identity details.
 
@@ -215,7 +274,9 @@ For Cash App identity, pass the replayable Cash App session cookie as `sessionMa
 
 For Alipay identity, pass a replayable `Cookie` header. The service fetches the authenticated account page and signs
 the historical transfer-recipient preimage: normalized recipient name concatenated directly with the redacted,
-lowercased email. The full normalized email is returned as `identity.username` for Curator binding.
+lowercased email. CJK names use their final CJK character to match Alipay's masked transfer detail; non-CJK names keep
+the existing token normalization. The normalized full email remains `identity.username`; the authenticated account's
+16-digit PID is returned as `identity.metadata.alipayPid` for payment routing.
 
 Buyer TEE and identity expose discriminated unions keyed by `platform` and `actionType`, including per-platform
 `params`, so invalid pairings fail during TypeScript compilation. Seller credential upload keeps its existing
@@ -268,6 +329,17 @@ Identity helpers emit `{ platform, actionType, sessionMaterial, boundPubKeySha25
 like buyer TEE capture. The outer `callerAddress` is required by `POST /identity` and included in the signed typed data,
 but is not encrypted into or authenticated by the session envelope.
 
+For dispute flows with a cached attestation:
+
+```ts
+const encryptedSessionMaterial = await nitro.encryptDisputeSessionMaterial({
+  key: verified.attestedSellerUploadKey,
+  platform: "paypal",
+  actionType: "dispute_paypal",
+  sessionMaterial: { rawEmail: completeRfc5322Email },
+});
+```
+
 The attested SPKI is stable within one enclave process. If the enclave restarts, cached keys become stale and upload decrypt will fail; fetch a fresh attestation for a new session.
 
 ## React Native Wiring
@@ -290,18 +362,23 @@ Any conforming `SubtleCrypto` works. The package does not require `Buffer`.
 ```ts
 import {
   createEncryptedBuyerTeeSessionMaterial,
+  createEncryptedDisputeSessionMaterial,
   createEncryptedIdentitySessionMaterial,
   createEncryptedSellerCredentialUpload,
   encryptBuyerTeeSessionMaterial,
+  encryptDisputeSessionMaterial,
   encryptIdentitySessionMaterial,
   encryptSellerCredentialUpload,
   fetchAndVerifyAttestation,
   getUnifiedPaymentVerifierDomainSeparator,
+  getDisputeVerifierDomainSeparator,
   hashUtf8,
   requestIdentityAttestation,
   uploadSellerCredential,
   verifyBuyerTeePaymentAttestation,
   verifyBuyerTeePayment,
+  verifyDispute,
+  verifyDisputeAttestation,
   verifyIdentityAttestation,
   verifySellerCredentialBundle,
 } from "@zkp2p/zkp2p-attestation";

package/dist/cli/verify.js

@@ -4510,10 +4510,8 @@ var DEFAULT_TIMEOUT_MS = 1e4;
 // src/trust/pins.ts
 var STAGING_PCR8 = "5636e3bd96f847cf12cfd9de7faa8cad0e6fa00962ce16ba185f8e5ea57105abb3cc9cc34f1e1e4de3444ceabcca7485";
 var PRODUCTION_PCR8 = "41a4ae0b9b96752cab5addb7d22689b3070e564e29f90a54316fa33fa38ea51387a6e887ea4f5a4b0cc34f69cea3f40e";
-var PREPROD_PCR8 = "5453c5bfb7d040285be5ba9af142f4fbdd9685d082f244b66c62bf7b22d8d02a638fa2e02b9a6fe8877953a9429209e0";
 var DEFAULT_EXPECTED_PCR8_BY_HOST = {
   "attestation-service-staging.zkp2p.xyz": normalizePcr8Pin(STAGING_PCR8, "bundled staging PCR8"),
-  "attestation-service-preprod.zkp2p.xyz": normalizePcr8Pin(PREPROD_PCR8, "bundled preprod PCR8"),
   "attestation-service.zkp2p.xyz": normalizePcr8Pin(PRODUCTION_PCR8, "bundled production PCR8")
 };