@zkp2p/zkp2p-attestation 1.6.3 → 3.0.0

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # Changelog
 
+## 3.0.0
+
+- BREAKING: `/identity` and its package helpers now require normalized `callerAddress` inside session-material JWEs and require the encrypted address to match the outer request. Unbound identity envelopes are rejected; buyer TEE envelopes are unchanged.
+- Add typed Alipay buyer TEE and identity requests using `transfer_alipay`/`register_alipay` with encrypted `Cookie` session material.
+- Add typed Monobank buyer TEE payloads using `transfer_monobank`, encrypted `X-Token` session material, and `ACCOUNT_ID`/`TRANSACTION_ID` params.
+- Type seller-produced Monobank identity attestations as `register_monobank` while keeping Monobank excluded from the standalone identity request API.
+
+## 2.0.0
+
+- Hard-cut the preprod hostname to the isolated preprod enclave PCR8. Production remains pinned only at `attestation-service.zkp2p.xyz`.
+- BREAKING: Buyer TEE Zelle verification now accepts only `platform: "zelle"` with `transfer_zelle_bofa`, `transfer_zelle_chase`, or `transfer_zelle_citi`. All three actions attest the generic Zelle payment-method hash.
+
 ## 1.6.3
 
 - Bind the default global `fetch` fallback to `globalThis` so browser and extension callers that rely on SDK defaults do not hit receiver-sensitive `Illegal invocation` failures. Caller-provided `fetch` overrides are still used unchanged.
@@ -15,7 +27,7 @@
 
 ## 1.6.0
 
-- Add generic buyer TEE Zelle typing for `platform: "zelle"` and bank-specific action types `transfer_zelle_bofa`, `transfer_zelle_chase`, and `transfer_zelle_citi`; direct bank-specific Zelle routes and method hashes remain legacy drain-only.
+- Add generic buyer TEE Zelle typing for `platform: "zelle"` and bank-specific action types `transfer_zelle_bofa`, `transfer_zelle_chase`, and `transfer_zelle_citi`.
 
 ## 1.5.1
 

package/README.md

@@ -10,7 +10,9 @@ The package runs in Chrome MV3 service workers, browser DOM contexts, React Nati
 yarn add @zkp2p/zkp2p-attestation
 ```
 
-During monorepo development, point clients at `attestation-service/package/zkp2p-attestation`.
+In the protocol coordination workspace, `bin/workspace refresh-packages`
+creates an ignored local package link for declared consumers. Standalone builds
+and deployments must install a published package version.
 
 ## Environment Init
 
@@ -31,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 historical `https://attestation-service-preprod.zkp2p.xyz` hostname remains pinned to the same production PCR8 while it continues to serve the Nitro prod deployment.
+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.
 
 ## Fast Path
 
