Authorization That Survives Disconnection: Capability-Based Security and Portable Evidence for the Cloud-Fog-Edge Continuum

Abstract

Authorization in Internet of Things deployments assumes a reachable cloud; the cloud-fog-edge continuum breaks that assumption where decisions matter most. This article presents a delegation architecture in which authority is granted at the cloud and attenuated tier by tier down to fog nodes, gateways, and constrained devices, with caveats for topic scope, rate, geofence, and validity window. The architecture requires every tier to verify locally and offline, binds requests to the leaf key, bounds revocation by epochs and expiry, and records decisions as hash-chained evidence. A Python reference implementation realizes verification, request handling, revocation, and evidence; the device-tier verifier and the attested OP-TEE fog verifier are specified, not built. In a medical IoT scenario, CBOR-encoded chains fit CoAP without block-wise transfer up to depth 4 and a negotiated BLE notification at depth 1; on LoRaWAN only a depth-1 chain fits, at the fastest data rates without repeaters, so LoRa-class links need session-anchored authorization. Under hour-long disconnection, authorization availability is 0.93–0.98 for expiry horizons of 8 h or more, and a credential revoked while still valid stays honored for 32–33 min. On three Raspberry Pi boards, chain verification costs 327–645 $\mathsf{\mu }$s per hop, under 4 ms at depth 6, and about 0.38 mJ per hop.

1. Introduction

Authorization in deployed IoT systems is a promise about connectivity. The device asks, the cloud decides, the answer travels back, and every link in that sentence is an assumption the cloud-fog-edge continuum breaks. Intelligence is moving out of centralized platforms into fog nodes, gateways, and the devices themselves; the network between those tiers is intermittent by design and adversarial by exposure; and the decisions that matter most (may this actuator fire, may this reading leave the ward) arrive when the uplink is congested, degraded, or gone. An architecture that sends every authorization decision to a reachable policy server has made the availability of that server a precondition for safety at the edge.

The mismatch sharpens as the delegate changes character. The requester at the edge is no longer only firmware following a schedule. It is increasingly an autonomous agent, an edge-AI controller or an orchestrator spawning tasks across tiers, whose authority is delegated, sub-delegated, and exercised at machine speed [1]. Governing such delegates with coarse, cloud-issued bearer tokens repeats a mistake the security community has diagnosed once already: ambient authority, decoupled from the request that exercises it, is the confused-deputy vulnerability class [2,3]. The continuum needs authority that carries its own bounds, narrows at every delegation hop, is verifiable where the action happens, and is accountable afterwards.

This article presents such an architecture and measures it. Authority originates at the cloud root and attenuates tier by tier (fog node, gateway, constrained device) as a chain of signed capability grants whose caveats speak the vocabulary of IoT deployments: topic scope, rate limits, geofences, validity windows. The design requires verification to be local at every tier: a fog node, a gateway, or a constrained device checks the full chain offline, with no policy-server round-trip and no availability dependency. Revocation is epoch-based, with expiry as the hard safety bound, which turns staleness from an unbounded liability into a tunable parameter. Every authorization decision leaves a hash-chained evidence record, buffered through disconnection and anchored upstream on reconnect, so offline operation stays auditable. The fog node is where the design concentrates trust, so its verifier is specified for a confidential-computing tier: an ARM TrustZone/OP-TEE trusted application whose remote-attestation evidence [4] would cover verification and evidence-writing and turn “trust the gateway” into a claim that can be checked.

The contributions:

C1. 

A continuum delegation architecture: cloud-rooted capability chains with monotone, attenuation-only caveats for topic scope, rate, geofence, and validity window, specified for local, fail-closed verification at every tier, with explicit request handling: proof of possession, replay protection, and verifier-side rate counting (Section 4).

C2. 

Disconnection-tolerant operation with explicit semantics: an epoch/expiry revocation model that bounds staleness, and a quantified trade between availability and exposure under offline windows from minutes to days, with the stochastic model stated in full (Section 4 and Section 6).

C3. 

A portable evidence tier at the fog: signed, hash-chained decision records, buffered offline and anchored on reconnect, with the guarantee stated separately for each way evidence can be altered or lost. The evidence log is implemented; the attested OP-TEE verifier that would protect the writer itself is specified, not built (Section 4 and Section 5).

C4. 

An evaluation in an Internet of Medical Things scenario: credential size against the payload budgets of MQTT, CoAP, BLE, and LoRaWAN under stated configurations; authorization availability and revocation exposure under disconnection (simulated); and verification latency and energy of the reference implementation, measured on fog- and gateway-class boards (Section 6).

The measurements cover the reference implementation on fog- and gateway-class boards; they do not cover the full four-tier architecture. Device-class verification and the overhead of attesting the fog verifier are not measured here; Section 5 lists what is implemented, measured, simulated, estimated, or only specified, and Section 7 states what that leaves open.

The architecture instantiates, for the continuum, the runtime-governance program of computational jurisprudence [5]; its cryptographic machinery for sealed delegation and graduated attribution is out of scope here. Section 2 positions the design against capability-based access control for IoT, attenuable-token systems, edge attestation, and offline authorization. Section 3 states the system and threat model, Section 4 the design, Section 5 the implementation, and Section 6 the evaluation. Section 7 discusses limits, and Section 8 concludes.

2. Related Work

Four lines of work border this design. To the best of our knowledge, none combines attenuable delegation, offline verification, portable evidence, and attested enforcement.

• Capability-based access control for IoT.

The CapBAC line is the design’s closest ancestor. Gusmeroli et al. [6] argued for capabilities over identity-centric access control in IoT a decade ago; DCapBAC [7] pushed authorization onto constrained devices through ECC optimizations and showed that local enforcement on smart things is feasible. The line has since moved toward externalized trust: blockchain-mediated capability management [8] puts token state on a ledger, and verifiable-credential schemes [9] anchor capabilities in the W3C VC ecosystem [10]. A 2025 survey of IoT access-control models [11] names the line’s persistent gaps: revocation efficiency, interoperability, and reliance on trusted third parties. This article addresses the first and the third. Revocation is epoch-based with a quantified staleness bound, and no ledger, online authorization server, or third party sits on the decision path. The delegation format stays neutral to transport and ecosystem.

• Attenuable-token systems.

Macaroons [12] introduced bearer credentials whose caveats can only narrow authority, verified offline; Biscuit tokens carry the same discipline onto public-key cryptography with Ed25519 chaining. Both live mostly in cloud and microservice deployments. Their newest adopters are agent stacks, where Biscuit-style invocation-bound tokens carry delegation across agent protocols [13]. To our knowledge, no peer-reviewed work evaluates them on IoT-class hardware and IoT-class transports. Section 6 prices attenuable chains in the terms an IoT architect needs, bytes against LoRaWAN and BLE payload budgets and microseconds of verification on fog- and gateway-class boards, and reports where the discipline fits and where it does not. The attenuation semantics follow the monotone, conjunctive, negation-free fragment whose analyzability is argued in [5].

