



SPICE                                                        R. Krishnan
Internet-Draft                                       JPMorgan Chase & Co
Intended status: Informational                                 A. Prasad
Expires: 19 September 2026                                        Oracle
                                                                D. Lopez
                                                              Telefonica
                                                            S. Addepalli
                                                                  Aryaka
                                                           18 March 2026


Cryptographically Verifiable Inference Chain for AI Agent Computational
                               Provenance
                   draft-mw-spice-inference-chain-00

Abstract

   This document defines the inference_root claim as a companion to the
   actor_chain claim ({{!I-D.draft-mw-spice-actor-chain}}) and the
   intent_root claim ({{!I-D.draft-mw-spice-intent-chain}}).  While the
   actor chain addresses delegation provenance (WHO) and the intent
   chain addresses content provenance (WHAT), the inference chain
   addresses computational provenance (HOW) — providing cryptographic
   proof that a claimed AI model actually performed the inference that
   produced a given output.

   The inference chain leverages two complementary mechanisms: Zero-
   Knowledge Machine Learning (ZKML) proofs for mathematical certainty,
   and Trusted Execution Environment (TEE) attestation quotes for
   production-scale AI workloads.  The full inference chain is stored as
   ordered logs, with only the Merkle root included in the OAuth token
   for efficiency.

   Together, the three chains — actor, intent, and inference — form a
   complete "Truth Stack" for autonomous AI agent governance.

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/.






Krishnan, et al.        Expires 19 September 2026               [Page 1]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   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 19 September 2026.

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  The Problem: Computational Spoofing . . . . . . . . . . .   3
     1.2.  Relationship to Actor Chain and Intent Chain  . . . . . .   4
     1.3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Inference Proof Types . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  ZKML Proofs . . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  TEE Attestation Quotes  . . . . . . . . . . . . . . . . .   9
     3.4.  Hybrid Proofs . . . . . . . . . . . . . . . . . . . . . .  10
   4.  Entry Structure . . . . . . . . . . . . . . . . . . . . . . .  11
     4.1.  Common Fields . . . . . . . . . . . . . . . . . . . . . .  11
     4.2.  Binding to Intent Chain . . . . . . . . . . . . . . . . .  12
   5.  Storage Architecture  . . . . . . . . . . . . . . . . . . . .  13
     5.1.  Inference Registry  . . . . . . . . . . . . . . . . . . .  13
     5.2.  Merkle Tree Construction  . . . . . . . . . . . . . . . .  14
     5.3.  Merkle Root in Token  . . . . . . . . . . . . . . . . . .  14
   6.  Token Structure . . . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  Combined Token Format (Full Truth Stack)  . . . . . . . .  15
     6.2.  Claim Definitions . . . . . . . . . . . . . . . . . . . .  17
   7.  Verification Procedures . . . . . . . . . . . . . . . . . . .  17
     7.1.  Three-Point Verification  . . . . . . . . . . . . . . . .  17
     7.2.  ZKML Proof Verification . . . . . . . . . . . . . . . . .  17
     7.3.  TEE Quote Verification  . . . . . . . . . . . . . . . . .  18
     7.4.  Tiered Verification . . . . . . . . . . . . . . . . . . .  18



Krishnan, et al.        Expires 19 September 2026               [Page 2]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   8.  Policy Enforcement  . . . . . . . . . . . . . . . . . . . . .  18
     8.1.  Policy Examples . . . . . . . . . . . . . . . . . . . . .  18
       8.1.1.  Require Inference Proof for All Agent Outputs . . . .  18
       8.1.2.  Require TEE for Financial Operations  . . . . . . . .  19
       8.1.3.  Block Specific Model Versions . . . . . . . . . . . .  19
     8.2.  Integration with Policy Engines . . . . . . . . . . . . .  19
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
     9.1.  STRIDE Analysis for Inference Chain . . . . . . . . . . .  20
     9.2.  Trust Assumptions . . . . . . . . . . . . . . . . . . . .  20
       9.2.1.  ZKML Proofs . . . . . . . . . . . . . . . . . . . . .  20
       9.2.2.  TEE Attestation . . . . . . . . . . . . . . . . . . .  20
     9.3.  Verification Key Management . . . . . . . . . . . . . . .  21
     9.4.  Proof Freshness . . . . . . . . . . . . . . . . . . . . .  21
     9.5.  Credential Isolation  . . . . . . . . . . . . . . . . . .  21
     9.6.  ZKML Proof Size Considerations  . . . . . . . . . . . . .  21
     9.7.  Relationship to Proof of Residency  . . . . . . . . . . .  22
   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  22
     10.1.  Model Weight Privacy . . . . . . . . . . . . . . . . . .  22
     10.2.  Input Privacy  . . . . . . . . . . . . . . . . . . . . .  22
     10.3.  Selective Disclosure . . . . . . . . . . . . . . . . . .  22
   11. Implementation Guidance . . . . . . . . . . . . . . . . . . .  23
     11.1.  Current ZKML Landscape . . . . . . . . . . . . . . . . .  23
     11.2.  TEE Integration  . . . . . . . . . . . . . . . . . . . .  23
     11.3.  Scalability Considerations . . . . . . . . . . . . . . .  23
     11.4.  Multi-AS Deployments . . . . . . . . . . . . . . . . . .  23
     11.5.  Registry Availability  . . . . . . . . . . . . . . . . .  24
       11.5.1.  Proof Size and Storage . . . . . . . . . . . . . . .  24
     11.6.  Performance Guidance: TEE vs ZKML  . . . . . . . . . . .  25
   12. Design Rationale: Merkle Root in Token  . . . . . . . . . . .  26
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
     13.1.  JWT Claim Registration . . . . . . . . . . . . . . . . .  26
     13.2.  CWT Claim Registration . . . . . . . . . . . . . . . . .  27
   Appendix A.  Full Token Example (Three-Chain Governance)  . . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

