Hi Mohamad, Agreed. Let's report N2 and the dispatch check separately.
I should also have linked our native PSEA adapter: https://github.com/emiliaprotocol/emilia-protocol/blob/e507acdf8efbe8951cb4294801d4c440f0b86a5a/packages/verify/src/aeb-psea-adapter.ts It verifies the ES256 proof and recomputes the action digest against pinned verifier inputs. It is pinned to -02, not your current -03, so this is not a result against your 31-case suite. At dispatch, our adapter snapshots the parameters before asynchronous verification and passes that snapshot to the provider: https://github.com/emiliaprotocol/emilia-protocol/blob/e507acdf8efbe8951cb4294801d4c440f0b86a5a/packages/gate/src/adapters/_kit.ts#L86 For the shared case, the executor test should check the actual provider-call parameters as well as refusal after the amount mutation. N11 still needs separate evidence of verification before dispatch. A valid token alone cannot establish that ordering. Best, Iman On Thu, 15 Oct 2026 09:25:23 +0300, Mohamad Khalil Yossif <[email protected]> wrote: > > Iman, > > > > Thanks, that is the case I meant. Your Gate test covers one half: the > > executor refuses a changed amount. The other half is evidence a relying > > party can check without trusting whoever produced the signoff. > > > > The verifier side of your case is already in the published suite: N2, > > changed subject, refused with DIGEST_MISMATCH. What it cannot show is > > that dispatch used the parameters that were verified. That is your > > half, and it is the ordering gap the suite declares as N11. > > > > So the shared case could be: one approval, the amount changed, refused > > at the digest check, and refused again at dispatch. If your Gate ever > > verifies a PSEA token directly, the 31 cases would be the > > interoperability check you mention. > > > > Mohamad _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
