Trust Model¶

Date: 2026-04-12

Purpose: - define the platform-scale trust model behind the QR verifier idea - separate QR generation from issuer trust, runtime safety, and scanner UX - give publication and product work a coherent system center

Core Thesis¶

Signed QR codes are not enough.

What matters is whether the scanner can answer all of these questions:

1. who issued this QR?
2. is that issuer enrolled in a trusted program?
3. is this destination still the issuer-approved destination?
4. is opening that destination safe right now?

If the scanner cannot answer those questions, the QR may be: - syntactically valid - cryptographically valid - still unsafe to open

Design Principles¶

1. Any QR may exist¶

The system does not try to ban ordinary QR generation.

Anyone can still: - generate a QR with Python - print it - post it in public

The platform difference is: - not every QR receives a trust signal

2. Trust is a platform signal, not a QR property¶

A QR is not inherently trusted because it exists or because it contains a URL.

Trust is produced by: - issuer enrollment - policy enforcement - current destination validation - runtime safety checks - scanner UX

3. QR generation and trust enrollment are separate¶

The QR does not need to be generated by Apple, Google, or the root trust provider.

Generation can happen in: - a CMS plugin - a restaurant dashboard - a payment platform - a business portal - a local script

What matters is: - which issuer is bound to that QR - what destination set is approved - what the scanner trusts

4. The scanner should express trust state, not just decode state¶

Current phone scanners mostly answer: - "I found a URL"

A trust-aware scanner should answer: - "who vouched for this" - "whether that voucher is still valid" - "whether the destination is still safe to open"

Main Actors¶

1. Issuer¶

The party that wants a QR to be trusted.

Examples: - individual music teacher - small restaurant - ticketing provider - enterprise - school - bank

2. Enrollment Authority¶

The party that verifies issuer identity or eligibility and issues trust status.

Examples: - Apple / Google - payment providers - business verification providers - enterprise IT - federated trust operators

3. QR Generator¶

The tool that creates the QR artifact.

Examples: - platform dashboard - SaaS tool - plugin - script

This does not have to be the trust authority.

4. Runtime Safety Provider¶

The party that evaluates whether the destination is safe right now.

Examples: - Safe Browsing provider - mobile threat defense vendor - enterprise security vendor - platform-native risk engine

5. Scanner Platform¶

The phone, browser, tablet, or desktop scanner that consumes trust and safety state and presents it to the user.

Required System Capabilities¶

A. Issuer Identity¶

The system needs a notion of issuer identity strong enough to support trusted UX.

That identity may be: - personal - business - institutional - ecosystem-specific

B. Destination Binding¶

The issuer must bind one or more approved destinations.

The scanner must validate: - exact destination - normalization rules - optional subdomain rules - current issuer-approved state

C. Revocation And Status¶

The system must support: - issuer revocation - destination revocation - policy change after issuance - temporary safety advisories

D. Runtime Safety Evaluation¶

The system must distinguish: - trusted issuer - approved destination - currently risky destination

E. User-Facing Trust States¶

The platform must show consistent outcomes for: - verified - unverified - signed but unaccepted issuer - approved but risky - blocked

Practical Consequence¶

The real product is not: - "secure QR codes"

The real product is: - a managed trust program for machine-readable destinations

That trust program has to sit above ordinary web PKI and above raw QR decoding.

Non-Goals¶

This model does not assume: - all QR codes can be banned - every user will reveal full identity - browser TLS alone is enough - every QR needs deep malware scanning - every platform must use one global trust authority

Strategic Implication¶

The PoC remains useful as: - protocol reference - verifier behavior proof - payload-binding proof - replay-control proof

But ecosystem success depends on: - issuer enrollment - trust policy - runtime safety integration - platform adoption