• Trusted execution at the edge.

Remote attestation of edge infrastructure has matured from secure-boot chains on TrustZone nodes [14] to the standardized RATS architecture [4]. Confidential-computing surveys map the widening gap between cloud-class TEEs (SEV-SNP and TDX, characterized empirically in [15]) and what edge hardware offers [16,17]. This article uses that machinery without extending it. Its contribution is placement: it specifies attestation of the authorization verifier and evidence writer at the fog tier, so the component every device must trust is the component that proves what it runs.

• Offline and disconnection-tolerant authorization.

Production systems acknowledge the problem: Azure IoT Edge caches identities and tokens so that child devices can authenticate through an offline gateway [18]. Such cached-credential designs are the realistic centralized alternative to a capability chain, and Section 6.2 compares against them as well as against an online-only decision point. Peer-reviewed treatment of authorization semantics under disconnection is thin, and the first dedicated designs are only now appearing as preprints. Vouchsafe [19] builds an offline capability graph for zero-infrastructure trust, without revocation semantics or an evidence layer. Three questions stay open: what a cached credential authorizes, for how long, and what revocation means while the uplink is down. Section 4 answers them with explicit semantics (expiry as the hard bound, epochs as the freshness parameter), and Section 6 quantifies the resulting frontier between availability and staleness, to our knowledge the first such quantification for capability chains on the continuum.

Within our own program, the architecture instantiates Pillars I–II of computational jurisprudence [5] for the continuum. The agentic-payments instantiation [20] shares the enforcement pattern and none of the tiers, transports, or hardware evaluated here. The evidence side of the program has two published instantiations for ambient-assisted-living telemetry: a compliance transformation layer that seals records at the edge gateway [21], and its ledger-anchored extension, which commits batched Merkle roots to a consortium ledger so that a verifier holding no key can check them [22]. This article is the authorization-side counterpart: those papers make the record of an action believable to a third party; this one makes the authority for the action verifiable where it is exercised, and its evidence layer (Section 4.5) follows their anchoring pattern. Sealed delegation chains and graduated attribution (Pillar III) remain future work.

3. System and Threat Model

3.1. The Continuum, Concretely

We model four tiers, named throughout with the running IoMT scenario. The cloud tier is the hospital’s backend: it holds the organizational root of authority and the long-term evidence store. The fog tier is a ward-level node (a Pi-class machine in a network closet) that mediates between the hospital network and the ward’s devices; it concentrates both function and risk. The gateway tier is a bedside unit bridging IP transports to constrained radios. The device tier is the sensor or actuator itself: a microcontroller-class endpoint (Cortex-M or ESP32 class) that reports vitals or drives an infusion-rate limiter, reachable over BLE, IEEE 802.15.4, or LoRaWAN, and publishing over MQTT or CoAP where IP is available [23,24].

Two properties of this environment drive the design. Disconnection is normal: uplinks fail, wards reconfigure, mobile carts roam; offline windows range from seconds to days, and safety-relevant actions cannot wait for reconnection. Constraint is permanent: device-tier memory, energy, and payload budgets (Section 6) do not grow with Moore’s law, so whatever the credential format costs, it pays on every exercise.

3.2. Threat Model

We consider four adversary classes. (A1) Compromised device: an attacker controlling a device-tier endpoint tries to exercise authority beyond its grant (publish outside its topic scope, exceed its rate, act outside its geofence or window) or to replay captured credentials. (A2) Rogue or compromised gateway/fog node: the mediating tier tries to broaden authority as it re-delegates, to fabricate or suppress evidence, or to honor credentials it should reject. (A3) Network observer: reads and injects traffic on any link; constrained radios offer no confidentiality beyond what the credential and session layers provide. (A4) Disconnection-window attacker: exercises a revoked credential during an offline window, exploiting the gap between revocation issuance and epoch synchronization. Section 6 quantifies this staleness channel by simulation. Clock manipulation is in scope as a capability of A1 and A2: a requester may lie about time, and a compromised verifier may set its own clock back to extend expired credentials.

The trust assumptions are these. The cloud root’s signing key is sound. Ed25519 and SHA-256 are secure. The OP-TEE trusted application at the fog tier is correctly attested per RATS [4], with the hardware vendor’s attestation-key infrastructure as residual root risk, as in every TEE deployment [15,17]. Device-tier endpoints hold their private keys in whatever key storage the platform affords, which at MCU class is weak. The OP-TEE trusted application is specified, not implemented (Section 5), so this assumption describes the target architecture; Table 1 states what holds without it.

Table 1. What a compromised fog node (A2) can do, with the reference verifier as implemented and with the attested verifier as specified (Section 4.6).

A2 Behavior	Implemented Verifier (No TEE)	Attested Verifier (Specified)
Widen authority at downstream verifiers	Prevented: they verify the chain against the root	Prevented
Accept requests it should reject, at its own verifier	Not prevented	Detectable where receivers demand a TA-signed verdict; otherwise the normal world bypasses the TA
Set its clock back to extend expired credentials	Not prevented	Prevented only with a secure time source in the TEE
Forge or rewrite unanchored evidence	Not prevented: the node holds the writer key	Prevented: the key stays in the TA
Rewrite anchored evidence	Detected at the anchor	Detected at the anchor
Drop requests, withhold or destroy the evidence buffer	Not prevented; visible as missing anchors	Not prevented; visible as missing anchors

• Time and location.

Validity windows and epochs are only as sound as the clock that evaluates them, and a geofence is only as sound as the position it is checked against. The verifier therefore uses its own clock and its own location source. A requester’s timestamp is checked against the verifier’s clock within a skew bound (30 s in the reference implementation) and never decides anything by itself. Fog and gateway nodes keep time with a battery-backed real-time clock, disciplined while online by authenticated time synchronization such as Network Time Security [25]; a crystal with $\pm 20$ ppm tolerance drifts by at most 3.5 s over a 48 h outage, well inside the skew bound. A device-tier verifier without a real-time clock counts monotonic time since its last authenticated synchronization; after a reboot without a time source, it fails closed on every time-bound caveat until it resynchronizes. These clock rules are design requirements; the reference implementation takes verifier time as an input.

Location follows the same rule. The verifier checks a geofence against a position it trusts, such as the installed position of a fixed bedside device or a fixed beacon infrastructure for mobile carts, and not against a position the requester reports. A device that reports its own position can spoof it (A1), so a geofence over self-reported location binds only an honest device. Deployments that need spatial authority must supply the position from the verifier side.

• Byzantine behavior.

