Information-Centric Networking Research Group S. Liu Internet-Draft Nanjing University Intended status: Informational 15 July 2026 Expires: 16 January 2027 A Metadata Model for Verifiable and Reusable Compute-Result Objects in Information-Centric Edge Networks draft-liu-icnrg-verifiable-compute-results-00 Abstract 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. Status of This Memo 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 Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Liu Expires 16 January 2027 [Page 1] Internet-Draft Verifiable Compute Results July 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement, Goals, and Non-Goals . . . . . . . . . . . 5 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5 3.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Compute-Result Object Model . . . . . . . . . . . . . . . . . 7 4.1. Components . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Result Identity . . . . . . . . . . . . . . . . . . . . . 8 4.3. Invocation Binding . . . . . . . . . . . . . . . . . . . 9 4.4. Execution and Semantic Context . . . . . . . . . . . . . 9 4.5. Provenance and Execution Evidence . . . . . . . . . . . . 9 4.6. Time, Freshness, and Validity . . . . . . . . . . . . . . 10 4.7. Reuse Policy . . . . . . . . . . . . . . . . . . . . . . 11 5. Conceptual Metadata Fields . . . . . . . . . . . . . . . . . 11 6. Production and Publication Workflow . . . . . . . . . . . . . 13 7. Retrieval, Validation, and Reuse Workflow . . . . . . . . . . 13 8. Caching, Replication, and Aggregation . . . . . . . . . . . . 14 8.1. Cache Behavior . . . . . . . . . . . . . . . . . . . . . 14 8.2. Deduplication and Multiple Descriptors . . . . . . . . . 15 8.3. Collections and Derived Results . . . . . . . . . . . . . 15 9. Multi-Domain and Disruption-Tolerant Operation . . . . . . . 15 10. Relationship with Existing Work . . . . . . . . . . . . . . . 16 10.1. Information-Centric Networking . . . . . . . . . . . . . 16 10.2. Compute-Service Discovery . . . . . . . . . . . . . . . 16 10.3. Computing-Aware Traffic Steering . . . . . . . . . . . . 16 10.4. Remote Attestation . . . . . . . . . . . . . . . . . . . 17 10.5. CBOR and COSE . . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11.1. Descriptor Forgery and Namespace Abuse . . . . . . . . . 17 11.2. Payload and Invocation Substitution . . . . . . . . . . 17 11.3. Replay and Stale Results . . . . . . . . . . . . . . . . 17 11.4. Misinterpretation of Execution Evidence . . . . . . . . 18 11.5. Policy Downgrade and Gateway Translation . . . . . . . . 18 11.6. Denial of Service . . . . . . . . . . . . . . . . . . . 18 Liu Expires 16 January 2027 [Page 2] Internet-Draft Verifiable Compute Results July 2026 11.7. Digest Agility and Canonicalization . . . . . . . . . . 18 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 15. Normative References . . . . . . . . . . . . . . . . . . . . 19 16. Informative References . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 1. 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 [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: * 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. Liu Expires 16 January 2027 [Page 3] Internet-Draft Verifiable Compute Results July 2026 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. 2. Conventions and Terminology 2.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.2. 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. Liu Expires 16 January 2027 [Page 4] Internet-Draft Verifiable Compute Results July 2026 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. 3. Problem Statement, Goals, and Non-Goals 3.1. 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. Liu Expires 16 January 2027 [Page 5] Internet-Draft Verifiable Compute Results July 2026 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. 3.2. 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. 3.3. 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; Liu Expires 16 January 2027 [Page 6] Internet-Draft Verifiable Compute Results July 2026 * 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. 4. 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. +--------------------------------------------------------------+ | 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 | +-----------------------+ +------------------------+ Figure 1: Conceptual Compute-Result Object 4.1. 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. Liu Expires 16 January 2027 [Page 7] Internet-Draft Verifiable Compute Results July 2026 * *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. 4.2. 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. Liu Expires 16 January 2027 [Page 8] Internet-Draft Verifiable Compute Results July 2026 4.3. 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. 4.4. 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. 4.5. 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: Liu Expires 16 January 2027 [Page 9] Internet-Draft Verifiable Compute Results July 2026 * 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 [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. 4.6. 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 Liu Expires 16 January 2027 [Page 10] Internet-Draft Verifiable Compute Results July 2026 * 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. 4.7. 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: 1. May a store retain the object? 2. May a store deliver the object to a particular requester? 3. 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. 5. 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. +=====================+=============+===============================+ | Field Group | Requirement | Purpose | +=====================+=============+===============================+ | descriptor | Required | identifies metadata semantics | | version | | and extension rules | +---------------------+-------------+-------------------------------+ | result identifier | Required | names the produced result | | | | object | +---------------------+-------------+-------------------------------+ | payload digest or | Required | binds metadata to output | | immutable | | bytes | Liu Expires 16 January 2027 [Page 11] Internet-Draft Verifiable Compute Results July 2026 | reference | | | +---------------------+-------------+-------------------------------+ | service | Required | identifies the logical | | identifier and | | computation | | version | | | +---------------------+-------------+-------------------------------+ | input-set binding | Required | identifies the input objects | | | | and roles | +---------------------+-------------+-------------------------------+ | parameter binding | Required | prevents reuse across | | | when | incompatible invocations | | | semantic | | +---------------------+-------------+-------------------------------+ | execution-profile | Conditional | captures semantic execution | | binding | | context | +---------------------+-------------+-------------------------------+ | producer and | Required | supports provenance and trust | | publisher | | decisions | | identity | | | +---------------------+-------------+-------------------------------+ | creation and | Required or | supports freshness evaluation | | observation time | profiled | | +---------------------+-------------+-------------------------------+ | validity or | Required | limits reuse lifetime | | revalidation rule | | | +---------------------+-------------+-------------------------------+ | reuse policy | Required | controls retention, delivery, | | | | and substitution | +---------------------+-------------+-------------------------------+ | evidence or | Optional | supports execution- | | attestation | | environment appraisal | | reference | | | +---------------------+-------------+-------------------------------+ | confidentiality | Optional | supports selective metadata | | and disclosure | | exposure | | class | | | +---------------------+-------------+-------------------------------+ | extensions | Optional | supports service-specific | | | | semantics | +---------------------+-------------+-------------------------------+ Table 1: Result Descriptor Field Groups 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. Liu Expires 16 January 2027 [Page 12] Internet-Draft Verifiable Compute Results July 2026 6. Production and Publication Workflow A typical production workflow is: 1. The requester or scheduler constructs an invocation descriptor. 2. The service instance validates authorization and resolves input objects. 3. The result producer executes the service and produces the result payload. 4. The producer records semantic execution context and any evidence required by policy. 5. The publisher creates a result descriptor that binds the payload and invocation. 6. The publisher integrity protects the descriptor and publishes the result name. 7. 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. 7. 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. 1. *Parse and profile check:* determine the descriptor version and reject unsupported critical extensions. Liu Expires 16 January 2027 [Page 13] Internet-Draft Verifiable Compute Results July 2026 2. *Integrity check:* verify the descriptor protection and authorization of the publisher for the result namespace. 3. *Payload binding:* verify that the retrieved payload matches the authenticated digest or immutable reference. 4. *Invocation match:* compare service identity, version, input-set binding, parameters, and output profile with the current request. 5. *Semantic-context match:* evaluate execution-profile fields required by the service profile. 6. *Freshness check:* evaluate creation, observation, expiration, and revalidation information. 7. *Provenance and evidence check:* validate producer statements and any evidence required by acceptance policy. 8. *Authorization and reuse check:* determine whether the cache may deliver the result and whether the requester may use it as a substitute. 9. *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. 8. Caching, Replication, and Aggregation 8.1. 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. Liu Expires 16 January 2027 [Page 14] Internet-Draft Verifiable Compute Results July 2026 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. 8.2. 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. 8.3. 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. 9. 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. Liu Expires 16 January 2027 [Page 15] Internet-Draft Verifiable Compute Results July 2026 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. 10. Relationship with Existing Work 10.1. Information-Centric Networking 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. 10.2. Compute-Service Discovery [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. 10.3. Computing-Aware Traffic Steering 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. Liu Expires 16 January 2027 [Page 16] Internet-Draft Verifiable Compute Results July 2026 10.4. Remote Attestation 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. 10.5. CBOR and COSE 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. 11. Security Considerations 11.1. 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. 11.2. 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. 11.3. 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. Liu Expires 16 January 2027 [Page 17] Internet-Draft Verifiable Compute Results July 2026 11.4. 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. 11.5. 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. 11.6. 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. 11.7. 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. 12. 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. Liu Expires 16 January 2027 [Page 18] Internet-Draft Verifiable Compute Results July 2026 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. 13. IANA Considerations This document has no IANA actions. 14. Acknowledgements The authors welcome discussion on terminology, service-specific result profiles, compact encodings, interaction with ICN manifests, and experimental validation in constrained edge environments. 15. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 16. Informative References [RFC7927] Kutscher, D., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, . [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, . Liu Expires 16 January 2027 [Page 19] Internet-Draft Verifiable Compute Results July 2026 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, . [RFC8763] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran, "Deployment Considerations for Information-Centric Networking (ICN)", RFC 8763, DOI 10.17487/RFC8763, April 2020, . [RFC8793] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C. Tschudin, "Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology", RFC 8793, DOI 10.17487/RFC8793, June 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9171] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, . [RFC9172] Birrane, E. and K. McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January 2022, . [RFC9236] Hong, J., You, T., and V. Kafle, "Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service", RFC 9236, DOI 10.17487/RFC9236, May 2022, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . Liu Expires 16 January 2027 [Page 20] Internet-Draft Verifiable Compute Results July 2026 [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . [I-D.liu-icnrg-cross-domain-compute-discovery] Liu, S., "Requirements for Name-Based Compute-Service Discovery in Heterogeneous Space-Terrestrial-Maritime Edge Networks", Work in Progress, Internet-Draft, draft-liu- icnrg-cross-domain-compute-discovery-00, 26 June 2026, . [I-D.ietf-cats-framework] Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J. E. Drake, "A Framework for Computing-Aware Traffic Steering (CATS)", Work in Progress, Internet-Draft, draft-ietf- cats-framework-24, April 2026, . Author's Address Shuai Liu Nanjing University School of Electronic Science and Engineering Nanjing 210023 China Email: shuai_liu@smail.nju.edu.cn Liu Expires 16 January 2027 [Page 21]