Replies: 4 comments
Part II — Control-plane model20. The product is the authority boundaryThe central architectural decision is that the Product, rather than Canopy or another remote service, is the final enforcement point for its own operation. External systems may:
But the Product determines:
The fundamental direction of authority is therefore: flowchart LR
External["Local / Canopy / Partner / Peer"]
Claim["Authenticated authority claim"]
Product["Product Control plane"]
Execution["Local execution"]
External --> Claim
Claim --> Product
Product --> Execution
This should remain true whether a product has no remote management, one Jangala Canopy relationship or several external relationships. 21. Root and ControlThe Product has two conceptual authority layers: flowchart TB
Root["ROOT\nidentity • trust • ultimate recovery"]
Control["CONTROL\nordinary administration and operation"]
Root --> Control
RootRoot contains only the state which must survive the failure or replacement of ordinary Control:
Root is deliberately small. ControlControl contains ordinary mutable authority:
Control may be reconstructed by Root without requiring the Product to lose unrelated configuration, software or physical identity. This is the basis for the rule:
22. PrincipalA Principal is a locally meaningful actor or authority. Examples include: A Principal does not mean “a login account”. It is the identity to which authority is attached. This distinction matters because the same Principal may be authenticated in several ways. For example: Likewise a personal Principal might have: The authentication mechanism may change without necessarily changing the authority represented by the Principal. 23. Institutional and personal PrincipalsThe model should support both. Institutional PrincipalsExamples: These scale well. The Product need not know every employee of Partner A. It needs to know that Partner A has a particular authority relationship. Partner A may then delegate some of that authority to Alice. Personal PrincipalsExamples: These are useful where an individual needs:
The model should not force every user into one category. 24. Credential and authenticatorA Credential is evidence used to authenticate an actor or Principal. Possible credentials include:
An Authenticator is the mechanism by which the credential is verified in a particular interaction. Examples: The model should therefore distinguish: This distinction is especially important for audit. 25. GrantA Grant specifies authority held by a Principal. Grants should be semantic. Good examples: Poor examples: The former survive changes to Devicecode's internal service decomposition. The latter expose implementation detail as security policy. A Principal can delegate only authority which it already possesses. Thus: Delegation can narrow authority but never amplify it. 26. EpochEvery durable authority instance has an Epoch. For example: If that relationship is revoked and subsequently recreated: is a different authority. The core rule is:
Retiring an Epoch should invalidate authority-bearing state associated with it, including:
This prevents a stale backup, old certificate or former cloud relationship from silently becoming valid after authority has been withdrawn. A replacement Epoch inherits nothing automatically. Any migration of configuration or authority is an explicit operation. 27. IntentIntent represents persistent desired state proposed by an authorised Principal. Examples: Intent contains provenance. Conceptually: Intent persists independently of connectivity. If Partner A submits an SSID and then Canopy disappears, the SSID does not stop being Partner A's Intent merely because the transport is unavailable. If Partner A's authority Epoch is revoked, however, that Intent becomes ineligible. This is the crucial difference between: and: 28. Intent resolutionThe Product resolves eligible Intent into the intended configuration supplied to Devicecode domains. flowchart TB
Base["Base / product Intent"]
J["Jangala Intent"]
P["Partner Intent"]
L["Local Intent"]
Resolver["Control resolver"]
CFG["cfg/<service>"]
Domain["Existing Devicecode domain"]
State["state/<domain>/..."]
Base --> Resolver
J --> Resolver
P --> Resolver
L --> Resolver
Resolver --> CFG
CFG --> Domain
Domain --> State
The resolver should initially remain simple. The architecture should not assume: or: or: Instead, authority is defined for meaningful properties or groups of properties. For example: Where possible, overlapping write authority should be avoided rather than solved with increasingly elaborate precedence logic. 29. CapabilityA Capability represents a transient semantic action. Examples:
The distinction is: An SSID should be Intent. “Run a ping test now” should be a Capability. This keeps configuration and command semantics distinct. 30. StateState is canonical Product truth produced locally. It should continue to use the distinctions already developed in Devicecode: Canopy can cache and present State. TimescaleDB can retain historical observations. Neither becomes authoritative merely because it holds a copy. 31. Historical telemetry versus current StateCurrent Jangala infrastructure already provides useful remote observability: That should remain valuable. The richer control plane adds concepts which are different from historical telemetry. For example: These should be related in Canopy UX without being collapsed into one data model. Grafana may remain valuable for internal engineering and deep analysis. Canopy should provide the product-facing and tenancy-aware experience. 32. Mapping onto DevicecodeThe new Control layer should sit above existing domain services. A new
It should not take over Wi-Fi, networking or GSM behaviour. flowchart TB
Interfaces["Local UI / Canopy / federation"]
Control["control service"]
Authz["Devicecode authz"]
Config["config service"]
Domains["wifi • net • gsm • update • ..."]
State["state/..."]
Interfaces --> Control
Control --> Authz
Control --> Config
Config --> Domains
Domains --> State
The desirable migration property is:
They continue to consume one resolved 33. Authorisation enforcement
The existing Devicecode authoriser should enforce them. The preferred model is an immutable or atomically replaceable authorisation snapshot rather than a synchronous RPC to External interfaces must execute requests using restricted authority. For example: The transport process may need substantial internal access to function. A remote Jangala action should nevertheless execute as: or another relevant Principal, not as an omnipotent Canopy service. |
Part III — Authentication, recovery and product assurance34. One authorisation model, several authentication systemsThe target should be:
Possible authentication routes include: All eventually resolve to locally meaningful authority. flowchart LR
P["Passkey"]
O["OAuth/OIDC"]
D["Offline delegation"]
C["Certificate"]
R["Recovery proof"]
Resolve["Authenticate\nand resolve authority"]
Principal["Principal + Epoch"]
Grants["Local Grants"]
P --> Resolve
O --> Resolve
D --> Resolve
C --> Resolve
R --> Resolve
Resolve --> Principal --> Grants
Canopy should therefore integrate modern identity systems without turning them into a mandatory dependency for local operation. 35. Canopy identityCanopy should support familiar organisational identity:
Canopy can authenticate Alice and determine that she may act for Partner A. The Product need not necessarily create Instead it may receive: This provides scalable organisational authority while retaining human attribution. 36. Offline organisational delegationFor excellent local offline access, an organisation should eventually be able to issue a portable, holder-bound delegation. Example: Alice's device proves possession of the bound holder key. The Product checks:
This lets a user who has never visited a particular product gain appropriate offline access without the Product storing the organisation's complete directory. 37. Offline revocationOffline delegated credentials create an unavoidable limitation:
The design should state this plainly. Possible controls include:
Different authorities may receive different offline treatment. For example:
Open question: exact offline revocation and validity model. 38. Local PWAThe local interface should be a TLS-enabled PWA and a normal administration path. The intended experience is: An offline product should say: rather than presenting a special degraded interface. The local PWA should ultimately include:
39. Local identity and discoveryThe local experience needs a stable answer to:
Likely ingredients include:
For example: Normal administration should not require users to ignore certificate warnings. Open questions:
40. Root recoveryRoot exists so that ordinary Control can be repaired without unnecessarily affecting the rest of the Product. A strong recovery flow might be: sequenceDiagram
participant User as Legitimate recovery operator
participant Product as Product recovery
participant Root as Root authority
User->>Product: Enter recovery channel
Product-->>User: Product identity + fresh challenge
User->>Root: Request narrow recovery authorisation
Root-->>User: Signed recovery proof
User->>Product: Proof + replacement credential
Product->>Product: Verify Root epoch and challenge
Product->>Product: Repair ordinary Control only
The proof should be narrowly bound to:
This should be locally verifiable wherever practical. Canopy may facilitate the ceremony but should not be inherently required for verification. 41. Recovery is not resetThe architecture should explicitly distinguish: Each operation should state exactly what it affects. For example: should not accidentally imply: This is one of the principal operational benefits of the Root/Control separation. 42. Physical presencePhysical presence is evidence about context, not identity by itself. For ordinary administration it may be irrelevant. For strong recovery it may be required in combination with legitimate authority. For example: is substantially stronger than either alone. A thief has physical possession but not the Root credential. A remote attacker may have a compromised account but not the Product. The precise physical-presence mechanism will vary between product profiles. 43. Ultimate recoveryThe hardest case is loss of Root recovery material itself. This cannot be solved universally without making a trade-off. The Product should therefore have an explicit ultimate recovery policy. Possible policies include: Root-lockedOnly the existing Root authority can authorise replacement. Strong theft resistance, but loss of all Root material may make that ownership state unrecoverable. Assisted recoveryAdditional Root recovery authority is deliberately enrolled. Examples:
This is explicit and consensual. Destructive reclaimA strong physical ceremony:
This trades some theft deterrence for eventual hardware reuse. Open question: which products and ownership models should permit destructive reclaim. 44. Product claimingAn unclaimed Product must cross a clear boundary into first ownership/stewardship. flowchart LR
Factory["Factory Product identity"]
Unclaimed["Unclaimed Product"]
Ceremony["Claim ceremony"]
Root["Root epoch 1"]
Control["Initial Control"]
Recovery["Recovery established"]
Factory --> Unclaimed --> Ceremony --> Root --> Control --> Recovery
A Product should not be considered fully provisioned merely because one administrator password exists. Provisioning should establish:
The exact claim experience may differ for:
Open question: claim protocols for each. 45. Persistence and backupSecurity state should be split into three broad classes. Root stateSmall, strongly protected and rollback-sensitive: Control stateDurable and recoverable: Cloud stateOperational convenience and history: Cloud data does not override current Product authority. 46. Backup principleThe guiding rule is:
For example, if current Product state says: restoring a filesystem containing: must not silently make Likewise, restoring an old Canopy database cannot recreate a Product relationship which the Product has since revoked. Recovery should generally prefer: over restoration of historical secrets. 47. Product assurance profilesCommon semantics do not imply common hardware security. Each Product profile should eventually document its concrete guarantees.
The purpose of the table is honesty. The architecture should not claim TPM-grade assurance on hardware which cannot provide it. For Big Box, the existing trust design already gives the RP2354X a significant appliance-identity and reprovisioning role. 48. Software trust and updatesSoftware management should distinguish four separate questions: flowchart TB
Release["Release publication"]
Trust["Software trust"]
Policy["Update Intent / policy"]
Grant["Operational Grants"]
Update["Local Update service"]
Release --> Update
Trust --> Update
Policy --> Update
Grant --> Update
Update --> Components["Product components"]
This allows Jangala to remain the normal software authority for Jangala-managed Products without making Jangala cloud connectivity the direct executor of physical updates. 49. Big Box trust-world transitionsFor Big Box, the existing design proposes: with trusted recovery as the only bridge between them. A move away from managed operation should:
Return to managed operation should create a fresh managed epoch with fresh credentials rather than revive the old managed identity. This provides a useful pattern for future Jangala products even where their hardware implementation differs. 50. AuditEvery meaningful security or control action should preserve enough information to answer:
Conceptually: The model should distinguish:
Local audit remains valuable offline. Canopy provides searchable central history where available. Open questions:
|
Part IV — Delivery plan51. Delivery principleThe roadmap should proceed from the final architecture backwards. Stage 1 is therefore:
rather than:
The sequence should be driven by the smallest set of functionality which tests the strategic assumptions in real deployments. 52. Stage 0 — establish the substrateImplement the minimum local semantics required by all later interfaces:
Preserve existing The immediate aim is not broad functionality. It is to establish the correct meaning of: 53. Stage 1 — Jangala control, locally and remotelyLocal UI and Jangala Canopy should arrive against the same substrate. flowchart TB
LocalUser["Local administrator"]
Prog["Jangala programmes user"]
PWA["Local PWA"]
Canopy["Canopy"]
Control["Common Product Control"]
Domains["Existing Devicecode"]
LocalUser --> PWA --> Control
Prog --> Canopy --> Control
Control --> Domains
This stage should include a deliberately small control catalogue, for example:
The purpose is not exhaustive remote administration. It is to prove that local and remote operation are genuinely two routes into one Product authority model. 54. Stage 1 observabilityExisting remote telemetry should remain in service. Canopy should begin combining: into one coherent product experience. Grafana can remain an internal engineering tool. Canopy becomes the product-facing interface. 55. Stage 1 acceptance journeysStage 1 should be considered successful only if representative end-to-end journeys work. For one setting such as administrative Wi-Fi:
This one scenario exercises much of the architecture. 56. Stage 2 — partner tenancyCanopy then adds:
Devicecode should not need Canopy's full tenancy model. It sees locally meaningful authority such as: Canopy establishes which humans may exercise that authority. Where possible, avoid overlapping remote write Grants initially. 57. Stage 2 — organisational offline accessOnce the core tenancy model is stable, add portable organisational delegation so authorised partner staff can access their Products locally while offline. Likely progression: This is an important strategic capability but need not block the earliest partner-control experience if the credential design is not yet mature. 58. Stage 3 — device-led software updatesMove update admission and execution into Devicecode. Existing hawkBit infrastructure can remain where useful for:
But the Product gains responsibility for:
This also removes the present need to use software image variation and rebootstrap as a substitute for proper configuration control. 59. Stage 4 — broader control relationshipsOnce the Product authority model is stable, allow additional remote-management arrangements:
The Product should not need a fundamentally different model. Each new system authenticates a Principal and receives whatever Grants exist locally. 60. Stage 5 — local federationIntroduce Product-to-Product federation only when a concrete use case justifies it. Potential examples:
The architecture should reuse:
rather than invent a completely unrelated trust model. 61. Stage 6 — wider product profilesAs Rust Fibers and future hardware mature, implement constrained forms of the same product semantics on MCU-class devices. The objective is not identical code. It is conceptual continuity: across the Jangala product family. 62. WorkstreamsThe strategic programme can be divided into several related but independently designable workstreams. Product authority
Authentication
Product assurance
Devicecode
Canopy
Local PWA
Updates
Federation
63. Open design questionsThe following should remain explicitly unresolved until sufficient design work or hardware investigation has been completed. Root
Product claiming
Authentication
Local networking
Intent
Recovery
Persistence
Canopy
Updates
Federation
64. Architectural invariantsThe design should remain governed by the following:
65. Strategic destinationThe intended architecture can be summarised as: flowchart TB
subgraph Participants["Participants"]
Humans["Local users"]
JC["Jangala Canopy"]
Partner["Partner / owner systems"]
Release["Software authorities"]
Peers["Other Products"]
end
subgraph Product["JANGALA PRODUCT"]
subgraph Root["ROOT"]
PID["Physical identity"]
Trust["Trust world"]
RA["Root authority"]
RE["Root Epoch"]
Recovery["Recovery policy"]
end
subgraph Control["CONTROL"]
Auth["Authentication / assertions"]
P["Principals"]
G["Grants + Epochs"]
I["Intent"]
C["Capabilities"]
S["State"]
CFG["cfg/..."]
Domains["Devicecode domains"]
Composition["HAL / Device / Fabric"]
end
end
Root --> Control
Humans --> Auth
JC --> Auth
Partner --> Auth
Release --> Auth
Peers --> Auth
Auth --> P
P --> G
G --> I
G --> C
G --> S
I --> CFG
CFG --> Domains
C --> Domains
Domains --> Composition
Domains --> S
S --> Humans
S --> JC
S --> Partner
The practical objective behind this architecture is straightforward:
The technical model exists to make those product experiences ordinary rather than exceptional. |
flowchart TB
%% ───────────────── USERS ─────────────────
subgraph PEOPLE["1 — USERS & ORGANISATIONS"]
JU["Jangala teams"]
PU["Partner teams"]
LU["Local / field users"]
end
%% ───────────────── CLOUD ─────────────────
subgraph CLOUD["2 — CANOPY"]
direction LR
subgraph HOSTED["Jangala-hosted Canopy on AWS"]
UX["Canopy UI"]
AUTH["Identity & tenancy"]
CTRL["Product control"]
DATA["Telemetry & reporting"]
end
subgraph SELF["Self-hosted Canopy"]
SMALL["Compact open deployment"]
end
end
%% ───────────────── OPEN BOUNDARY ─────────────────
PROTOCOL["3 — OPEN PRODUCT PROTOCOL\nIdentity • State • Intent • Capabilities"]
%% ───────────────── PRODUCTS ─────────────────
subgraph FIELD["4 — AUTONOMOUS JANGALA PRODUCTS"]
direction LR
BB["Big Box"]
GB["Get Box"]
LOCAL["Local TLS PWA"]
CONTROL["Local Devicecode control plane\nAuthority • Configuration • State"]
end
%% Users
JU --> UX
PU --> UX
LU --> LOCAL
%% Hosted Canopy internals
UX --> AUTH
UX --> CTRL
UX --> DATA
%% Both Canopy profiles use same boundary
CTRL <--> PROTOCOL
DATA <--> PROTOCOL
SMALL <--> PROTOCOL
%% Device side
PROTOCOL <--> CONTROL
LOCAL <--> CONTROL
CONTROL --- BB
CONTROL --- GB
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Part I
User journeys, architecture and delivery direction
1. Start with the experience
The control-plane architecture should begin with the experiences we want Jangala staff, partners and owners to have over the complete life of a product.
These journeys are deliberately more important than the implementation mechanisms which follow them.
They give us two tests:
The journeys also illustrate why Jangala products should not be designed as conventional cloud-controlled IoT devices.
The recurring requirements are:
2. Journey: a charity partner receives a Jangala Big Box
This is the normal Jangala deployment model.
Jangala owns the Big Box and provides it to Partner A on a long-term pro-bono basis.
Before shipment, the box has a genuine physical identity and is in the Jangala-managed software trust world.
Its governance is approximately:
Jangala assigns BB123 to Partner A in Canopy.
The partner administrator receives an invitation and signs in using the identity system they already use: for example Microsoft, Google, another OIDC provider or a Canopy account.
They see:
When they receive the physical product, they connect locally and open its TLS-enabled PWA.
The product identifies itself:
Because the administrator has already authenticated through Partner A, the product can recognise an appropriate organisational authority.
It offers:
The administrator establishes a local passkey or other holder-bound offline credential.
From then on they can administer the box:
They are not aware of two separate configuration systems. They are simply administering the same product through two interfaces.
What this implies
The product cannot derive its operational authority solely from Canopy.
Partner A's authority must be meaningful locally.
Canopy must be able to represent organisational authority without becoming the source of product truth.
Local and remote authentication may differ, but both must resolve into the same product authorisation model.
3. Journey: a field worker reaches an offline site
Alice works for Partner A.
She arrives at a site where BB123 has been operating for several weeks without internet connectivity.
The box is functioning normally.
Alice joins the local management network and opens:
The PWA shows:
Alice selects:
Her device presents her passkey, or an offline organisational credential previously issued by Partner A.
The box verifies locally that:
Alice enters immediately:
She can see health, run diagnostics and perform whatever ordinary operations her role permits.
There is no “offline mode”.
There is simply no current Canopy connection.
What this implies
A product must be able to authenticate useful authority locally.
OAuth or Canopy may help issue offline credentials, but cannot be required to exercise them.
Authority delegated by an organisation can never exceed the authority the product gave that organisation.
4. Journey: a Partner A employee who has never visited this box arrives offline
Bob is another Partner A field engineer.
BB123 has never previously seen Bob.
Bob nevertheless has a current Partner A offline credential, cryptographically bound to his holder key, which states that he is a Partner A field engineer.
BB123 already recognises:
and permits Partner A field engineers a limited class of local access.
Bob presents:
The box calculates:
Bob receives the appropriate access without:
What this implies
The architecture should support institutional Principals with delegated human actors.
This is likely to be important for large fleets.
A product should not need a durable local account for every employee who may ever visit it.
5. Journey: the partner forgets its administrator credentials
Partner A has operated BB123 successfully for three years.
The employee who originally administered the fleet leaves, and the organisation subsequently discovers that it has lost all ordinary administrative credentials.
The box is still:
This should not be a factory-reset event.
Partner A contacts Jangala.
Because this is Jangala-owned long-term-loan equipment, Jangala retains Root recovery authority.
After verifying the operational request, Jangala authorises creation of replacement Partner A administration.
The recovery operation changes only the authority which was lost.
It does not:
The partner resumes administration.
What this implies
Ordinary administration and ultimate recovery must be distinct layers.
Root must be able to reconstruct Control.
The architecture should make recovery of a credential or administrator a narrow operation rather than a euphemism for product reset. This is consistent with the existing principle that Root recovers ordinary Control.
6. Journey: a programmes user changes an SSID remotely
A Jangala programmes-team user is authorised to administer BB123.
They open Canopy and change:
Canopy sends an authenticated product-level request.
The device admits it as Intent under the relevant Principal.
Devicecode resolves the currently authoritative Intent and updates its ordinary intended Wi-Fi configuration.
The existing Wi-Fi service reconciles that configuration.
Canopy subsequently shows:
No firmware image is built.
No hawkBit deployment occurs.
No rebootstrap takes place.
What this implies
Ordinary configuration must be represented as persistent Intent, not as software release variation.
The existing
cfg/...and domain-service architecture should remain underneath the new control layer.7. Journey: local and remote users disagree
Partner A remotely requests:
A site administrator, dealing with an immediate local situation, sets:
The product does not simply accept whichever write arrived last.
It retains both facts.
The local control policy says that for this property the site administrator has emergency override authority.
The local UI and Canopy can therefore both explain:
When the local override is removed, Partner A's standing Intent can become authoritative again without somebody reconstructing it from an audit log.
What this implies
Remote and local configuration cannot be represented as one destructively overwritten desired-state object.
Intent must retain provenance.
Conflict resolution must be local and explainable.
There should not be a universal
LOCAL > CLOUDrule; control should be defined according to the authority model for the property concerned.8. Journey: Canopy is unavailable for a month
A regional connectivity problem prevents BB123 from reaching Canopy.
Nothing structurally changes.
The device continues:
Its local UI reports:
When Canopy becomes available again, it synchronises with the product.
Canopy learns:
The product does not reset itself to whatever copy of desired state the cloud happened to retain one month earlier.
What this implies
Canopy cannot be the unique source of product authority or desired configuration.
The device remains the enforcement point and current source of truth.
Cloud reconnection is reconciliation, not reassertion of ownership.
9. Journey: a partner is given access to its fleet
Partner A operates 40 Jangala devices.
Its users sign into Canopy using their normal organisational identity provider.
They see:
They do not see:
Grafana may continue to be extremely useful to Jangala engineers, but it is not the partner product interface.
What this implies
The existing Mainflux → TimescaleDB → Grafana observability stack remains valuable.
What is missing is a product- and tenancy-aware application layer.
Historical telemetry, current canonical State and product authority are different concepts and should remain so.
10. Journey: a Jangala-owned box moves to another partner
BB123 is returned by Partner A and assigned to Partner B.
This is not a new physical product and does not inherently require a software-trust transition.
Jangala removes Partner A's ordinary authority.
The relevant Partner A authority Epoch is retired.
Any Intent bound to that Epoch becomes ineligible.
Partner B receives a fresh authority instance:
The product is then configured according to the agreed handover process.
Some product configuration might deliberately be retained; some might be reset or replaced.
That is a product/operational decision, not an accidental consequence of account deletion.
What this implies
Authority requires durable Epochs.
Re-enrolment or reassignment must not revive stale authority or stale Intent.
Organisational reassignment is normally a Control-plane operation rather than a Root transition.
11. Journey: a partner buys the Big Box from Jangala
After several years, Partner A purchases BB123 outright.
Before the sale:
The ownership transfer is explicit.
A stronger ceremony transfers Root authority to Partner A.
Afterwards:
Partner A may choose to retain:
But those are now explicit relationships rather than consequences of Jangala's former ownership.
What this implies
Legal/ultimate ownership and ordinary product operation should not be conflated.
Changing Root authority is qualitatively different from changing an administrator or fleet assignment.
12. Journey: an organisation buys a Big Box outright
A customer purchases a new Big Box.
On first use it identifies itself as an unclaimed physical product.
The claiming experience establishes:
flowchart LR New["Unclaimed product"] Claim["Claim"] Root["Establish Root authority"] Admin["Establish administration"] Recovery["Establish recovery"] Services["Optional services"] Ready["Operational"] New --> Claim --> Root --> Admin --> Recovery --> Services --> ReadyThe owner may choose:
or:
or eventually:
They may separately choose:
without granting Jangala ordinary operational authority.
They may also choose an appropriate recovery arrangement:
The product makes the consequences clear.
What this implies
Cloud management, software trust, Root ownership and operational authority are independent dimensions.
The initial claim process is therefore a Root lifecycle event, not merely creation of a Canopy account.
13. Journey: a privately owned box is stolen
An independently owned BB is stolen.
What happens depends on the recovery policy the owner deliberately selected.
If the owner selected strong Root locking, physical possession alone should not allow the thief to replace Root authority.
If the owner deliberately enrolled an assisted recovery authority, that authority may participate in recovery or loss management.
If the owner selected a destructive-reclaim policy, the product may eventually permit an appropriately strong physical process to destroy all former identity, credentials and claim continuity and return the hardware to a new unclaimed state.
What it must not do is allow a new possessor to impersonate the former owner or the former managed product.
What this implies
There is no universally correct answer to theft and ultimate recovery.
The policy must be explicit.
A hidden vendor backdoor is not an acceptable substitute for making the trade-off visible.
14. Journey: the owner leaves Jangala entirely
An outright owner has used:
They decide they no longer want any Jangala dependency.
They first remove or replace ordinary Jangala Control relationships.
They then deliberately enter the stronger software-freedom procedure.
For Big Box, the existing proposal treats the move from Jangala-managed to owner-controlled software as a trusted recovery operation requiring physical presence, with managed credentials destroyed before owner-controlled software runs.
The product subsequently operates using:
Jangala can no longer claim that the device is currently Jangala-managed.
The hardware remains useful.
What this implies
Software freedom is a real lifecycle state, not merely publication of source code.
The control-plane model must remain meaningful without Jangala.
15. Journey: the owner later returns to Jangala management
The same owner later wishes to return BB123 to Jangala-managed service.
This is not treated as revival of the previous managed identity.
The product goes through a reprovisioning ceremony and enters:
with fresh credentials.
The former managed epoch remains retired.
This is already the direction of the Big Box trust design.
What this implies
Physical product identity and management identity are distinct.
Epochs provide clean boundaries across major authority/trust transitions.
16. Journey: Jangala changes its cloud platform
Several years from now, Canopy's implementation changes substantially, or a partner moves to a self-hosted deployment.
Products should not need a conceptual migration from one device model to another.
The new system authenticates an appropriate Principal and receives locally granted authority.
The product still contains:
Canopy's database schema and implementation may have changed completely.
What this implies
Canopy must not become the ontology of the product.
The product API should be semantic and stable above Canopy/Mainflux/Magistrala implementation details.
17. Journey: neighbouring Jangala products cooperate without cloud
A future deployment contains a Big Box and several Get Boxes.
The Big Box has a strong upstream connection.
A nearby Get Box can discover that the Big Box offers an appropriate local connectivity Capability.
An authorised local relationship is established between the products.
The Get Box can consume that capability without the interaction being routed through Canopy.
Canopy may observe the relationship later if it has the appropriate Grants.
What this implies
The same broad ideas of:
should ultimately apply beyond human/cloud administration.
Fabric, local product federation and Canopy occur at different scopes, but need not be unrelated architectural worlds.
18. What these journeys tell us
Taken together, the journeys require several properties.
The product must remain locally sovereign
Cloud absence must not remove:
Authority must be explicit
We need to distinguish:
Credentials cannot be the authority model
Credentials rotate and disappear.
Authority must survive ordinary credential lifecycle.
Durable authority needs identity across time
Revoked authority must not return because an organisation has the same display name later.
Hence authority Epochs.
Configuration needs provenance
Several legitimate actors may want different things.
Hence Intent rather than one destructive desired-state document.
Persistent and transient operations differ
Hence Intent versus Capability.
Product truth must remain local
Hence canonical State.
Recovery must be layered
Lost passwords, lost clouds, reassignment, Root transfer and software-trust transitions are different events.
They should not all become “factory reset”.
Cloud and local authentication should converge on one authorisation model
OAuth, passkeys, offline organisational delegation and recovery proofs are different authentication mechanisms.
They should resolve to locally meaningful authority rather than creating separate local/cloud control systems.
19. Architectural consequence
These journeys lead to a compact model:
flowchart TB subgraph RootPlane["ROOT"] ID["Product identity"] Trust["Trust world"] RA["Root authority"] RE["Root epoch"] Recovery["Recovery policy"] end subgraph ControlPlane["CONTROL"] P["Principals"] Cred["Credentials / assertions"] G["Grants + authority epochs"] I["Intent"] C["Capabilities"] S["State"] CFG["cfg/..."] Domains["Devicecode domains"] end RootPlane --> ControlPlane Cred --> P P --> G G --> I G --> C G --> S I --> CFG CFG --> Domains C --> Domains Domains --> SThe remaining architecture can then be introduced as the machinery required to provide the journeys above.
The argument for a sovereign device model is therefore not primarily theoretical.
It follows directly from the user experience we want:
All reactions