A1 and A2 are Byzantine adversaries: a compromised device or fog node may act arbitrarily (lie, equivocate, collude, present valid credentials toward invalid ends) and need not merely stop. We have addressed dependability under this fault model before, for service-oriented systems, by binding assurance instruments to each phase of the life cycle, with replication as the runtime instrument [26]; the continuum keeps the fault model and changes the instrument. Replication is unaffordable at constrained tiers, so the design bounds Byzantine behavior instead of outvoting it. What it can bound depends on what is built, and Table 1 separates the two cases. With the reference verifier as implemented, without a TEE, fail-closed verification at every other tier confines a Byzantine fog node to the monotone closure of its own grant: downstream gateways and devices verify the full chain against the cloud root, so the node cannot widen authority there. Inside its own verification path the node is unconstrained. It can honor requests it should reject, set its clock back, and write, withhold, or rewrite evidence it has not yet anchored. The attested verifier, once built, narrows this: a doctored verifier fails attestation, and evidence signed by a key that never leaves the trusted application can no longer be forged by the normal world.

The design offers no Byzantine consensus and no masking. There is no replicated fog quorum; a Byzantine fog node costs its subtree availability or staleness until detection; and masking through replicated attested verifiers is future work in the life-cycle spirit of [26].

Non-goals. The design excludes: anonymity of delegation chains and minimal-disclosure attribution (sealed chains, Pillar III of [5]); protection against a compromised cloud root, which is the trust anchor; availability under radio jamming; and IoMT-specific clinical safety logic, for which the architecture supplies the enforcement substrate and leaves the policy content to the deployment [27].

4. Design: Attenuated Authority for the Continuum

Four mechanisms carry the design: capability chains that only narrow, verification that never phones home, revocation with bounded staleness, and evidence that survives disconnection. This section states the design; Section 5 states which parts are implemented.

4.1. Capability Chains and the IoT Caveat Vocabulary

Authority is a chain of signed grants. The cloud root issues a grant to the fog node’s key; the fog node re-delegates to a gateway, and the gateway to a device. Each hop is an Ed25519 signature over a canonical serialization that names the child’s public key and appends caveats. Caveats are conjunctive, negation-free, and attenuation-only, the fragment in which monotonicity holds by construction [5]: a child’s authority is always a subset of its parent’s, so the worst-case reach of any tier can be read statically off the root grant.

The vocabulary is chosen for the continuum. Topic scope: a prefix over the deployment’s naming hierarchy (ward3/bed12/vitals/), narrowed by extension at each hop. Rate: a per-minute exercise ceiling, non-increasing down the chain, counted by each verifier per leaf key (Section 4.3). Geofence: a containment circle, checked against a position the verifier trusts (Section 3.2); a child’s circle must lie inside its parent’s, so a mobile cart’s authority is spatial as well as topical. Validity window: valid_from/valid_until, with the child’s window contained in the parent’s; this caveat doubles as the revocation safety bound (Section 4.4). The verifier is fail-closed: an unknown caveat type, a non-narrowing caveat, a broken signature, or an action outside the accumulated caveat set each causes rejection. There is no permissive default and no fallback tier.

Two wire encodings serialize the same chain: a compact JSON form for IP transports and diagnostics, and a CBOR form with integer keys for constrained links. Section 6 prices both. The signature never covers the wire bytes. It covers one canonical byte string per hop, the same for both encodings: the hop body (index, roles, parent and child keys in hexadecimal, caveats) serialized as JSON with lexicographically sorted keys, no insignificant whitespace, ASCII output with \u escapes for other characters, and integers in shortest decimal form. A verifier decodes either encoding, rebuilds this string, and checks the signature over it, so the two encodings cannot verify different content. Decoding is strict. A CBOR chain is accepted only in canonical form, that is, only if re-encoding the decoded value reproduces the received bytes (for the small integer keys used here, the RFC 7049 canonical order and the RFC 8949 core deterministic order coincide [28]). A JSON object with a repeated key is rejected, because parsers disagree on which value wins. Text is accepted only in Unicode Normalization Form C, so that one topic cannot have two spellings that compare differently. Integers are bounded to the widths a fixed-width embedded verifier uses (32-bit rate, 64-bit time). One point stays fragile: geofence coordinates are floating-point values serialized by the shortest round-trip representation, which another language must reproduce byte for byte. A production profile should sign the deterministic CBOR bytes directly or adopt the JSON Canonicalization Scheme [29], and encode coordinates as scaled integers.

4.2. Local Verification at Every Tier

Every tier verifies the full chain (signatures, key succession, monotone attenuation, caveat satisfaction for the presented action) locally and offline. No policy decision point sits on the exercise path: not the cloud, which may be unreachable; not the fog, which may be the adversary (A2); nothing whose availability could gate a bedside action. The companion program established the same result for agentic payments [5,20]: a remote decision point costs a round-trip on every action and an availability dependency always, while local capability verification costs microseconds and holds during disconnection. On the continuum that dependency is a safety cliff, and removing it is the purpose of the design. Local verification at every tier is a design requirement; this article implements and measures it at the fog and gateway tiers (Section 5).

4.3. Handling a Request

A valid chain proves a delegation. It does not prove that the party presenting it holds the leaf key, that the request is fresh, or how often the authority has been used. Three checks close that gap, performed after chain verification and the revocation check.

Proof of possession. The requester signs the request with the leaf private key: the chain digest, the topic, a digest of the message payload, a counter, and its own timestamp, under a domain-separation prefix. The verifier checks this signature against the child key named in the last hop. A captured chain without the leaf key authorizes nothing, and the payload digest binds the authorization to one message. Freshness. The timestamp must lie within the skew bound of the verifier’s clock, and the counter must exceed the highest counter the verifier has consumed for that leaf key. An authenticated, fresh request on a valid chain consumes its counter whatever the action verdict, so no signed request is ever evaluated twice; a request that fails chain verification or proof of possession consumes nothing, which is why steps 3 and 4 of Table 2 carry the same counter. Rate. The verifier counts the leaf key’s accepted exercises in a sliding 60 s window and rejects the request that would exceed the effective ceiling. The count is the verifier’s own; the requester claims nothing about it.

Table 2. Worked example: successive requests from one sensor at one fog verifier, as the reference implementation processes them (request_trace.py). Depth-4 IoMT chain (the device sub-delegates to one sensor), effective caveats: topic ward3/bed12/vitals/hr, 12 exercises per minute. t is verifier time in seconds after the first request; Ctr is the request counter. Every row, allow or deny, appends one evidence record; step 5 aggregates ten accepted requests. Before step 9 the verifier installs epoch 1, which revokes the gateway-to-device hop.

Step	t	Ctr	Signed by	Request	Verdict and Reason
1	0	1	sensor	topic vitals/hr	allow
2	1	1	sensor	replay of step 1	deny: replayed or reordered request
3	2	2	device	parent key, not the leaf key	deny: no proof of possession of the leaf key
4	3	2	sensor	topic meds/rate	deny: action topic outside topic_prefix
5	4–13	3–12	sensor	10 requests	allow
6	14	13	sensor	12th exercise in the minute	allow
7	15	14	sensor	13th in the minute	deny: action rate exceeds rate_limit_per_min
8	61	15	sensor	step 1 has left the window	allow
9	62	16	sensor	after epoch 1	deny: chain contains a revoked hop

