A Metadata Model for Verifiable and Reusable Compute-Result Objects in Information-Centric Edge Networks

Introduction Edge and in-network computing systems increasingly execute functions close to data sources and users. A logical function may be instantiated at a terrestrial edge site, an enterprise gateway, a maritime platform, an airborne node, or a non-terrestrial node. The output of an invocation may subsequently be copied, cached, or transferred to another administrative domain. When a later requester needs the same or an equivalent computation, reusing a previously generated output may avoid repeated input transfer and execution. This is especially useful when connectivity is intermittent, contact duration is limited, or compute resources are energy constrained. Information-Centric Networking (ICN) provides location-independent naming, named data retrieval, in-network caching, and object-oriented security concepts that are relevant to this problem . However, an ordinary named payload is not sufficient to determine whether a computation result is acceptable for reuse. A requester may need to establish all of the following:

which logical service and service version produced the result;
which input object set and invocation parameters were used;
whether execution-context properties that affect semantics are represented;
whether the result and its metadata have verifiable provenance;
whether the result is fresh enough for the current request;
whether authorization and reuse policy permit delivery to the requester; and
whether a cache has preserved the original bindings rather than replacing them with local assertions.

The requirements-oriented discovery model in treats a result as a named object with metadata sufficient to evaluate freshness, provenance, and reuse eligibility. This document develops that result-object concept into a separate metadata model and validation workflow. The two documents are complementary: discovery can identify candidate result objects, while the model in this document describes the information needed to decide whether a candidate is acceptable. The model is intentionally independent of a particular ICN architecture or encoding. A realization could represent the metadata in a signed ICN manifest, a CBOR object protected with COSE, a signed JSON document, or another integrity-protected structure. It could retrieve the payload and metadata together or as separately named objects. This document specifies the semantic roles and required bindings, not their concrete serialization.

Conventions and Terminology

Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terms

Compute-Result Object:: A named output of a computing-service invocation together with, or cryptographically bound to, metadata that describes its identity, production context, provenance, freshness, and reuse policy.
Result Payload:: The application-visible output bytes or named output object produced by an invocation.
Result Descriptor:: The integrity-protected metadata structure that binds a result payload to the service, inputs, parameters, execution context, time information, and policy relevant to validation and reuse.
Invocation Descriptor:: A canonical or otherwise unambiguous description of the service request that produced a result, including service identity, input references, parameters, and requested output semantics.
Execution Evidence:: Evidence or an attestation result concerning the execution environment, software state, or execution event. Execution evidence is optional unless required by policy.
Result Publisher:: The entity that creates or signs the result descriptor and makes the result object available.
Result Producer:: The service instance or execution environment that generated the result payload.
Result Store:: A cache, repository, gateway, or service site that retains and serves a result object.
Reuse Policy:: Authenticated conditions under which a previously produced result may be delivered or treated as a substitute for a new invocation.
Acceptance Policy:: Requester-side rules used to determine whether a candidate result satisfies semantic, freshness, provenance, authorization, and evidence requirements.
Semantic Context:: The subset of invocation and execution properties that can change the meaning or acceptable interpretation of a result.

Problem Statement, Goals, and Non-Goals

Problem Statement A cache can verify that a payload matches a content digest without knowing whether the payload answers a particular computation request. Similarly, a requester can authenticate a publisher without knowing whether that publisher used the expected service version, inputs, parameters, or execution profile. Content integrity and publisher authentication are necessary but do not by themselves establish result suitability. Two requests that use the same human-readable service name may differ in model version, preprocessing method, geographic scope, confidence threshold, random seed policy, precision, or observation interval. Conversely, two differently located service instances may produce results that are semantically equivalent under a defined profile. A reusable result therefore needs explicit machine-verifiable bindings rather than an implicit association based on a locator, cache key, or display name. The problem is more difficult across administrative domains. The result producer, descriptor publisher, evidence verifier, cache, and requester may belong to different organizations. Connectivity to an authorization server, revocation service, or provenance repository may be unavailable at validation time. A model needs to preserve original evidence and make limitations visible without assuming a single global trust anchor.

Goals The model has the following goals:

identify a result independently of its current storage location;
bind the result to the service, input set, parameters, and semantic execution context that produced it;
allow a requester to evaluate freshness and validity without trusting a cache's local clock assertions alone;
preserve provenance and optional execution evidence through replication and cache delivery;
support policy-controlled reuse, including non-reusable and domain-restricted results;
support deterministic and non-deterministic computations without falsely claiming output equivalence;
permit compact or selectively disclosed representations for constrained links; and
remain usable over native ICN, ICN overlays, and conventional IP-based systems.

Non-Goals This document does not:

define a universal result-name syntax or allocate name components;
define a wire protocol, media type, CBOR schema, or ICN TLV;
specify how to execute, schedule, split, or steer a computing task;
define a cryptographic proof that arbitrary computation was performed correctly;
require a trusted execution environment or remote attestation;
define application-specific semantic equivalence rules;
guarantee that a predicted or cached result remains available; or
replace application authorization, accounting, or data-governance systems.

Compute-Result Object Model A compute-result object is modeled as a set of independently addressable but cryptographically bound components. A deployment may combine these components into one object or store them separately.

Components The model contains the following logical components:

Result payload: the produced output, represented inline or by an authenticated reference.
Result descriptor: the metadata object that binds all properties used for validation.
Invocation descriptor: the normalized request description or a digest and reference to it.
Supporting artifacts: service-interface descriptions, input manifests, execution profiles, evidence, or authorization artifacts.
Protection information: signatures, message authentication, certificate or key references, and any countersignatures required by policy.

The result descriptor MUST be integrity protected. If components are stored separately, the descriptor MUST bind each component that affects validation by a cryptographic digest, an immutable name with defined integrity semantics, or an equivalent authenticated reference.

Result Identity A result identity identifies a particular output object, not merely a service type. It MUST be bound to the result payload. It SHOULD also be bound to an invocation identity that covers the service, inputs, parameters, and semantic context. A conceptual invocation identity can be derived from the following tuple: Invocation-ID = H( Service-ID, Service-Version, Interface-Version, Input-Set-Descriptor, Parameter-Descriptor, Semantic-Execution-Profile, Requested-Output-Profile) The notation is illustrative and does not mandate a particular hash function or byte encoding. A concrete specification needs deterministic serialization or another method that prevents two implementations from hashing semantically identical fields differently. The result identity may be content-derived, publisher-assigned, or both. A content-derived identifier is useful for deduplication but does not by itself express provenance or authorization. A publisher-assigned identifier can express namespace ownership but must still bind to the payload digest.

Invocation Binding The result descriptor MUST identify the logical service and service version. When service behavior depends on an executable, model, configuration, or policy artifact, the descriptor SHOULD include an immutable artifact digest or a reference to a signed artifact manifest. The input set MUST be represented unambiguously. For one input object, a content digest or immutable name may be sufficient. For multiple or ordered inputs, the descriptor needs an input-set manifest that specifies membership, ordering where relevant, role labels, and transformations performed before execution. Invocation parameters that can affect output semantics MUST be bound to the descriptor. Parameters that do not affect semantics, such as a transport retry limit, need not be included. A profile may divide parameters into semantic, operational, and private categories.

Execution and Semantic Context A result may depend on more than code and inputs. Examples include numeric precision, accelerator type, model quantization, randomization policy, locale, time window, coordinate reference system, external data snapshot, and preprocessing pipeline. The descriptor MUST bind every execution-context property that the service profile declares semantically relevant. The model does not require disclosure of every hardware or runtime detail. A service profile can define an execution-profile identifier whose signed description lists the properties relevant to result interpretation. This permits compact descriptors and reduces unnecessary operational disclosure. For deterministic services, the descriptor may indicate that equivalent invocations are expected to produce byte-identical outputs. For non-deterministic services, the descriptor MUST NOT imply byte-level reproducibility. It may instead identify the randomization policy, seed handling, confidence representation, or tolerance profile used by the application.

Provenance and Execution Evidence The descriptor MUST identify the result publisher and SHOULD identify the result producer when those entities differ. A relying party needs to distinguish at least the following statements:

the publisher asserts that the descriptor and payload binding are authentic;
the producer asserts that it generated the payload for the bound invocation;
a verifier asserts an attestation result about the execution environment; and
a cache asserts only that it stores or transferred the protected object.

A cache signature MUST NOT be treated as a substitute for the producer or publisher signature. A cache may add a separate receipt, custody statement, or delivery timestamp without modifying the original descriptor. Execution evidence is optional unless required by the acceptance policy. When used, it should follow an established attestation architecture such as RATS . The result descriptor should normally bind to a verifier-produced attestation result rather than requiring every requester to appraise raw platform evidence. Entity Attestation Tokens are one possible representation . Attestation of a platform does not prove the semantic correctness of arbitrary application output. It can provide evidence about the identity or state of the execution environment. A result profile must state what conclusion a requester is allowed to draw from the referenced evidence.

Time, Freshness, and Validity The descriptor MUST include a result creation time or an equivalent authenticated event reference. When input data represents observations, the descriptor SHOULD distinguish the observation time from the computation time and publication time. The descriptor MUST provide at least one mechanism for evaluating reuse lifetime:

an absolute expiration time;
a maximum age measured from an authenticated creation time;
a revalidation requirement and revalidation reference;
a validity interval associated with an input snapshot; or
an application-defined freshness profile.

Freshness describes policy suitability, not cryptographic integrity. An expired result can remain authentic but no longer acceptable. A cache MUST NOT extend the producer's validity period by changing local metadata. If a trusted authority revalidates a result, the revalidation statement must be separately authenticated and bound to the original descriptor.

Reuse Policy The result descriptor MUST indicate whether the result is reusable. A reusable result may carry restrictions based on requester identity, administrative domain, purpose, geographic region, maximum number of deliveries, confidentiality class, or downstream redistribution. The descriptor should separate three questions:

May a store retain the object?
May a store deliver the object to a particular requester?
May the requester treat the object as a substitute for a new invocation?

A positive answer to one question does not imply a positive answer to the others. For example, a result may be cacheable for disaster recovery but not reusable for a later decision, or it may be reusable only within the producer's domain.

Conceptual Metadata Fields This section lists conceptual fields. A concrete specification may split fields across multiple objects, use profiles, or omit fields that are not applicable. Fields marked required are required by the abstract model, not by a particular wire format. Result Descriptor Field Groups

Field Group	Requirement	Purpose
descriptor version	Required	identifies metadata semantics and extension rules
result identifier	Required	names the produced result object
payload digest or immutable reference	Required	binds metadata to output bytes
service identifier and version	Required	identifies the logical computation
input-set binding	Required	identifies the input objects and roles
parameter binding	Required when semantic	prevents reuse across incompatible invocations
execution-profile binding	Conditional	captures semantic execution context
producer and publisher identity	Required	supports provenance and trust decisions
creation and observation time	Required or profiled	supports freshness evaluation
validity or revalidation rule	Required	limits reuse lifetime
reuse policy	Required	controls retention, delivery, and substitution
evidence or attestation reference	Optional	supports execution-environment appraisal
confidentiality and disclosure class	Optional	supports selective metadata exposure
extensions	Optional	supports service-specific semantics

Every field that affects acceptance MUST be covered by the descriptor's integrity protection. Unknown critical extensions MUST cause validation failure. Unknown non-critical extensions may be ignored, but an implementation should make that decision observable for diagnostics.

Production and Publication Workflow A typical production workflow is:

The requester or scheduler constructs an invocation descriptor.
The service instance validates authorization and resolves input objects.
The result producer executes the service and produces the result payload.
The producer records semantic execution context and any evidence required by policy.
The publisher creates a result descriptor that binds the payload and invocation.
The publisher integrity protects the descriptor and publishes the result name.
A result store may cache or replicate the protected components without changing producer assertions.

The entity that signs the descriptor needs authority for the result namespace or another explicit delegation from the service operator. A publisher MUST NOT claim execution properties it cannot substantiate. When the publisher and producer are separate, the descriptor should contain a producer statement or another authenticated binding between them. The publication mechanism may announce the result through a discovery service, an ICN routing advertisement, a synchronization protocol, a catalog, or an application-specific index. Publication does not imply that all metadata is disclosed to all consumers. A public catalog may expose a minimal descriptor while authorized consumers retrieve protected details separately.