1.  Introduction

1.1.  The Problem: Computational Spoofing

   The Actor Chain ({{!I-D.draft-mw-spice-actor-chain}}) proves WHO
   delegated to whom.  The Intent Chain ({{!I-D.draft-mw-spice-intent-
   chain}}) proves WHAT was produced and how it was transformed.
   Neither addresses a critical remaining gap: was the *claimed
   computational process* actually used to produce the output?

   In AI agent workflows, an agent may claim to use a high-capability,
   safety-aligned model (e.g., a frontier model with RLHF alignment)
   while actually running a cheaper, unaligned model.  This "Model



Krishnan, et al.        Expires 19 September 2026               [Page 3]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   Masquerading" attack is undetectable by content hashes alone — the
   output hash in the intent chain proves the output exists, but not
   that the claimed model produced it.

   *Concrete threats:*

   *  *Model Substitution*: A cost-optimized deployment swaps a
      regulated, audited model for a cheaper alternative with weaker
      safety properties.
   *  *Weight Tampering*: Model weights are modified (e.g., fine-tuned
      to remove safety guardrails) while the model identifier remains
      unchanged.
   *  *Environment Spoofing*: Inference runs in an unprotected
      environment where model inputs/outputs can be intercepted, while
      the agent claims TEE execution.
   *  *Replay of Stale Proofs*: A valid inference proof from a previous
      execution is reattached to a new, unverified output.

1.2.  Relationship to Actor Chain and Intent Chain

   This specification completes the three-axis "Truth Stack":

    +=================+=============+==============+==================+
    | Specification   | Axis        | Question     | STRIDE Coverage  |
    |                 |             | Answered     |                  |
    +=================+=============+==============+==================+
    | *Actor Chain*   | Identity    | WHO          | Spoofing,        |
    | ({{!I-D.draft-  |             | delegated to | Repudiation,     |
    | mw-spice-actor- |             | whom?        | Elevation of     |
    | chain}})        |             |              | Privilege        |
    +-----------------+-------------+--------------+------------------+
    | *Intent Chain*  | Content     | WHAT was     | Repudiation,     |
    | ({{!I-D.draft-  |             | produced and | Tampering        |
    | mw-spice-       |             | transformed? |                  |
    | intent-chain}}) |             |              |                  |
    +-----------------+-------------+--------------+------------------+
    | *Inference      | Computation | HOW was the  | Spoofing         |
    | Chain* (this    |             | output       | (computational), |
    | document)       |             | computed?    | Tampering        |
    |                 |             |              | (model)          |
    +-----------------+-------------+--------------+------------------+

                                  Table 1








Krishnan, et al.        Expires 19 September 2026               [Page 4]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


    +=============+=======+============+==========+==================+
    | Chain       | Plane | Token      | Full     | Primary Consumer |
    |             |       | Content    | Chain    |                  |
    +=============+=======+============+==========+==================+
    | *Actor*     | Data  | Full chain | In token | Every Relying    |
    |             | Plane | inline     |          | Party (real-time |
    |             |       |            |          | authorization)   |
    +-------------+-------+------------+----------+------------------+
    | *Intent*    | Audit | Merkle     | External | Audit systems,   |
    |             | Plane | root only  | registry | forensic         |
    |             |       |            |          | investigators    |
    +-------------+-------+------------+----------+------------------+
    | *Inference* | Audit | Merkle     | External | Auditors,        |
    |             | Plane | root only  | registry | compliance       |
    |             |       |            |          | systems          |
    +-------------+-------+------------+----------+------------------+

                                 Table 2

   The three chains are independent and composable:

   *  *Actor + Intent*: Identity and content governance without
      computational proof (sufficient for rule-based systems).
   *  *Actor + Inference*: Identity and computational governance without
      content transformation tracking (sufficient for single-agent
      systems).
   *  *All Three*: Full governance for multi-agent pipelines with
      content transformation and computational integrity.

1.3.  Design Goals

   1.  *Computational Provenance*: Cryptographic proof that a specific
       model produced a specific output.
   2.  *Mechanism Agnostic*: Support both ZKML proofs and TEE
       attestation quotes as proof types.
   3.  *Binding to Intent Chain*: Inference proofs are bound to specific
       intent chain entries via content hashes.
   4.  *Efficiency*: Only Merkle root in token; full proofs in registry.
   5.  *Incremental Adoption*: Deployable alongside existing actor and
       intent chains without requiring changes to those specifications.

2.  Terminology

   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.



Krishnan, et al.        Expires 19 September 2026               [Page 5]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   Inference Chain:  An ordered sequence of Inference Chain Entries
      providing cryptographic proof of the computational processes that
      produced AI agent outputs within a session.
   Inference Chain Entry:  A record binding a specific AI agent output
      to a cryptographic proof of the computational process that
      produced it.
   Inference Root:  The Merkle root hash of the complete inference
      chain, included in the OAuth token via the inference_root claim.
   Inference Registry:  An append-only ordered log storing the full
      inference chain entries, partitioned by session.
   ZKML Proof:  A Zero-Knowledge proof (SNARK or STARK) demonstrating
      that a specific neural network with specific weights produced a
      specific output from a specific input, without revealing the model
      weights or input data.
   TEE Quote:  A hardware-signed attestation from a Trusted Execution
      Environment (e.g., Intel TDX, AMD SEV-SNP, NVIDIA H100
      Confidential Computing) proving that specific code ran within a
      verified enclave with specific measurements.  TEE attestation
      follows the RATS architecture {{!RFC9334}}.
   Model Fingerprint:  A cryptographic hash of the model weights,
      architecture definition, and inference configuration, uniquely
      identifying the computational process.

3.  Inference Proof Types

3.1.  Overview

   The inference chain supports two primary proof types, each with
   different trust assumptions and performance characteristics:






