Replay and rate state is kept per leaf key, in the verifier’s memory. A restart loses it, so a restarted verifier refuses every request for a warm-up period of $\max (60\mathrm{s},2\times \mathrm{skew}\mathrm{bound})$. Any request accepted afterwards carries a timestamp later than the restart, so a request captured before the restart cannot be replayed; and no exercise from before the restart is still inside the rate window, so a reboot cannot reset the budget. State is not shared between verifiers. A leaf key served by k verifiers, for instance during failover, can reach k times its rate; a deployment that needs a global ceiling must split it across verifiers in the chain itself.

Table 2 traces successive requests from one sensor through the reference implementation. A replayed request, a request signed by the parent device instead of the leaf, a topic outside scope, the thirteenth exercise in a minute, and a request after a revoking epoch are each refused, and every decision leaves one evidence record. Proof of possession adds one Ed25519 verification per request, the cost of one more hop (Section 6.1); it has not been timed on the boards.

4.4. Revocation: Epochs Below, Expiry Above

Under disconnection, revocation cannot be both instantaneous and available; the design makes the trade explicit. Revocations are batched into epochs of length E: each epoch publishes a revocation digest signed by the cloud root, listing revoked hops, and a verifier refuses every chain that contains a revoked hop from the moment it installs that epoch. Revoking a hop revokes every chain below it. An offline verifier cannot receive epochs, so the validity window caps its exposure: a revoked credential is honored at most until its valid_until, whatever the connectivity. While offline, staleness is therefore bounded by $\min (\mathrm{time}\text{-}\mathrm{to}\text{-}\mathrm{expiry},\mathrm{offline}\mathrm{remainder})$; after reconnection the verifier may wait up to one more epoch before the revocation reaches it. The deployment tunes the trade by choosing expiry horizons per tier and role: short horizons for actuation authority, longer ones for telemetry. Its time base is the verifier’s clock, under the rules of Section 3.2.

Two terms carry the evaluation. Authorization availability is the fraction of an offline window during which a credential that was valid at disconnection stays exercisable at its verifier. It is a property of the credential under disconnection, not of the system; it says nothing about radio, power, or service availability. Revocation exposure (staleness) is the time a credential stays honored after it is revoked. Section 6.2 quantifies both for offline windows from one minute to 48 h. The operator picks a point on that frontier, and the architecture enforces it.

4.5. Evidence: Hash-Chained, Buffered, Anchored

Offline operation must stay auditable. Every authorization decision, allow or deny, emits a decision record: chain digest, leaf key, request counter, topic, payload digest, verdict and reason, epoch identifier, and verifier time. Record n carries sequence number n and the hash of record $n-1$, and the writer signs each record. During disconnection the chain grows in local storage. On reconnect the verifier ships the segment upstream, and the cloud evidence store records an anchor, the pair (sequence number, head hash), which fixes every record up to it. The pattern reuses the append-only observation discipline and content-addressed evidence conventions of the broader program [5].

The anchoring interval A is the design’s second freshness parameter, next to the epoch length E. E bounds how long revocation lags behind issuance; A bounds how much evidence a failing or compromised node can lose or rewrite. Short outages anchor on reconnect; wards with strict evidentiary requirements should also anchor opportunistically, over any reachable path, at a fixed A.

What hash chaining guarantees depends on whether a record is anchored and on who controls the writer. Table 3 separates the cases. A third party who alters stored or transmitted evidence is always detected, by a broken link, a bad signature, or a sequence gap. A compromised writer without a TEE holds the signing key and can rebuild any suffix it has not anchored, so for unanchored evidence hash chaining proves nothing against the writer itself. Anchored records are fixed against everyone. No mechanism here proves that a decision which was never recorded took place. Request counters give one indirect signal: if a leaf key’s counters in anchored records skip values, some requests reached no record, although a device may also skip values on its own.

Table 3. Evidence-layer guarantees by failure case. “Detected” means the cloud evidence store detects the change when it checks the shipped segment against record signatures, hash links, sequence numbers, and earlier anchors.

Case	Third Party (Storage, Transit)	Compromised Writer, No TEE (Implemented)	Attested Writer (Specified)
Modify an anchored record	Detected	Detected	Detected
Modify or delete an unanchored record, or an unanchored internal segment	Detected	Not detected: the writer re-signs the suffix	Detected: the key stays in the TA
Suppress a new record (decision never logged)	–	Not detected	Not detected for requests withheld from the TA
Truncate the unanchored tail	Not detected; loss bounded by A	Not detected; loss bounded by A	Not detected; loss bounded by A
Destroy the buffer before anchoring	Lost; missing anchor visible	Lost; missing anchor visible	Lost; missing anchor visible

4.6. The Attested Tier: Proving the Verifier

The fog node concentrates the design’s residual trust: it re-delegates, verifies for its subtree, and holds the evidence buffer. The attested tier is meant to turn that trust into a claim that can be checked. It is specified, not built (Section 5); this subsection states the trust path precisely enough to assess.

The verifier and evidence writer execute as a trusted application (TA) under OP-TEE on the fog node’s TrustZone. The trust path follows the background-check model of the RATS architecture [4]. The attester is the fog node: its secure boot chain, the OP-TEE OS, and the TA. The verifier is a cloud attestation service holding reference values for the boot chain and every released TA version. The relying party is the cloud evidence store, which accepts evidence segments and re-delegations only from a node whose attestation result is current. Evidence takes the form of an Entity Attestation Token [30], signed by a device attestation key provisioned by the hardware vendor. Its claims are the measurements of the boot chain (trusted firmware and OP-TEE OS) and of the TA binary, the hash of the configured trust anchor and caveat vocabulary version, and the public half of the evidence-signing key. The TA generates that key inside secure storage and never exports it, so the attestation binds the key to the measured instance.

Freshness comes from the relying party. At every reconnect the cloud sends a nonce, the node returns a token over it, and only then does the cloud accept the buffered segment. Segments written offline are accepted only if they are signed by the key attested at the previous connection and continue the hash chain from the last anchor; a node that cannot attest at reconnect has its segment held, not anchored. A software update changes the TA measurement. The cloud adds the new reference values before rollout; the updated TA generates a new evidence key, and the first record under that key carries the last anchor of the old key, so the rotation itself lies on the chain. OP-TEE’s rollback protection, together with withdrawal of old reference values, refuses a downgrade to a superseded TA.

This makes a doctored verifier or evidence writer on a compromised fog node (A2) detectable by attestation, at the next reconnect rather than at the moment of compromise. It gives no protection against vendor-key compromise or physical side channels [14,16], and none against a normal world that drops requests before they reach the TA (Table 1). Attestation applies at the fog tier, where the hardware affords it; MCU-class devices remain outside the attested perimeter, which is why their authority is the most attenuated in the chain.

5. Implementation

The reference implementation is complete for the fog and gateway tiers, and Section 6 measures it. The embedded verifier and the OP-TEE trusted application are specified but not yet built, and this article reports no measurements for either. Table 4 gives the status of every component, and the rest of the article uses the same distinction.

