REFERENCE SCENARIOREFERENCE

RS-02 — consumer-policy-view

Người tiêu dùng quét và nhận view theo policy

END-TO-END PATH

Actor → Channel → AuthN → AuthZ → Disclosure → Core/DPP → Evidence → Connector → External Authority.

Not every scenario traverses every optional capability; the path shows the governance checkpoints that must remain explainable.

Thing / Product
Official Identifier
Trusted ThingIDResolver · Alias · Assurance
DPP
Claims · Policy · Evidence
External ecosystem
MATERIAL TRANSITION

State changes require more than an event name.

Event
+
Authorized actor
+
Precondition
+
Evidence
+
Trusted time
+
Policy / profile version
=
Resulting state
ACCEPTANCE EVIDENCE

Define what makes this journey auditable.

Evidence areaExpected record
Identity / mandateActor/context and mandate evidence where applicable
PolicyDecision + policy/profile version
Business objectSubject identifier + authority context
TransitionPrevious/resulting state + preconditions
EvidenceSource/provenance + trusted time
IntegrationCorrelation + delivery/reconciliation outcome
ACTUAL PRODUCT UI

Reference UI for this scenario

DPP Public / Restricted Viewer · Carrier Discovery Resolve Success

02_DPP_PUBLIC_RESTRICTED_VIEWER.zip · TTID--M01-L01-002-Carrier_Discovery_Resolve_Success_final.png

REFERENCE SCENARIO · IMPLEMENTATION-GRADE

RS-02 — Consumer scans a product and receives a policy-composed DPP view

This scenario connects a user action to state, authority, policy, evidence and integration boundaries. It is a reference model; legal or regulatory decisions remain with the authoritative party for each data domain.

Actors / systemsConsumer / Owner; Consumer App or DPP Viewer; Resolver; disclosure/policy services; authoritative DPP sources.
PreconditionsA carrier or identifier can be resolved and the product has a DPP/read model accessible for the requested persona.
TriggerThe user scans QR/NFC or opens a deep link.
End-to-end flowRead carrier → resolve official identifier/aliases → determine public or authenticated persona → evaluate purpose/mandate/assurance → compose field-level view → present lifecycle/recall/evidence references.
State modelNormally read-only. A view does not create ownership, custody or regulatory state by itself.
Authority boundaryOfficial identifier and regulatory status are not made authoritative by the viewer. The UI displays policy-composed facts from governed sources.
Policy / disclosurePublic vs authenticated session; persona; purpose; mandate; assurance; data classification; consent where applicable.
EvidenceResolution trace, policy decision reference, disclosure context and access/audit evidence where required.
API / event / connectorResolver API; DPP API; claims/status read; disclosure composition; search/read APIs.

Failure / retry / reconciliation

Unknown identifier → explain resolution failure; unavailable authoritative source → degraded/stale status must be explicit; denied restricted field → show least-privilege view without leaking field values.

Architecture

P02 · P03 · P04

Actor → Experience → Action → Business Object → Authority → Policy → State → Evidence → API/Connector → Architecture → Standard.

Standards / profiles

GS1 Digital Link / carrier standards where applicable; disclosure and identity protocols as profiled by deployment.

REFERENCE ARCHITECTURE
Product UI statusUI/UX BASELINE — *_final.png is embedded only when the approved source binary and provenance are available; no screenshot is fabricated to fill a missing source.