Trust Residuals for Navigation QR Codes

1.1. Relationship to the Research Papers

The model and evaluation methodology were developed in [RESIDUALS], building on the trust-model framework of [QRTRUST]. This document specifies the residual input model, states, invariants, profiles, and decision procedure. [RESIDUALS] reports the measured comparison against weaker baselines, the ablation analysis, and the full evaluation methodology. Independent implementation, longitudinal operation, privacy measurement, issuance-time witness experiments, and human-subject evaluation remain research work rather than protocol guarantees.¶

1.2. Scope and Non-Goals

The conformance scope of this version is a Navigation QR Code whose decoded payload contains an absolute HTTP or HTTPS URI. Native app intents, deep links, non-HTTP payment schemes, and other action types require separate, versioned mappings and are outside this version.¶

The conformance claim is narrow and testable. Given a residual vector constructed from issuer, destination, status, freshness, safety, and artifact evidence, a decision engine maps it to a scanner state through the precedence rules in Section 7.¶

This version defines decision-semantics conformance. It does not define a QR payload carrier, complete signed governance-object schemas, cryptographic envelope, discovery or distribution protocol, media type, or registry. The object examples and binding requirements in Section 9 are design input to a future Standards Track binding. Evidence acquisition and the complete mapping from observations to residual severities likewise are not claimed as interoperable by the Delta conformance corpus.¶

The following remain outside the conformance claim:¶

• Enrollment coverage, business identity from a bare signature or URL reputation, universal maliciousness detection, and any requirement for machine learning.¶

• DNS resolution, hosting continuity, resource bytes, page content, and post-navigation browser state. R_D authorizes normalized URL components only; R_S and separately specified content-integrity mechanisms answer different questions.¶

• App intents, native deep links, payment URI schemes, complete governance objects, and an interoperable wire protocol.¶

• Improved user behavior without empirical testing of scanner states and warnings.¶

Deployment also requires root selection, issuer enrollment, revocation authority, scanner adoption, and tested user-interface behavior. This document does not specify those functions, presentation-mode QR payments inside closed ecosystems, brand recognition, governance selection, or liability.¶

1.3. Relationship to Existing Mechanisms

The RATS architecture [RFC9334] is the closest role-level comparison. A RATS Verifier appraises Evidence and emits Attestation Results; a Relying Party applies its own policy to decide an action. Here a QR verifier appraises the decoded payload and available signed state into R, then Delta produces (S,A,L) for the QR relying party that offers or blocks navigation. One scanner process can combine those two roles, but their policy responsibilities remain distinct.¶

This is an analogy, not a RATS profile. RATS Evidence is produced by an Attester about an attested environment. A merchant organization or authorized URL is not an EAT entity: EAT [RFC9711] reserves that notion for hardware or software, although a scanner's own platform attestation could separately use EAT. The active AR4SI work [AR4SI] defines reusable Attestation Result elements, categories, tiers, and JSON/CBOR serializations for consistent relying-party policy. QR Trust instead defines six navigation-specific residuals and Delta; it does not claim to extend AR4SI. The RATS Conceptual Message Wrapper [RFC9999] also demonstrates that an architecture's conceptual messages can remain separate from their typed wire wrapper; this document does not claim that CMW already types QR messages.¶

W3C Verifiable Credentials [VCDM] define a general credential data model. Separate W3C Recommendations define JOSE/COSE securing [VCJOSECOSE] and privacy-conscious suspension or revocation via Bitstring Status Lists [VCSTATUS]. A future QR binding could evaluate a VC representation or status mechanism, but VC alone does not define accepted-root policy, destination authorization, redirect observation, runtime-safety residuals, or Delta. QR capacity, processing cost, and privacy need measurement before such a binding is selected.¶

JWS [RFC7515] and COSE [RFC9052] are established signature envelopes, with their own protected-header, key, and algorithm machinery [RFC7517] [RFC8725] [RFC9053]. A future binding needs to select and fully profile one primary envelope rather than require both or invent a parallel generic signature envelope. JWS signs a JWS Signing Input, while COSE signs its Sig_structure; even when they carry the same application payload octets, their signature inputs and values are not byte-identical.¶

The Internet X.509 profile [RFC5280], TLS service-identity rules [RFC9525], and browser root-program governance are three separate layers. Together they can authenticate a TLS service under a locally accepted public root, but do not establish QR publisher legitimacy, authorize a path or query, or supply the decision semantics here. Domain-control evidence can support enrollment without turning a TLS certificate into business identity. Browser safe-browsing feeds likewise answer destination-reputation questions; invariants I1 and I2 prevent either signal from creating issuer trust.¶