Table 4. Status of each architecture component in this article.

Component	Status
Chain verification (signatures, key succession, attenuation, caveats)	Implemented; vector-tested; latency and energy measured on three boards (X1)
Wire encodings and strict decoding (JSON, CBOR)	Implemented; vector-tested; sizes exact (X3)
Request handling (proof of possession, replay, rate)	Implemented; vector-tested; worked example (Table 2); not timed on boards
Revocation epochs	Implemented; vector-tested; availability and exposure simulated (X2)
Evidence log (signed, hash-chained records)	Implemented; vector-tested; not timed on boards
Anchoring protocol (shipping segments, storing anchors)	Specified (Section 4.5)
Clock discipline and trusted location source	Specified (Section 3.2); the implementation takes time and position as verifier inputs
Device-tier no_std verifier	Specified; timing estimated from a published Ed25519 cycle count
OP-TEE trusted application and attestation	Specified (Section 4.6); neither built nor measured

• Reference implementation and correctness gate.

A Python reference implementation (feasibility/ in the artifact repository) realizes the complete chain semantics: Ed25519 per-hop signatures over the canonical serialization of Section 4.1, child-key succession, the four-caveat vocabulary with monotone-attenuation checking, fail-closed verification against presented actions, and both wire encodings (compact JSON; CBOR with integer keys). On top of chain verification it implements request handling (Section 4.3), root-signed revocation epochs, and the signed, hash-chained evidence log (Section 4.5). It takes verifier time and position as inputs, so the clock and location rules of Section 3.2 sit outside it.

A vector suite of golden and adversarial cases gates every result. Nineteen vectors exercise every rejection path in the threat model’s A1/A2 repertoire (broadened topic, widened window, increased rate, geofence escape, wrong child key, tampered payload, expired credential, action outside caveats, unknown wire fields in either encoding) plus encoding-equivalence checks. Twelve more fall into two groups. Six cover wire robustness: truncated and non-UTF-8 input, a JSON object with a duplicate key, non-canonical CBOR (trailing bytes, reordered map keys), type confusion and out-of-range integers (a rate given as text or as a Boolean, a rate beyond 32 bits, a time beyond 64 bits, a fractional time, a malformed or out-of-range geofence), a topic not in Normalization Form C, and a malleated signature with $S+L$ in place of S. Six cover requests and evidence: proof of possession, replay and clock skew, verifier-counted rate, restart warm-up, revocation by epoch (including an epoch not signed by the root), and evidence tampering (an edited anchored record, a deleted internal record, a truncated anchored tail, and an unanchored truncation that is not detected, matching Table 3). All 31 pass, and every malformed input ends in the verifier’s single rejection error and in no other exception. Run against the submitted implementation, five of the six new wire vectors fail: it accepted duplicate JSON keys, non-canonical CBOR, and text outside Normalization Form C; it decoded mistyped fields, which only the signature check then rejected; and it raised parser exceptions on truncated input. The malleated signature was already rejected, because the Ed25519 library enforces $S<L$. The vectors are the oracle against which every later implementation is certified.

The board measurements of Section 6.1 were taken with the submitted implementation and its 19-vector gate. They time chain verification alone, which the revision leaves unchanged; the stricter decoding and everything built on top of chain verification sit outside the timed path.

• Embedded verifier.

The device-tier verifier is specified as a Rust implementation targeting no_std operation on Cortex-M and ESP32-class hardware, to be certified against the same vector suite. A side-channel-hardened Ed25519 implementation verifies in roughly 720k cycles on Cortex-M4 [31], which puts one hop at roughly 4–11 ms at clock rates of 64–168 MHz. This is an estimate of the signature cost from the published bound; it is no device-tier authorization benchmark, and this study does not measure it. A complete device-tier verifier also parses the chain, evaluates caveats, checks key succession, rebuilds the canonical serialization, allocates memory, and shares the processor with radio and application code; any of these can move the real figure materially.

• OP-TEE trusted application.

The fog-tier verifier and evidence writer are specified to execute as an OP-TEE trusted application with the trust path of Section 4.6. The normal world passes chains and requests across the TA boundary, together with epoch digests, and receives verdicts and signed evidence records. The quantities that would price this tier are attestation token generation and verification, and the world-switch cost the TA boundary adds to each verification and evidence write, measured against the plain fog verifier of Section 6.1. We do not measure them here.

All reported results are generated from committed CSVs by a single script, seeds are recorded in every result file, and the continuum-capability-eval repository is tagged at the commits that produced the reported results (Data Availability Statement).

6. Evaluation

The evaluation asks three questions. X1: what does chain verification cost at the fog and gateway compute classes? X2: what does disconnection-tolerant authorization cost in revocation staleness, and what does it buy in availability? X3: does an attenuable capability chain fit the transports the continuum uses? X1 reports measurements of the reference implementation on three real boards (the rented reference Pi 4, a lab Pi 4, and a lab Pi 3), with board-level energy on the lab Pi 4, the one board we could instrument physically. X2 is a seeded simulation study over the design’s parameter space, and X3 is platform-independent. Device-class verification and attestation overhead are outside this evaluation (Section 5 and Section 7).

Setup. All numbers come from the reference implementation and its result scripts; every CSV row records its seed; the simulation uses 10,000 trials per grid point at base seed 20260718. The chain under test is the running IoMT scenario, cloud root → ward fog → bedside gateway → device, with a realistic caveat set (topic ward3/bed12/vitals/hr, geofence, rate, window) and depths 1–6 to cover sub-delegation within tiers.

6.1. X1: Verification Latency at the Fog and Gateway Tiers

Table 5 reports full delegation-chain verification on three real boards spanning the fog and gateway compute classes: the rented reference Pi 4 (Mythic Beasts, 1.5 GHz), a lab Pi 4 (1.8 GHz), and a lab Pi 3 (Cortex-A53, 1.2 GHz). Each is 10,000 verifications per depth after warmup, with the 19-vector correctness gate passed before any timing; the three platforms are reported side by side and never merged. On every board the cost is linear in depth to within measurement noise and Ed25519-dominated: the incremental slope is $\sim 390\mathsf{\mu }$s per hop on the rented Pi 4 (2.35 ms p50 at depth 6), $\sim 327\mathsf{\mu }$s per hop on the lab Pi 4 (1.96 ms), and $\sim 645\mathsf{\mu }$s per hop on the lab Pi 3 (3.84 ms). Distributions are tight throughout under the performance governor, with no thermal drift (all boards stayed below 57 °C), so the figures are stable operating points. The harness records percentiles and the minimum rather than every sample, so a standard deviation cannot be recovered without re-running the boards. The recorded spread is narrow: across all boards and depths the minimum lies within 1.2% below the p50, the p90 within 2.9% above it, and the p99 within 6% (3.6%, 3.3%, and 5.7% at most on the rented Pi 4, lab Pi 4, and Pi 3).

