REFERENCE SCENARIOREFERENCE

RS-07 — device-attestation

Onboard thiết bị và runtime attestation

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 area	Expected record
Identity / mandate	Actor/context and mandate evidence where applicable
Policy	Decision + policy/profile version
Business object	Subject identifier + authority context
Transition	Previous/resulting state + preconditions
Evidence	Source/provenance + trusted time
Integration	Correlation + delivery/reconciliation outcome

ACTUAL PRODUCT UI

Reference UI for this scenario

Device / Thing Operations Console · Dashboard Overview

09_DEVICE_THING_OPERATIONS_CONSOLE.zip · TTID--M01-L01-001-Dashboard_Overview_final.png

REFERENCE SCENARIO · IMPLEMENTATION-GRADE

RS-07 — Connected-device onboarding and runtime attestation

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 / systemsDevice / Thing Operator; Device Operations Console; device PKI/attestation verifier; policy engine; connected device.

PreconditionsDevice identity/certificate enrolment path exists and selected assurance level is appropriate to risk and device capability.

TriggerA device is enrolled, reconnects or is challenged for runtime trust.

End-to-end flowResolve device/thing → verify certificate status → collect attestation evidence where L3 is required → appraise claims against policy → produce runtime trust decision → record evidence → enforce allow/restrict/quarantine independently of ownership.

State modelCertificate Valid/Revoked is one state domain; Runtime Trust Trusted/Degraded/Denied is another. Ownership/custody is separate again.

Authority boundaryDevice CA/PKI is authoritative for certificate status; the runtime policy/appraisal service is authoritative for the deployment-specific runtime trust decision.

Policy / disclosureAssurance level L0–L3, device class, firmware/secure-boot claims, freshness, nonce/challenge, risk and enforcement policy.

EvidenceCertificate check reference, challenge/attestation evidence, appraisal result, policy version, enforcement action and audit.

API / event / connectorDevice attestation API; certificate/status integration; evidence API; device events; operations policy/enforcement APIs.

Failure / retry / reconciliation

Stale attestation → challenge again; revoked certificate → deny according to policy; unsupported capability → fall back only to an explicitly permitted lower assurance level, never silently upgrade trust.

Architecture

P03 · P05 · P06

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

Standards / profiles

IEEE 802.1AR / RATS-family concepts where applicable; deployment-specific PKI and attestation profiles.

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.