| Internet-Draft | Verifiable Compute Results | July 2026 |
| Liu | Expires 16 January 2027 | [Page] |
Distributed edge systems can execute the same logical computing service at multiple sites and can retain previously generated outputs in gateways, caches, or result stores. Reusing such an output can reduce communication and computation, but a payload alone does not indicate which service, inputs, parameters, execution environment, or validity conditions produced it. This document defines a conceptual metadata model for named compute-result objects. The model binds a result payload to service identity, input identity, invocation context, execution provenance, freshness information, and reuse policy. It also describes validation and cache-reuse workflows for intermittently connected and multi-domain edge environments. This document does not define a wire encoding, a naming syntax, a remote-attestation profile, or a traffic-steering protocol.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 16 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC7927] [RFC8569] [RFC8793].¶
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:¶
The requirements-oriented discovery model in [I-D.liu-icnrg-cross-domain-compute-discovery] 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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.¶
The model has the following goals:¶
This document does not:¶
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.¶
+--------------------------------------------------------------+
| Result Descriptor |
| result identity | payload binding | time and validity |
| invocation binding | provenance | evidence references |
| reuse policy | extension and disclosure information |
+--------------------------+-----------------------------------+
|
cryptographic binding / authenticated reference
|
+-------------------+--------------------+
| |
+------+----------------+ +---------+--------------+
| Result Payload | | Supporting Artifacts |
| bytes or named object | | input manifests, |
| | | interface descriptions,|
| | | attestation results |
+-----------------------+ +------------------------+
The model contains the following logical components:¶
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.¶
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.¶
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.¶
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.¶
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:¶
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 [RFC9334]. 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 [RFC9711].¶
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.¶
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:¶
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.¶
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:¶
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.¶
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.¶
| 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.¶
A typical production workflow is:¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 [RFC9171], and BPSec may protect Bundle Protocol blocks [RFC9172]. 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.¶
CCNx defines named Interest and Content Object semantics [RFC8569] and a TLV message format [RFC8609]. ICN deployment considerations include native, overlay, and gateway-assisted approaches [RFC8763]. 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 [RFC9236]. Name resolution, however, does not by itself determine whether a computation result is semantically acceptable.¶
[I-D.liu-icnrg-cross-domain-compute-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.¶
CATS concerns selection and steering among service contact instances using network and computing information [I-D.ietf-cats-framework]. 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.¶
RATS defines roles and conceptual messages for evidence appraisal and attestation results [RFC9334]. 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 provides a compact data representation [RFC8949], and COSE provides signatures, MACs, and encryption for CBOR structures [RFC9052]. They are plausible building blocks for a constrained result-descriptor encoding. This document does not select an encoding or request an IANA registration.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶
The authors welcome discussion on terminology, service-specific result profiles, compact encodings, interaction with ICN manifests, and experimental validation in constrained edge environments.¶