Krishnan, et al.        Expires 19 September 2026               [Page 6]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   +================+==========================+=======================+
   | Property       | ZKML Proof               | TEE Quote             |
   +================+==========================+=======================+
   | *Trust Basis*  | Mathematics              | Hardware              |
   |                | (cryptographic hardness) | manufacturer root     |
   |                |                          | of trust              |
   +----------------+--------------------------+-----------------------+
   | *Verification* | Deterministic, no        | Requires              |
   |                | external dependency      | manufacturer PKI      |
   |                |                          | (Intel/AMD/NVIDIA)    |
   +----------------+--------------------------+-----------------------+
   | *Model Scale*  | Currently limited (~100M | Production-scale      |
   |                | parameters)              | LLMs (100B+           |
   |                |                          | parameters)           |
   +----------------+--------------------------+-----------------------+
   | *Proof         | Minutes to hours per     | Real-time             |
   | Generation*    | inference                | (millisecond          |
   |                |                          | overhead)             |
   +----------------+--------------------------+-----------------------+
   | *Proof Size*   | ~200 bytes (Groth16),    | ~2KB (Intel TDX),     |
   |                | ~50KB (STARKs)           | ~4KB (NVIDIA)         |
   +----------------+--------------------------+-----------------------+
   | *Privacy*      | Zero-knowledge: hides    | Enclave-bound:        |
   |                | model weights            | hardware isolation    |
   +----------------+--------------------------+-----------------------+

                                  Table 3

   Deployments SHOULD select the proof type based on their performance
   requirements and trust model.

3.2.  ZKML Proofs

   ZKML proofs provide mathematical certainty that a specific model
   produced a specific output.  They are constructed by encoding the
   neural network's forward pass as an arithmetic circuit and generating
   a zero-knowledge proof of correct execution.

   *Proof Statement*: "There exist model weights W such that hash(W) =
   model_fingerprint AND forward_pass(W, input) = output."

   *Properties*:

   *  The verifier learns nothing about the model weights (zero-
      knowledge property).
   *  The proof cannot be forged without performing the actual
      computation (soundness).




Krishnan, et al.        Expires 19 September 2026               [Page 7]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   *  Proof verification is fast (milliseconds) regardless of model
      size.
   *  Proof generation is computationally expensive (orders of magnitude
      slower than inference).

   *Applicable Proof Systems*:

   +=========+============+===================+========================+
   | System  | Proof Size | Verification Time | Trusted Setup          |
   +=========+============+===================+========================+
   | Groth16 | ~200 bytes | _5ms              | Required               |
   |         |            |                   | (per-circuit)          |
   +---------+------------+-------------------+------------------------+
   | PLONK   | ~400 bytes | _10ms             | Universal              |
   |         |            |                   | (one-time)             |
   +---------+------------+-------------------+------------------------+
   | STARKs  | _50KB      | _50ms             | None                   |
   |         |            |                   | (transparent)          |
   +---------+------------+-------------------+------------------------+
   | Halo2   | _5KB       | _15ms             | None                   |
   |         |            |                   | (recursive)            |
   +---------+------------+-------------------+------------------------+

                                  Table 4

   *Entry Structure*:

   {
     "type": "zkml_proof",
     "sub": "spiffe://example.com/agent/analyst",
     "proof_system": "groth16",
     "model_fingerprint": "sha256:weights_hash...",
     "model_id": "analyst-model-v3.2",
     "input_hash": "sha256:input_data...",
     "output_hash": "sha256:output_data...",
     "intent_entry_ref": 3,
     "proof": "base64:proof_bytes...",
     "verification_key_hash": "sha256:vk_hash...",
     "verification_key_registry":
       "https://vk-registry.example.com/keys/analyst-v3.2",
     "iat": 1700000030,
     "inference_digest": "sha256:...",
     "inference_sig": "eyJhbGci..."
   }







Krishnan, et al.        Expires 19 September 2026               [Page 8]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


3.3.  TEE Attestation Quotes

   TEE attestation quotes provide hardware-rooted proof that inference
   was performed within a verified enclave.  The hardware generates a
   signed "quote" containing measurements of the code, data, and
   configuration running inside the enclave.

   *Proof Statement*: "Hardware H with platform certificate C attests
   that enclave E with measurements M produced output O from input I."

   *Properties*:

   *  Proof is generated in real-time with minimal overhead.
   *  Verification requires the hardware manufacturer's PKI (root
      certificate).
   *  The quote binds the computation to specific hardware and firmware
      versions.
   *  The enclave protects model weights and inference data from the
      host OS.

   *Supported Platforms*:

     +==========+=======================+=============+==============+
     | Platform | TEE Technology        | GPU Support | Quote Format |
     +==========+=======================+=============+==============+
     | Intel    | TDX (Trust Domain     | Via NVIDIA  | DCAP Quote   |
     |          | Extensions)           | H100 CC     | v4           |
     +----------+-----------------------+-------------+--------------+
     | AMD      | SEV-SNP               | Via NVIDIA  | Attestation  |
     |          |                       | H100 CC     | Report       |
     +----------+-----------------------+-------------+--------------+
     | NVIDIA   | H100 Confidential     | Native      | GPU          |
     |          | Computing             |             | Attestation  |
     +----------+-----------------------+-------------+--------------+
     | ARM      | CCA (Confidential     | Planned     | CCA Token    |
     |          | Compute Architecture) |             |              |
     +----------+-----------------------+-------------+--------------+

                                  Table 5

   *Entry Structure*:










Krishnan, et al.        Expires 19 September 2026               [Page 9]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   {
     "type": "tee_attestation",
     "sub": "spiffe://example.com/agent/analyst",
     "platform": "nvidia_h100_cc",
     "model_fingerprint": "sha256:weights_hash...",
     "model_id": "analyst-model-v3.2",
     "input_hash": "sha256:input_data...",
     "output_hash": "sha256:output_data...",
     "intent_entry_ref": 3,
     "quote": {
       "format": "nvidia_gpu_attestation_v1",
       "enclave_measurement": "sha384:enclave_mr...",
       "firmware_version": "H100.96.00.5E.00.01",
       "platform_cert_chain": [
         "base64:nvidia_device_cert...",
         "base64:nvidia_intermediate_cert..."
       ],
       "report_data": "sha256:binding_hash...",
       "signature": "base64:hw_signature..."
     },
     "por_ref": "spiffe://example.com/wia/gpu-node-7",
     "iat": 1700000030,
     "inference_digest": "sha256:...",
     "inference_sig": "eyJhbGci..."
   }

3.4.  Hybrid Proofs

   For high-assurance deployments, both proof types MAY be combined for
   a single inference operation:

   *  *TEE quote* provides real-time proof that inference ran in a
      protected enclave.
   *  *ZKML proof* provides mathematical proof of correct computation
      (generated asynchronously after inference).

   The inference chain entry for a hybrid proof references both:














Krishnan, et al.        Expires 19 September 2026              [Page 10]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   {
     "type": "hybrid_proof",
     "sub": "spiffe://example.com/agent/analyst",
     "tee_entry_ref": 4,
     "zkml_entry_ref": 5,
     "model_fingerprint": "sha256:weights_hash...",
     "output_hash": "sha256:output_data...",
     "intent_entry_ref": 3,
     "iat": 1700000035,
     "inference_digest": "sha256:...",
     "inference_sig": "eyJhbGci..."
   }

4.  Entry Structure

4.1.  Common Fields

   All inference chain entries share common fields:

































Krishnan, et al.        Expires 19 September 2026              [Page 11]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   +===================+========+==========+===========================+
   | Field             | Type   | Required | Description               |
   +===================+========+==========+===========================+
   | type              | string | REQUIRED | Entry type: zkml_proof,   |
   |                   |        |          | tee_attestation,          |
   |                   |        |          | hybrid_proof              |
   +-------------------+--------+----------+---------------------------+
   | sub               | string | REQUIRED | SPIFFE ID of the agent    |
   |                   |        |          | that performed            |
   |                   |        |          | inference                 |
   +-------------------+--------+----------+---------------------------+
   | model_fingerprint | string | REQUIRED | SHA-256 hash of model     |
   |                   |        |          | weights + architecture    |
   +-------------------+--------+----------+---------------------------+
   | model_id          | string | REQUIRED | Human-readable model      |
   |                   |        |          | identifier and version    |
   +-------------------+--------+----------+---------------------------+
   | output_hash       | string | REQUIRED | SHA-256 hash of           |
   |                   |        |          | inference output (MUST    |
   |                   |        |          | match intent chain        |
   |                   |        |          | entry)                    |
   +-------------------+--------+----------+---------------------------+
   | intent_entry_ref  | number | REQUIRED | Index of corresponding    |
   |                   |        |          | entry in intent chain     |
   +-------------------+--------+----------+---------------------------+
   | iat               | number | REQUIRED | Timestamp when proof      |
   |                   |        |          | was generated             |
   +-------------------+--------+----------+---------------------------+
   | inference_digest  | string | REQUIRED | Cumulative hash for       |
   |                   |        |          | Merkle tree               |
   +-------------------+--------+----------+---------------------------+
   | inference_sig     | string | REQUIRED | Signature over            |
   |                   |        |          | inference_digest          |
   +-------------------+--------+----------+---------------------------+

                                  Table 6

   The sub field identifies the agent that performed inference.  It
   corresponds to the sub field of the matching actor chain entry ({{!I-
   D.draft-mw-spice-actor-chain}}).

4.2.  Binding to Intent Chain

   The intent_entry_ref field binds each inference proof to a specific
   intent chain entry.  The output_hash in the inference entry MUST
   match the output_hash (for agent outputs) in the referenced intent
   chain entry.  This binding ensures that the computational proof
   corresponds to the actual content recorded in the intent chain.



Krishnan, et al.        Expires 19 September 2026              [Page 12]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   Intent Chain:                 Inference Chain:
   ┌──────────────────┐         ┌──────────────────┐
   │ Entry 0          │         │                  │
   │ type: non_det    │◄────────│ Entry 0          │
   │ output: sha:abc  │         │ type: tee_quote  │
   │                  │         │ output: sha:abc  │
   │                  │         │ intent_ref: 0    │
   └──────────────────┘         └──────────────────┘
   ┌──────────────────┐
   │ Entry 1          │         (no proof needed
   │ type: determ.    │          for deterministic
   │                  │          filters)
   └──────────────────┘
   ┌──────────────────┐         ┌──────────────────┐
   │ Entry 3          │         │                  │
   │ type: non_det    │◄────────│ Entry 1          │
   │ output: sha:def  │         │ type: zkml       │
   │                  │         │ output: sha:def  │
   │                  │         │ intent_ref: 3    │
   └──────────────────┘         └──────────────────┘

5.  Storage Architecture

5.1.  Inference Registry

   The inference registry stores immutable inference chain entries as
   ordered logs, following the same architecture as the intent registry.

   *Properties*:

   *  Append-only (immutable)
   *  Ordered by offset within session
   *  Partitioned by session ID
   *  Eventual consistency acceptable

   |  Inference registry entries MUST NOT contain OAuth tokens, bearer
   |  credentials, or signing keys.  Entries contain only inference
   |  proofs, content hashes, metadata, and agent identities.  The token
   |  references the registry via the inference_registry claim; the
   |  registry MUST NOT store or reference the token itself.

   Implementations SHOULD use an append-only log with tamper-evident
   guarantees and partitioned, ordered retrieval by session ID.

   *Log Structure*:






