QR Trust Problem Diagram¶

Date: 2026-08-21

Purpose: - render the paper's Figure 1 as a diagram the docs site can display and zoom - show why successful decoding is not the same thing as trust

Source figure: - Figure 1 in the published QR trust paper - published visual asset: QR_TRUST_PROBLEM_DIAGRAM.svg - semantic reference: QR_TRUST_PROBLEM_DIAGRAM_ASCII.md

The SVG remains the authoritative published artwork. The diagrams below restate the same relationships in the docs' own diagram style; if the two ever diverge, the paper's figure governs.

Diagram color key

Color encodes function, not trustworthiness: blue marks the framing columns, red marks the failure this figure is about, amber marks a limit of the current approach, violet marks the architectural conclusion, and green marks the decision layer the trust stack builds toward. Select any diagram to open the interactive zoom-and-pan view.

Why Decoding Is Mistaken for Trust¶

graph TD S["What scanners do today
convenience pipeline
1. detect QR
2. decode payload
3. surface URL or app intent
4. let the user absorb the risk"] I["What the industry keeps focusing on
integrity layer
signed payloads
certificate checks
HTTPS transport
cleaner warning UI"] U["What users actually need
trust questions
1. who issued this code?
2. is the issuer trusted?
3. is the destination still approved?
4. is opening it safe right now?"] S --> I I --> U SF["Failure
successful decoding is mistaken for trust;
the scanner answers what is this,
never should I trust it"] IL["Limit
a QR can be syntactically valid,
cryptographically valid,
and still unsafe"] UC["Consequence
trust is a managed platform signal,
not a property of successful decoding"] S --> SF I --> IL U --> UC classDef framing fill:#eaf2ff,stroke:#1d4ed8,color:#172033,stroke-width:2px; classDef failure fill:#fee2e2,stroke:#b91c1c,color:#450a0a,stroke-width:2px; classDef limit fill:#fff6db,stroke:#d97706,color:#4a2b05,stroke-width:1.5px; classDef conclusion fill:#f1edff,stroke:#7c3aed,color:#2e2153,stroke-width:1.5px; class S,I,U framing; class SF failure; class IL limit; class UC conclusion;

The three columns read left to right as an escalation: what scanners ship, what the industry has invested in, and what a user is actually trying to find out. Each column drops to the problem it leaves unsolved.

Required Trust Stack¶

graph LR T1["1. Issuer legitimacy
who is authorized to issue this QR
under a trusted program?"] --> T2["2. Destination binding
is the QR still bound to the
issuer-approved destination?"] T2 --> T3["3. Runtime safety
is the destination safe now?
compromise can happen after issuance"] T3 --> T4["4. Scanner decision UX
user-visible outcomes that separate
unverified, signed unaccepted issuer,
verified issuer, risky destination, blocked"] classDef layer fill:#f1edff,stroke:#7c3aed,color:#2e2153,stroke-width:1.5px; classDef decision fill:#e8f8f5,stroke:#0f766e,color:#123c38,stroke-width:2px; class T1,T2,T3 layer; class T4 decision;

Issuer legitimacy: Examples of what a trusted program accredits: verified individual, verified business, verified institution, payment operator.
Destination binding: Checks: exact URL, normalization, subdomain policy, post-issuance changes.
Runtime safety: Inputs: redirects, reputation, malware, phishing, injected content.
Scanner decision UX: The five outcomes above are specified in SCANNER_UX_STATES.md and mapped to policy in SCANNER_DECISION_MATRIX.md.