Retrieval, Validation, and Reuse Workflow A requester that receives a candidate result should perform the following conceptual checks. The order may be optimized, but an implementation should reject malformed or unauthorized objects before performing expensive verification.

Parse and profile check: determine the descriptor version and reject unsupported critical extensions.
Integrity check: verify the descriptor protection and authorization of the publisher for the result namespace.
Payload binding: verify that the retrieved payload matches the authenticated digest or immutable reference.
Invocation match: compare service identity, version, input-set binding, parameters, and output profile with the current request.
Semantic-context match: evaluate execution-profile fields required by the service profile.
Freshness check: evaluate creation, observation, expiration, and revalidation information.
Provenance and evidence check: validate producer statements and any evidence required by acceptance policy.
Authorization and reuse check: determine whether the cache may deliver the result and whether the requester may use it as a substitute.
Application acceptance: apply application-specific confidence, tolerance, or equivalence rules.

A failure in any required check MUST prevent substitution of the candidate result for a new invocation. The requester may try another result, invoke an eligible service instance, defer the request, or fail according to application policy. Validation outcomes should distinguish at least: valid and acceptable; authentic but stale; authentic but semantically incompatible; authentic but unauthorized; evidence unavailable; and invalid. Treating all failures as a cache miss can hide attacks or operational problems.

Caching, Replication, and Aggregation

Cache Behavior A cache may store result objects according to storage policy and authenticated reuse restrictions. It MUST preserve the original result descriptor and payload binding. It MUST NOT remove producer provenance, weaken critical policy, replace expiration information, or silently convert an unverifiable reference into a local assertion. A cache may add local metadata such as receipt time, eviction priority, observed retrieval count, or custody information. Such metadata must be clearly separated from producer-authenticated metadata. Consumers must be able to determine which entity asserted each field.

Deduplication and Multiple Descriptors The same payload bytes may be associated with more than one valid descriptor. For example, two authorized producers may independently generate an identical deterministic result, or one payload may be republished under different reuse policies. Payload deduplication MUST NOT collapse distinct provenance or policy statements. Conversely, the same invocation identity may produce multiple non-identical outputs for a non-deterministic service. A result store may index these outputs under a common invocation identity while preserving distinct result identifiers and provenance.

Collections and Derived Results A manifest may describe a collection of result objects. A derived result that aggregates, filters, compresses, translates, or summarizes earlier results is itself a new compute-result object. Its descriptor needs to identify the derivation service and bind the source result set as inputs. It must not inherit source provenance as though the original producers generated the derived payload.

Multi-Domain and Disruption-Tolerant Operation The model does not assume continuous access to the producer, publisher, verifier, or authorization infrastructure. A gateway may retrieve a result during a short contact and later serve it within a disconnected domain. The descriptor therefore needs self-contained or locally resolvable information for the checks required during disconnection. Deployments should use bounded validity and pre-position the trust anchors, profiles, revocation snapshots, and authorization artifacts needed for expected offline operation. If current revocation state or revalidation information is unavailable, the validator MUST expose that limitation to the acceptance policy. It must not silently treat old status information as current. Bundle Protocol mechanisms may transport result objects across disrupted paths , and BPSec may protect Bundle Protocol blocks . Those mechanisms protect delivery units and do not replace the end-to-end result descriptor. The object-level binding remains useful after a result is extracted from a bundle, copied to a cache, or transported by another protocol. Different domains may use different local names or transports. A gateway may map a stable result identity to a URI, an ICN name, or another locator. Translation MUST preserve the authenticated result identity and must report when a target system cannot represent a critical property.

Relationship with Existing Work

Information-Centric Networking CCNx defines named Interest and Content Object semantics and a TLV message format . ICN deployment considerations include native, overlay, and gateway-assisted approaches . The model in this document can be carried by those mechanisms but does not change them. ICN manifests and named metadata are natural candidates for representing result descriptors and supporting artifacts. An ICN Name Resolution Service can also map stable object names to other forwarding information . Name resolution, however, does not by itself determine whether a computation result is semantically acceptable.