Krishnan, et al.        Expires 19 September 2026              [Page 13]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   {
     "session_id": "sess-uuid-12345",
     "offset": 0,
     "entry": {
       "type": "tee_attestation",
       "sub": "spiffe://example.com/agent/A",
       "model_fingerprint": "sha256:weights...",
       "model_id": "agent-A-model-v2",
       "output_hash": "sha256:abc...",
       "intent_entry_ref": 0,
       "quote": { "..." : "..." },
       "iat": 1700000010,
       "inference_digest": "sha256:...",
       "inference_sig": "eyJ..."
     }
   }

5.2.  Merkle Tree Construction

   The inference chain Merkle tree follows the same construction
   algorithm as the intent chain (defined in {{!I-D.draft-mw-spice-
   intent-chain}} Section 5.3).  Leaf nodes are the SHA-256 hashes of
   canonically serialized inference chain entries.  The resulting root
   hash is included in the OAuth token as the inference_root claim.

5.3.  Merkle Root in Token

   Only the Merkle root is included in the OAuth token:

   {
     "inference_root": "sha256:xyz789...",
     "inference_proof_type": "groth16",
     "inference_registry":
       "https://proof-log.example.com"
   }
















Krishnan, et al.        Expires 19 September 2026              [Page 14]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


      +======================+========+==========+==================+
      | Field                | Type   | Required | Description      |
      +======================+========+==========+==================+
      | inference_root       | string | REQUIRED | Merkle root hash |
      |                      |        |          | of inference     |
      |                      |        |          | chain            |
      +----------------------+--------+----------+------------------+
      | inference_proof_type | string | OPTIONAL | Primary proof    |
      |                      |        |          | algorithm used   |
      |                      |        |          | (e.g., groth16,  |
      |                      |        |          | tee_tdx, hybrid) |
      +----------------------+--------+----------+------------------+
      | inference_registry   | string | REQUIRED | URI of inference |
      |                      |        |          | registry for     |
      |                      |        |          | proof retrieval  |
      +----------------------+--------+----------+------------------+

                                  Table 7

6.  Token Structure

6.1.  Combined Token Format (Full Truth Stack)

   The complete token combines session, actor chain, intent chain, and
   inference chain:


























Krishnan, et al.        Expires 19 September 2026              [Page 15]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   {
     "iss": "https://auth.example.com",
     "sub": "user-alice",
     "aud": "https://api.example.com",
     "jti": "tok-eee-12345",
     "sid": "sess-uuid-12345",
     "iat": 1700000000,
     "exp": 1700003600,

     "session": {
       "session_id": "sess-uuid-12345",
       "type": "human_initiated",
       "initiator": "user-alice",
       "approval_ref": "approval-uuid-789",
       "max_chain_depth": 5
     },

     "actor_chain": [
       {
         "sub":
           "spiffe://example.com/agent/orchestrator",
         "iss": "https://auth.example.com",
         "iat": 1700000010
       },
       {
         "sub":
           "spiffe://example.com/agent/analyst",
         "iss": "https://auth.example.com",
         "iat": 1700000030
       }
     ],

     "intent_root": "sha256:abc123...",
     "intent_registry":
       "https://intent-log.example.com/sessions/sess-uuid-12345",

     "inference_root": "sha256:xyz789...",
     "inference_proof_type": "tee_h100",
     "inference_registry":
       "https://proof-log.example.com/sessions/sess-uuid-12345"
   }










Krishnan, et al.        Expires 19 September 2026              [Page 16]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


6.2.  Claim Definitions

       +======================+========+==========================+
       | Claim                | Type   | Description              |
       +======================+========+==========================+
       | inference_root       | string | Merkle root hash of      |
       |                      |        | inference chain          |
       +----------------------+--------+--------------------------+
       | inference_proof_type | string | Primary proof algorithm  |
       |                      |        | (e.g., groth16, tee_tdx, |
       |                      |        | tee_h100, hybrid)        |
       +----------------------+--------+--------------------------+
       | inference_registry   | string | URI for retrieving full  |
       |                      |        | inference chain or       |
       |                      |        | proofs (REQUIRED)        |
       +----------------------+--------+--------------------------+

                                 Table 8

7.  Verification Procedures

7.1.  Three-Point Verification

   A Relying Party receiving a token with all three chains performs a
   "Three-Point Check":

   1.  *Identity* (Actor Chain): Is the delegation chain valid?  Are all
       actors authorized?
   2.  *Integrity* (Intent Chain): Does the content hash trail match the
       intent_root?
   3.  *Validity* (Inference Chain): Does the computational proof verify
       against the inference_root?

7.2.  ZKML Proof Verification

   To verify a ZKML inference entry:

   1.  Retrieve the entry from the inference registry.
   2.  Fetch the verification key from verification_key_registry.
   3.  Verify hash(verification_key) == verification_key_hash.
   4.  Run the ZKP verifier: verify(proof, verification_key,
       public_inputs) where public_inputs = (model_fingerprint,
       input_hash, output_hash).
   5.  Verify output_hash matches the corresponding intent chain entry.







Krishnan, et al.        Expires 19 September 2026              [Page 17]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


7.3.  TEE Quote Verification

   To verify a TEE attestation entry:

   1.  Retrieve the entry from the inference registry.
   2.  Validate the platform certificate chain against the
       manufacturer's root CA (e.g., Intel, NVIDIA).
   3.  Check the platform certificate has not been revoked (TCB recovery
       check).
   4.  Verify the quote signature using the platform certificate.
   5.  Verify enclave_measurement matches the expected measurement for
       the claimed model.
   6.  Verify report_data binds the quote to the specific input/output
       hashes.
   7.  Verify output_hash matches the corresponding intent chain entry.