RPKI [RFC6480] is a narrower design analogy. It uses resource certificates and CRLs, route-origin authorizations, signed manifests, untrusted repositories, and relying-party caches to constrain authorization over hierarchically allocated Internet number resources. QR Trust can learn from signed-object publication, revocation, manifest completeness, and cache freshness, but RPKI does not define QR status-event streams or previous_sequence chains, and QR issuer and destination identity do not inherit Internet-number allocation semantics.¶

SCITT [RFC9943] is the candidate substrate if a later QR binding needs statement transparency. SCITT defines COSE-enveloped Signed Statements, protected issuer and subject claims [RFC9597], registration with a Transparency Service, receipts, and verifiable history. A receipt can support audit and equivocation detection; it does not decide current QR trust, distribute urgent revocation, or replace local root acceptance and Delta. This -00 therefore defines no parallel transparency-log protocol.¶

A future binding should select one primary cryptographic envelope and application schema instead of stacking JOSE, COSE, VC, EAT, SCITT, and RPKI. Optional ecosystem and transparency bindings need separate implementation evidence.¶

ISO/IEC JTC 1/SC 31 owns QR symbology [ISO18004], which this document does not modify. Scanner user interfaces remain platform concerns. The DISPATCH question concerns the security architecture and decision semantics between issuers, status publishers, verifiers, and relying parties. A separate document can define signed-object and carrier bindings using established IETF mechanisms.¶

3.1. Verification Function

A complete verifier implements a function:¶

V(q, t, C_t, P) -> (S, A, L, R, E)

where q is the scanned artifact (decoded payload plus capture metadata), t is the evaluation time, C_t is the verifier's cached signed trust state at time t, and P is the active verification profile. The outputs are a decision state S (Section 6), a residual vector R, and an evidence set E that records the artifacts, hashes, sequence numbers, and freshness windows consulted. A is the ordered annotation list and L is the derived attention level.¶

The decision-semantics function specified by this document is the narrower function:¶

Delta(R, P) -> (S, A, L)

where P is the decision context defined in Section 8, A is the ordered annotation list, and L is the derived attention level. Delta does not acquire evidence or decide whether an observation justifies a residual tier. It consumes the closed input below.¶

The residual vector has one entry per family:¶

R = [R_I, R_D, R_R, R_S, R_F, R_A]

for issuer chain (R_I), destination policy (R_D), redirect flow (R_R), runtime safety (R_S), freshness (R_F), and artifact integrity (R_A).¶

3.2. Residual Record

Each residual is a record (tier, causes, evidence_refs, freshness_ref):¶

tier:

One token permitted for the family by Section 3.3. Delta consumes this field.¶

causes:

An ordered, duplicate-free list drawn from the family's enumeration in Section 4. A passing residual has an empty cause list. Causes explain appraisal but do not alter Delta independently of tier.¶

evidence_refs:

An ordered, duplicate-free list of opaque references into E that identify the signed artifacts, observations, or measurements used by the appraiser. Delta preserves but does not inspect them.¶

freshness_ref:

An opaque reference into E for the validity window, sequence, and evaluation-time facts used by appraisal, or null when the family is not applicable or no time-bound source applies. Delta does not re-evaluate time.¶

Mandatory-family membership is carried once in P, not duplicated in each residual. Confidence is outside the conformance record: an appraiser can retain a calibrated score in E, but Delta MUST ignore it.¶

3.3. Severity Lattice

The generic evidence tiers form the ordered set:¶

pass < unknown < stale < warn < fail < block

The generic unknown class is represented in the closed family vocabularies by three explicit tier tokens that decision rules can distinguish:¶

not-applicable:

The family does not apply to this artifact under the active profile (for example, redirect-flow evaluation for a payload with no redirect and a profile that does not require controlled resolution).¶

not-checked:

The verifier did not evaluate the family (for example, artifact integrity on a platform without capture forensics).¶

unavailable:

The verifier attempted evaluation and could not obtain the required state (for example, a runtime-safety provider that did not answer within its budget).¶

The decision input uses the following closed family-specific tier sets. no-issuer, unaccepted-issuer, invalid-managed-claim, revoked-issuer, and cross-root-contradiction retain issuer meaning that a generic severity would erase.¶

A decision engine MUST reject a missing family, an extra family, or a tier outside the permitted set before applying Delta. This validation turns unknown extensions into a loud version mismatch rather than the D15 caution default. D15 provides totality over valid combinations of the vocabulary above; it is not an extension mechanism.¶

The lattice orders evidence classes, not decision precedence. An insufficiency tier in a mandatory family can outweigh a warn tier in an optional family: rule D14 in Section 7 makes a mandatory family that lacks positive-eligible evidence fatal to positive eligibility, regardless of lattice position. Runtime safety has no not-applicable tier; see Section 4.4.¶

