Research Foundations

This page lists the studies behind OpenIAP's guarantees: what each one showed, and where the project applies it. Inline citations across the docs link back to these sources.

Payment security#

Study	What it showed	Where OpenIAP applies it
VirtualSwindle — Mulliner, Robertson, Kirda. AsiaCCS 2014	A fully automated attack on Android in-app billing cracked 60% of 85 popular apps that trusted client-side purchase state.	The server-side verification requirement in Validation, and the conformance MUST behavior `verification.forged-token-is-invalid`.
Show Me the Money! — Yang et al. NDSS 2017	Payment vulnerabilities trace back to payment SDK design, ambiguous documentation, and vulnerable sample code, which lead merchants into the mistakes that follow.	The reason OpenIAP exists as one audited specification with consistent SDKs and a conformance suite, instead of per-store integrations.

Conformance and differential testing#

Study	What it showed	Where OpenIAP applies it
Frankencerts — Brubaker et al. IEEE S&P 2014	When several implementations of one specification disagree on the same input, the disagreement is a cheap source of candidate defects — 8.1M mutated inputs exposed 208 discrepancies in SSL/TLS validation. A disagreement is a candidate, not a verdict: the authors allow that some are benign where behavior is unspecified.	The differential mode of the conformance runner, which runs adapters side by side and reports divergences. Ships as `openiap-conformance/differential` with suite 3.0.0.
Parsing JSON is a Minefield — Seriot, 2016	No two of 34 JSON parsers behave identically; whatever a specification leaves loose, implementations will diverge on.	The versioned behavior registry: each behavior pins down semantics the GraphQL schema alone cannot, so six SDKs cannot drift apart silently.
Metamorphic Testing — Chen et al. ACM Computing Surveys 2018	Systems without a predictable expected output are verified through relations between executions instead of exact outputs.	The metamorphic relation registry used to verify live store behavior — for example, a purchased item must appear in a following restore. Ships as `openiap-conformance/metamorphic` with suite 3.0.0.

Versioning and API evolution#

Study	What it showed	Where OpenIAP applies it
Raemaekers, van Deursen, Visser. Journal of Systems and Software 2017	About one third of releases across 22,000 Maven libraries introduce breaking changes regardless of their version label.	The schema semver guard: CI diffs the GraphQL schema on every pull request and fails on any breaking change that has not been explicitly acknowledged as release-planned.
Breaking Bad? — Ochoa et al. Empirical Software Engineering 2022	20.1% of non-major upgrades in Maven Central contain breaking changes.	The same guard, plus the version floor policy in `openiap-versions.json` that release audits enforce.
Why and How Java Developers Break APIs — Brito et al. SANER 2018	Breaking changes are mostly deliberate — new features, simplification, maintainability — so detection cannot rely on author intent.	Mechanical, review-independent detection: the guard runs on every schema change, not only on releases someone marked as risky.

API learnability and misuse#

Study	What it showed	Where OpenIAP applies it
What Makes APIs Hard to Learn? — Robillard, IEEE Software 2009, with the 2011 field study by Robillard and DeLine	Documentation is the dominant obstacle to learning an API. The 2009 article surveys and interviews developers; the 2011 field study, across more than 440 professional developers, is the source of the documentation factors.	The reader-first standard every OpenIAP doc follows, and the issue-mining pipeline that collects nine years of failure reports across the six SDK ecosystems as the evidence base for troubleshooting docs.
MUBench — Amann et al. MSR 2016	API misuse is a rare but disproportionately severe bug class — 61 of the 89 catalogued misuses cause crashes.	The IAP misuse catalog — patterns like granting entitlement from unverified local state or skipping finishTransaction — mapped, where a mechanical check exists, to the conformance behavior that detects it.

Supply chain#

Study	What it showed	Where OpenIAP applies it
Small World with High Risks — Zimmermann et al. USENIX Security 2019	A small number of packages or compromised maintainer accounts can reach most of an ecosystem; unmaintained packages ship known vulnerabilities for years.	The published SBOM, provenance, dependency snapshot, and Scorecard posture described in Supply Chain Security.

AI agents and MCP#

Study	What it showed	Where OpenIAP applies it
MCP at First Glance — Hasan et al. 2025	The first large-scale study of 1,899 open-source MCP servers measured recurring security and maintainability failures.	The threat-model review of the hosted IAPKit MCP server, kept next to the server code and re-run when tools or auth change.
MCP: Landscape, Security Threats — Hou et al. ACM TOSEM 2025	Decomposes the MCP server lifecycle into four phases with a threat model per phase.	The structure that same review follows: creation, deployment, operation, and maintenance are audited as separate tables.

Design rationale#

Why the Commerce Protocol draws its boundaries where it does — the reasoning behind each decision and the prior work it rests on — is published as a PDF under Whitepapers.

The full registry#

The annotated bibliography — including the engineering backlog items derived from each study — lives in the repository: knowledge/research. Every entry records where it is applied, and code derived from a study cites it back by key.