All packsApp Store MachinerySolve
app store server api jws verification x5c chain
Trusting a transaction means verifying its whole certificate chain
A transaction's JWS carries an x5c certificate chain that has to verify all the way to an Apple root cert -- trusting the payload without walking that chain trusts nothing.
What goes wrong
StoreKit 2 transactions and Server Notifications arrive as signed JWS payloads whose x5c header carries a certificate chain, and the server has to walk that chain up to a genuine Apple root certificate to actually trust the payload's contents. Code that decodes the JWS (reading its claims as plain JSON, which is trivial since JWS payloads are just base64) without verifying the signature and chain accepts anything shaped like a valid transaction, including one an attacker constructed themselves.
Why agents get it wrong
A JWS is easy to partially decode without a library at all -- split on dots, base64-decode the middle segment, read the JSON -- and that shortcut produces data that looks completely legitimate for every transaction that actually came from Apple, since real payloads decode to sensible-looking claims. Nothing about that shortcut fails until someone deliberately sends a forged payload, which a functional test suite built around real Apple transactions never does.
What App Store Machinery pre-decides
The server is architected as the entitlement authority specifically because client-reported state can't be trusted (decision 2): every transaction is verified server-side via @apple/app-store-server-library's SignedDataVerifier, configured with Apple's actual root certificates fetched once from apple.com and committed to the repo. The pack's own test strategy (decision 13) generates a real 3-certificate ECDSA chain with Apple's marker OIDs and runs the genuine verifier against it offline, including negative tests -- tampered payload, wrong bundle id, wrong environment -- that must all reject.
Source: ARCHITECTURE.md decisions 2, 3, 5