4.1. Issuer Chain (R_I)

Pass condition: the payload carries a managed trust claim whose signature verifies under a key bound to an issuer record, the issuer record chains through a valid delegation path to an accepted root, and every element of the path is within its validity window and free of revocation or suspension.¶

Residual causes: no-trust-claim, invalid-signature, invalid-trust-claim, unaccepted-root, unknown-issuer, malformed-chain, delegation-depth-exceeded, issuer-revoked, issuer-suspended, key-revoked, key-suspended, record-expired, record-not-yet-valid, key-window-mismatch, and trust-state-unavailable. The cause invalid-trust-claim marks a claim that is present but fails validation, used when a profile carve-out routes such a payload to "unverified" instead of "blocked" (Section 7).¶

A verifiable signature from an issuer outside every accepted root is not an error condition; it is the distinct "signed unaccepted issuer" outcome (Section 6).¶

4.2. Destination Policy (R_D)

Pass condition: under the appraiser's selected normalization and policy-matching profile, the final destination and, when a resolver is used, the first-hop resolver both fall within the issuer's signed destination policy (Section 9), and the policy itself is valid and in window. Section 10.1 explains why this condition needs a future binding before different appraisers can claim interoperability.¶

Residual causes: destination-not-authorized, resolver-not-authorized, policy-expired, policy-unavailable, normalization-failure, policy-invalid.¶

A destination outside the signed policy of an otherwise valid issuer is treated as adverse evidence, not as missing evidence: it yields severity "fail" and rule D6 (Section 7) maps it to "blocked", never to "unverified". A signed claim pointing outside its own policy is a stronger signal of compromise or misissuance than an unsigned code.¶

An R_D pass is URL authorization, not resource integrity. It says that the normalized scheme, host, port, path, and query satisfy the signed policy at evaluation time. It does not attest DNS resolution, hosting continuity, resource bytes, page content, or navigation after the scanner hands the URL to another user agent. A resource change behind the same authorized URL leaves R_D at "pass" unless some other policy or evidence family detects it.¶

4.3. Redirect Flow (R_R)

Redirect flow is evaluated in trusted mode when the payload carries a managed trust claim, because only then is a positive state reachable and worth protecting. Pass condition: under controlled resolution, the observed chain stays within the policy's allowed redirect hosts, does not exceed the policy's maximum depth, and terminates at a destination consistent with R_D.¶

Residual causes: depth-exceeded, unauthorized-intermediary, nested-shortener, resolver-mismatch, cloaking-indicator, resolution-unavailable.¶

4.4. Runtime Safety (R_S)

Pass condition: a fresh, signed runtime-safety verdict for the final destination (and resolver, when used) reports no adverse state.¶

Residual causes: verdict-warn, verdict-block, verdict-expired, verdict-stale, provider-unavailable, provider-disagreement.¶

Runtime safety MAY reduce trust but MUST NOT create issuer trust (invariant I1 in Section 5). This family has no "not-applicable" tier: every navigation has a present-time safety question. The only positive-eligible non-pass tier is "unavailable", and only when the active profile is neither strict-online (Section 8) nor marks runtime safety mandatory; a positive state emitted in that situation MUST carry a limited-visibility annotation. An expired verdict is recorded here (as verdict-expired) rather than in R_F, so that freshness of the safety signal and freshness of governance objects remain independently visible.¶

4.5. Freshness (R_F)

Pass condition: every governance object consulted (see Section 9 for the object types) is within its validity window, sequence numbers are monotonic with no observed rollback, no gap is observed in any previous_sequence-chained stream, and the verifier's clock is within the deployment's permitted skew of the objects' timestamps.¶

Residual causes: object-expired, object-not-yet-valid, sequence-rollback, sequence-gap, clock-skew-exceeded, cache-unverifiable.¶

State past its window but within an appraisal-profile grace bound is tier warn, distinct from block. Rule D9 in Section 7 governs the outcome: profiles of the strict class block, while the bounded and testing classes continue with an explicit warning annotation (profile classes are defined in Section 8).¶

4.6. Artifact Integrity (R_A)

Pass condition: capture-side analysis of the physical or digital artifact reveals no tampering indicators.¶

Residual causes: overlay-suspected, conflicting-symbols, framed-symbol-anomaly, print-provenance-anomaly, container-mismatch, analysis-unavailable.¶