Compute-Service Discovery defines requirements for discovering logical computing services, service instances, and reusable result objects in heterogeneous intermittently connected environments. This document focuses on the internal semantic bindings and validation workflow of the result object after discovery.

Computing-Aware Traffic Steering CATS concerns selection and steering among service contact instances using network and computing information . A CATS system may select where to execute a request. The model in this document concerns how a produced output can later be validated and reused. It neither defines CATS metrics nor modifies CATS forwarding.

Remote Attestation RATS defines roles and conceptual messages for evidence appraisal and attestation results . A result descriptor may reference an attestation result when acceptance depends on execution-environment state. This document does not define an evidence format or appraisal policy and does not equate platform integrity with computation correctness.

CBOR and COSE CBOR provides a compact data representation , and COSE provides signatures, MACs, and encryption for CBOR structures . They are plausible building blocks for a constrained result-descriptor encoding. This document does not select an encoding or request an IANA registration.

Security Considerations

Descriptor Forgery and Namespace Abuse An attacker may publish a descriptor for a service namespace it does not control, replace a payload reference, or claim a stronger execution profile. Implementations need publisher authentication, namespace authorization, integrity protection, and explicit handling of delegated publishers. Authentication of an identity alone does not authorize that identity to publish every service or result name.

Payload and Invocation Substitution A malicious cache may pair a valid descriptor with a different payload, or pair a valid payload with metadata from another invocation. Cryptographic binding of the payload, input set, parameters, and semantic context is required. Human-readable names and transport security are not sufficient substitutes.

Replay and Stale Results An authentic old result may be unsafe for a current decision. Attackers may replay descriptors after model replacement, input update, policy change, or contact expiration. Validators need authenticated time or sequence information, bounded validity, and application freshness policy. Local cache receipt time must not be confused with producer creation time.

Misinterpretation of Execution Evidence Attestation evidence can be over-interpreted. Evidence that a known binary ran in a trusted environment does not necessarily prove correct inputs, correct external dependencies, absence of application bugs, or semantic correctness of the output. Profiles must state the claims established by evidence and acceptance policies must not infer stronger properties.

Policy Downgrade and Gateway Translation A gateway may be unable to represent a critical policy or provenance field in a target system. Silently discarding such information can turn a restricted result into an apparently unrestricted one. Translation must fail safely or carry an explicit authenticated indication of the limitation.

Denial of Service Attackers can send large descriptors, long provenance chains, expensive evidence, or references that trigger recursive retrieval. Implementations should bound descriptor size, nesting depth, reference count, signature operations, evidence appraisal cost, and resolution recursion. Cheap syntactic and authorization checks should precede expensive cryptographic or remote operations.

Digest Agility and Canonicalization A concrete encoding needs algorithm agility and deterministic interpretation of digested structures. Ambiguous serialization can allow two parties to calculate different invocation identities. Profiles should define canonicalization, algorithm identifiers, deprecation handling, and collision-resistance requirements.

Privacy Considerations Result descriptors can reveal requester interests, sensor locations, observation times, model versions, operational capabilities, service inventories, and relationships among administrative domains. Input-set digests may also enable dictionary attacks when the input space is small or predictable. Deployments should minimize metadata, avoid publishing unnecessary dynamic resource details, and use confidentiality and access control where appropriate. A public descriptor may contain opaque authenticated references to protected details. Selective disclosure mechanisms may be used, but every disclosed subset needs an unambiguous relationship to the originally protected descriptor. Stable result identifiers can enable cross-domain correlation. Applications should avoid embedding personal or operationally sensitive information directly in names. Pairwise or scoped identifiers may be appropriate when global correlation is not required. Cache telemetry and reuse receipts can reveal who requested a result and when. Such records should be retained only as required by policy and should not be included in the producer descriptor unless they are part of the service semantics.

IANA Considerations This document has no IANA actions.

Acknowledgements The authors welcome discussion on terminology, service-specific result profiles, compact encodings, interaction with ICN manifests, and experimental validation in constrained edge environments.