7.4.  Tiered Verification

   Inference verification extends the tiered strategy from {{!I-D.draft-
   mw-spice-intent-chain}}:

   +============+=============+==============+===========+=============+
   | Risk Level | Actor Chain | Intent       | Inference | Use Case    |
   |            |             | Chain        | Chain     |             |
   +============+=============+==============+===========+=============+
   | Low        | Sync        | Skip         | Skip      | Read        |
   |            |             |              |           | operations  |
   +------------+-------------+--------------+-----------+-------------+
   | Medium     | Sync        | Cached       | Skip      | Create/     |
   |            |             | proof        |           | update      |
   +------------+-------------+--------------+-----------+-------------+
   | High       | Sync        | Full         | TEE quote | Financial   |
   |            |             |              | check     | decisions   |
   +------------+-------------+--------------+-----------+-------------+
   | Critical   | Sync        | Full         | Full ZKML | Regulatory, |
   |            |             |              | + TEE     | high-stakes |
   +------------+-------------+--------------+-----------+-------------+

                                  Table 9

8.  Policy Enforcement

8.1.  Policy Examples

8.1.1.  Require Inference Proof for All Agent Outputs






Krishnan, et al.        Expires 19 September 2026              [Page 18]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   require_inference_proofs {
       intent_chain := get_intent_chain(
           input.intent_root)
       inference_chain := get_inference_chain(
           input.inference_root)

       agent_outputs := [i |
           intent_chain[i].type == "non_deterministic"]

       every i in agent_outputs {
           some j
           inference_chain[j].intent_entry_ref == i
       }
   }

8.1.2.  Require TEE for Financial Operations

   require_tee_for_finance {
       input.action in ["transfer", "approve",
                         "underwrite"]

       inference_chain := get_inference_chain(
           input.inference_root)

       every entry in inference_chain {
           entry.type in ["tee_attestation",
                          "hybrid_proof"]
       }
   }

8.1.3.  Block Specific Model Versions

   block_deprecated_models {
       inference_chain := get_inference_chain(
           input.inference_root)

       every entry in inference_chain {
           not entry.model_id in
               data.deprecated_models
       }
   }

8.2.  Integration with Policy Engines

   The inference chain claims are designed for consumption by policy
   engines such as Open Policy Agent (OPA).  A policy engine SHOULD:





Krishnan, et al.        Expires 19 September 2026              [Page 19]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   1.  Verify actor chain integrity (per {{!I-D.draft-mw-spice-actor-
       chain}}).
   2.  Verify intent chain integrity (per {{!I-D.draft-mw-spice-intent-
       chain}}).
   3.  Verify inference_root and inference_registry are present and non-
       empty.
   4.  Evaluate deployment-specific requirements such as proof type
       (ZKML vs TEE), model version policies, and hardware platform
       requirements.

9.  Security Considerations

9.1.  STRIDE Analysis for Inference Chain

    +=================+===================+===========================+
    | Threat          | Attack            | Mitigation                |
    +=================+===================+===========================+
    | *Spoofing*      | Model             | model_fingerprint binds   |
    | (Computational) | substitution      | proof to specific weights |
    +-----------------+-------------------+---------------------------+
    | *Tampering*     | Weight            | Hash of weights in proof  |
    | (Model)         | modification      | statement                 |
    +-----------------+-------------------+---------------------------+
    | *Repudiation*   | "I didn't run     | Signed inference entries  |
    |                 | that model"       | with agent SPIFFE ID      |
    +-----------------+-------------------+---------------------------+
    | *Replay*        | Reuse old proof   | input_hash + output_hash  |
    |                 | for new output    | binding + iat timestamp   |
    +-----------------+-------------------+---------------------------+
    | *Environment    | Claim TEE without | TEE quote with hardware-  |
    | Spoofing*       | using one         | signed measurements       |
    +-----------------+-------------------+---------------------------+

                                  Table 10

9.2.  Trust Assumptions

9.2.1.  ZKML Proofs

   *  Trust the cryptographic hardness assumptions of the proof system
      (e.g., discrete log for Groth16, collision resistance for STARKs).
   *  Trust the correctness of the arithmetic circuit encoding the
      neural network.
   *  DO NOT require trust in any hardware manufacturer.

9.2.2.  TEE Attestation





Krishnan, et al.        Expires 19 September 2026              [Page 20]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   *  Trust the hardware manufacturer's root of trust (Intel, AMD,
      NVIDIA).
   *  Trust the manufacturer's TCB recovery process (firmware updates,
      revocation).
   *  Trust that the TEE hardware correctly isolates the enclave from
      the host.
   *  ACKNOWLEDGE the risk of hardware-level attacks (side channels,
      fault injection) although these require physical access and are
      outside the typical threat model.

9.3.  Verification Key Management

   For ZKML proofs, the verification key uniquely identifies the circuit
   (and therefore the model architecture).  Verification keys:

   *  MUST be published in a discoverable registry
      (verification_key_registry).
   *  MUST be versioned alongside model versions.
   *  SHOULD be pinned by deployers to prevent key substitution attacks.
   *  MAY be registered in a SCITT transparency log for long-term
      auditability.

9.4.  Proof Freshness

   Inference proofs MUST include an iat timestamp.  Verifiers SHOULD
   reject proofs older than a configurable maximum age.  For TEE quotes,
   the platform firmware version SHOULD be checked against the
   manufacturer's latest TCB baseline to ensure the hardware is patched.

9.5.  Credential Isolation

   Inference registry entries MUST NOT contain OAuth tokens, bearer
   credentials, or signing keys.  The relationship between tokens and
   registry entries is one-directional: the token references the
   registry via the inference_registry URI claim, but the registry MUST
   NOT store or reference the token.  This separation ensures that
   compromise of the inference registry does not expose bearer
   credentials.

9.6.  ZKML Proof Size Considerations

   STARK-based proofs can be tens of kilobytes.  The Merkle tree
   architecture ensures this does not affect token size (only the root
   hash is in the JWT).  However, deployments using STARKs SHOULD
   consider:

   *  Pre-computing and caching proofs for frequently-used model/input
      combinations.