Artifact-integrity analysis is probabilistic and environment dependent, so this family is supporting evidence by default: optional, advisory, and unable to create trust. Delta consumes an R_A tier of block without inferring how the appraiser reached it. A future appraisal binding must define the evidence and signed policy needed to assign block, including any treatment of conflicting symbols or overlays in a signed-only workflow. Other detections downgrade or annotate (rules D11 and D12) and become blocking only where P marks the family mandatory (m_A).¶

7.1. Decision Rules

The overall evaluation first applies the capture rule D0. If capture and decode succeed, the decision function Delta maps a residual vector and decision context P to one of the five decision states via the remaining rules. D0 stays in the table to make the total evaluation order explicit, but its result inhabits the separate capture-outcome type. Conditions abbreviate the pass conditions of Section 4; m_x denotes "family x is mandatory".¶

Rule D4's positive-eligibility predicate is: R_I is pass; R_D is pass or not-applicable; R_R is pass, warn, or not-applicable; R_S is pass or unavailable where the profile and m_S allow it; R_F is pass, warn, or not-applicable where the profile allows it; R_A is pass or warn; no mandatory family lacks positive-eligible evidence; and no earlier rule returned. Warn-grade evidence that survives to D4 surfaces as annotations, and any annotation removes the positive attention level (Section 6).¶

For D9, "continue" means that the annotation is accumulated before later rules run. If no later rule downgrades the result, D4 emits verified-issuer with stale-offline-warning, whose attention level is warning rather than positive. For D13, the exact strict result is blocked with no annotation; the exact bounded or testing result is unverified with incomplete-verification-warning. Both carry a cross-root-contradiction diagnostic reason. A stronger earlier block condition wins before D13.¶

D3 consumes issuer tiers, not raw signature or lifecycle evidence. invalid-managed-claim is the invalid-claim tier, while revoked-issuer is the block-grade issuer-or-key lifecycle tier; the cause list preserves whether appraisal observed an invalid signature, malformed chain, issuer suspension or revocation, or key suspension or revocation. Under reference-testing, invalid-managed-claim instead returns unverified with annotations invalid-trust-claim-warning then policy-profile-warning. revoked-issuer remains blocked under every profile.¶

D14's runtime-specific arms are exact: R_S stale blocks under strict-online and otherwise returns unverified with incomplete-verification-warning; R_S not-checked has the same outcomes; and R_S unavailable blocks under strict-online but continues with limited-runtime-safety-visibility under a non-strict profile unless P marks R_S mandatory. The general arm then applies to every family P marks mandatory. R_S warn is decision-grade risky evidence and belongs to D5, not to the missing-evidence arm of D14.¶

7.2. Evaluation Order

The overall evaluation uses the following order. D0 is the sole pre-Delta class. Once capture succeeds, Delta is total over every valid R and P. A terminal outcome returns immediately; an annotation step appends to A and continues:¶

1. Capture: D0.¶

2. Adverse blocks: D3; D6; D7; D8; the R_F block arm of D9; the strict-profile R_F warn arm of D9; D10; and the mandatory arm of D11.¶

3. Early adverse downgrades: the non-mandatory arm of D11, then D13.¶

4. Claim status: D1, then D2. These terminals intentionally precede optional-evidence annotation: an unsigned or unaccepted path does not gain warning qualifiers that cannot change its trust claim.¶

5. Runtime insufficiency: D14 handles R_S stale; strict profiles also block R_S unavailable and not-checked; non-strict profiles return an annotated caution for not-checked.¶

6. Annotation accumulation, in order: the non-strict R_F warn arm of D9; R_S unavailable; the R_A warn arm of D12; R_R warn; and the reference-testing profile marker.¶

7. Risky downgrade: D5.¶

8. General mandatory-family insufficiency: D14.¶

9. Totality: D15 catches a tier combination outside the positive- eligibility sets.¶

10. Positive terminal: D4.¶

Adverse evidence (fail or block in any family) preempts the claim-status outcomes: a payload with no managed trust claim but a blocking safety verdict is "blocked", not "unverified". Insufficiency (any "unknown" refinement or "stale") gates only the positive path: under the bounded and testing classes it never converts a claim-status outcome into a block by itself, and under the strict class mandatory-family insufficiency blocks (Section 8). The positive terminal fires only for vectors whose full eligibility predicate holds; because that predicate is self-guarding, D4 is reached only by vectors no earlier class matched. The totality class is evaluated immediately before D4, so that it catches exactly the valid vectors that cannot reach the positive terminal and every vector still reaches a state.¶

D4 repeats D12's warn-annotation condition so that the positive predicate can be read independently. Listing strict-profile D9 among the mandatory blocks does not change its outcome. The reference-testing profile (Section 8) routes invalid managed trust claims to "unverified" with an invalid-trust-claim cause and profile warnings, allowing negative fixtures to traverse the pipeline without invoking block handling; a corpus case pair pins this behavior (Section 15). Runtime safety has no "not-applicable" tier for the reason given in Section 4.4.¶