Table 5. Measured (this work). X1—full delegation-chain verification latency on the fog reference platform, by chain depth: hosted bare-metal Raspberry Pi 4 Model B Rev 1.4 (Mythic Beasts; aarch64, 64-bit OS, Python 3.11.2, performance governor, 1.5 GHz), 10,000 verifications per depth after 1000 warmup, correctness gate 19/19 (v1.0 suite), temperature 37.9→40.9 °C; lab Raspberry Pi 4 Model B Rev 1.5 (aarch64, Bookworm 64-bit, Python 3.11.2, performance governor, 1.8 GHz), 10,000 verifications per depth after 1000 warmup, correctness gate 19/19 (v1.0 suite), temperature 50.1→55.0 °C; lab Raspberry Pi 3 Model B Rev 1.2 (Cortex-A53, aarch64, Bookworm 64-bit, Python 3.11.2, performance governor, 1.2 GHz), 10,000 verifications per depth after 1000 warmup, correctness gate 19/19 (v1.0 suite), temperature 47.2→56.4 °C. Platforms are reported per column group and never merged.

Depth	Fog (Rented Pi 4)			Fog (Lab Pi 4)			Gateway (Lab Pi 3)
	p50 ($\mathsf{\mu }$s)	p99 ($\mathsf{\mu }$s)	Mean ($\mathsf{\mu }$s)	p50 ($\mathsf{\mu }$s)	p99 ($\mathsf{\mu }$s)	Mean ($\mathsf{\mu }$s)	p50 ($\mathsf{\mu }$s)	p99 ($\mathsf{\mu }$s)	Mean ($\mathsf{\mu }$s)
1	378.4	391.9	379.7	315.1	325.5	316.0	611.6	646.2	615.4
2	770.8	789.0	773.2	642.1	656.9	643.9	1254.4	1293.5	1260.1
3	1164.2	1183.3	1167.6	969.0	987.2	971.6	1908.2	1961.0	1909.7
4	1555.8	1575.1	1559.8	1295.9	1314.6	1299.0	2552.0	2593.3	2550.4
6	2354.4	2366.1	2351.3	1955.8	1978.2	1956.7	3836.6	3877.7	3839.6

The two Pi 4s are the same model on different hosting, and the runbook treats any disagreement beyond noise as a finding. Here the lab board is $1.20\times$ faster than the rented one at every depth, exactly the $1800/1500$ clock ratio. The Pi 3 is a genuinely lower compute class: it runs $1.96\times$ slower than the lab Pi 4, of which the $1.50\times$ clock ratio explains most and the remaining $\sim 1.3\times$ is microarchitecture (the in-order A53 against the out-of-order A72). These are reference-implementation (Python) figures: they price the fog and gateway tiers as deployed in our harness and give no basis for extrapolating to a compiled device-tier verifier. Even so, the budget holds with room to spare. The slowest board, a Pi 3 acting as a constrained gateway, verifies a depth-6 chain in under four milliseconds with no network dependency, while a remote decision point pays its round trip before doing any work.

Table 6 adds board-level energy on the physically accessible lab Pi 4. The method is coarse: whole-board watts, read by eye off an inline USB-C power meter, taken as the delta between a 1.84 W idle baseline and a 3.02 W sustained-load draw, divided by the sustained verification throughput over a 60 s loop per depth. Each reading carries $\pm 0.03$ W, so the 1.18 W delta carries $\pm 0.06$ W, or $\pm 5\%$, and Table 6 reports each energy value with that interval, rounded to its precision. The result is $0.38\pm 0.02$ mJ per hop, flat across depth within the interval, so energy scales linearly with chain length, as latency does, reaching $2.3\pm 0.1$ mJ for a full depth-6 verification. These are whole-board incremental figures: they include the Python interpreter, memory traffic, and everything else the board does under load, and they are not the energy of the cryptographic operation alone. Throughput falls from 3145 verifications per second at depth 1 to 509 at depth 6, which is the headroom a ward fog node has for authorization under sustained load. One caveat on method: inserting the meter power-cycles the board and does not persist the governor, so this run used ondemand rather than performance; the clock still held 1.8 GHz throughout, and the per-depth latencies matched the performance-governor run of Table 5 within 0.5%, so the energy figures sit on the same operating point as the latency figures.

Table 6. Measured (this work). X1—board-level energy per delegation-chain verification on the lab Pi 4, by chain depth. Sustained throughput is the mean over a 60 s fixed-duration loop per depth; energy is the whole-board load–idle power delta (3.02 W load over a 1.84 W idle baseline, eyeball-read off an inline USB-C power meter, $\pm 0.03$ W read uncertainty) divided by throughput. Governor ondemand for this run (meter insertion power-cycles the board and does not persist the governor); clock held 1.8 GHz throughout and per-depth latencies matched the performance-governor run within 0.5%. The interval propagates the read uncertainty of both readings linearly ($\pm 0.06$ W on the 1.18 W delta, $\pm 5\%$). This is whole-board incremental energy, not the energy of the cryptographic operation alone.

Depth	Throughput (ops/s)	Energy/Verify (mJ)	Energy/Hop (mJ)
1	3145	0.38 ± 0.02	0.38 ± 0.02
2	1546	0.76 ± 0.04	0.38 ± 0.02
3	1023	1.15 ± 0.06	0.38 ± 0.02
4	766	1.54 ± 0.08	0.39 ± 0.02
6	509	2.3 ± 0.1	0.39 ± 0.02

The device tier is not measured in this study. For Cortex-M4-class devices, the published $\sim 720$k-cycle Ed25519 verification bound [31] puts one signature verification at roughly 4–11 ms at 64–168 MHz, an order of magnitude above the fog figures. We cite this as a lower-level feasibility indicator, not as a device-tier authorization benchmark (Section 5).

6.2. X2: Availability and Staleness Under Disconnection

Model. Each trial follows one credential through one outage; the verifier goes offline at $t=0$ and reconnects at $t=D$, with D fixed per grid point. Credentials have a fixed lifetime H and are reissued at expiry while the verifier is online, and the outage starts at a time independent of that schedule. The remaining lifetime at disconnection is therefore uniform, $t_{\exp }\sim U(0,H)$; equivalently, issuance times are uniform relative to the outage. A revocation of the credential is issued at $r\sim U(0,D)$, independent of $t_{\exp }$, so the model studies revocations issued during the outage. Availability is $\min (t_{\exp },D)/D$. Exposure, the time a revoked credential stays honored, is $\max (0,\min (t_{\exp },D)-r)$: the credential is honored until it expires or the verifier reconnects, whichever comes first, and a reconnected verifier is assumed to learn the revocation at once. The epoch-aware variant drops that assumption: after reconnect the verifier waits $w\sim U(0,E)$ for the next epoch boundary, giving $\max (0,\min (t_{\exp },D+w)-r)$. This over-states the wait when the revocation precedes reconnection by more than one epoch, since that revocation is already published, so the variant is conservative. Online verifiers are assumed to hold the current epoch; the up-to-E lag they have while online is not counted. A trial is live if the credential is still honored at the moment it is revoked, that is, if its exposure is positive. Grid: D at 20 log-spaced points from 1 min to 48 h, $H\in \{15\min ,1\mathrm{h},8\mathrm{h},24\mathrm{h},168\mathrm{h}\}$, $E\in \{1,15,60,480\}$ min. The middle grid point, $D=3971$ s (66 min), is the log-spaced point nearest one hour; it was not chosen to match an observed outage.

