SOLUTIONREFERENCE SOLUTION

Connected Device Trust

Extend passive DPP identity with optional hardware-bound device identity and runtime attestation where risk justifies it.

Review journey Request pilot scope

P05Architecture

Scoped pilotEntry point

BUSINESS PROBLEM

Frame the obligation before choosing implementation technology.

The solution is scoped around business outcomes and authoritative sources, not around a generic DPP database.

Product-group or market obligations must be translated into implementable data, access and lifecycle rules.
Multiple actors and external authorities create ambiguity about who can assert, update or restrict each fact.
Integration failure and incomplete evidence can undermine the business outcome even when the happy path works.

TARGET OUTCOME

Explicit authority and source mapping
Versioned policy/profile and portal journey
Evidence-backed acceptance criteria

ACTORS & AUTHORITY

The same actor may be authoritative for one fact and only a consumer for another.

Authority is assigned by data domain and applicable context.

Device Operator

Role is scoped by purpose, mandate and data domain.

Connected Thing

Role is scoped by purpose, mandate and data domain.

Attester/Verifier

Role is scoped by purpose, mandate and data domain.

Policy Owner

Role is scoped by purpose, mandate and data domain.

JOURNEY

Trace the request to an auditable result.

The journey preserves policy and evidence context from request through external authority interaction.

Thing / Product

Official Identifier

Trusted ThingIDResolver · Alias · Assurance

DPP

Claims · Policy · Evidence

External ecosystem

Event

Authorized actor

Precondition

Evidence

Trusted time

Policy / profile version

Resulting state

TRUSTED THINGID APPROACH

Compose only the capabilities needed for this outcome.

Optional device, ledger or credential mechanisms are not inserted unless the use case justifies them.

Thing Identity & Resolver

REFERENCE IMPLEMENTATION

Resolve official identifiers, correlate aliases and extend assurance without redefining the authoritative product identifier.

Explore

Policy, Mandate & Disclosure

REFERENCE ARCHITECTURE

Separate authentication, authorization and field-level disclosure through PAP/PIP/PDP/PEP policy semantics.

Explore

Evidence & Provenance

PILOT READY

Bind business events and claims to source evidence, provenance, trusted time, immutable audit and retention policy.

Explore

Device Trust & Attestation

REFERENCE ARCHITECTURE

Select assurance from L0 passive carrier through L3 runtime attestation according to risk and device capability.

Explore

Connector & Integration Platform

PILOT READY

Use domain-specific adapters over shared API, event, workflow, semantic mapping, retry and reconciliation capabilities.

Explore

PILOT SCOPE

A pilot must define what success means.

Suggested acceptance criteria are evidence-oriented and should be adapted to the exact product group and external interfaces.

Reference pilot acceptance matrix
Area	Pilot scope	Acceptance evidence
Applicability	One product group / regulatory profile	Approved applicability record + source references
Identity	Official identifier + resolver mapping	Resolution/collision/supersession tests
Portal journey	Primary actor flow + restricted view	Task completion + disclosure audit
Integration	One authoritative/external connector	Happy-path + timeout/retry/reconciliation evidence
Evidence	Material transition and retention	Evidence manifest + provenance + timestamp/version

ARCHITECTURE WORKSHOP

Define a project-specific pilot boundary.

The architecture is reusable; applicability, interfaces, evidence and acceptance criteria must be confirmed for the target deployment.

Request a workshop Explore architecture