@@ -75,7 +77,7 @@ const verifiedCredentialBundle = verifySellerCredentialBundle(credentialBundle,
 });
 ```
 
-Venmo, Cash App, PayPal, and Zelle still require a top-level `payeeId`; existing callers can keep using the same call shape:
+Venmo, Cash App, and PayPal still require a top-level `payeeId`; existing callers can keep using the same call shape:
 
 ```ts
 const encryptedUpload = await nitro.createEncryptedSellerCredentialUpload({
@@ -84,12 +86,8 @@ const encryptedUpload = await nitro.createEncryptedSellerCredentialUpload({
 });
 ```
 
-Venmo seller uploads can use either the existing session material or Google OAuth. For Google OAuth, pass the numeric Venmo account id as `payeeId` and use `sessionMaterial: { credentialSource: "google_oauth", authorizationCode, redirectUri }`; the service validates Gmail access against venmo.com DKIM-signed incoming payment receipts. To onboard through a partner-owned Google OAuth app instead of Peer's default app, include `oauthClient: { clientId, clientSecret }` inside that encrypted `sessionMaterial`. The client secret is seller credential material: the package only places it in the compact JWE upload plaintext, it reaches the service enclave through that JWE, and the service persists it only inside the KMS-envelope-sealed seller credential bundle that the curator holds as ciphertext. It rides the same encrypted credential envelope as the Gmail refresh token and is reused only for later Gmail token refresh.
-
 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.
 
-Zelle seller uploads use the same Gmail OAuth shape with `platform: "zelle"` and a top-level `payeeId` for the seller's Zelle recipient identifier. The service validates the OAuth mailbox by finding at least one DKIM-verified incoming Zelle receipt from a supported bank/Zelle sender, then later resolves `/seller/verify/zelle` by matching `txId` against the received receipt's transaction, confirmation, reference, or payment id. Seller Zelle attestations use the generic on-chain payment method `keccak256("zelle")`; receipt providers such as Chase, Citi, and Bank of America are metadata only.
-
 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`.
@@ -150,25 +148,22 @@ Buyer TEE platform matrix:
 | `monzo` | `transfer_monzo` | `Authorization` | `TX_ID` |
 | `wise` | `transfer_wise` | `Cookie` or `X-Access-Token` | `PROFILE_ID`, `TRANSACTION_ID` |
 | `revolut` | `transfer_revolut` | `Cookie`, `x-device-id` | `index` |
-| `citi` | `transfer_zelle` | `Cookie` | `index` |
 | `chime` | `transfer_chime` | `Cookie`, `body` | `{}` |
-| `chase` | `transfer_zelle` | `Cookie`, `x-jpmc-channel`, `x-jpmc-csrf-token`, `Referer`, `Origin` | `index` |
-| `bankofamerica` | `transfer_zelle` | `Cookie` | `index` |
 | `zelle` | `transfer_zelle_bofa` | `Cookie` | `index` |
 | `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` |
+| `alipay` | `transfer_alipay` | `Cookie` | `TRADE_NO` |
 
-The generic Zelle buyer routes use bank-specific action types and attest `intent.paymentMethod = hashUtf8("zelle")`.
-New Zelle deposits and intents should use generic `zelle`. Direct bank-specific routes remain available only for
-legacy drain support with `hashUtf8("zelle-citi")`, `hashUtf8("zelle-chase")`, or `hashUtf8("zelle-bofa")`.
+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.
 
 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 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
+Identity requests use the same attested upload key as buyer TEE, but use a caller-bound plaintext envelope. The typed
+helper normalizes `callerAddress`, encrypts it together with 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`,
@@ -204,6 +199,11 @@ Identity platform matrix:
 | `paypal` | `register_paypal` | `Cookie` | `{}` |
 | `wise` | `register_wise` | `Cookie`, `X-Access-Token` | `PROFILE_ID` |
 | `cashapp` | `register_cashapp` | `sessionCookie`, `requestPayload`, optional `requestHeaders` | `{}` |
+| `alipay` | `register_alipay` | `Cookie` | `{}` |
+
+This matrix is intentionally limited to the caller-bound `POST /identity` request flow. A Monobank seller credential
+upload can additionally return a typed `IdentityAttestationOutputFor<"monobank">` with `register_monobank`; consumers
+can pass that response directly to `verifyIdentityAttestation`, but cannot request it through `POST /identity`.
 
 For Venmo identity, pass `SENDER_ID` in public params and include a replayable `Cookie` header in encrypted session
 material. The service verifies the authenticated account id, derives the stories URL from `SENDER_ID`, and requires
@@ -213,12 +213,16 @@ For Cash App identity, pass the replayable Cash App session cookie as `sessionMa
 `MY_ACTIVITY_WEB_V2` activity request body as `sessionMaterial.requestPayload`. Include captured replayable headers in
 `sessionMaterial.requestHeaders` when needed; the service ignores public params for this flow.
 
+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.
+
 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
-platform narrowing (`wise` derives payee id from the credential; Venmo, Cash App, PayPal, and Zelle require `payeeId`) but
-does not add exhaustive `sessionMaterial` typing: each seller platform can accept multiple credential sources, such as
-cookie headers or Google OAuth with optional partner OAuth client material, and encoding all combinations would make
-the SDK brittle without improving the wire contract.
+platform narrowing (Wise and Monobank derive payee id from the credential; Venmo, Cash App, and PayPal require
+`payeeId`) but
+does not add exhaustive `sessionMaterial` typing because the service owns connector-specific validation and the SDK
+would otherwise duplicate the wire contract.
 
 ## Cache-Friendly Path
 
@@ -254,12 +258,18 @@ const encryptedSessionMaterial = await nitro.encryptIdentitySessionMaterial({
   key: verified.attestedSellerUploadKey,
   platform: "paypal",
   actionType: "register_paypal",
+  callerAddress: "0x0000000000000000000000000000000000000002",
   sessionMaterial: {
     Cookie: "<captured-cookie-header>",
   },
 });
 ```
 
+Identity helpers emit `{ platform, actionType, sessionMaterial: { callerAddress, sessionMaterial },
+boundPubKeySha256 }` inside the compact JWE. The service requires the encrypted, normalized address to exactly match
+the outer request address before any provider request or signature. Identity JWEs created without this binding are
+rejected and must be regenerated. Buyer TEE envelopes retain their existing wire shape.
+
 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

package/dist/cli/verify.js

@@ -4510,9 +4510,10 @@ 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(PRODUCTION_PCR8, "bundled production PCR8"),
+  "attestation-service-preprod.zkp2p.xyz": normalizePcr8Pin(PREPROD_PCR8, "bundled preprod PCR8"),
   "attestation-service.zkp2p.xyz": normalizePcr8Pin(PRODUCTION_PCR8, "bundled production PCR8")
 };