7.3. Worked Examples

Example 1. A table-tent code carries a valid claim from an issuer chained to an accepted root; the destination and resolver are within policy; the safety verdict, freshness, and artifact analysis all pass. No rule in classes 1-9 returns; D4 emits "verified issuer" with no annotations: the positive attention level.¶

Example 2. The same code, but the safety provider reports a warn-grade verdict for the destination. No terminal in classes 1-6 fires; class 7 applies D5 and emits "verified issuer destination risky". Invariant I1 is preserved: the warn reduced trust and could never have created it.¶

Example 3. A code carries a valid claim, but controlled resolution terminates at a host outside the signed destination policy. R_D is "fail"; class 2 matches at D6 and emits "blocked" -- despite the fully valid issuer chain, per invariant I3.¶

Example 4. An appraiser operating under a binding that classifies conflicting decodable symbols as R_A block supplies that tier to Delta. Class 2 matches at D10 and emits "blocked" regardless of profile or signature state. This document specifies the result of the tier, not the capture-to-tier classification.¶

8.1. Conformance

This version defines decision-semantics conformance, not complete verifier or wire-protocol conformance. Given R and P as closed above, a decision engine claiming conformance MUST implement Delta exactly and MUST satisfy the invariants of Section 5.¶

A deployed pipeline MAY demand more user attention than Delta for a given input (for example, blocking where Delta warns, under a declared stricter posture) but MUST NOT demand less. Delta agreement is REQUIRED for any positive state, and a deployment MUST NOT upgrade Delta's outcome. Every emitted state MUST carry its residual vector and evidence set (invariant I6), and profile identifiers outside the closed enumeration MUST be rejected before evaluation.¶

The acquisition of evidence and its appraisal into residual severities are inputs to this conformance surface; they are not fully specified by this version. Likewise, conformance to Delta does not establish interoperability for the illustrative governance objects or payload claims of Section 9. An implementation claiming broader verifier or wire interoperability needs a future binding and appraisal specification in addition to this decision-semantic core.¶

8.2. Versioned Conformance Representation

The following JSON shape is the versioned test-vector representation for qr-trust-delta-v1. It is not an on-the-wire verifier protocol, governance object, or QR payload encoding. JSON object member order is insignificant [RFC8259]; the example displays residuals in R family order only for readability. A decision engine MUST reject an unknown or missing member rather than ignore it.¶

{
  "semantics_version": "qr-trust-delta-v1",
  "profile": "bounded-offline",
  "mandatory_families": [],
  "evidence": {
    "e:issuer": "fixture:C10b:issuer-record",
    "e:issuer-window": "fixture:C10b:issuer-window",
    "e:policy": "fixture:C10b:destination-policy",
    "e:policy-window": "fixture:C10b:policy-window",
    "e:redirect-observation": "fixture:C10b:redirect-observation",
    "e:observation-time": "fixture:C10b:observation-time",
    "e:safety-verdict": "fixture:C10b:safety-verdict",
    "e:safety-window": "fixture:C10b:safety-window",
    "e:capture": "fixture:C10b:capture"
  },
  "residuals": {
    "issuer_chain": {
      "tier": "pass",
      "causes": [],
      "evidence_refs": ["e:issuer"],
      "freshness_ref": "e:issuer-window"
    },
    "destination_policy": {
      "tier": "pass",
      "causes": [],
      "evidence_refs": ["e:policy"],
      "freshness_ref": "e:policy-window"
    },
    "redirect_flow": {
      "tier": "pass",
      "causes": [],
      "evidence_refs": ["e:redirect-observation"],
      "freshness_ref": "e:observation-time"
    },
    "runtime_safety": {
      "tier": "pass",
      "causes": [],
      "evidence_refs": ["e:safety-verdict"],
      "freshness_ref": "e:safety-window"
    },
    "freshness": {
      "tier": "warn",
      "causes": ["object-expired"],
      "evidence_refs": ["e:issuer"],
      "freshness_ref": "e:issuer-window"
    },
    "artifact_integrity": {
      "tier": "pass",
      "causes": [],
      "evidence_refs": ["e:capture"],
      "freshness_ref": null
    }
  },
  "result": {
    "primary_state": "verified-issuer",
    "annotations": ["stale-offline-warning"],
    "attention_level": "warning"
  }
}

The top-level and residual-record member sets shown above are exact for this test-vector version; unknown or missing members are rejected, but member order is not examined. Every evidence_refs value and non-null freshness_ref value MUST name a member of evidence. Delta does not inspect those values, but their presence preserves the evidence association at the conformance boundary.¶

