From a552e393b1389f73192cdcc214f12b814d63501c Mon Sep 17 00:00:00 2001 From: Arc Studio Agent Date: Wed, 7 Oct 2026 19:08:35 +0000 Subject: [PATCH] docs(ack-pay): document incomplete verifyPaymentReceiptClaim checks The verifyPaymentReceiptClaim function only validates the schema of the credential subject but does not perform deeper semantic verification (expiry of paymentRequestToken, paymentOptionId membership). These gaps are already handled by verifyPaymentReceipt, but the ClaimVerifier interface leaves the intent unclear. Replace the vague 'For now' comment with a structured TODO that names exactly which checks are missing, why they are absent (interface constraints), and where the equivalent checks already live. --- .../ack-pay/src/receipt-claim-verifier.ts | 21 +++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/packages/ack-pay/src/receipt-claim-verifier.ts b/packages/ack-pay/src/receipt-claim-verifier.ts index ccc01658..3020762d 100644 --- a/packages/ack-pay/src/receipt-claim-verifier.ts +++ b/packages/ack-pay/src/receipt-claim-verifier.ts @@ -41,7 +41,25 @@ async function verifyPaymentReceiptClaim( throw new InvalidCredentialSubjectError() } - return Promise.resolve() + // TODO: The schema check above confirms the credential subject is + // structurally valid (paymentRequestToken is a JWT string, paymentOptionId + // is present). Deeper semantic checks that could be added here: + // + // 1. Verify that paymentRequestToken is not expired (call + // verifyPaymentRequestToken with verifyExpiry: true). Note that + // verifyPaymentReceipt already does this on the outer credential, but + // the ClaimVerifier runs against the proof-decoded subject and could + // enforce it independently. + // + // 2. Verify that paymentOptionId matches one of the options in the + // decoded paymentRequestToken. verifyPaymentReceipt already performs + // this check, but centralising it here would make the ClaimVerifier + // self-contained and usable outside of verifyPaymentReceipt. + // + // Both checks require the resolver (or at minimum the decoded payment + // request), so the ClaimVerifier interface would need to be extended to pass + // additional context, or the checks should remain in verifyPaymentReceipt + // where that context is already available. } /** @@ -52,7 +70,6 @@ async function verifyPaymentReceiptClaim( export function getReceiptClaimVerifier(): ClaimVerifier { return { accepts: (type: string[]) => type.includes("PaymentReceiptCredential"), - // For now, we just verify the credential subject matches the expected schema verify: verifyPaymentReceiptClaim, } }