Krishnan, et al.        Expires 19 September 2026              [Page 21]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   *  Using recursive proof composition to compress multiple STARK
      proofs into a single succinct proof.
   *  Implementing proof compression techniques specific to their proof
      system.

9.7.  Relationship to Proof of Residency

   The inference chain's TEE attestation entries are complementary to,
   but distinct from, the Proof of Residency (PoR) in actor chain
   entries ({{!I-D.draft-mw-spice-transitive-attestation}}):

   *  *PoR* (in actor chain): Proves the agent's IDENTITY is bound to a
      TEE.  Answers "Is this agent running in a secure environment?"
   *  *TEE Quote* (in inference chain): Proves a specific COMPUTATION
      ran in a TEE.  Answers "Did this model execution happen inside an
      enclave?"

   Both MAY reference the same underlying hardware, but serve different
   verification purposes.  The por_ref field in TEE attestation entries
   allows cross-referencing.

10.  Privacy Considerations

10.1.  Model Weight Privacy

   ZKML proofs provide zero-knowledge privacy for model weights — the
   verifier learns that the output was produced by a model with a
   specific fingerprint, but learns nothing about the actual weights.
   This is valuable for proprietary models where the weights are
   confidential.

   TEE attestation provides enclave isolation — the model weights are
   protected from the host OS, but the enclave measurement reveals
   information about the model binary.

10.2.  Input Privacy

   Both proof types include input_hash rather than the raw input,
   providing input privacy by default.  For applications requiring
   stronger guarantees, ZKML proofs can be constructed to hide the input
   entirely (proving only that "some valid input" produced the output).

10.3.  Selective Disclosure

   Inference chain entries MAY use Selective Disclosure (SD-JWT) {{!I-
   D.ietf-oauth-selective-disclosure-jwt}} to hide sensitive fields such
   as model_id or platform from certain verifiers while maintaining
   proof integrity.



Krishnan, et al.        Expires 19 September 2026              [Page 22]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


11.  Implementation Guidance

11.1.  Current ZKML Landscape

   As of this writing, ZKML is practical for models up to approximately
   100 million parameters.  Active research is scaling this boundary
   through optimized circuit designs and recursive proof composition.

   Deployments SHOULD plan for ZKML scalability improvements and MAY use
   TEE attestation as a near-term bridge.

11.2.  TEE Integration

   For TEE-based inference proofs:

   1.  Deploy the model inside a TEE enclave (e.g., NVIDIA Confidential
       Computing on H100).
   2.  At inference time, generate a hardware quote binding the input
       hash and output hash to the enclave measurement.
   3.  Append the quote as a TEE attestation entry to the inference
       registry.
   4.  The quote's report_data field MUST contain sha256(input_hash ||
       output_hash) to bind the proof to specific content.

11.3.  Scalability Considerations

   *  *Async ZKML*: ZKML proofs MAY be generated asynchronously after
      inference.  The intent chain entry is appended immediately; the
      inference chain entry is appended when the proof is ready.  The
      Merkle root is recomputed at token exchange time.
   *  *Proof Batching*: Multiple inference operations MAY be batched
      into a single ZKML proof using recursive composition, reducing
      verification overhead.
   *  *Quote Caching*: TEE quotes for the same enclave measurement MAY
      be cached for a configurable period, reducing quote generation
      overhead.

11.4.  Multi-AS Deployments

   In deployments involving multiple Authorization Servers, the
   inference registry is shared across all participating ASes under the
   same session partition.  Each AS appends inference chain entries
   under the sid partition established at session initiation.  The
   inference_root in each successive token is recomputed over all proof
   entries accumulated so far — it therefore differs at each hop as the
   chain grows.  This is expected behavior: a relying party receiving a
   later token will see a larger inference_root than one receiving an
   earlier token in the same session.  ASes do not need to share keys or



Krishnan, et al.        Expires 19 September 2026              [Page 23]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   coordinate directly — the session partition and append-only log
   semantics provide the necessary consistency, following the same
   pattern as the Actor Chain Registry ({{!I-D.draft-mw-spice-actor-
   chain}}) and Intent Registry ({{!I-D.draft-mw-spice-intent-chain}}).

11.5.  Registry Availability

   Inference registry unavailability does not affect data-plane
   operation — the token's AS-signed inference_root is sufficient for
   request-time policy decisions.  Per-entry proof verification is
   deferred to the audit plane.

   However, inference proofs are uniquely valuable because they cannot
   be regenerated after the fact — the exact model state, input, and
   execution environment may no longer be available.  Deployments
   SHOULD:

   *  Replicate inference registry entries across availability zones.
   *  Use append-only log services designed for high durability (e.g.,
      SCITT transparency logs).
   *  Define a fail-mode policy: *fail-closed* for regulated workloads
      (e.g., financial, healthcare), or *fail-open* with verification
      gap logging for lower-risk workloads.

   A federated IAM/IdM platform (e.g., Keycloak, Microsoft Entra, Okta,
   PingFederate) MAY host the inference registry alongside the Actor
   Chain Registry and Intent Registry under the same session partition —
   see {{!I-D.draft-mw-spice-actor-chain}} Section "Registry Hosting"
   for detailed requirements.

11.5.1.  Proof Size and Storage

   Inference proof payloads are significantly larger than actor chain
   entries (~0.5-1KB) or intent chain entries (_(0.5-1KB):)

















Krishnan, et al.        Expires 19 September 2026              [Page 24]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


      +=======================+==============+======================+
      | Proof Type            | Typical Size | Storage Implication  |
      +=======================+==============+======================+
      | TEE attestation quote | _(2-4KB)     | Compatible with most |
      |                       |              | IAM data stores      |
      +-----------------------+--------------+----------------------+
      | Groth16 ZK proof      | ~200 bytes   | Compatible with most |
      |                       |              | IAM data stores      |
      +-----------------------+--------------+----------------------+
      | STARK proof           | _50KB        | May exceed IAM data  |
      |                       |              | store blob limits    |
      +-----------------------+--------------+----------------------+

                                  Table 11

   Most IAM/IdM platforms are not designed to store large binary blobs.
   Deployments that include STARK proofs SHOULD either:

   *  Use a dedicated object store (e.g., S3, GCS, Azure Blob Storage)
      for proof payloads, with the IAM platform serving as the registry
      index and access control layer.
   *  Or use a SCITT transparency log that natively supports variable-
      size entries.