The annotation vocabulary is closed. A contains only artifact-warning, stale-offline-warning, limited-runtime-safety-visibility, redirect-variation-warning, invalid-trust-claim-warning, policy-profile-warning, and incomplete-verification-warning, in the order imposed by the evaluation rules. A conforming engine rejects an unknown or duplicate annotation. L is derived exactly: blocked maps to block; signed-unaccepted-issuer, verified-issuer-destination-risky, or any annotated result maps to warning; unannotated unverified maps to neutral; and unannotated verified-issuer maps to positive.¶

Diagnostic reason codes MAY accompany the result, but they are not an output of Delta and MUST NOT change S, A, or L. D0 is encoded as a separate capture outcome and MUST NOT be serialized as result.primary_state. The example above is the C10b decision class from the public corpus; the corpus remains the machine-checkable source of examples and expected outcomes.¶

9.1. Canonicalization and Signature Coverage

The semantic requirement is identity of the canonical application payload within a selected binding, not identity of signatures across formats. A future binding MUST select and completely profile one primary envelope. A JWS binding needs to define the JWS serialization, protected alg and kid processing, key discovery and representation, allowed algorithms, critical-header behavior, detached-payload rules, and media type using [RFC7515], [RFC7517], and [RFC8725]. A COSE binding needs the corresponding COSE structure, protected headers, algorithm and key identifiers, external additional authenticated data, detached-payload rules, and media type using [RFC9052] and [RFC9053].¶

JWS and COSE MUST NOT be treated as signing the same byte string. JWS signs its JWS Signing Input; COSE signs its Sig_structure. If two bindings represent the same semantic object, they can require the same canonical application payload octets, but their envelope-specific signature inputs and signature values differ. Within one selected binding, embedded and detached presentations must preserve the exact application payload octets and every security-affecting parameter must be integrity protected.¶

A future binding MUST reject an object whose application payload, envelope, sequence, or validity window cannot be checked under that binding's deterministic rules. This -00 does not define a generic raw signature field beside JOSE or COSE.¶

9.2. Object Types

Root trust program manifest:

Defines the trust anchor: root public keys, the accepted signature-algorithm set for the root's subtree, the delegation policy (allowed operator types, maximum delegation depth), recognized assurance tiers, and status distribution points. A separate future SCITT application binding can make selected root or governance statements transparent; a generic log field is not part of this template. Verifiers MUST reject a signature algorithm outside the root's declared set; algorithm rotation and post-quantum migration are manifest updates under the existing sequence and validity machinery, with Ed25519 [RFC8032] as the illustrative baseline. A root manifest defines the rules under which subordinate authorities can exist, not merely a key list.¶

Delegated operator manifest:

Binds an operator to the root's delegation policy and scopes what the operator may issue.¶

Issuer record:

Binds a specific issuer to keys, assurance attributes, and allowed policy scope.¶

Destination policy object:

Defines authorized destinations and resolver behavior. The policy MUST bind both the first-hop resolver and the final destination; otherwise a trusted-looking short URL can conceal an untrusted final destination. An illustrative template:¶

{
  "object_type": "destination_policy",
  "policy_id": "policy:restaurant-12345:v3",
  "root_id": "qrtrust.example.root",
  "operator_id": "merchant-platform.example",
  "issuer_id": "restaurant-12345",
  "allowed_final_destinations": [
    { "scheme": "https",
      "host": "order.restaurant.example",
      "path_prefix": "/qr/" }
  ],
  "allowed_resolvers": [
    { "scheme": "https",
      "host": "qr.merchant-platform.example",
      "path_prefix": "/r/restaurant-12345/" }
  ],
  "allowed_redirect_hosts": [
    "qr.merchant-platform.example",
    "order.restaurant.example"
  ],
  "max_redirect_depth": 3,
  "prohibit_nested_shorteners": true,
  "require_https": true,
  "runtime_safety_required": true,
  "runtime_safety_ttl_seconds": 300
}

Status event and runtime-safety verdict:

Updates issuer, key, policy, or destination state, or provides a time-bounded risk verdict for a resolver or final destination. A status event MUST be signed by a key on the subject's delegation path at or above the subject's parent, so that a subject whose only key is compromised can still be revoked from above. A status event MUST carry an expiry no later than its issuance time plus the profile's maximum status-event lifetime, and its absence MUST NOT silently preserve positive trust when policy requires fresh status (invariants I4 and I7). In a stream chained by previous_sequence, an observed gap is not a pass condition: it yields the sequence-gap cause in R_F at tier warn only while a declared appraisal grace bound remains, and block otherwise, since state continuity can no longer be shown.¶