Two closed forms check the simulation. For $D\ge H$ every credential expires before reconnect, so a fraction $H/\left(2D\right)$ of trials is live and the mean exposure of a live credential is $H/3$. For $H\gg D$ nearly every credential outlives the outage, so exposure is $D-r$ with mean $D/2$. The simulated values agree with both to within Monte Carlo error.

Baselines. The zero availability in the caption of Table 7 belongs to an online-only policy decision point: during disconnection it authorizes nothing, and legitimate and revoked authority are equally unavailable. That is an outage, and it buys no security. It is not the only centralized design. A cached-credential design (Section 2) that keeps a token of lifetime H at the gateway has, under this model, exactly the availability and exposure of Table 7: both are set by the expiry bound, not by the credential format. The frontier is therefore a property of expiry-bounded offline authorization in general. What the capability chain adds is not more availability. A gateway can attenuate and sub-delegate authority to a device that joins while the uplink is down, every tier can verify that sub-delegation offline, and each exercise carries proof of possession and leaves evidence.

Table 7. Availability and revocation exposure at representative grid points (offline duration D, expiry horizon H). Avail.: fraction of the offline window during which a credential that was valid at disconnection stays exercisable; an online-only PDP has availability 0 throughout. Live: fraction of trials in which the credential is still honored when it is revoked. Exposure: time a revoked credential stays honored, as a mean over all trials (credentials that expired before revocation count as 0) and over live trials only; the epoch-aware column adds the wait for the next epoch after reconnect at $E=15$ min. Exposure is in seconds (s), minutes (m), or hours (h). 10,000 seeded trials per point; Section 6.2 gives the sampling model.

				Mean Exposure
$\mathit{D}$	$\mathit{H}$	Avail.	Live	All	Live	Live, $\mathit{E}=\mathbf{15}$ m
1 min	1 h	0.991	0.994	30 s	30 s	7.3 m
1 min	8 h	0.999	0.999	30 s	30 s	7.9 m
1 min	24 h	1.000	1.000	30 s	30 s	8.0 m
66 min	1 h	0.455	0.451	8.8 m	19.5 m	19.5 m
66 min	8 h	0.934	0.931	30.1 m	32.3 m	39.2 m
66 min	24 h	0.977	0.976	32.5 m	33.3 m	40.6 m
48 h	1 h	0.010	0.011	13 s	19.5 m	19.5 m
48 h	8 h	0.084	0.082	13.4 m	2.72 h	2.72 h
48 h	24 h	0.249	0.253	2.00 h	7.92 h	7.92 h

Reading the table. Availability stays near unity for offline windows short relative to the expiry horizon (0.99 at $D=1$ min for $H\ge 1$ h; 0.93–0.98 at $D=66$ min for $H\ge 8$ h) and degrades as designed when windows approach the horizon (0.25 at $D=48$ h, $H=24$ h). The price is exposure, and the table reports it two ways. The mean over all trials counts a credential that expired before its revocation as zero exposure; the mean over live trials gives the exposure of a credential that is still valid when revoked. The two diverge when outages are long against the horizon. At $D=48$ h and $H=1$ h, only 1.1% of credentials are still live when revoked: the all-trial mean of 13 s is that fraction times a live exposure of 19.5 min, close to the closed-form $H/3=20$ min. A credential still valid at revocation is honored for about a third of its lifetime, and the short all-trial mean only says that most credentials die first. At $D=66$ min and $H\ge 8$ h nearly every credential is live, and exposure is set by the outage: a mean of 32–33 min, about $D/2$, which is where the $\sim 30$ min of the all-trial column comes from.

Epoch length. The epoch enters only after reconnect. At $E=15$ min it adds 7 min to the live exposure at $D=66$ min, $H=8$ h (32.3 to 39.2 min), and it adds nothing at $D=48$ h for $H\le 24$ h, where every credential expires before reconnect. Across the epoch grid, the live epoch-aware exposure at $D=66$ min, $H=8$ h is 32.4, 39.2, 58.8, and 167.5 min for $E=1$, 15, 60, and 480 min. While the epoch is short against the outage, it adds about $E/2$; an epoch longer than the outage dominates exposure. The table is the design’s contract with the operator: pick the horizon for actuation authority so that the live-exposure column is tolerable, pick E short against typical outages, and give telemetry authority longer horizons for availability.

6.3. X3: Credential Size Against Transport Budgets

Table 8 reports serialized chain size by depth for both encodings, against the application-payload budget of each transport under a stated configuration. LoRaWAN: application payload N with the FOpts field empty (MAC commands carried in FOpts reduce it), from the EU863-870 tables of the 1.0.3 Regional Parameters [32]: 51 B at DR0–DR2 (SF12–SF10); 222 B at DR4–DR7 in the repeater-compatible table; and 242 B at DR4–DR7 for a device that never operates behind a repeater. US902-928 uplinks allow 242 B at DR3–DR4 in the same document. BLE: one ATT Handle Value Notification or Write Command carries ATT_MTU − 3 bytes [33]. The default ATT_MTU of 23 leaves 20 B. The 244 B budget requires both a negotiated ATT_MTU of at least 247 and LE Data Length Extension at its 251 B link-layer maximum; the notification then travels in one link-layer PDU (251 B minus 4 B L2CAP and 3 B ATT header). Data Length Extension alone does not enlarge the ATT payload, and a large ATT_MTU without it splits one notification across several link-layer PDUs. IEEE 802.15.4: the 127 B PHY payload [34], an upper bound, since MAC and 6LoWPAN headers come out of it. CoAP: a payload of up to 1024 B in a message sized to fit one IPv6 packet at the 1280 B minimum MTU, without Block-wise transfer [24,35]. “Un-fragmented” refers to the CoAP layer only: over 6LoWPAN on 802.15.4 such a message is still fragmented by the adaptation layer [36]. MQTT: effectively unconstrained, at a 1 MiB broker default [23].

Table 8. Serialized capability-chain size and transport-payload fit by delegation depth (compact JSON vs. CBOR with integer keys). Sizes are exact serializations. Each transport column gives the application-payload budget under the stated configuration: LoRaWAN EU863-870 with FOpts empty, at DR0 and at DR5 with and without repeater compatibility (Regional Parameters 1.0.3, its Tables 8 and 9); BLE as one ATT notification or Write Command at the default ATT_MTU of 23 and at ATT_MTU ≥ 247 with LE Data Length Extension at 251 B; the 127 B IEEE 802.15.4 PHY payload as an upper bound; CoAP without Block-wise transfer in one IPv6 packet; MQTT at a 1 MiB broker limit (Section 6.3).