11.6.  Performance Guidance: TEE vs ZKML

   Deployments SHOULD select proof types based on their latency
   requirements:

   *  *Real-time applications* (chat, interactive agents, API serving):
      Use TEE attestation quotes exclusively.  TEE proof generation adds
      millisecond-level overhead and is compatible with production-scale
      LLMs (100B+ parameters).
   *  *Batch/offline applications* (document generation, model
      evaluation, regulatory reporting): ZKML proofs provide
      mathematical certainty independent of hardware trust.  Proof
      generation latency (minutes to hours) is acceptable when not on
      the critical path.
   *  *Hybrid deployments*: Use TEE quotes for real-time inference and
      generate ZKML proofs asynchronously for high-value operations,
      appending them to the inference chain after the fact.  The Merkle
      root is recomputed at the next token exchange.









Krishnan, et al.        Expires 19 September 2026              [Page 25]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


12.  Design Rationale: Merkle Root in Token

   The inference chain follows the same Merkle root architecture as the
   intent chain (see {{!I-D.draft-mw-spice-intent-chain}} Design
   Rationale for the detailed comparison).  The same trade-offs apply,
   with additional motivation: inference proofs are large (STARK proofs
   ~50KB, TEE quotes ~2-4KB), making inline embedding in tokens
   impractical.  The Merkle root enables selective verification of
   individual proofs using O(log n) sibling hashes, which is critical
   for the tiered verification strategy.

13.  IANA Considerations

13.1.  JWT Claim Registration

   This document requests registration of the following claims in the
   "JSON Web Token Claims" registry established by {{!RFC7519}}:

   *  *Claim Name*: inference_root

   *  *Claim Description*: Merkle root hash of the inference chain for
      computational provenance verification.

   *  *Change Controller*: IETF

   *  *Specification Document(s)*: [this document]

   *  *Claim Name*: inference_proof_type

   *  *Claim Description*: Primary proof algorithm used in the inference
      chain.

   *  *Change Controller*: IETF

   *  *Specification Document(s)*: [this document]

   *  *Claim Name*: inference_registry

   *  *Claim Description*: URI of the inference registry for proof
      retrieval.

   *  *Change Controller*: IETF

   *  *Specification Document(s)*: [this document]







Krishnan, et al.        Expires 19 September 2026              [Page 26]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


13.2.  CWT Claim Registration

   This document requests registration of the following claims in the
   "CBOR Web Token (CWT) Claims" registry established by {{!RFC8392}}:

   *  *Claim Name*: inference_root

   *  *Claim Description*: Merkle root hash of the inference chain.

   *  *CBOR Key*: TBD (e.g., 60)

   *  *Claim Type*: tstr

   *  *Change Controller*: IETF

   *  *Specification Document(s)*: [this document]

   *  *Claim Name*: inference_registry

   *  *Claim Description*: URI of the inference registry for proof
      retrieval.

   *  *CBOR Key*: TBD (e.g., 61)

   *  *Claim Type*: tstr

   *  *Change Controller*: IETF

   *  *Specification Document(s)*: [this document]

   *  *Claim Name*: inference_proof_type

   *  *Claim Description*: Primary proof algorithm used in the inference
      chain.

   *  *CBOR Key*: TBD (e.g., 62)

   *  *Claim Type*: tstr

   *  *Change Controller*: IETF

   *  *Specification Document(s)*: [this document]

Appendix A.  Full Token Example (Three-Chain Governance)







Krishnan, et al.        Expires 19 September 2026              [Page 27]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


   {
     "iss": "https://auth.example.com",
     "sub": "user-alice",
     "aud": "https://api.example.com",
     "jti": "tok-fff-67890",
     "iat": 1700000000,
     "exp": 1700003600,

     "session": {
       "session_id": "sess-uuid-12345",
       "type": "human_initiated",
       "initiator": "user-alice",
       "approval_ref": "approval-uuid-789",
       "max_chain_depth": 5
     },

     "actor_chain": [
       {
         "sub":
           "spiffe://example.com/agent/orchestrator",
         "iss": "https://auth.example.com",
         "iat": 1700000010,
         "scope": "ticket:*",
         "chain_digest": "sha256:aaa...",
         "chain_sig": "eyJhbGci..."
       },
       {
         "sub":
           "spiffe://example.com/agent/analyst",
         "iss": "https://auth.example.com",
         "iat": 1700000030,
         "scope": "analysis:run",
         "chain_digest": "sha256:bbb...",
         "chain_sig": "eyJhbGci..."
       }
     ],

     "intent_root": "sha256:abc123...",
     "intent_registry":
       "https://intent-log.example.com/sessions/sess-uuid-12345",

     "inference_root": "sha256:xyz789...",
     "inference_proof_type": "tee_h100",
     "inference_registry":
       "https://proof-log.example.com/sessions/sess-uuid-12345"
   }





Krishnan, et al.        Expires 19 September 2026              [Page 28]

Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


Authors' Addresses

   Ram Krishnan
   JPMorgan Chase & Co
   Email: ramkri123@gmail.com


   A Prasad
   Oracle
   Email: a.prasad@oracle.com


   Diego R. Lopez
   Telefonica
   Email: diego.r.lopez@telefonica.com


   Srinivasa Addepalli
   Aryaka
   Email: srinivasa.addepalli@aryaka.com































Krishnan, et al.        Expires 19 September 2026              [Page 29]