Verifier cache entry:

Records the local state used during scan-time validation: the exact source artifacts, hashes, sequence numbers, freshness windows, and verification profile used to compute the decision state. Without this record, later review cannot distinguish a correct warning from a stale positive result.¶

9.3. Payload Trust Claim

The managed trust claim is the payload-side counterpart of the governance objects. A future binding needs at least these semantics:¶

• The claim identifies the issuing chain (root, operator, and issuer identifiers) and the signing key (key_id).¶

• The claim binds the exact destination carried in the payload, under the future binding's closed normalization profile, so that claim and payload cannot diverge.¶

• The claim is signed under a key bound by the issuer's record, with the selected envelope and application-payload rules of Section 9.¶

• The claim can be embedded in the payload or detached (retrieved via a reference carried in the payload). Within the selected binding, a verifier MUST NOT accept a detached claim unless it preserves the exact signed application payload octets and protected parameters required by that envelope. Detached-claim retrieval is a pre-verification network fetch with the privacy properties of controlled resolution (Section 12); embedded claims are RECOMMENDED where payload capacity allows.¶

Payload size in QR symbols is constrained, so compact encodings are expected. The later binding must measure this constraint before choosing its carrier, application encoding, and envelope; this -00 does not select them.¶

10.1. Destination Normalization and Matching

Step 3 cannot be an interoperable evidence-appraisal step until a future binding pins one closed normalization and policy-matching profile. That binding needs to specify, at minimum: accepted schemes; default-port handling; userinfo rejection; dot-segment processing; percent-encoding and UTF-8 failure behavior; IDN version and mapping; empty and trailing paths; fragment treatment; query separators, blank values, duplicate keys, key/value decoding, and ordering; path-segment boundary rules; and the residual tier produced by every parse or normalization failure.¶

The present implementation illustrates converting scheme and host to lowercase, removing default ports, resolving dot-segments, normalizing percent-encoding under [RFC3986], rejecting userinfo, exact host comparison, and segment-aligned path-prefix comparison. Those choices do not become protocol requirements merely because one implementation uses them. Until a future binding closes the list above and publishes matching test vectors, an implementation MUST NOT claim URI-policy or wire interoperability from conformance to Delta alone. Its appraiser records the selected normalization profile and parameters in E before assigning R_D.¶

These rules compare URI components; they do not resolve the host or fetch the resource. Controlled redirect resolution belongs to R_R, runtime observations belong to R_S, and neither changes the meaning of an R_D pass into a DNS, hosting, content, or navigation-integrity claim.¶

13.1. Hostile Split-View Trace

This trace distinguishes fixed-object replay from continuous fresh equivocation by an accepted root:¶

1. At t0, verifiers A and B accept root K under local policy.¶

2. At t1, K signs issuer state X for A and contradictory state Y for B. Both objects identify the same subject and are valid until t1+H.¶

3. Before t1+H, K signs fresh successors X2 and Y2 with later sequence values inside each view. K repeats this before every expiry.¶

4. A and B each observe a fresh, internally monotonic history, so Delta can continue to accept each local R_I input. Even if one verifier later obtains both same-root views, D13 MUST NOT be used: its cross-root-contradiction tier concerns different accepted roots. This version supplies no automatic same-root arbitration; the evidence instead informs local root-distrust policy.¶

5. If statements are registered through a future SCITT binding and a monitor compares the histories, the receipts can prove that contradictory statements were registered. That evidence does not revoke K or change Delta by itself.¶

6. At t2, local policy removes K and distributes that trust-anchor change. Only then do affected verifiers stop accepting newly signed descendants of K. A verifier that never receives the local policy change can remain deceived.¶

If K stops signing after step 2, expiry plus R_F does bound the fixed objects. The unconditional time-bound claim fails specifically at step 3, where an authorized malicious signer creates fresh evidence.¶

Resource exhaustion:

Oversized objects, deep chains, and floods of governance state can exhaust a verifier. Verifiers SHOULD enforce size, count, and cache quotas; exceeding a quota yields "unavailable" (or cache-unverifiable in R_F) and follows the insufficiency rules -- degraded verification is never fail-open (I7).¶

Residual risks include cloaking against the resolution vantage (Section 12), probabilistic artifact analysis, imperfect runtime-safety providers, and every institutional assumption listed in Section 1.2. The invariants are stated for machine-checkable review, but this document does not claim a mechanized proof of them.¶

13.2. Downgrade to Unverified