Depth	JSON (B)	CBOR (B)	CBOR/JSON	LoRa DR0 (51)	LoRa DR5 Rep. (222)	LoRa DR5 (242)	BLE Default (20)	BLE DLE (244)	802.15.4 (127)	CoAP (1024)	MQTT (1 MiB)
1	574	238	0.415	–	–	C	–	C	–	✓	✓
2	1067	446	0.418	–	–	–	–	–	–	C	✓
3	1572	664	0.422	–	–	–	–	–	–	C	✓
4	2078	882	0.424	–	–	–	–	–	–	C	✓
6	3091	1321	0.427	–	–	–	–	–	–	–	✓

Budgets in bytes. ✓: both encodings fit; C: only CBOR fits; –: neither fits.

Three findings stand out. First, CBOR encoding cuts the wire cost to $\sim 0.42\times$ JSON (238 versus 574 bytes at depth 1, $\sim 218$ versus $\sim 505$ bytes per hop), and moves the CoAP-layer ceiling without Block-wise transfer from depth 1 to depth 4, which separates a toy from a deployable chain on IP-class constrained links. Second, a depth-1 CBOR chain fits one BLE notification or Write Command whenever the negotiated ATT_MTU is at least 241, and it travels in one link-layer PDU at ATT_MTU ≥ 247 with Data Length Extension; nothing deeper fits, and at the default ATT_MTU nothing fits at all. Peers often negotiate less than 247 (some phones settle at 185), and then even a single-hop grant needs a Long Write or application-level fragmentation. For BLE-presented credentials, the practical delegation depth is one. Third, and against our own expectation, no evaluated chain fits within the repeater-compatible EU863-870 limits, and none fits at DR0–DR3 in either table. A depth-1 CBOR chain (238 B) fits the 242 B limit only at the fastest, shortest-range data rates (EU863-870 DR4–DR7 without repeaters, US902-928 DR3–DR4), with 4 B to spare and no MAC command in FOpts; adaptive data rate leaves those rates first as link margin shrinks. Credential presentation therefore does not belong on LoRa-class uplinks: at the long-range data rates nothing fits, and at the fast ones a single-hop grant fits with no margin, before LoRaWAN’s duty-cycle economics enter. LoRaWAN devices need session-anchored authorization, with the chain presented once over a provisioning channel and later exercises bound to a session key; fragmentation schemes are no answer on a transport this constrained.

7. Discussion and Limitations

Six limits bound these results.

Staleness is bounded, not eliminated. The epoch/expiry design converts revocation under disconnection from an unbounded liability into a tunable exposure, and X2 prices the tuning. A bounded window in which revoked actuation authority is honored is still a window. Deployments whose harm model cannot tolerate hours of staleness must buy short expiry horizons at the availability cost shown in Table 7, and safety-critical actuation may also need interlocks outside the authorization layer. The architecture makes the trade visible and leaves it in place.

Two tiers are specified, not measured. The evaluation prices the reference implementation at the fog and gateway tiers on real boards. It measures neither the compiled verifier on a device-class microcontroller nor the attested fog tier, so the architecture-wide claims of this article are design claims, and only the fog and gateway figures are measured ones (Table 4). For the device tier, the published Cortex-M4 Ed25519 bound estimates the signature cost alone; parsing, caveat evaluation, canonical serialization, memory allocation, and radio load are not in it (Section 5). For the attested tier, token generation and verification and the per-call world-switch cost remain open. Until that tier exists, a fully compromised fog node keeps the powers listed in Table 1 for the implemented verifier. Both are the next measurements for this architecture, on hardware in the classes named in Section 5.

The attested perimeter ends at the fog. TrustZone/OP-TEE attestation is specified to cover the verifier where the hardware affords it. MCU-class devices sit outside that perimeter with software-held keys, and the design compensates structurally by giving device authority the most attenuation in the chain. A compromised device still exercises everything its leaf grant permits until expiry or the next epoch. TEE trust carries the standard residue: vendor attestation-key infrastructure and physical side channels [16,17].

LoRa-class transports exclude presentation. X3’s negative result is a real boundary, scoped to the configurations of Table 8: no chain fits a LoRaWAN payload at the long-range data rates, and a single-hop grant fits the fastest rates only without repeaters and with 4 B to spare. The consequence, session-anchored authorization with out-of-band provisioning, reintroduces a provisioning-time dependency that the IP-class tiers do not have. The design claims local verification where the credential can travel and names where it cannot. A LoRa profile with a fixed caveat dictionary may narrow the gap and is future work.

Evidence buffering trusts the writer until anchoring. Hash chaining makes tampering by third parties detectable and gaps visible, yet evidence not yet anchored dies with the node that holds it, and a compromised writer without a TEE can rewrite it (Table 3). The anchoring interval A (Section 4.5) bounds both losses, and the anchoring protocol that enforces it is specified, not implemented.

What the continuum still cannot get from this design. Delegation chains here are visible to verifiers. Privacy of the delegation graph, minimal-disclosure attribution upon dispute, and bonded remedies belong to Pillar III, sealed delegation chains and graduated attribution [5], and their cryptographic cost on fog-class hardware is an open question. In our judgment the continuum is that program’s most demanding deployment target; this article supplies its substrate and a measured baseline.

8. Conclusions

Authorization that assumes connectivity fails the continuum at its most characteristic moment. This article argued for an alternative and priced it: authority as cloud-rooted capability chains that only narrow, designed for local verification at every tier, including disconnected ones; requests bound to the leaf key, fresh, and counted by the verifier; revocation as an explicit epoch/expiry contract with quantified staleness; evidence as hash-chained records that keep offline operation auditable; and a fog-tier verifier specified to attest what it runs. The reference implementation realizes chain verification, request handling, revocation epochs, and the evidence log; we measured it on fog- and gateway-class boards. The device-tier verifier and the attested fog tier remain specifications. The measurements give the architecture its IoT shape. CBOR encoding makes chains deployable to depth 4 on un-fragmented CoAP, where JSON reaches depth 1; BLE carries single-hop grants once ATT_MTU and Data Length Extension are negotiated up; LoRaWAN carries no chain at its long-range data rates and a single-hop grant only at its fastest, with no margin, which makes session-anchored authorization a design requirement. The trade between availability and staleness under disconnection is now a table an operator can use to set expiry horizons: a credential still valid when revoked stays honored for about a third of its lifetime once outages outlast it, and for about half the outage when they do not. On fog- and gateway-class boards, full-chain verification in the Python reference implementation costs 327–645 $\mathsf{\mu }$s and $0.38\pm 0.02$ mJ of whole-board energy per hop, under 4 ms at depth 6. Device-class verification and the overhead of attesting the fog verifier are the next measurements, and the sealed-delegation machinery of the wider computational-jurisprudence program remains the continuum’s hardest open problem. Trustworthy operation at the edge begins with authority that does not need to phone home.