SOLUTIONREFERENCE SOLUTION

Connected Device Trust

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

Review journeyRequest 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
AreaPilot scopeAcceptance evidence
ApplicabilityOne product group / regulatory profileApproved applicability record + source references
IdentityOfficial identifier + resolver mappingResolution/collision/supersession tests
Portal journeyPrimary actor flow + restricted viewTask completion + disclosure audit
IntegrationOne authoritative/external connectorHappy-path + timeout/retry/reconciliation evidence
EvidenceMaterial transition and retentionEvidence 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 workshopExplore architecture