The attack this document's own motivating examples begin with -- an unsigned sticker covering a signed table tent -- lands in the neutral "unverified" state, not in a warning or block. This is a structural limit shared by every opt-in trust marking from EV certificates to BIMI: the absence of a claim is unauthenticatable, and no verifier can prove that a claim should have been present. The semantics guarantee the downgrade terminates in a bounded neutral state rather than a spoofable positive one (I1, I2), and capture-side evidence can catch the physical form of the attack (R_A: overlay detection and conflicting symbols; D10 when appraisal assigns block). Deployments supply the remaining countermeasures:¶

• In open consumer scanning, the defense is the salience of the neutral state itself. User-interface treatments SHOULD make "unverified" visibly distinct from every positive and issuer-verification state, and the cited scanner-interface studies ([KOWALEWSKI], [SEQR]) document how weak unaided recognition is -- salience is a measured requirement, not a nicety.¶

• Deployments that control their surfaces (enterprise gateways, document workflows, venue-managed placements) SHOULD declare a signed-only posture using the stricter-posture allowance of the conformance clause (Section 8): treat "unverified" as blocked where every legitimate code is known to carry a claim. There the downgrade attack converts to a hard failure. A future appraisal binding can additionally define a signed-workflow policy that assigns R_A block for specified tampering evidence; only then does D10 turn that classified evidence into a block.¶

16.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

16.2. Informative References

[AR4SI]

Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V. Scarlata, "Attestation Results for Secure Interactions", Work in progress, May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-ar4si-10>.

[ISO18004]

ISO/IEC, "Information Technology - Automatic Identification and Data Capture Techniques - QR Code Bar Code Symbology Specification", ISO/IEC 18004:2024, 2024.

[KOWALEWSKI]

Kowalewski, M., Lassak, L., Duermuth, M., and T. Schnitzler, "Scanned and Scammed: Insecurity by ObsQRity? Measuring User Susceptibility and Awareness of QR Code-Based Attacks", 34th USENIX Security Symposium, pp. 1415-1434, 2025.

[QRTRUST]

El-Masri, H., "QR Navigation Security Is Not Primarily a Cryptography Problem: A Trust-Model Framework for Managed Issuer Verification, Destination Binding, and Runtime Safety", SSRN Working Paper 6577478, DOI 10.2139/ssrn.6577478, 2026, <https://ssrn.com/abstract=6577478>.

[RESIDUALS]

El-Masri, H., "Trust Residuals for Navigation QR Codes: Decision Semantics for Issuer, Destination, and Runtime Safety State", SSRN Working Paper 7225699, 2026, <https://ssrn.com/abstract=7225699>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC6480]

Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/rfc/rfc6480>.

[RFC6973]

Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/rfc/rfc6973>.

[RFC7493]

Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/rfc/rfc7493>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/rfc/rfc7517>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[RFC8725]

Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/rfc/rfc8725>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9053]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9525]

Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, <https://www.rfc-editor.org/rfc/rfc9525>.

[RFC9597]

Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024, <https://www.rfc-editor.org/rfc/rfc9597>.

[RFC9711]

Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, <https://www.rfc-editor.org/rfc/rfc9711>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

[RFC9999]

Birkholz, H., Smith, N., Fossati, T., and H. Tschofenig, "Remote ATtestation procedureS (RATS) Conceptual Message Wrapper (CMW)", RFC 9999, DOI 10.17487/RFC9999, July 2026, <https://www.rfc-editor.org/rfc/rfc9999>.

[SEQR]

Mossano, M., Veit, M. F., Laenge, T., Berens, B. M., Sharevski, F., and M. Volkamer, "Development, Evaluation, and Implementation of SEQR - a Usable Secure QR Code Scanner", Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems (CHI '26), ACM, DOI 10.1145/3772318.3793213, 2026, <https://doi.org/10.1145/3772318.3793213>.

[VCDM]

W3C, "Verifiable Credentials Data Model v2.0", W3C Recommendation, 2025, <https://www.w3.org/TR/vc-data-model-2.0/>.

[VCJOSECOSE]

W3C, "Securing Verifiable Credentials using JOSE and COSE", W3C Recommendation, 2025, <https://www.w3.org/TR/2025/REC-vc-jose-cose-20250515/>.

[VCSTATUS]

W3C, "Bitstring Status List v1.0", W3C Recommendation, 2025, <https://www.w3.org/TR/2025/REC-vc-bitstring-status-list-20250515/>.

[VIDAS]

Vidas, T., Owusu, E., Wang, S., Zeng, C., Cranor, L. F., and N. Christin, "QRishing: The Susceptibility of Smartphone Users to QR Code Phishing Attacks", Financial Cryptography and Data Security, LNCS 7862, Springer, DOI 10.1007/978-3-642-41320-9_4, 2013, <https://doi.org/10.1007/978-3-642-41320-9_4>.