REFERENCE SCENARIOREFERENCE

RS-03 — ownership-transfer

Chuyển Ownership / Custody

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

Consumer / Owner App · Scan and Resolve Resolve Success

01_CONSUMER_OWNER_APP.zip · TTID--M03-L01-002-Scan_and_Resolve_Resolve_Success_final.png

REFERENCE SCENARIO · IMPLEMENTATION-GRADE

RS-03 — Ownership / custody transfer with evidence-backed relationships

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 / systemsCurrent owner/custodian; receiving party; Owner App; relationship/claim service; identity and mandate services.

PreconditionsBoth parties can be identified to the assurance required by policy; the current relationship claim is active and transferable.

TriggerAn authorised party initiates a transfer or custody handoff.

End-to-end flowResolve thing → verify current relationship → authenticate parties → validate mandate/policy → create transfer intent → recipient accepts where required → close/supersede prior relationship → issue new claim → record evidence.

State modelRelationship claim Active(A) → Transfer Pending → Superseded/Closed; new relationship claim Pending → Active. DPP lifecycle remains separate.

Authority boundaryTrusted ThingID records evidence-backed relationship claims; it does not turn a DPP creation event into legal ownership.

Policy / disclosureRelationship state, transferability, party identity, mandate, assurance, time-bounded acceptance and conflict rules.

EvidenceTransfer intent, party authentication/mandate references, acceptance, previous/new claim linkage, timestamp and audit trail.

API / event / connectorClaims / relationship API; mandate API; evidence API; lifecycle events for relationship claims.

Failure / retry / reconciliation

Recipient does not accept → expire transfer; conflicting claim → hold for policy resolution; replay/duplicate → idempotent rejection or return existing result.

Architecture

P02 · P03 · P05

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

Standards / profiles

Identity/credential profiles and evidence/time standards as applicable; ownership remains a governed business claim.

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.