# drafts

name: draft-mpsb-agntcy-messaging
rev: 01
title: An Overview of Messaging Systems and Their Applicability to Agentic AI
time: 2026-02-24T22:24:23Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-28T22:24:23Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-03T15:50:09.773554+00:00
abstract:
  Agentic AI systems require messaging infrastructure that supports
     real-time collaboration, high-volume streaming, and dynamic group
     coordination across distributed networks.  Traditional protocols like
     AMQP, MQTT, and NATS address some requirements but fall short on
     security, particularly regarding [AMQP] [MQTT] [NATS] post-compromise
     protection and quantum-safe encryption essential for autonomous
     agents handling sensitive data.

     This document analyzes six messaging protocols—AMQP, MQTT, NATS, AMQP
     over WebSockets, Kafka, and AGNTCY SLIM—across dimensions critical
     for GenAI agent systems: streaming performance, delivery guarantees,
     security models, and operational complexity.  We examine how each
     protocol's design decisions impact agentic AI deployments, from
     lightweight edge computing scenarios to large-scale multi-
     organizational collaborations.

     AGNTCY SLIM emerges as a purpose-built solution, integrating Message
     Layer Security (MLS) [RFC9420] with gRPC [gRPC] over HTTP/2 [RFC7540]
     to provide quantum-safe end-to-end encryption, efficient streaming,
     and OAuth-based authentication [RFC6749].  Unlike transport-layer
     security approaches, SLIM's MLS implementation ensures secure
     communication even through untrusted intermediaries while supporting
     dynamic group membership changes essential for collaborative AI
     agents.

full_text:
  Network Working Group                                     L. Muscariello
  Internet-Draft                                               M. Papalini
  Intended status: Informational                                M. Sardara
  Expires: 28 August 2026                                         S. Betts
                                                                     Cisco
                                                          24 February 2026


   An Overview of Messaging Systems and Their Applicability to Agentic AI
                       draft-mpsb-agntcy-messaging-01

  Abstract

     Agentic AI systems require messaging infrastructure that supports
     real-time collaboration, high-volume streaming, and dynamic group
     coordination across distributed networks.  Traditional protocols like
     AMQP, MQTT, and NATS address some requirements but fall short on
     security, particularly regarding [AMQP] [MQTT] [NATS] post-compromise
     protection and quantum-safe encryption essential for autonomous
     agents handling sensitive data.

     This document analyzes six messaging protocols—AMQP, MQTT, NATS, AMQP
     over WebSockets, Kafka, and AGNTCY SLIM—across dimensions critical
     for GenAI agent systems: streaming performance, delivery guarantees,
     security models, and operational complexity.  We examine how each
     protocol's design decisions impact agentic AI deployments, from
     lightweight edge computing scenarios to large-scale multi-
     organizational collaborations.

     AGNTCY SLIM emerges as a purpose-built solution, integrating Message
     Layer Security (MLS) [RFC9420] with gRPC [gRPC] over HTTP/2 [RFC7540]
     to provide quantum-safe end-to-end encryption, efficient streaming,
     and OAuth-based authentication [RFC6749].  Unlike transport-layer
     security approaches, SLIM's MLS implementation ensures secure
     communication even through untrusted intermediaries while supporting
     dynamic group membership changes essential for collaborative AI
     agents.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Source for this draft and an issue tracker can be found at
     https://github.com/agntcy/slim-spec.







  Muscariello, et al.      Expires 28 August 2026                 [Page 1]


  Internet-Draft            agncty-messaging-eco             February 2026


  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 28 August 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.

  Table of Contents

     1.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Protocol Analysis for Agentic AI Systems  . . . . . . . . . .   4
       3.1.  Traditional Enterprise Messaging: AMQP  . . . . . . . . .   4
       3.2.  IoT-Optimized Messaging: MQTT . . . . . . . . . . . . . .   4
       3.3.  Cloud-Native Messaging: NATS  . . . . . . . . . . . . . .   5
       3.4.  Browser Integration: AMQP over WebSockets . . . . . . . .   5
       3.5.  High-Throughput Streaming: Apache Kafka . . . . . . . . .   6
       3.6.  Next-Generation Agent Messaging: SLIM . . . . . . . . . .   7
       3.7.  Security Considerations for Agentic AI  . . . . . . . . .   9
       3.8.  Performance Implications  . . . . . . . . . . . . . . . .   9
       3.9.  Deployment and Operational Considerations . . . . . . . .  10
     4.  RPC in Agentic Protocols and Relationship to Messaging  . . .  11
       4.1.  RPC vs. Messaging: Synchronous vs. Asynchronous . . . . .  11
       4.2.  When Asynchronous Feels Synchronous (Interactive
             Real-Time)  . . . . . . . . . . . . . . . . . . . . . . .  11
       4.3.  Bridging Patterns: RPC over Messaging and Streaming
             RPC . . . . . . . . . . . . . . . . . . . . . . . . . . .  12



  Muscariello, et al.      Expires 28 August 2026                 [Page 2]


  Internet-Draft            agncty-messaging-eco             February 2026


       4.4.  A2A and MCP in Context  . . . . . . . . . . . . . . . . .  12
       4.5.  SLIM RPC (SRPC) . . . . . . . . . . . . . . . . . . . . .  12
       4.6.  Advantages of SLIM for A2A APIs . . . . . . . . . . . . .  13
       4.7.  Security Implications . . . . . . . . . . . . . . . . . .  13
     5.  Comparison  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
       6.2.  Informative References  . . . . . . . . . . . . . . . . .  19
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

  1.  Conventions and Definitions

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

     When designing a multi-agent system for generative AI, the messaging
     layer becomes a critical piece of infrastructure.  GenAI agents—built
     with frameworks like LangGraph, AutoGen, or LlamaIndex—often need to
     collaborate in real time, exchange high volumes of streaming data
     (e.g., token-by-token outputs), and coordinate complex tasks such as
     voting or consensus.  Moreover, security requirements extend well
     beyond basic TLS; in scenarios where agents share sensitive models or
     partial computations, post-compromise security and robust end-to-end
     encryption are essential.

     In practice, you’ll want a protocol that efficiently handles one-to-
     many or many-to-many communication, supports dynamic membership (with
     agents joining or leaving on the fly), and scales to accommodate a
     “forest” of agents spread across global networks.  Some protocols
     excel at ultra-low-latency, high-throughput streaming—critical for
     continuous token streams or aggregated embeddings—while others
     emphasize strong consistency and durability.  Additionally, advanced
     cryptographic features such as automatic key rotation and forward
     secrecy are vital when compromised credentials must not enable an
     attacker to decrypt future communications.

     Below, we compare six popular messaging protocols—AMQP, MQTT, NATS,
     AMQP over WebSockets, Kafka, and the emerging AGNTCY SLIM (Secure
     Low-Latency Interactive Messaging)—across dimensions that matter for
     GenAI agent systems: streaming performance, delivery guarantees,
     flexible pub/sub patterns, agent coordination, security (including
     end-to-end encryption and zero-trust support), and real-world
     adoption.



  Muscariello, et al.      Expires 28 August 2026                 [Page 3]


  Internet-Draft            agncty-messaging-eco             February 2026


  3.  Protocol Analysis for Agentic AI Systems

     The following sections provide detailed analysis of each messaging
     protocol in the context of agentic AI requirements.

  3.1.  Traditional Enterprise Messaging: AMQP

     The Advanced Message Queuing Protocol (AMQP), most commonly
     implemented through RabbitMQ, represents the gold standard for
     enterprise messaging systems.  AMQP's strength lies in its
     sophisticated message routing capabilities through exchanges, queues,
     and routing keys, enabling complex message flow patterns essential
     for enterprise applications.

     For agentic AI systems, AMQP offers several advantages.  Its support
     for both at-least-once and exactly-once delivery semantics
     (particularly in AMQP 1.0) ensures reliable message delivery between
     AI agents, which is crucial when agents are coordinating critical
     tasks or sharing expensive computational results.  The protocol's
     durable queue support means that agent messages can persist across
     system restarts, preventing loss of important coordination data.

     However, AMQP's enterprise focus comes with trade-offs.  The protocol
     carries higher overhead due to its rich feature set, which may impact
     performance in high-frequency agent communication scenarios.
     Streaming capabilities require extensions like RabbitMQ Streams,
     adding complexity to deployments focused on real-time agent
     collaboration.

     Authentication in AMQP relies on traditional enterprise mechanisms
     like SASL, LDAP, and Kerberos, which integrate well with existing
     corporate identity systems but may not align with modern cloud-native
     authentication patterns preferred in AI infrastructure.

  3.2.  IoT-Optimized Messaging: MQTT

     Message Queuing Telemetry Transport (MQTT) emerged from the IoT world
     with a focus on lightweight, efficient communication over constrained
     networks.  Its topic-based publish-subscribe model maps naturally to
     many agent communication patterns, where agents subscribe to topics
     representing different types of events or data streams.

     MQTT's three Quality of Service levels (QoS 0, 1, and 2) provide
     flexibility in balancing performance versus reliability.  For agentic
     AI systems, QoS 0 (at-most-once) works well for frequent status
     updates or non-critical notifications, while QoS 2 (exactly-once)
     ensures critical agent coordination messages are delivered reliably.




  Muscariello, et al.      Expires 28 August 2026                 [Page 4]


  Internet-Draft            agncty-messaging-eco             February 2026


     The protocol's very low overhead makes it attractive for scenarios
     involving large numbers of lightweight AI agents or edge computing
     deployments where bandwidth is constrained.  However, MQTT's IoT
     heritage shows in its limitations for agentic AI use cases.  Native
     streaming support requires broker extensions, and message-level
     security typically relies entirely on transport-layer TLS rather than
     end-to-end encryption.

     MQTT's authentication mechanisms, while sufficient for IoT devices,
     may not provide the sophisticated identity and access management
     features required for complex multi-agent AI systems involving
     different trust domains.

  3.3.  Cloud-Native Messaging: NATS

     NATS represents a modern approach to messaging designed for cloud-
     native architectures.  Its lightweight design and support for
     multiple communication patterns—publish-subscribe, request-reply, and
     queue groups—make it particularly well-suited for microservices-based
     AI agent deployments.

     The protocol's core at-most-once delivery semantics align well with
     scenarios where AI agents can tolerate occasional message loss in
     favor of high performance.  For use cases requiring stronger
     guarantees, NATS JetStream provides at-least-once delivery and
     streaming capabilities, though this requires additional
     infrastructure complexity.

     NATS's optional broker architecture offers interesting deployment
     flexibility for agentic AI systems.  While most deployments use a
     broker for efficiency, the protocol can support peer-to-peer
     communication, potentially enabling direct agent-to-agent
     communication in specialized scenarios.

     Authentication in NATS includes modern options like JWT tokens and
     NKey cryptographic authentication, aligning better with cloud-native
     security practices.  However, like MQTT, NATS relies primarily on
     transport-layer security rather than providing built-in end-to-end
     message encryption.

  3.4.  Browser Integration: AMQP over WebSockets

     AMQP over WebSockets addresses a specific deployment challenge:
     enabling browser-based AI agents or user interfaces to participate in
     AMQP-based agent coordination systems.  This approach tunnels
     standard AMQP protocols through WebSocket connections, allowing web
     applications to overcome firewall restrictions and network topology
     limitations.



  Muscariello, et al.      Expires 28 August 2026                 [Page 5]


  Internet-Draft            agncty-messaging-eco             February 2026


     For agentic AI systems that include web-based components—such as
     user-facing AI assistants that need to coordinate with backend AI
     agents—this protocol variant provides a bridge between browser
     environments and enterprise messaging infrastructure.  The WebSocket
     Secure (WSS) transport ensures encrypted communication from browser
     to broker.

     However, the additional protocol layers (AMQP within WebSockets)
     introduce higher overhead compared to native AMQP or other
     lightweight protocols.  This makes AMQP over WebSockets primarily
     suitable for scenarios where browser integration is essential rather
     than for high-performance agent-to-agent communication.

  3.5.  High-Throughput Streaming: Apache Kafka

     Apache Kafka represents a fundamentally different approach to
     messaging, based on distributed commit logs rather than traditional
     message queues.  This architecture provides exceptional throughput
     and built-in streaming capabilities that align well with certain
     agentic AI use cases.

     Kafka's partition-based topic model enables massive horizontal
     scaling, making it suitable for AI systems that need to process large
     volumes of training data, model updates, or inference results across
     distributed agent networks.  The platform's native streaming
     capabilities through Kafka Streams and KSQL provide powerful tools
     for real-time processing of agent-generated data.

     The protocol's built-in persistence across distributed clusters
     ensures that agent communication history is preserved and can be
     replayed, which is valuable for AI systems that need to audit agent
     decisions or retrain models based on historical interactions.
     Consumer groups enable multiple agents to process different
     partitions of the same topic concurrently, supporting parallel AI
     workloads.

     However, Kafka's strengths come with complexity costs.  The
     requirement for a distributed cluster infrastructure may be overkill
     for simpler agent coordination tasks.  While Kafka provides exactly-
     once semantics through transactions, the default at-least-once
     delivery may require additional deduplication logic in agent
     implementations.

     Kafka's security model, while comprehensive, relies primarily on
     transport-layer encryption and broker-based access controls rather
     than end-to-end message encryption, which may not meet the security
     requirements of AI systems handling sensitive model data or
     proprietary algorithms.



  Muscariello, et al.      Expires 28 August 2026                 [Page 6]


  Internet-Draft            agncty-messaging-eco             February 2026


  3.6.  Next-Generation Agent Messaging: SLIM

     AGNTCY SLIM (Secure Low-Latency Interactive Messaging) represents a
     purpose-built protocol for modern agentic AI systems, designed to
     address the specific security, performance, and coordination
     requirements that existing protocols cannot fully satisfy.

     SLIM is intended as a transport layer for agent protocols like A2A
     and MCP.  It handles secure routing, group messaging, and end-to-end
     encryption so protocol implementations can focus on agent semantics.
     A registration-based model lets agents become reachable through the
     SLIM network without exposing server ports, while only routing nodes
     need to be publicly reachable.  This simplifies deployment for agents
     behind NATs and firewalls.

     SLIM's foundation on gRPC over HTTP/2 and HTTP/3 provides several
     immediate advantages for AI agent communication.  The binary protocol
     buffer wire format minimizes serialization overhead while supporting
     both binary and text data types essential for AI workloads.  HTTP/2's
     multiplexing capabilities allow a single connection to carry multiple
     concurrent agent conversations, reducing connection overhead in
     systems with many interacting agents.

     SLIM is architected as a distributed system with a clear separation
     of concerns:

     *  *Data plane*: Routes messages across SLIM nodes using only
        metadata for efficient forwarding and topology management.

     *  *Session layer*: Provides reliable delivery, MLS-based end-to-end
        encryption, and secure group management (create, invite, join,
        remove).

     *  *Control plane*: Orchestrates routing nodes, configuration, and
        administrative operations.

     Routing nodes run only the data plane, keeping infrastructure
     lightweight, while language bindings include the data-plane client
     plus the session layer for full security and reliability.

     The protocol's quality of service model explicitly addresses the
     diverse communication patterns found in agentic AI systems.  Fire-
     and-forget messaging supports high-frequency status updates and non-
     critical notifications, while reliable exactly-once delivery ensures
     critical coordination messages and expensive computational results
     are never lost.  This extends consistently across request-reply
     patterns and streaming communications.




  Muscariello, et al.      Expires 28 August 2026                 [Page 7]


  Internet-Draft            agncty-messaging-eco             February 2026


     Perhaps most significantly, SLIM's integration of Message Layer
     Security (MLS) provides quantum-safe, end-to-end encryption
     specifically designed for group communications.  Unlike transport-
     layer security approaches used by other protocols, MLS ensures that
     messages remain secure even when transmitted through potentially
     compromised intermediaries—a critical requirement for AI systems
     operating across multiple trust domains.

     The protocol's authentication model demonstrates particular
     innovation in addressing agentic AI security requirements.  By
     transporting MLS credentials and cryptographic proofs within OAuth
     bearer tokens over HTTP/2, SLIM achieves several important
     properties:

     *  *Interoperability*: Leverages standard HTTP/2 and OAuth libraries,
        reducing implementation complexity and improving compatibility
        with existing infrastructure

     *  *Scalability*: Single persistent HTTP/2 connections efficiently
        carry many MLS-secured messages between agents

     *  *Immediate revocation*: Malicious or compromised agents can be
        immediately ejected by revoking their OAuth tokens without
        requiring complex ratchet tree rebalancing operations

     SLIM's naming system is hierarchical and DID-inspired, for example:
     organization/namespace/service/instance.  This supports anycast
     routing (to any available instance), unicast routing (to a specific
     instance), and service discovery without hardcoded endpoints or
     external registries.  The structure maps cleanly to organizational
     boundaries and multi-tenant deployments.

     The protocol's support for both broker-based and peer-to-peer
     operation offers deployment flexibility.  While broker-based
     operation provides efficiency for multi-party group communications
     typical in agent coordination scenarios, peer-to-peer capabilities
     enable direct agent-to-agent communication when appropriate.  SLIM
     exposes two session types that map to common agent patterns: point-
     to-point sessions for tool calls and group sessions for coordination
     and broadcast.

     SLIM provides multi-language bindings.  Python and Go bindings are
     available today, with JavaScript/TypeScript, C#, and Kotlin in
     progress, enabling heterogeneous agent systems to interoperate on the
     same transport.






  Muscariello, et al.      Expires 28 August 2026                 [Page 8]


  Internet-Draft            agncty-messaging-eco             February 2026


  3.7.  Security Considerations for Agentic AI

     Security requirements for agentic AI systems extend well beyond the
     capabilities provided by traditional messaging protocols.  The
     autonomous nature of AI agents, combined with their access to
     sensitive data and computational resources, creates unique threat
     models that messaging infrastructure must address.

     *Post-Compromise Security*: In traditional systems, credential
     compromise typically requires immediate revocation and re-
     authentication.  However, AI agents may operate for extended periods
     with limited human oversight.  SLIM's MLS implementation provides
     forward secrecy, ensuring that compromise of current credentials
     cannot decrypt past communications, and post-compromise security,
     guaranteeing that future communications remain secure even after
     credential compromise.

     *Quantum-Safe Cryptography*: As quantum computing advances threaten
     current cryptographic standards, AI systems—which may operate for
     years with the same cryptographic keys—need protection against future
     quantum attacks.  SLIM's quantum-safe MLS implementation provides
     this protection, while traditional protocols rely on classical
     cryptographic assumptions that may become vulnerable.

     *Multi-Domain Operations*: Agentic AI systems often span multiple
     organizational and security domains, with agents from different
     organizations collaborating on shared tasks.  Traditional protocols
     typically assume trust in messaging infrastructure, but SLIM's end-
     to-end encryption ensures secure communication even when messages
     transit through potentially untrusted intermediaries.

     *Dynamic Group Membership*: AI agent groups frequently change as
     agents join collaborations, complete tasks, or become unavailable.
     MLS's efficient group key management handles these membership changes
     while maintaining security properties, unlike approaches that require
     complete cryptographic context regeneration.

  3.8.  Performance Implications

     The performance characteristics of messaging protocols significantly
     impact the behavior and capabilities of agentic AI systems,
     particularly as the number of agents and frequency of interactions
     scale.








  Muscariello, et al.      Expires 28 August 2026                 [Page 9]


  Internet-Draft            agncty-messaging-eco             February 2026


     *Latency Sensitivity*: Many AI agent interactions are latency-
     sensitive, particularly in real-time decision-making scenarios or
     when agents are coordinating time-critical tasks.  SLIM's HTTP/2
     foundation provides header compression and multiplexing that reduce
     per-message overhead, while the binary protocol buffer encoding
     minimizes serialization costs.

     *Throughput Requirements*: Large-scale agentic AI systems may involve
     thousands of agents generating substantial message volumes.  While
     protocols like Kafka excel at raw throughput, they may introduce
     latency through their log-based architecture.  SLIM balances
     throughput and latency through efficient connection reuse and
     optional reliability levels.

     *Connection Efficiency*: Traditional protocols often require separate
     connections for each communication pattern or security context.
     SLIM's connection multiplexing allows a single HTTP/2 connection to
     handle diverse communication patterns between agents, reducing
     resource consumption and connection establishment overhead.

     *Streaming Performance*: AI agents frequently exchange streaming
     data—such as token-by-token language model outputs or real-time
     sensor data.  SLIM's native gRPC streaming support over HTTP/2
     provides efficient bidirectional streaming without the overhead of
     connection-per-stream approaches.

  3.9.  Deployment and Operational Considerations

     The operational characteristics of messaging protocols significantly
     impact the total cost of ownership and operational complexity of
     agentic AI systems.

     *Infrastructure Requirements*: Traditional enterprise protocols like
     AMQP require dedicated message broker infrastructure with high
     availability and clustering capabilities.  Kafka requires even more
     complex distributed infrastructure.  SLIM's optional broker
     architecture allows deployments to scale infrastructure complexity
     with system requirements.

     *Monitoring and Observability*: Debugging distributed agentic AI
     systems requires comprehensive visibility into agent communications.
     SLIM's foundation on standard HTTP/2 infrastructure enables use of
     existing observability tools and practices, while proprietary
     protocols may require specialized monitoring solutions.

     *Integration with Cloud Services*: Modern AI deployments increasingly
     rely on cloud services for scalability and managed operations.
     SLIM's HTTP/2 foundation integrates naturally with cloud load



  Muscariello, et al.      Expires 28 August 2026                [Page 10]


  Internet-Draft            agncty-messaging-eco             February 2026


     balancers, API gateways, and observability services, while
     specialized messaging protocols may require additional integration
     layers.

     *Compliance and Auditing*: AI systems in regulated industries require
     comprehensive audit trails and compliance capabilities.  SLIM's
     structured topic hierarchy and optional message persistence support
     regulatory requirements, while the end-to-end encryption provides
     compliance with data protection regulations.

  4.  RPC in Agentic Protocols and Relationship to Messaging

     Most agent-facing interfaces in use today — notably A2A and the Model
     Context Protocol (MCP) — are Remote Procedure Call (RPC) oriented.
     They expose synchronous request/response semantics for tool
     invocation, resource listing, and capability execution.  This section
     clarifies how RPC relates to asynchronous messaging and how the two
     paradigms interoperate in agentic systems.

  4.1.  RPC vs. Messaging: Synchronous vs. Asynchronous

     *  *RPC (A2A, MCP)*: Caller issues a request and blocks/awaits a
        timely response.  Semantics emphasize tightly scoped operations
        (for example, “call tool X with parameters Y”) with bounded
        latency and explicit error contracts.

     *  *Messaging (AMQP, MQTT, NATS, Kafka, SLIM)*: Decoupled producers/
        consumers communicate via topics/subjects/queues.  Delivery can be
        one-to-one, one-to-many, or many-to-many with loose coupling,
        buffering, and retries.  Producers are not inherently blocked by
        consumers.

     In practice, agentic applications need both: synchronous tool
     invocations for interactivity and asynchronous channels for streaming
     output, progress, coordination, and fan-out/fan-in patterns.

  4.2.  When Asynchronous Feels Synchronous (Interactive Real-Time)

     Asynchronous transports can provide an interactive, “RPC-like”
     experience when: - A request message includes a correlation ID and
     reply-to destination. - The callee publishes a response on the
     indicated reply destination within a short SLA. - Client libraries
     surface responses as futures/promises and manage timeouts/retries.

     This underpins instant messaging UX and maps well to agent UIs where
     a user triggers an action and expects prompt, possibly streaming,
     results.




  Muscariello, et al.      Expires 28 August 2026                [Page 11]


  Internet-Draft            agncty-messaging-eco             February 2026


  4.3.  Bridging Patterns: RPC over Messaging and Streaming RPC

     *  *Request/Reply over Pub/Sub*: Implement RPC by publishing a
        command event and awaiting a correlated reply event (applies to
        AMQP, NATS, MQTT, and SLIM topics).

     *  *Streaming RPC*: Use bidirectional streams (for example, gRPC over
        SLIM HTTP/2/3) to deliver token streams, partial results, or
        progress updates while retaining an RPC caller experience.

     *  *Sagas and CQRS*: For multi-step workflows across agents,
        coordinate via asynchronous orchestration with idempotency keys,
        correlation/causation IDs, and compensations.

     *  *Backpressure and Flow Control*: Prefer streaming transports
        (HTTP/2/3, gRPC) or messaging systems with flow control when
        returning large/continuous results.

  4.4.  A2A and MCP in Context

     *  *A2A Agent Cards*: Describe capabilities/endpoints commonly
        invoked via RPC-style calls (tool execution, configuration).  They
        benefit from messaging for discovery, eventing, and long-running
        workflows.

     *  *MCP*: Standardizes RPC-like interactions (resources, tools,
        prompts).  For multi-party sessions, combine MCP RPC with a
        messaging layer for broadcast, presence, and coordination.

  4.5.  SLIM RPC (SRPC)

     SLIM also supports a native RPC style via SRPC (Slim RPC), which
     layers request/response semantics on top of SLIM's interactive, real-
     time messaging.  SRPC addresses practical RPC concerns in distributed
     agent systems:

     *  Correlation and reply routing for synchronous calls over an async
        transport

     *  Idempotency keys and deduplication to make retries safe

     *  Lightweight synchronization/ordering guarantees for request/
        response and streaming

     *  Seamless fit for A2A/MCP-style tool calls while retaining SLIM's
        MLS security and multiplexing





  Muscariello, et al.      Expires 28 August 2026                [Page 12]


  Internet-Draft            agncty-messaging-eco             February 2026


     *  Supports all four gRPC interaction patterns (unary, server
        streaming, client streaming, bidirectional streaming)

     See SRPC reference and examples: SLIM RPC (SRPC) README
     (https://github.com/agntcy/slim/blob/main/data-
     plane/python/integrations/slimrpc/README.md).

  4.6.  Advantages of SLIM for A2A APIs

     SLIM augments existing A2A-style RPC with capabilities that are
     difficult to achieve over plain request/response transports:

     *  *Simultaneous fan-out RPC (scatter-gather)*: Invoke a single RPC
        across many agents (by topic/group/labels) concurrently and
        aggregate responses (first-success, quorum, all-success) with
        correlation IDs.

     *  *Group addressing and dynamic membership*: Target MLS-secured
        groups; add/remove agents without reconfiguring endpoints.

     *  *Streaming responses*: Return partial results or token streams
        from each agent over a single multiplexed connection (gRPC over
        HTTP/2/3).

     *  *Idempotency and safe retries*: SRPC supports idempotency keys and
        deduplication, enabling robust retry without duplicating effects.

     *  *QoS, deadlines, and backpressure*: Apply delivery guarantees,
        per-call timeouts, and flow control to avoid overload while
        maintaining interactivity.

     *  *End-to-end security and multi-tenant isolation*: MLS E2E
        encryption and OAuth-based policy across both RPC and messaging
        channels.

     *  *Observability and tracing*: Correlation/causation IDs and
        standardized transport enable distributed tracing and per-agent
        metrics.

     These capabilities let A2A-style tool calls scale beyond one-to-one
     interactions, enabling broadcast queries, coordinated multi-agent
     actions, and efficient collection of results in real time.

  4.7.  Security Implications

     *  *Identity and Authorization*: Reuse OAuth tokens across RPC (gRPC)
        and messaging (SLIM channels as topics) for consistent policy
        enforcement.



  Muscariello, et al.      Expires 28 August 2026                [Page 13]


  Internet-Draft            agncty-messaging-eco             February 2026


     *  *End-to-End Security*: MLS-backed secure channels (SLIM) so both
        RPC and messaging inherit end to end message encryption. ##
        Guidance: When to Choose What

     *  Use *RPC (A2A/MCP)* for low-latency, point operations with
        immediate feedback and well-defined error contracts.

     *  Use *Messaging* for broadcast/fan-out, decoupling, retries,
        buffering, and multi-party coordination.

     *  Use *Streaming RPC or RPC over Messaging* for interactive UX with
        partial/continuous results or uncertain duration operations.

  5.  Comparison

     Table 1 provides a detailed comparison of three popular messaging
     protocols commonly considered for agent communication systems:

     +================+================+==================+==============+
     |Feature         | AMQP (e.g.     | MQTT             |NATS          |
     |                | RabbitMQ)      |                  |              |
     +================+================+==================+==============+
     |*Protocol Type* | Message        | Lightweight pub/ |Lightweight   |
     |                | queueing       | sub for IoT      |messaging     |
     |                | (queues/       |                  |(pub/sub, req/|
     |                | exchanges)     |                  |reply, queue  |
     |                |                |                  |groups)       |
     +----------------+----------------+------------------+--------------+
     |*Transport*     | TCP            | TCP (optionally  |TCP           |
     |                | (optionally    | TLS)             |(optionally   |
     |                | TLS)           |                  |TLS)          |
     +----------------+----------------+------------------+--------------+
     |*Message Model* | Queues,        | Topic-based      |Subjects (pub/|
     |                | exchanges,     |                  |sub), queue   |
     |                | routing keys   |                  |groups,       |
     |                |                |                  |request/reply |
     +----------------+----------------+------------------+--------------+
     |*QoS / Delivery*| At-least-once, | QoS 0 (at-most-  |At-most-once  |
     |                | exactly-once   | once), 1, 2      |(core), at-   |
     |                | (AMQP 1.0)     | (exactly-once)   |least-once    |
     |                |                |                  |with JetStream|
     +----------------+----------------+------------------+--------------+
     |*Streaming*     | Via            | Not native       |Native with   |
     |                | extensions/    | (requires broker |JetStream     |
     |                | plugins (e.g.  | extensions)      |              |
     |                | RabbitMQ       |                  |              |
     |                | Streams)       |                  |              |
     +----------------+----------------+------------------+--------------+



  Muscariello, et al.      Expires 28 August 2026                [Page 14]


  Internet-Draft            agncty-messaging-eco             February 2026


     |*Persistence*   | Yes (durable   | Broker-dependent |Optional via  |
     |                | queues)        |                  |JetStream     |
     +----------------+----------------+------------------+--------------+
     |*Protocol       | Higher (rich   | Very low         |Very low      |
     |Overhead*       | feature set)   |                  |              |
     +----------------+----------------+------------------+--------------+
     |*Broker         | Yes            | Yes              |Optional (but |
     |Required*       |                |                  |common)       |
     +----------------+----------------+------------------+--------------+
     |*Authentication*| User/password, | Username/        |NKey, JWT,    |
     |                | SASL (e.g.,    | password or      |token, user/  |
     |                | LDAP,          | custom tokens    |password      |
     |                | Kerberos)      |                  |              |
     +----------------+----------------+------------------+--------------+
     |*Transport      | TLS            | TLS              |TLS           |
     |Security*       |                |                  |              |
     +----------------+----------------+------------------+--------------+
     |*Message        | Typically      | Usually none at  |None in core  |
     |Security*       | broker-level   | message level;   |(TLS in       |
     |                | or plugin-     | rely on TLS      |transit),     |
     |                | based          |                  |JetStream can |
     |                | encryption     |                  |encrypt at    |
     |                |                |                  |rest          |
     +----------------+----------------+------------------+--------------+
     |*Binary or Text*| Binary framing | Binary framing   |Text-based    |
     |                |                |                  |protocol      |
     |                |                |                  |(core), binary|
     |                |                |                  |clients       |
     |                |                |                  |available     |
     +----------------+----------------+------------------+--------------+
     |*Use Cases*     | Enterprise     | IoT, mobile,     |Cloud-native  |
     |                | messaging,     | sensor networks  |microservices,|
     |                | financial      |                  |real-time     |
     |                | transactions,  |                  |communications|
     |                | RPC            |                  |              |
     +----------------+----------------+------------------+--------------+
     |*Real-World     | Very widely    | Dominant in IoT  |Gaining       |
     |Usage*          | used via       | ecosystems;      |traction in   |
     |                | RabbitMQ (top  | supported by     |cloud-native  |
     |                | open-source    | many device/     |(CNCF         |
     |                | broker) in     | broker vendors   |project), used|
     |                | enterprises of |                  |by major tech |
     |                | all sizes      |                  |companies     |
     +----------------+----------------+------------------+--------------+

                                    Table 1





  Muscariello, et al.      Expires 28 August 2026                [Page 15]


  Internet-Draft            agncty-messaging-eco             February 2026


     Table 2 extends the comparison to include additional protocols
     relevant to modern agentic AI systems:

     +================+==========+============+==========================+
     |Feature         |AMQP over |Kafka       | SLIM                     |
     |                |WebSockets|            |                          |
     +================+==========+============+==========================+
     |*Protocol Type* |AMQP      |Distributed | Secure low-latency       |
     |                |tunneled  |commit log, | interactive messaging    |
     |                |through   |high-       |                          |
     |                |WebSockets|throughput  |                          |
     |                |          |pub/sub     |                          |
     +----------------+----------+------------+--------------------------+
     |*Transport*     |WebSockets|TCP         | gRPC (over               |
     |                |over TLS  |(optionally | HTTP/2-HTTP/3)           |
     |                |          |TLS)        |                          |
     +----------------+----------+------------+--------------------------+
     |*Message Model* |Same as   |Topics with | Hierarchical names       |
     |                |AMQP      |partitions, | (org/namespace/service/  |
     |                |(depends  |consumer    | instance), point-to-     |
     |                |on the    |groups,     | point and group          |
     |                |broker's  |offset-based| sessions                 |
     |                |AMQP      |consumption |                          |
     |                |model)    |            |                          |
     +----------------+----------+------------+--------------------------+
     |*QoS / Delivery*|Same as   |At-least-   | Fire&Forget unreliable   |
     |                |AMQP      |once        | (at-most-once),          |
     |                |          |default;    | unreliable and reliable  |
     |                |          |exactly-once| (exactly-once).  This    |
     |                |          |possible via| extends to request/      |
     |                |          |transactions| reply and streaming as   |
     |                |          |            | well.                    |
     +----------------+----------+------------+--------------------------+
     |*Streaming*     |Same as   |Native log- | Native gRPC support via  |
     |                |AMQP if   |based       | HTTP/2/3 client          |
     |                |broker    |streaming   | streaming, server        |
     |                |supports  |(Kafka      | streaming.  Notice that  |
     |                |streaming |Streams,    | Server Sent Events       |
     |                |          |KSQL, etc.) | (SSE) with HTTP/1.1      |
     |                |          |            | cannot carry binary nor  |
     |                |          |            | compressed data.         |
     +----------------+----------+------------+--------------------------+
     |*Persistence*   |Same as   |Built-in:   | Not supported            |
     |                |AMQP      |messages    |                          |
     |                |          |persist on  |                          |
     |                |          |disk across |                          |
     |                |          |clusters    |                          |
     +----------------+----------+------------+--------------------------+



  Muscariello, et al.      Expires 28 August 2026                [Page 16]


  Internet-Draft            agncty-messaging-eco             February 2026


     |*Protocol       |Higher    |Moderate    | Low: Wire format uses    |
     |Overhead*       |(AMQP +   |(custom     | protocol buffer.         |
     |                |WebSockets|binary      | Supports also binary     |
     |                |handshake)|protocol,   | (byte type in protobuf)  |
     |                |          |but         |                          |
     |                |          |optimized   |                          |
     |                |          |for high    |                          |
     |                |          |throughput) |                          |
     +----------------+----------+------------+--------------------------+
     |*Broker         |Yes       |Yes         | Yes for efficient        |
     |Required*       |          |(distributed| multi-party.  P2P is     |
     |                |          |cluster)    | also possible.           |
     +----------------+----------+------------+--------------------------+
     |*Authentication*|Same as   |SASL/PLAIN, | Transports MLS           |
     |                |AMQP      |SASL/SCRAM, | credentials and proofs   |
     |                |(broker-  |Kerberos,   | inside OAuth bearer      |
     |                |based)    |OAuth       | tokens over HTTP/2.      |
     |                |          |            | This gives you:          |
     |                |          |            | Interoperability:        |
     |                |          |            | Leverage standard        |
     |                |          |            | HTTP/2 and OAuth         |
     |                |          |            | libraries.               |
     |                |          |            | Scalability: One         |
     |                |          |            | persistent HTTP/2        |
     |                |          |            | connection carries many  |
     |                |          |            | MLS messages.            |
     |                |          |            | Immediate revocation:    |
     |                |          |            | Eject bad actors by      |
     |                |          |            | revoking their OAuth     |
     |                |          |            | tokens—no need to        |
     |                |          |            | rebalance the ratchet    |
     |                |          |            | tree first.              |
     +----------------+----------+------------+--------------------------+
     |*Transport      |WSS       |TLS         | TLS                      |
     |Security*       |(WebSocket|            |                          |
     |                |Secure)   |            |                          |
     +----------------+----------+------------+--------------------------+
     |*Message        |Same as   |TLS in-     | MLS (Quantum safe,       |
     |Security*       |AMQP      |flight      | Secure end-to-end, even  |
     |                |(depends  |encryption, | across insecure hops,    |
     |                |on the    |optional at-| post-compromise          |
     |                |broker's  |rest        | security)                |
     |                |encryption|encryption  |                          |
     |                |at rest/  |(broker     |                          |
     |                |in-       |config)     |                          |
     |                |transit)  |            |                          |
     +----------------+----------+------------+--------------------------+
     |*Binary or Text*|Binary    |Binary      | Binary or Text           |



  Muscariello, et al.      Expires 28 August 2026                [Page 17]


  Internet-Draft            agncty-messaging-eco             February 2026


     |                |AMQP      |protocol    |                          |
     |                |frames    |(common     |                          |
     |                |over      |payloads:   |                          |
     |                |WebSockets|Avro, JSON, |                          |
     |                |          |Protobuf)   |                          |
     +----------------+----------+------------+--------------------------+
     |*Use Cases*     |Browser-  |High-       | Group messaging, one-    |
     |                |based apps|throughput  | to-many, many-to-many,   |
     |                |needing   |data        | Cloud-native             |
     |                |AMQP      |pipelines,  | microservices, real-     |
     |                |behind    |streaming   | time communications,     |
     |                |firewalls |analytics,  | streaming                |
     |                |          |event       |                          |
     |                |          |sourcing    |                          |
     +----------------+----------+------------+--------------------------+
     |*Real-World     |Less      |Extremely   | New Entrant, low         |
     |Usage*          |common,   |widespread  |                          |
     |                |mainly for|across      |                          |
     |                |browser/  |industries; |                          |
     |                |firewall  |de facto    |                          |
     |                |scenarios |standard for|                          |
     |                |using     |large-scale |                          |
     |                |RabbitMQ  |event       |                          |
     |                |or similar|streaming   |                          |
     +----------------+----------+------------+--------------------------+

                                    Table 2

  6.  References

  6.1.  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,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/rfc/rfc6749>.

     [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
                Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
                DOI 10.17487/RFC7540, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7540>.






  Muscariello, et al.      Expires 28 August 2026                [Page 18]


  Internet-Draft            agncty-messaging-eco             February 2026


     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC9420]  Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
                Omara, E., and K. Cohn-Gordon, "The Messaging Layer
                Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
                July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.

  6.2.  Informative References

     [AMQP]     OASIS, "OASIS Advanced Message Queuing Protocol (AMQP) 1.0
                Specification", n.d.,
                <https://www.oasis-open.org/standards#amqp>.

     [gRPC]     CNCF, "gRPC Documentation", n.d., <https://grpc.io/docs/>.

     [Kafka]    Foundation, A. S., "Apache Kafka Documentation", n.d.,
                <https://kafka.apache.org/documentation/>.

     [MQTT]     OASIS, "OASIS MQTT Version 5.0 Specification", n.d.,
                <https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-
                v5.0.html>.

     [NATS]     Communications, S., "NATS Documentation", n.d.,
                <https://docs.nats.io/>.

     [SLIM]     AGNTCY, "AGNTCY SLIM Specification", n.d.,
                <https://spec.slim.agntcy.org>.

  Authors' Addresses

     Luca Muscariello
     Cisco
     Email: lumuscar@cisco.com


     Michele Papalini
     Cisco
     Email: micpapal@cisco.com


     Mauro Sardara
     Cisco
     Email: msardara@cisco.com






  Muscariello, et al.      Expires 28 August 2026                [Page 19]


  Internet-Draft            agncty-messaging-eco             February 2026


     Sam Betts
     Cisco
     Email: sambetts@cisco.com
















































  Muscariello, et al.      Expires 28 August 2026                [Page 20]


name: draft-mpsb-agntcy-slim
rev: 01
title: Secure Low-Latency Interactive Messaging (SLIM)
time: 2026-02-24T22:24:54Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-28T22:24:54Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Data formats/interop", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:06.864921+00:00
abstract:
  This document specifies the Secure Low-Latency Interactive Real-Time
     Messaging (SLIM), a protocol designed to support real-time
     interactive AI applications at scale.  SLIM provides the transport
     layer for agent protocols (for example, A2A and MCP), combining gRPC
     over HTTP/2 and HTTP/3 with secure messaging, group communication,
     and native RPC semantics.  The protocol provides mechanisms for
     connection management, stream multiplexing, and flow control while
     maintaining compatibility with existing gRPC deployments and
     supporting end-to-end encryption via MLS.

full_text:
  Network Working Group                                     L. Muscariello
  Internet-Draft                                               M. Papalini
  Intended status: Informational                                M. Sardara
  Expires: 28 August 2026                                         S. Betts
                                                                     Cisco
                                                          24 February 2026


              Secure Low-Latency Interactive Messaging (SLIM)
                         draft-mpsb-agntcy-slim-01

  Abstract

     This document specifies the Secure Low-Latency Interactive Real-Time
     Messaging (SLIM), a protocol designed to support real-time
     interactive AI applications at scale.  SLIM provides the transport
     layer for agent protocols (for example, A2A and MCP), combining gRPC
     over HTTP/2 and HTTP/3 with secure messaging, group communication,
     and native RPC semantics.  The protocol provides mechanisms for
     connection management, stream multiplexing, and flow control while
     maintaining compatibility with existing gRPC deployments and
     supporting end-to-end encryption via MLS.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Source for this draft and an issue tracker can be found at
     https://github.com/agntcy/slim-spec.

  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 28 August 2026.





  Muscariello, et al.      Expires 28 August 2026                 [Page 1]


  Internet-Draft                 agent-slim                  February 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.

  Table of Contents

     1.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Routing Nodes (Data Plane)  . . . . . . . . . . . . . . .   5
         3.1.1.  Connection Table  . . . . . . . . . . . . . . . . . .   7
         3.1.2.  Subscription Table and Matching . . . . . . . . . . .   7
       3.2.  Control Plane . . . . . . . . . . . . . . . . . . . . . .   8
       3.3.  Session Layer . . . . . . . . . . . . . . . . . . . . . .   9
         3.3.1.  Core Responsibilities . . . . . . . . . . . . . . . .   9
         3.3.2.  API Design Principles . . . . . . . . . . . . . . . .   9
         3.3.3.  Session Management  . . . . . . . . . . . . . . . . .  10
       3.4.  Naming Considerations . . . . . . . . . . . . . . . . . .  10
       3.5.  Deployment Considerations . . . . . . . . . . . . . . . .  11
     4.  RPC in Agentic Protocols and Relationship to Messaging  . . .  11
       4.1.  RPC vs. Messaging: Synchronous vs. Asynchronous . . . . .  11
       4.2.  Challenges of RPC over Messaging  . . . . . . . . . . . .  12
       4.3.  Remote Procedure Calls over SLIM (SRPC) . . . . . . . . .  13
         4.3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  13
         4.3.2.  Key Features  . . . . . . . . . . . . . . . . . . . .  13
         4.3.3.  Architecture  . . . . . . . . . . . . . . . . . . . .  13
         4.3.4.  Benefits for Agentic Applications . . . . . . . . . .  14
         4.3.5.  SLIM Naming in SRPC . . . . . . . . . . . . . . . . .  14
     5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
       5.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
       5.2.  Informative References  . . . . . . . . . . . . . . . . .  16
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

  1.  Conventions and Definitions

     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.



  Muscariello, et al.      Expires 28 August 2026                 [Page 2]


  Internet-Draft                 agent-slim                  February 2026


  2.  Introduction

  2.1.  Summary

     The Secure Low-Latency Interactive Messaging (SLIM) protocol
     addresses the unique communication requirements of modern AI agentic
     applications by providing a secure, scalable, and efficient messaging
     infrastructure.  SLIM combines the reliability and performance of
     gRPC with secure messaging and group communication, creating a
     comprehensive solution for interactive AI application communication.

     At its core, SLIM consists of three primary components: data plane
     routing nodes that forward messages based on metadata, session-layer
     clients that manage secure group state and reliability, and
     application endpoints that publish and receive encrypted content.
     The protocol leverages Message Layer Security (MLS) for end-to-end
     encryption, ensuring that messages remain confidential even when
     passing through intermediate nodes or experiencing TLS termination
     along the communication path.

     The architecture is built around a distributed network of routing
     nodes, each maintaining connection and subscription tables to enable
     efficient message routing.  A control plane orchestrates the system,
     handling node discovery, configuration management, and administrative
     operations.  This separation of control, session, and data planes
     allows for scalable deployment while keeping routing nodes
     lightweight.

     SLIM employs a hierarchical naming system based on Decentralized
     Identifiers (DIDs) to ensure globally unique, secure, and routable
     names.  The name structure follows a organization/namespace/service/
     instance pattern, supporting anycast and unicast routing as well as
     service discovery.  This naming scheme supports both decentralized
     and federated authentication models, enabling flexible deployment
     across different organizational boundaries while maintaining security
     and interoperability.

     The protocol includes a session layer that abstracts the complexity
     of MLS operations and messaging infrastructure from applications,
     providing secure point-to-point and group sessions plus native Remote
     Procedure Call (RPC) semantics via SRPC (SLIM RPC).  SRPC enables
     request/response and streaming RPC directly over SLIM's secure
     messaging fabric (see [SRPC]), while handling authentication,
     encryption, connection management, and fault recovery automatically.
     This design enables developers to focus on application logic rather
     than the underlying messaging complexities.





  Muscariello, et al.      Expires 28 August 2026                 [Page 3]


  Internet-Draft                 agent-slim                  February 2026


     Security is fundamental to SLIM's design, with authentication and
     authorization handled through MLS groups, cryptographic client
     identities, and configurable access policies.  The protocol supports
     deployment in various environments, from data center workloads and
     mobile applications, while maintaining consistent security guarantees
     and low-latency performance characteristics.

  3.  Protocol Overview

     SLIM is designed to work as a messaging layer for applications
     running as workloads in a data center, but also running in a browser
     or mobile device while guaranteeing end-to-end security and low-
     latency communication.  SLIM leverages HTTP/2 and HTTP/3 end to end
     as a thin waist of the communication stack and avoids the need to
     create message transcoding along the path.  By leveraging message
     encryption via MLS [RFC9420] [RFC9750], TLS connection termination
     along the path does not negatively affect confidentiality.
     Authentication and authorization are handled at the application level
     and can be managed in a decentralized or federated way or a mix of
     both.

     In SLIM there are three main communication elements: routing nodes
     (data plane), session-layer clients, and application endpoints that
     publish and receive messages.

     A producer (also called a "publisher") is an endpoint that
     encapsulates content in SLIM messages for transport within the SLIM
     message network of nodes.  A producer MUST belong to an MLS group to
     encrypt messages that can be decrypted by message consumers who are
     members of the same group, as specified by the MLS protocol.  Once a
     SLIM message is encrypted, it can be published under a routable name,
     which is human-readable and hierarchical.  This routable channel name
     is used by intermediate nodes to store and forward messages within
     the same channel, allowing consumers to retrieve messages using this
     name.

     A routable name is a name prefix that is stored in a forwarding table
     (FIB).  This enables requests to reach the producer and fetch a
     response, if one exists.












  Muscariello, et al.      Expires 28 August 2026                 [Page 4]


  Internet-Draft                 agent-slim                  February 2026


   +-------------+         +---------------------+         +-------------+
   | Producer 1  |         |                     |         | Consumer 1  |
   +-------------+         |    Routing Node     |         +-------------+
                           |                     |<------->| Consumer 2  |
   +-------------+         |                     |         +-------------+
   | Producer 2  |-------->|                     |<------->| Consumer 3  |
   +-------------+         +---------------------+         +-------------+

            |                        ^   ^   ^
            |                        |   |   |
            |                        |   |   |
            |                        |   |   |
            v                        |   |   |
   +------------------------+        |   |   |
   | MLS Authentication     |<-------+---+---+
   | Service                |
   +------------------------+

   Legend:
   - Producers publish to topics via routing nodes.
   - Consumers subscribe to topics via routing nodes.
   - MLS Authentication Service handles group authentication and key management.
   - Encryption group coincides with the topic identifier.

           Figure 1: Main components of the SLIM architecture.

     Secure group members are clients as described in [RFC9750] which can
     write messages as producers or read messages as consumers.  Most of
     the time, clients are able to read and write messages in the same
     secure group.  Clients join secure groups as described in the MLS
     standard [RFC9750] via an authentication service and by exchanging
     messages via the delivery service.  In the SLIM architecture, the
     SLIM nodes constitute the data-plane infrastructure that is
     responsible for delivering messages in a secure group via a logical
     SLIM channel.  MLS commit messages are exchanged directly using the
     SLIM routing nodes.

  3.1.  Routing Nodes (Data Plane)

     Routing nodes are fundamental components of the SLIM architecture
     that forward messages using metadata without inspecting payloads.
     They fulfill several critical functions in the messaging
     infrastructure.  At their core, nodes efficiently route messages
     between connected clients while handling the distribution and
     delivery of messages across the network infrastructure.






  Muscariello, et al.      Expires 28 August 2026                 [Page 5]


  Internet-Draft                 agent-slim                  February 2026


         Producer A              Producer B              Producer C
             |                       |                       |
             v                       v                       v
        +----------+            +----------+            +----------+
        |  Node 1  |<---------->|  Node 2  |<---------->|  Node 3  |
        +----------+            +----------+            +----------+
             ^                       ^                       ^
             |                       |                       |
             v                       v                       v
        +----------+            +----------+            +----------+
        |  Node 4  |<---------->|  Node 5  |<---------->|  Node 6  |
        +----------+            +----------+            +----------+
             ^                       ^                       ^
             |                       |                       |
         Consumer X             Consumer Y             Consumer Z

     Legend:
     - Each Node maintains connection and subscription tables
     - Bidirectional arrows represent inter-node communication paths
     - Producers and Consumers connect to their local nodes
     - Messages are routed through the node network based on subscriptions

                 Figure 2: SLIM routing node network topology.

     The node architecture relies on two essential data structures that
     work in concert.  The connection table forms the foundation for
     tracking all active client connections and their states, maintaining
     crucial metadata about each connected client.  Alongside it, the
     subscription table manages topic subscriptions and implements message
     filtering rules, determining which messages should be delivered to
     which clients.

     Through this dual-table architecture, routing nodes can effectively
     coordinate message delivery while maintaining optimal system
     performance.  The connection and subscription mechanisms work
     together seamlessly to ensure reliable message routing, proper client
     tracking, and efficient subscription management across the
     distributed system.  Each node operates autonomously while
     participating in the broader network, creating a resilient and
     scalable messaging infrastructure.











  Muscariello, et al.      Expires 28 August 2026                 [Page 6]


  Internet-Draft                 agent-slim                  February 2026


  3.1.1.  Connection Table

     The connection table serves as a fundamental data structure within
     the SLIM routing node architecture, maintaining a comprehensive
     registry of both client-to-node and node-to-node connections.  Each
     entry in the table contains essential metadata about connected
     endpoints, including their unique identifiers, connection timestamps,
     authentication status, and current state information.

     For client connections, the table tracks end-user applications that
     connect to receive or send messages through the system.  For node
     connections, it maintains the network fabric topology by recording
     inter-node relationships and routing paths.  This dual-purpose nature
     enables SLIM to manage both the edge connectivity with clients and
     the internal communication infrastructure between nodes.

     Connection states are dynamically tracked and updated to reflect the
     real-time status of each endpoint.  This includes monitoring whether
     clients or nodes are actively connected, temporarily disconnected, or
     in various intermediate states.  The table maintains crucial session
     information such as endpoint capabilities, protocol versions, and
     quality of service parameters that influence message handling.

     By maintaining this detailed connection state, the table enables
     efficient routing decisions across the entire network fabric.  It
     provides each routing node with immediate access to both client and
     node status information, allowing for rapid determination of message
     delivery paths and handling of connection-related events.  The
     connection table also plays a vital role in system reliability by
     tracking connection health and enabling quick detection of
     disconnections or network issues at both the client and node levels.

     A connection table maps location-independent channel names to
     connections to remote nodes.  The mapping is used to forward messages
     towards nodes that can either route messages or consume them in case
     consumers are directly connected to the node.

     Channel names are encoded as human-readable hierarchical names for
     efficient table lookup operations.

  3.1.2.  Subscription Table and Matching

     The subscription table is used to map channel subscriptions to
     neighboring nodes.  It manages the distribution of messages based on
     subscriptions and ensures efficient delivery of messages.  A message
     carries the data to be delivered as well as the channel name and the
     address locator of the message producer.




  Muscariello, et al.      Expires 28 August 2026                 [Page 7]


  Internet-Draft                 agent-slim                  February 2026


     The control plane manages the configuration and updates of the
     connection and subscription tables.

     +-------------------------------------------------------------+
     |                    SLIM Message Structure                   |
     +-------------------------------------------------------------+
     | Channel Name   | Address Locator   |      Data Payload       |
     +-------------------------------------------------------------+
     | "/foo/bar"     | 192.0.2.10:12345 |   { ... application ... |
     |                |                  |         data ... }      |
     +-------------------------------------------------------------+

     Legend:
     - Channel Name: Identifies the logical channel/topic for routing.
     - Address Locator: Specifies the producer's network address.
     - Data Payload: Contains the actual message content.

        Figure 3: SLIM message structure carrying channel name, address
                               locator, and data.

  3.2.  Control Plane

     The control plane is responsible for the management and orchestration
     of SLIM messaging nodes and their interconnections.  It handles the
     configuration, provisioning, and monitoring of nodes, ensuring that
     the messaging infrastructure operates smoothly and efficiently.

     Key functions of the control plane include:

     *  *Node Discovery and Registration*: New messaging nodes discover
        each other and register their presence with the control plane.
        This enables the control plane to maintain an up-to-date view of
        the messaging infrastructure.

     *  *Configuration Management*: The control plane distributes
        configuration updates to messaging nodes, including connection and
        subscription table updates.  This ensures consistent and correct
        routing behavior across the node network.

     *  *Monitoring and Analytics*: The control plane collects and
        analyzes telemetry data from messaging nodes, providing insights
        into system performance, message flow, and potential issues.

     *  *Security and Access Control*: The control plane manages security
        policies, authentication, and authorization of nodes and clients,
        ensuring a secure messaging environment.





  Muscariello, et al.      Expires 28 August 2026                 [Page 8]


  Internet-Draft                 agent-slim                  February 2026


     By centralizing these management functions, the control plane
     enhances the overall reliability, security, and performance of the
     SLIM messaging infrastructure.  It enables efficient scaling, dynamic
     reconfiguration, and proactive maintenance of the node network.

  3.3.  Session Layer

     The session layer serves as a critical abstraction component that
     bridges application frameworks with the underlying SLIM messaging
     infrastructure.  It provides a unified interface that simplifies the
     complexity of secure messaging while handling the details of MLS
     client operations and message distribution.

  3.3.1.  Core Responsibilities

     The session layer encapsulates several key functionalities:

     *MLS Client Operations*: The layer implements comprehensive MLS
     client functionality including authentication procedures, message
     encryption and decryption, key management, and group membership
     operations.  It handles the complex cryptographic operations
     transparently from the application perspective.

     *Channel Management*: It provides seamless channel subscription and
     unsubscription capabilities, managing the lifecycle of channel
     memberships and maintaining subscription state across connection
     interruptions or node failures.

     *Message Abstraction*: The session layer abstracts message passing
     between applications and the SLIM message distribution network,
     handling message formatting, routing, and delivery confirmation while
     providing simple send and receive primitives to applications.

     *Configuration Abstraction*: It eliminates the need for applications
     to manage complex configuration details required to connect to SLIM
     nodes, automatically handling node discovery, connection
     establishment, and subscription management.

  3.3.2.  API Design Principles

     The session layer API is designed with the following principles:

     *  Simplicity: Applications interact with the messaging system
        through intuitive publish/subscribe operations without needing to
        understand the underlying MLS or routing complexities.

     *  Asynchronous Operations: All messaging operations are designed to
        be non-blocking, supporting high-performance applications.



  Muscariello, et al.      Expires 28 August 2026                 [Page 9]


  Internet-Draft                 agent-slim                  February 2026


     *  Framework Agnostic: The API provides language bindings and
        framework adapters for various application development
        environments, ensuring broad compatibility across different
        technology stacks.

     *  Error Handling: Comprehensive error reporting and recovery
        mechanisms help applications handle communication issues and
        authentication failures.

  3.3.3.  Session Management

     The session layer maintains persistent session state at the client
     across network disconnections and node failures.  It implements
     automatic reconnection logic, subscription recovery, and message
     queuing to ensure reliable message delivery even in unstable network
     conditions.  Session persistence includes maintaining MLS group
     membership state, channel subscriptions, and pending message queues.

  3.4.  Naming Considerations

     SLIM requires several types of identifiers: node names, channel
     names, and client locators.

     Node names are used for secure onboarding and authentication.  Node
     names do not have aggregation requirements and therefore use
     decentralized identifiers:

     node name A: did:key(node_A)

     A channel name identifies a messaging group and must be routable;
     that is, it must include a globally unique network prefix that can be
     aggregated for scalable lookups and message forwarding.

     A group in SLIM is an MLS group with a moderator client responsible
     for adding and removing group members.  The moderator is identified
     by a cryptographic public key as defined in MLS [RFC9750], and in
     SLIM, also by a decentralized identifier derived as the hash of the
     public key [DID-W3C].

     By naming entities with hashes [RFC6920], SLIM achieves secure and
     globally unique naming, enabling the creation of permissionless
     systems where channel names and client names can be distributed
     across administrative boundaries.  W3C DIDs are optional but can be
     used when hash links are employed and conform to the Named
     Information [RFC6920] standard, referencing the IANA registry
     [NI-Registry].





  Muscariello, et al.      Expires 28 August 2026                [Page 10]


  Internet-Draft                 agent-slim                  February 2026


     SLIM routable name prefixes and client names can use different DID
     methods which have different resolution systems such as did:web
     [DID-Web], did:key [DID-Key] or did:plc [DID-ATProto].  See
     [DID-Methods] for well-known DID methods.

     The naming structure follows these patterns:

     client locator: did:key(org)/namespace(org)/service/did:key(client)
     channel name: did:key(org)/namespace(org)/service/did:key(moderator)

     Where the moderator is the special client that has the role to create
     a channel, add actual application clients and remove them from the
     group.  As mentioned above the moderator is a data plane client which
     is a decentralized instance of the MLS delivery service as described
     in [RFC9420].

     The hierarchical structure is required to maximize aggregation in
     subscription tables, which can aggregate multiple names under name
     prefixes such as organization identifiers, organization namespaces,
     and services.

  3.5.  Deployment Considerations

     SLIM helps the deployment of agentic AI applications where a
     combination of data streams, tools and LLMs are combined to create a
     distributed multi-agent systems that can solve problems via AI.

     These applications work as SLIM clients and MAY expose a service to
     the secure group.  The channel and client naming structure combined
     allows for service discovery capabilities by binding the application
     a specific application namespace and service name.

  4.  RPC in Agentic Protocols and Relationship to Messaging

     Most agent-facing interfaces in use today—such as A2A and the Model
     Context Protocol (MCP)—are Remote Procedure Call (RPC) oriented.
     They expose synchronous request/response semantics for tool
     invocation, resource listing, and capability execution.  This section
     clarifies how RPC relates to asynchronous messaging and how the two
     paradigms interoperate in agentic systems.

  4.1.  RPC vs. Messaging: Synchronous vs. Asynchronous

     *  *RPC (A2A, MCP)*: The caller issues a request and blocks or awaits
        a timely response.  Semantics emphasize tightly scoped operations
        (for example, “call tool X with parameters Y”) with bounded
        latency and explicit error contracts.




  Muscariello, et al.      Expires 28 August 2026                [Page 11]


  Internet-Draft                 agent-slim                  February 2026


     *  *Messaging (AMQP, MQTT, NATS, Kafka, SLIM)*: Decoupled producers
        and consumers communicate via topics, subjects, or queues.
        Delivery can be one-to-one, one-to-many, or many-to-many, with
        loose coupling, buffering, and retries.  Producers are not
        inherently blocked by consumers.

     In practice, agentic applications need both: synchronous tool
     invocations for interactivity and asynchronous channels for streaming
     output, progress, coordination, and fan-out/fan-in patterns.

  4.2.  Challenges of RPC over Messaging

     Bridging synchronous RPC semantics with asynchronous messaging
     infrastructure introduces several challenges:

     *  *Request/Response Correlation*: Messaging systems are inherently
        decoupled and do not guarantee a direct response path.
        Implementing RPC requires correlating requests and responses,
        often using unique identifiers and temporary reply channels.

     *  *Latency and Ordering*: Messaging layers may introduce variable
        delivery latency and do not guarantee strict ordering, which can
        complicate synchronous RPC expectations.

     *  *Error Handling*: Messaging systems may buffer, retry, or drop
        messages, making it difficult to propagate errors and timeouts in
        a way that matches RPC contracts.

     *  *Streaming and Multiplexing*: Supporting streaming RPC (e.g.,
        bidirectional or server/client streaming) over messaging requires
        careful management of stream lifecycles, backpressure, and
        multiplexing multiple logical RPCs over shared channels.

     *  *Security and Authorization*: Ensuring that only authorized
        parties can invoke or respond to RPCs, and that all messages are
        authenticated and encrypted, is more complex in a distributed,
        group-based messaging environment.

     The SRPC capability in SLIM addresses these challenges by providing a
     native, secure, and streaming RPC abstraction directly over the SLIM
     messaging layer, as described in the following section.










  Muscariello, et al.      Expires 28 August 2026                [Page 12]


  Internet-Draft                 agent-slim                  February 2026


  4.3.  Remote Procedure Calls over SLIM (SRPC)

     SLIM natively supports Remote Procedure Calls (RPC) through its SRPC
     (SLIM RPC) capability, enabling efficient, secure, and flexible
     communication patterns for distributed and agentic applications.
     SRPC is designed to provide gRPC-like streaming RPC semantics
     directly over the SLIM transport, leveraging SLIM's secure,
     multiplexed, and group-oriented messaging infrastructure.

  4.3.1.  Overview

     SRPC allows applications to define and invoke remote procedures using
     familiar gRPC patterns, including unary calls, client streaming,
     server streaming, and bidirectional streaming.  This enables
     developers to build complex, stateful, and interactive workflows
     between distributed agents, services, and tools, all while benefiting
     from SLIM's end-to-end security and group membership features.

  4.3.2.  Key Features

     *  *Streaming RPC Support*: SRPC supports all gRPC streaming modes,
        allowing for flexible data exchange patterns such as real-time
        data feeds, interactive sessions, and collaborative workflows.

     *  *Multiplexed Transport*: Multiple concurrent RPC streams can be
        established over a single SLIM connection, reducing overhead and
        improving resource efficiency.

     *  *Secure Group Communication*: SRPC leverages SLIM's MLS-based
        security model, ensuring that all RPC calls and responses are
        encrypted and authenticated within the context of secure groups.

     *  *Protocol Buffers Integration*: Service definitions and message
        schemas are specified using Protocol Buffers, enabling strong
        typing and interoperability across languages and platforms.

  4.3.3.  Architecture

     SRPC is implemented as a protocol extension and a set of client/
     server libraries that integrate with the SLIM session layer.
     Developers define service interfaces using Protocol Buffers, and code
     generation tools produce client and server stubs that handle message
     serialization, stream management, and invocation logic over SLIM
     channels.







  Muscariello, et al.      Expires 28 August 2026                [Page 13]


  Internet-Draft                 agent-slim                  February 2026


     The SRPC protocol manages the lifecycle of RPC streams, including
     initiation, message exchange, error handling, and stream termination.
     It ensures that all communication adheres to SLIM's security and
     routing policies, and that group membership and authorization are
     enforced for each RPC interaction.

  4.3.4.  Benefits for Agentic Applications

     By providing native, streaming RPC capabilities, SRPC enables agentic
     AI applications and distributed systems to:

     *  Orchestrate complex, multi-step workflows across multiple agents
        and services.

     *  Exchange large or continuous data streams efficiently and
        securely.

     *  Implement interactive, real-time collaboration between distributed
        components.

     *  Simplify integration with existing gRPC-based tools and
        ecosystems.

     SRPC makes it possible to build robust, scalable, and secure agentic
     applications that fully leverage the power of SLIM's messaging and
     group communication model.

  4.3.5.  SLIM Naming in SRPC

     SRPC derives per-service and per-handler routing names directly from
     the structured SLIM naming scheme to enable efficient subscription
     and message dispatch without requiring application developers to
     manually manage channel names.

     Each application participating in a secure SLIM group already has a
     hierarchical SLIM name composed of multiple components (organization
     identifier, namespace, service, and client/moderator key).  SRPC
     appends a handler-qualified suffix to the service component to form
     unique, routable identifiers for RPC methods.

     Service interface definitions (e.g., Protocol Buffers) describe one
     or more RPC handlers supporting the four common gRPC communication
     patterns:

     *  Unary → Unary

     *  Unary → Stream




  Muscariello, et al.      Expires 28 August 2026                [Page 14]


  Internet-Draft                 agent-slim                  February 2026


     *  Stream → Unary

     *  Stream → Stream (bidirectional)

     For every handler declared inside a service, SRPC generates a method
     routing token using the pattern:

     {package}.{service}-{handler}

     Example: Given a protobuf package example_service and service Test
     with handlers ExampleUnaryUnary, ExampleUnaryStream,
     ExampleStreamUnary, ExampleStreamStream, the generated handler tokens
     are:

     *  example_service.Test-ExampleUnaryUnary

     *  example_service.Test-ExampleUnaryStream

     *  example_service.Test-ExampleStreamUnary

     *  example_service.Test-ExampleStreamStream

     SRPC then embeds the handler token into the second component (service
     segment) of the full SLIM name for routing.  If the original SLIM
     application name components c[i] are:

     c[0]/c[1]/c[2]/c[3]

     The subscribed name for a specific handler becomes:

     c[0]/c[1]/c[2]-example_service.Test-ExampleUnaryUnary/c[3]

     This transformation yields a distinct, hierarchical, and aggregatable
     name per RPC method while preserving the organizational and namespace
     prefix structure needed for subscription table aggregation.
     Applications exposing SRPC services automatically subscribe to all
     derived handler names; the SRPC library manages these subscriptions
     and maps incoming messages to the corresponding generated server stub
     functions.  Developers implement only the handler logic exactly as
     with conventional gRPC, without manual SLIM channel management.

     Benefits of this naming approach: - Deterministic and collision-
     resistant per-method naming. - Preserves hierarchical aggregation for
     routing efficiency. - Avoids separate discovery round-trips for
     method endpoints. - Enables capability advertisement to reference
     method names directly. - Simplifies multi-service deployments—adding
     a new handler produces a single new routable token.




  Muscariello, et al.      Expires 28 August 2026                [Page 15]


  Internet-Draft                 agent-slim                  February 2026


     This integration of SRPC handler naming with SLIM's hierarchical
     naming model ensures consistent, secure, and scalable routing
     semantics for RPC traffic within agentic groups.

  5.  References

  5.1.  Normative References

     [DID-Methods]
                Group, W. C. C., "Known DID Methods in the Decentralized
                Identifier Ecosystem", 29 April 2025,
                <https://www.w3.org/TR/did-extensions-methods/>.

     [DID-W3C]  Group, W. C. C., "Decentralized Identifiers (DIDs) v1.0",
                19 July 2022, <https://www.w3.org/TR/did-core/>.

     [NI-Registry]
                IANA, "Named Information Hash Algorithm Registry", 1
                August 2013, <https://www.iana.org/assignments/named-
                information/named-information.xhtml>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
                Keranen, A., and P. Hallam-Baker, "Naming Things with
                Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
                <https://www.rfc-editor.org/rfc/rfc6920>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC9420]  Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
                Omara, E., and K. Cohn-Gordon, "The Messaging Layer
                Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
                July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.

     [RFC9750]  Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., and
                A. Duric, "The Messaging Layer Security (MLS)
                Architecture", RFC 9750, DOI 10.17487/RFC9750, April 2025,
                <https://www.rfc-editor.org/rfc/rfc9750>.

  5.2.  Informative References





  Muscariello, et al.      Expires 28 August 2026                [Page 16]


  Internet-Draft                 agent-slim                  February 2026


     [DID-ATProto]
                Community, B. P., "Decentralized Identifiers (DIDs) in the
                AT Protocol", n.d.,
                <https://atproto.wiki/en/wiki/reference/identifiers/did>.

     [DID-Key]  Group, W. C. C., "The did:key Method v0.7: A DID Method
                for Static Cryptographic Keys", 26 March 2025,
                <https://w3c-ccg.github.io/did-method-key/>.

     [DID-Web]  Group, W. C. C., "The did:web Method Specification", n.d.,
                <https://w3c-ccg.github.io/did-method-web/>.

     [SRPC]     AGNTCY, "SLIM RPC (SRPC) Reference", n.d.,
                <https://github.com/agntcy/slim/blob/main/data-plane/
                slimrpc-compiler/README.md>.

  Authors' Addresses

     Luca Muscariello
     Cisco
     Email: lumuscar@cisco.com


     Michele Papalini
     Cisco
     Email: micpapal@cisco.com


     Mauro Sardara
     Cisco
     Email: msardara@cisco.com


     Sam Betts
     Cisco
     Email: sambetts@cisco.com















  Muscariello, et al.      Expires 28 August 2026                [Page 17]


name: draft-barney-caam
rev: 00
title: Contextual Agent Authorization Mesh (CAAM)
time: 2026-02-25T22:11:58Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-29T22:11:58Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-03T15:50:11.000854+00:00
abstract:
  This document specifies the Contextual Agent Authorization Mesh
     (CAAM), an authorization profile composable with the Agent
     Registration and Discovery Protocol (ARDP) I-D.pioli-agent-discovery
     and other discovery mechanisms.  CAAM defines the Post-Discovery
     Authorization Handshake: the runtime authorization layer that governs
     agent behavior after an agent has been discovered through ARDP but
     before it is permitted to execute tool calls or delegate authority.

     CAAM provides a sidecar-based authorization mediator for enforcing
     Relationship-Based Access Control (ReBAC), purpose-bound delegation,
     and cryptographically verifiable intent propagation in Human-to-Agent
     (H2A) and Agent-to-Agent (A2A) flows.  It bridges identity provenance
     frameworks -- the Interoperability Profiling for Secure Identity in
     the Enterprise (IPSIE) IPSIE and the Secure Production Identity
     Framework for Everyone (SPIFFE) SPIFFE -- with the ARDP control
     plane, leveraging OpenID XAA for coarse-grained delegation, a
     Knowledge Graph for real-time relationship inference, and the Remote
     ATtestation procedureS (RATS) architecture RFC9334 for
     cryptographically verifiable attestation of agent execution
     environments.

     The Session Context Object (SCO) defined herein is encoded as a JSON
     Web Token (JWT) RFC7519 or a CBOR Web Token (CWT) RFC8392, and
     carries a new "ctx" (Contextual Assertion) claim that binds the
     agent's delegated authority to a specific purpose, session, and trust
     chain.

full_text:
  TBD                                                         J. M. Barney
  Internet-Draft                                                  R. Pioli
  Intended status: Informational                                 D. Watson
  Expires: 28 August 2026                                      Independent
                                                          24 February 2026


                 Contextual Agent Authorization Mesh (CAAM)
                            draft-barney-caam-00

  Abstract

     This document specifies the Contextual Agent Authorization Mesh
     (CAAM), an authorization profile composable with the Agent
     Registration and Discovery Protocol (ARDP) I-D.pioli-agent-discovery
     and other discovery mechanisms.  CAAM defines the Post-Discovery
     Authorization Handshake: the runtime authorization layer that governs
     agent behavior after an agent has been discovered through ARDP but
     before it is permitted to execute tool calls or delegate authority.

     CAAM provides a sidecar-based authorization mediator for enforcing
     Relationship-Based Access Control (ReBAC), purpose-bound delegation,
     and cryptographically verifiable intent propagation in Human-to-Agent
     (H2A) and Agent-to-Agent (A2A) flows.  It bridges identity provenance
     frameworks -- the Interoperability Profiling for Secure Identity in
     the Enterprise (IPSIE) IPSIE and the Secure Production Identity
     Framework for Everyone (SPIFFE) SPIFFE -- with the ARDP control
     plane, leveraging OpenID XAA for coarse-grained delegation, a
     Knowledge Graph for real-time relationship inference, and the Remote
     ATtestation procedureS (RATS) architecture RFC9334 for
     cryptographically verifiable attestation of agent execution
     environments.

     The Session Context Object (SCO) defined herein is encoded as a JSON
     Web Token (JWT) RFC7519 or a CBOR Web Token (CWT) RFC8392, and
     carries a new "ctx" (Contextual Assertion) claim that binds the
     agent's delegated authority to a specific purpose, session, and trust
     chain.

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



  Barney, et al.           Expires 28 August 2026                 [Page 1]


  Internet-Draft                    CAAM                     February 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 28 August 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  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Relationship to Existing Standards  . . . . . . . . . . .   5
       1.2.  The Post-Discovery Authorization Handshake  . . . . . . .   5
       1.3.  The Multi-Hop Intent Binding Problem  . . . . . . . . . .   6
         1.3.1.  Standardization Gap Analysis  . . . . . . . . . . . .   7
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   8
       3.1.  Architectural Foundations . . . . . . . . . . . . . . . .   8
         3.1.1.  SPIFFE/SPIRE as the Workload Identity Root  . . . . .   9
         3.1.2.  IPSIE as the Human Provenance Layer . . . . . . . . .   9
         3.1.3.  ARDP and the Discovery-Authorization Nexus  . . . . .   9
         3.1.4.  RFC 9334 (RATS) Alignment . . . . . . . . . . . . . .   9
       3.2.  The CAAM Sidecar Model  . . . . . . . . . . . . . . . . .  10
         3.2.1.  Intercepting the Outbound Tool Calls  . . . . . . . .  10
         3.2.2.  Impersonation vs. Delegation  . . . . . . . . . . . .  10
         3.2.3.  The Ghost Token Pattern . . . . . . . . . . . . . . .  11
       3.3.  The Session Context Object (SCO)  . . . . . . . . . . . .  11
         3.3.1.  The "ctx" Claim . . . . . . . . . . . . . . . . . . .  11
         3.3.2.  Intent-Signature Mechanism  . . . . . . . . . . . . .  13
       3.4.  Policy Substrate: Knowledge Graphs and ReBAC  . . . . . .  14
         3.4.1.  Relationship Ingestion  . . . . . . . . . . . . . . .  14
         3.4.2.  Common Ancestor Constraint  . . . . . . . . . . . . .  14
         3.4.3.  Zanzibar Model  . . . . . . . . . . . . . . . . . . .  14
       3.5.  Protocol Integration  . . . . . . . . . . . . . . . . . .  14
         3.5.1.  OpenID XAA Binding  . . . . . . . . . . . . . . . . .  14



  Barney, et al.           Expires 28 August 2026                 [Page 2]


  Internet-Draft                    CAAM                     February 2026


         3.5.2.  OpenID IPSIE Binding and Shared Signals . . . . . . .  15
         3.5.3.  Post-Discovery CAAM Handshake . . . . . . . . . . . .  15
         3.5.4.  Capability Fuzzing (Narrowed Persona) . . . . . . . .  16
         3.5.5.  Protocol Phases . . . . . . . . . . . . . . . . . . .  17
       3.6.  Contextual Risk Scoring (CRS) . . . . . . . . . . . . . .  17
       3.7.  Policy Orchestration  . . . . . . . . . . . . . . . . . .  18
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
       4.1.  Token Theft and Exfiltration  . . . . . . . . . . . . . .  18
       4.2.  Context Spoofing  . . . . . . . . . . . . . . . . . . . .  19
       4.3.  Proof-of-Possession Binding . . . . . . . . . . . . . . .  20
       4.4.  Prompt Injection as Privilege Escalation  . . . . . . . .  21
       4.5.  Multi-Hop Identity Dilution . . . . . . . . . . . . . . .  21
       4.6.  Confused Deputy Prevention  . . . . . . . . . . . . . . .  22
       4.7.  Data-in-Use Protection (Future Work)  . . . . . . . . . .  23
       4.8.  Policy and Knowledge Graph Integrity  . . . . . . . . . .  23
       4.9.  Agent Supply Chain Security . . . . . . . . . . . . . . .  23
       4.10. Formal Threat Model . . . . . . . . . . . . . . . . . . .  24
     5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  25
       5.1.  Inference Isolation . . . . . . . . . . . . . . . . . . .  25
       5.2.  Minimal Disclosure  . . . . . . . . . . . . . . . . . . .  26
         5.2.1.  Coarse-Grained Context by Default . . . . . . . . . .  26
         5.2.2.  Additional Disclosure Constraints . . . . . . . . . .  27
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
       6.1.  JSON Web Token Claims Registration  . . . . . . . . . . .  27
         6.1.1.  Registry Contents . . . . . . . . . . . . . . . . . .  27
       6.2.  OAuth Parameters Registration . . . . . . . . . . . . . .  28
       6.3.  OAuth Token Introspection Response  . . . . . . . . . . .  29
       6.4.  CAAM Agent Discovery Metadata Registry  . . . . . . . . .  29
         6.4.1.  Registration Policy . . . . . . . . . . . . . . . . .  29
         6.4.2.  Initial Registry Contents . . . . . . . . . . . . . .  29
         6.4.3.  ARDP Registry Extensions  . . . . . . . . . . . . . .  30
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  30
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  31
     Appendix A.  Appendix A.  Mathematical Models for Inference
             Isolation . . . . . . . . . . . . . . . . . . . . . . . .  32
     Appendix B.  Acknowledgments  . . . . . . . . . . . . . . . . . .  32
     Appendix C.  Document History . . . . . . . . . . . . . . . . . .  32
       C.1.  draft-barney-caam-00  . . . . . . . . . . . . . . . . . .  32
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32











  Barney, et al.           Expires 28 August 2026                 [Page 3]


  Internet-Draft                    CAAM                     February 2026


  1.  Introduction

     The evolution of enterprise infrastructure toward autonomous and
     semi-autonomous agentic systems has introduced a fundamental gap in
     identity and access management.  Traditional security architectures,
     designed for static workloads and direct human-to-service
     interactions, are insufficient for managing the non-deterministic,
     ephemeral, and multi-hop nature of Large Language Model (LLM) agents.

     Current security models address identity at two distinct layers: the
     human user (via OpenID Connect and IPSIE IPSIE) and the machine
     workload (via SPIFFE SPIFFE).  Autonomous agents occupy a hybrid
     space -- a software workload that possesses its own identity but
     operates with the delegated authority of a human user or another
     agent.  This hybridity creates a gap where traditional Role-Based
     Access Control (RBAC) fails to account for the ephemeral and purpose-
     driven nature of agentic tasks.

       +====================+===============+=========+===============+
       | Security Dimension | Workload      | Human   | Agent         |
       +====================+===============+=========+===============+
       | Identity Type      | SVID          | User ID | Composite     |
       +--------------------+---------------+---------+---------------+
       | Lifespan           | Long-lived    | Session | Ephemeral     |
       +--------------------+---------------+---------+---------------+
       | Decision Logic     | Deterministic | Human   | Probabilistic |
       +--------------------+---------------+---------+---------------+
       | Trust Anchor       | Attestor      | IdP     | Discovery+Ctx |
       +--------------------+---------------+---------+---------------+
       | Authorization      | Static        | Role    | Contextual    |
       +--------------------+---------------+---------+---------------+

                                   Table 1

     As agents move from simple request-response patterns to independent
     reasoning and tool invocation, the risk of "identity dilution" and
     "authorization loops" grows.  Without a dedicated mesh to manage
     these interactions, organizations face a choice between over-
     privileging agents -- expanding the blast radius of potential
     compromises -- or restricting them to functional uselessness.  CAAM
     resolves this tension by enforcing policy at the most granular level
     of the agent's internal reasoning loop.









  Barney, et al.           Expires 28 August 2026                 [Page 4]


  Internet-Draft                    CAAM                     February 2026


  1.1.  Relationship to Existing Standards

     CAAM is not intended as a replacement for existing identity,
     authorization, or attestation protocols.  It functions as an
     orchestration profile -- a connective layer that composes outputs
     from multiple mature standards into a single, coherent authorization
     decision tailored to autonomous agent ecosystems.

     CAAM occupies three complementary roles:

     *  GNAP Extension for Non-Deterministic Clients: The Grant
        Negotiation and Authorization Protocol (GNAP) RFC9635 assumes a
        client capable of participating in structured negotiation flows.
        Autonomous agents are non-deterministic clients whose resource
        requirements emerge dynamically during multi-step reasoning.  CAAM
        extends the GNAP model by introducing the Session Context Object
        (SCO) as a purpose-bound grant envelope that constrains the
        agent's evolving resource requests to the boundaries of the
        original human intent.

     *  Policy Enforcement Point for RATS: The RATS architecture RFC9334
        defines the roles of Attester, Verifier, and Relying Party but
        does not prescribe where in an application's request path the
        Attestation Result SHOULD be consumed or how it SHOULD influence
        fine-grained authorization decisions.  The CAAM sidecar serves as
        a dedicated Policy Enforcement Point (PEP) that ingests RATS
        Attestation Results and combines them with identity provenance and
        data sensitivity signals to produce the Contextual Risk Score
        (CRS) defined in contextual-risk-scoring.

     *  Trust Framework for Multi-Hop Delegation: OAuth 2.1 and Token
        Exchange RFC8693 provide mechanisms for single-hop delegation and
        impersonation.  They do not natively address the compound trust
        problem arising in N-hop agentic chains (User -> Agent A -> Agent
        B -> Agent C), where each intermediate agent introduces a new
        trust boundary.  CAAM provides Scope Attenuation, Depth-Limited
        Tokens, and Intent-Binding to ensure that delegated authority
        degrades gracefully rather than accumulating across hops.

  1.2.  The Post-Discovery Authorization Handshake

     CAAM provides the Post-Discovery Authorization Handshake for I-
     D.pioli-agent-discovery.  The ARDP control plane enables an
     orchestrating client to discover an agent's endpoint, capabilities,
     and network address.  However, ARDP does not prescribe the
     authorization protocol that governs the agent's behavior once a
     session is established.




  Barney, et al.           Expires 28 August 2026                 [Page 5]


  Internet-Draft                    CAAM                     February 2026


     CAAM fills this gap.  After an ARDP RESOLVE operation returns an
     agent's endpoint, the CAAM sidecar mediates a mutual attestation
     handshake between the client and the discovered agent before any tool
     call is permitted.  This handshake establishes:

     1.  Mutual identity verification via SPIFFE SVIDs and RATS
         Attestation Evidence.

     2.  A purpose-bound Session Context Object (SCO) that constrains the
         agent's authority to the specific task.

     3.  A JIT Scoped Token (via the Ghost Token Pattern) that replaces
         any long-lived credential with a short-lived, nonce-bound,
         single-use token.

     Without CAAM, an ARDP-discovered agent could be invoked with a static
     bearer token that carries no purpose binding, no environmental
     attestation, and no delegation-depth limit -- the failure mode
     observed in real-world incidents where agents used static bearer
     tokens without purpose binding.

  1.3.  The Multi-Hop Intent Binding Problem

     The core standardization gap that CAAM addresses is Multi-Hop Intent
     Binding: the problem of proving, at each hop in a delegation chain,
     that the current agent's request remains within the semantic bounds
     of the original user's intent -- without over-privileging the entire
     chain.

     Existing standards address adjacent concerns but leave this problem
     unresolved:

     *  OAuth XAA handles coarse-grained identity delegation across
        application boundaries.  It establishes who is delegating what
        scope to which application.  However, XAA does not track whether a
        sub-delegated agent three hops downstream is still operating
        within the purpose for which the original grant was issued.

     *  RATS RFC9334 provides cryptographic assurance of the execution
        environment's integrity.  It establishes where the agent is
        running and whether that environment is trustworthy.  However,
        RATS Evidence contains no semantic information about the agent's
        current task or whether that task aligns with the original user's
        intent.

     *  CAEP/SSE (Shared Signals and Events) enables reactive session-
        level signals (e.g., "user logged out," "device compromised").
        These signals operate at the granularity of sessions and are



  Barney, et al.           Expires 28 August 2026                 [Page 6]


  Internet-Draft                    CAAM                     February 2026


        propagated asynchronously.  They do not provide the synchronous,
        per-request intent verification required to gate individual tool
        calls within a multi-hop agentic flow.

     CAAM bridges this gap by binding each request in the delegation chain
     to a cryptographically signed Intent-Signature derived from the
     original SCO, verified at every hop by the CAAM sidecar before a JIT
     Scoped Token is synthesized.

  1.3.1.  Standardization Gap Analysis

     The following table identifies the authorization dimensions relevant
     to autonomous agent ecosystems and maps the coverage provided by
     existing standards against the extensions introduced by CAAM.

      +=============+============+=============+=========+=============+
      | Dimension   | OAuth/GNAP | RATS        | CAEP    | CAAM        |
      +=============+============+=============+=========+=============+
      | Delegation  | 1-hop      | N/A         | N/A     | N-hop+Scope |
      |             |            |             |         | Attenuation |
      +-------------+------------+-------------+---------+-------------+
      | Env Trust   | N/A        | HW/SW       | N/A     | CRS input   |
      +-------------+------------+-------------+---------+-------------+
      | Risk        | N/A        | N/A         | Async   | Sync        |
      | Signals     |            |             |         | narrowing   |
      +-------------+------------+-------------+---------+-------------+
      | Intent      | Static     | Env-only    | None    | Per-request |
      +-------------+------------+-------------+---------+-------------+
      | Credentials | Bearer     | N/A         | N/A     | Ghost Token |
      +-------------+------------+-------------+---------+-------------+
      | Inference   | N/A        | N/A         | N/A     | Firewall    |
      +-------------+------------+-------------+---------+-------------+
      | Granularity | Grant      | Attestation | Session | Request     |
      +-------------+------------+-------------+---------+-------------+
      | Decision    | Scope      | Pass/fail   | Event   | CRS tiers   |
      +-------------+------------+-------------+---------+-------------+

                                   Table 2

  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.

     Contextual Mesh:  A decentralized, sidecar-based authorization layer



  Barney, et al.           Expires 28 August 2026                 [Page 7]


  Internet-Draft                    CAAM                     February 2026


        that enforces purpose-bound and context-aware access controls
        across a network of autonomous agents.

     Agent Principal:  The composite identity of an agent, incorporating
        its hardware-attested workload identity (SPIFFE ID) and its
        delegated human user context (IPSIE claims).

     Inference Boundary:  A documented and machine-enforceable
        specification that defines the permissible and prohibited
        conclusions an agent MAY draw from the combination of authorized
        data sources.

     Session Context Object (SCO):  A cryptographically signed, transient
        data structure encoded as a JWT RFC7519 or CWT RFC8392 that
        encapsulates the intent, purpose, and provenance of an agentic
        interaction.

     Tool-Call Interception:  The process by which an authorization
        sidecar monitors and regulates the outbound network/API request
        calls made by an agent. steps of an LLM agent to prevent policy
        violations.

     Narrowed Persona:  The reduced capability set advertised by an agent
        after the Resolver applies contextual filtering based on
        participant relationships.

     Ghost Token:  A credential management pattern where the raw
        delegation token is never exposed to the agent; instead, the mesh
        synthesizes a short-lived, purpose-scoped replacement at the
        moment of use.

     Contextual Risk Score (CRS):  A real-valued score S in the range [0,
        1] assigned to every request within the mesh, encoding the
        combined risk of provenance, environment trust, and data
        sensitivity.

     Intent-Signature:  A cryptographic binding between the original
        user's purpose (as encoded in the SCO) and each subsequent request
        in a delegation chain, implemented as a Chained JWS RFC7515.

  3.  Protocol Overview

  3.1.  Architectural Foundations

     CAAM leverages the existing maturity of identity provenance standards
     while extending them to meet agentic requirements.





  Barney, et al.           Expires 28 August 2026                 [Page 8]


  Internet-Draft                    CAAM                     February 2026


  3.1.1.  SPIFFE/SPIRE as the Workload Identity Root

     The Secure Production Identity Framework for Everyone (SPIFFE) SPIFFE
     provides a platform-agnostic standard for identifying software
     workloads.  Every agent instance in a CAAM-compliant deployment MUST
     be registered with a SPIRE server and issued a SPIFFE Verifiable
     Identity Document (SVID), typically in the form of an X.509
     certificate.  This SVID provides the agent with a non-repudiable
     identity that is automatically rotated and cryptographically bound to
     the execution environment.  This machine-level identity is the first
     layer of the CAAM trust model.

  3.1.2.  IPSIE as the Human Provenance Layer

     While SPIFFE identifies the workload, the IPSIE profiles IPSIE
     identify the delegating human.  When a human user initiates a task
     requiring agent assistance, their IPSIE-compliant identity token
     serves as the original source of authority.  CAAM uses this
     provenance to bind the agent's workload identity to the human's
     session identity, creating a composite principal.

  3.1.3.  ARDP and the Discovery-Authorization Nexus

     The Agent Registration and Discovery Protocol (ARDP) I-D.pioli-agent-
     discovery establishes a control plane for agents to advertise
     capabilities and network endpoints.  CAAM extends ARDP by introducing
     "AuthZ-at-Discovery," where the security capabilities and policy
     compliance of an agent are verified before a session is established.

     Implementations that support CAAM MUST advertise the following
     metadata in the ARDP registry: the agent's SPIFFE trust domain,
     supported RATS Evidence types, Inference Boundary hash, and policy
     manifest URI.

  3.1.4.  RFC 9334 (RATS) Alignment

     The CAAM Mesh adopts the RATS architecture RFC9334.  Within the mesh,
     the following roles are defined:

     *  Attester: The Agent or Sub-Agent providing Evidence.  Every agent
        in a CAAM-compliant deployment MUST be capable of producing RATS
        Evidence that can be independently verified.  Evidence includes
        runtime state, TPM 2.0 platform quotes, and signed container image
        digests.







  Barney, et al.           Expires 28 August 2026                 [Page 9]


  Internet-Draft                    CAAM                     February 2026


     *  Verifier: The CAAM Sidecar component that processes Evidence
        against Endorsements from the SPIRE trust domain.  The Verifier
        produces an Attestation Result that encodes the trustworthiness of
        the agent's current execution environment.

     *  Relying Party: The Resource Server that consumes the Attestation
        Result to authorize the tool call.  The Relying Party MUST NOT
        process raw Evidence; it relies on the Verifier's signed
        Attestation Result.

  3.2.  The CAAM Sidecar Model

     The CAAM sidecar is the core enforcement mechanism.  It is a
     lightweight proxy that runs alongside the agent workload,
     intercepting all internal and external communications.

  3.2.1.  Intercepting the Outbound Tool Calls

     The tool-call loop is the fundamental interaction cycle of an
     autonomous agent:

     1.  Thought: The LLM generates a plan or tool call.

     2.  Action: The agent executes the tool call.

     3.  Observation: The agent receives results and reasons further.

     The CAAM sidecar MUST intercept this loop at the transition between
     Thought and Action.  By acting as a semantic gateway, the sidecar
     analyzes the intent of the tool call before it reaches the network.

  3.2.2.  Impersonation vs. Delegation

     CAAM utilizes Token Exchange RFC8693 to manage relationships in
     multi-hop chains.  It distinguishes between Impersonation (agent acts
     as the user) and Delegation (agent acts on behalf of the user while
     maintaining its own identity).

     In the CAAM delegation model, the resulting access token MUST include
     an act (actor) claim that captures the entire lineage:











  Barney, et al.           Expires 28 August 2026                [Page 10]


  Internet-Draft                    CAAM                     February 2026


            +=============+==================+===================+
            | Step        | Token Components | Identity State    |
            +=============+==================+===================+
            | User starts | IPSIE Token      | sub: User         |
            +-------------+------------------+-------------------+
            | A calls B   | A SVID + Token   | sub: User, act: A |
            +-------------+------------------+-------------------+
            | B calls RS  | B SVID + Prev    | act: B { act: A } |
            +-------------+------------------+-------------------+

                                   Table 3

     To maintain least privilege, CAAM mandates Scope Attenuation: each
     subsequent token in the chain MUST have an equal or smaller scope
     than its predecessor.  Implementations MUST NOT permit scope
     expansion during delegation.

  3.2.3.  The Ghost Token Pattern

     While OAuth XAA handles coarse delegation between applications, CAAM
     introduces the Ghost Token Pattern to prevent raw credential
     exposure:

     1.  Grant: The User provides a long-lived XAA grant to the Lead
         Agent, representing the ceiling of the agent's authority.

     2.  Shadowing: The Lead Agent MUST NOT possess the raw XAA token.
         The token resides exclusively in the CAAM Vault.  The agent holds
         only an opaque reference.

     3.  Synthesis: Upon a tool request, the Mesh synthesizes a JIT Scoped
         Token that merges the XAA permission ceiling with the current
         RATS Attestation Evidence and the active SCO.  This token MUST be
         short-lived (less than 60 seconds TTL), bound to a cryptographic
         nonce, scoped to the exact tool call, and non-replayable.

  3.3.  The Session Context Object (SCO)

     The Session Context Object (SCO) is the central data structure of the
     CAAM protocol.  It MUST be encoded as a JWT RFC7519 for HTTP-based
     transports or as a CWT RFC8392 for constrained environments.

  3.3.1.  The "ctx" Claim

     This document defines a new JWT/CWT claim:

     ctx (Contextual Assertion):  A JSON object (or equivalent CBOR map)




  Barney, et al.           Expires 28 August 2026                [Page 11]


  Internet-Draft                    CAAM                     February 2026


        that carries the contextual metadata required for CAAM
        authorization decisions.  The "ctx" claim is registered per iana-
        considerations.

     The "ctx" claim MUST contain the following members:

     *  "purpose": A string describing the human-readable intent of the
        agentic task.  This value is set at origination and MUST NOT be
        modified by intermediate agents.

     *  "scope_ceiling": An array of OAuth scope strings representing the
        maximum authority derived from the original XAA grant.

     *  "max_hops": An integer indicating the remaining delegation depth.
        This value MUST be decremented by 1 at each delegation hop.  When
        "max_hops" reaches 0, further delegation MUST be denied.

     *  "zookie": A consistency token (as defined by the Zanzibar model
        ZANZIBAR) ensuring that relationship queries reflect the most
        recent state of the Knowledge Graph.

     *  "rats_result": A reference to the Verifier's Attestation Result
        for the current agent, encoded as a URI or an embedded Evidence
        structure per RFC9334.

     *  "crs": The current Contextual Risk Score, a decimal value in the
        range [0, 1].

     The SCO MUST be signed by the originating Identity Provider at
     creation.  At each delegation hop, the delegating agent's CAAM
     sidecar MUST append an act claim and sign the extended SCO with its
     SPIFFE SVID key, forming a Chained JWS RFC7515.

     The following is a non-normative example of an SCO JWT payload:

















  Barney, et al.           Expires 28 August 2026                [Page 12]


  Internet-Draft                    CAAM                     February 2026


     {
       "iss": "https://idp.corp.internal",
       "sub": "user:jonathan@corp.com",
       "aud": "agent:finance-bot@corp.internal",
       "iat": 1740355200,
       "exp": 1740358800,
       "act": {
         "sub": "spiffe://corp.internal/agent/fb"
       },
       "ctx": {
         "purpose": "Q4 revenue audit",
         "scope_ceiling": [
           "finance:read",
           "crm:read"
         ],
         "max_hops": 3,
         "zookie": "zk_v1_998877",
         "rats_result":
           "https://verifier.corp.internal/abc",
         "crs": 0.22
       }
     }

  3.3.2.  Intent-Signature Mechanism

     To solve the Multi-Hop Intent Binding problem, CAAM uses the Intent-
     Signature: a Chained JWS RFC7515 binding the original user's purpose
     to each subsequent request.

     1.  Origination: The CAAM mesh generates an SCO containing the
         "purpose", "scope_ceiling", and "max_hops" claims.  The SCO is
         signed by the originating Identity Provider.

     2.  Propagation: At each hop, the delegating agent's sidecar appends
         its own "act" claim and a "sub_purpose" narrowing the task scope.
         The sidecar signs the extended SCO with its SPIFFE SVID key,
         producing a Chained JWS.

     3.  Verification: Before synthesizing a JIT Scoped Token, the
         receiving sidecar MUST verify the entire signature chain.
         Verification confirms that:

         *  Each signature is valid against the signer's SPIFFE SVID.

         *  The "sub_purpose" at the current hop MUST be validated against
            the permitted scope boundaries using deterministic policy
            evaluation (e.g., OPA/Cedar tag matching).




  Barney, et al.           Expires 28 August 2026                [Page 13]


  Internet-Draft                    CAAM                     February 2026


         *  The requested scope does not exceed the "scope_ceiling" after
            Scope Attenuation.

         *  The "max_hops" counter is non-negative.

         *  The current CRS is within the acceptable remediation tier.

     4.  Gating: If any verification step fails, the sidecar MUST deny the
         tool call and MAY trigger a HITL escalation per the CRS
         remediation tiers.

  3.4.  Policy Substrate: Knowledge Graphs and ReBAC

     To avoid manual policy sprawl, CAAM mandates a Policy Inference Plane
     that treats the enterprise Knowledge Graph as the source of truth for
     relationship-based access decisions.

  3.4.1.  Relationship Ingestion

     The mesh MUST ingest relationship triples from existing IAM data (via
     SCIM) and real-time collaboration signals.  These relationships form
     the edges of the Knowledge Graph and MUST be updated continuously.

  3.4.2.  Common Ancestor Constraint

     For multi-participant sessions, the Resolver MUST satisfy the Common
     Ancestor Constraint: all participants in a session MUST share a
     relationship path through the Knowledge Graph to the data silo being
     accessed.  If any participant lacks this path, the agent's capability
     set MUST be narrowed accordingly.

  3.4.3.  Zanzibar Model

     Implementation of the Zanzibar model ZANZIBAR (e.g., SpiceDB) is
     RECOMMENDED.  This allows the N-way intersection check to be
     performed using consistency tokens (e.g., Zanzibar-style 'zookies')
     to ensure causal consistency during policy evaluation.

  3.5.  Protocol Integration

     CAAM operates as a secondary control plane between the ARDP discovery
     layer I-D.pioli-agent-discovery and the execution protocol (e.g.,
     MCP, HTTP, or gRPC).

  3.5.1.  OpenID XAA Binding

     The initial delegation between the Human and the Agent occurs via
     OpenID XAA:



  Barney, et al.           Expires 28 August 2026                [Page 14]


  Internet-Draft                    CAAM                     February 2026


     *  The User grants the agent a scope (e.g., "client_data:read").

     *  This XAA grant is treated as a root node in the Knowledge Graph,
        providing the agent the potential to access data.  The potential
        is narrowed by real-time context.

     *  The raw XAA token MUST be stored in the CAAM Vault and MUST NOT be
        exposed to the agent directly.

  3.5.2.  OpenID IPSIE Binding and Shared Signals

     CAAM utilizes IPSIE IPSIE to manage the Agentic Session:

     *  The session_id in the ARDP RESOLVE call MUST map to an IPSIE
        session identifier.

     *  The Resolver MUST act as a Shared Signals Framework (SSF)
        receiver.  If an SSF event indicates a change in session risk or
        participant list, the Resolver MUST immediately narrow any agent
        capabilities that no longer satisfy the Knowledge Graph
        intersection.

  3.5.3.  Post-Discovery CAAM Handshake

     After a client successfully discovers an agent via the ARDP RESOLVE
     method, it initiates a separate, subsequent handshake to establish
     the cryptographic context required for contextual authorization.
     This is performed via an HTTP POST to the discovered agent's /caam/
     authorize endpoint:






















  Barney, et al.           Expires 28 August 2026                [Page 15]


  Internet-Draft                    CAAM                     February 2026


     {
       "method": "POST",
       "endpoint": "/caam/authorize",
       "aid": "agent:finance-bot@corp.internal",
       "context": {
         "session_id": "ipsie-session-2026-v1",
         "xaa_ref": "vault:opaque-ref-001",
         "participants": [
           {
             "format": "email",
             "email": "jonathan@corp.com"
           },
           {
             "format": "email",
             "email": "guest@client2.com"
           }
         ],
         "consistency_token": "zk_v1_998877",
         "rats_evidence": {
           "attester_id":
             "spiffe://corp.internal/agent/fb",
           "evidence_type": "tpm2.0",
           "manifest_hash": "sha256:ab12cd34"
         }
       }
     }

  3.5.4.  Capability Fuzzing (Narrowed Persona)

     Upon RESOLVE, the Resolver performs contextual capability filtering
     in two phases:

     Discovery-Time Narrowing:

     1.  Execute a Knowledge Graph traversal to determine whether all
         participants share a relationship with the target data silos.

     2.  If a participant lacks access to a data silo, the Resolver MUST
         remove tools associated with that silo from the agent's
         capability advertisement.

     3.  The agent is discovered with a Narrowed Persona.

     Session-Time Enforcement:

     1.  The sidecar MUST enforce the same filtering on every tool call
         via outbound request interception.




  Barney, et al.           Expires 28 August 2026                [Page 16]


  Internet-Draft                    CAAM                     February 2026


     2.  If an SSF event changes the participant list mid-session, the
         sidecar MUST re-execute the Knowledge Graph intersection and
         further narrow (MUST NOT expand) the agent's capabilities.

  3.5.5.  Protocol Phases

     The CAAM protocol proceeds through four phases:

     1.  Discovery Phase: The client searches for an agent via ARDP.  The
         Resolver returns the agent's endpoint along with its CAAM
         Capability Block (SPIFFE ID, supported policy languages,
         Inference Boundary hash).

     2.  Negotiation Phase: The client and the agent's sidecar perform
         mutual attestation.  The client provides its identity proof and
         the SCO.  The sidecar verifies the SCO against IPSIE risk signals
         and RATS Evidence.

     3.  Establishment Phase: Upon successful negotiation, a Contextual
         Session is established.  The sidecar issues a JIT Scoped Token
         via the Ghost Token Pattern.

     4.  Enforcement Phase: The sidecar intercepts the tool call and
         performs real-time validation of every tool call against the SCO,
         Inference Boundary, and CRS threshold.

  3.6.  Contextual Risk Scoring (CRS)

     Every request within the mesh MUST be assigned a Contextual Risk
     Score (CRS), S in the range [0, 1], calculated by the Verifier.

       S = w_1 * P + w_2 * E + w_3 * D

     Where P is Provenance, E is EnvTrust, D is DataSensitivity, w_1 + w_2
     + w_3 = 1, and weights are configurable per deployment.  The factors
     are:

     *  Provenance: The strength and freshness of the identity chain, hop
        count from the original user, SVID validity, and SCO integrity.

     *  EnvTrust: Trustworthiness of the execution environment per RATS
        Attestation Evidence -- TPM status, manifest integrity, geographic
        compliance.

     *  DataSensitivity: Classification of the target resource (public,
        internal, confidential, regulated PII).

     Remediation Tiers:



  Barney, et al.           Expires 28 August 2026                [Page 17]


  Internet-Draft                    CAAM                     February 2026


            +================+==========+========================+
            | CRS Range      | Level    | Action                 |
            +================+==========+========================+
            | S < 0.3        | Nominal  | JIT Token execution    |
            +----------------+----------+------------------------+
            | 0.3 <= S < 0.7 | Elevated | Step-Up (MFA) REQUIRED |
            +----------------+----------+------------------------+
            | S >= 0.7       | Critical | HITL REQUIRED          |
            +----------------+----------+------------------------+

                                   Table 4

     The CRS MUST be recalculated on every tool call.  A spike in CRS mid-
     session (e.g., from an SSF risk event) MUST trigger immediate re-
     evaluation and potential session downgrade.

  3.7.  Policy Orchestration

     CAAM translates high-level intent into machine-enforceable policies
     via HEXA HEXA and IDQL:

     1.  Intent Capture: An administrator defines intent in IDQL.

     2.  Translation: The HEXA orchestrator translates IDQL to target-
         specific format (Rego for OPA OPA, Cedar CEDAR).

     3.  Distribution: Policy bundles are pushed to sidecars.

     4.  Enforcement: The sidecar evaluates tool calls against bundles,
         using SCO metadata for context.

     Implementations MAY support both OPA and Cedar simultaneously.

  4.  Security Considerations

     This section analyzes the threat landscape specific to autonomous
     agent ecosystems and describes how CAAM mitigates each identified
     threat.  The analysis follows a defense-in-depth model where multiple
     independent controls reinforce each other.

  4.1.  Token Theft and Exfiltration

     An attacker who gains access to an agent's runtime environment (e.g.,
     via container escape or memory dump) may attempt to exfiltrate tokens
     for use outside the legitimate agent context.

     CAAM employs four independent defenses:




  Barney, et al.           Expires 28 August 2026                [Page 18]


  Internet-Draft                    CAAM                     February 2026


     1.  Ghost Token Pattern: The raw long-lived XAA delegation token
         never enters the agent's address space.  It resides exclusively
         in the CAAM Vault.  An attacker who compromises the agent runtime
         will find only opaque vault references, not actionable
         credentials.

     2.  JIT Token Ephemerality: The JIT Scoped Token synthesized for each
         tool call MUST have a maximum TTL of 60 seconds and MUST be bound
         to a single-use cryptographic nonce.  After the first
         presentation, the Relying Party MUST record the nonce in a replay
         cache and reject any subsequent presentation.

     3.  Proof-of-Possession via DPoP: Every JIT Scoped Token MUST be
         sender-constrained using the Demonstrating Proof-of-Possession
         (DPoP) mechanism defined in RFC9449.  The token includes a "jkt"
         (JWK Thumbprint) confirmation claim that binds it to the agent's
         SPIFFE SVID private key.  At each tool call, the agent MUST
         present a DPoP proof JWT signed with the corresponding private
         key.  A stolen token is unusable without the private key, which
         MUST be stored in a hardware-backed keystore (TPM 2.0 or Cloud
         KMS) and MUST NOT be exportable.

     4.  Environment Binding: The token embeds a hash of the RATS
         Attestation Result that was current at synthesis time.  An
         attacker presenting the token from a different environment will
         fail the attestation verification, and the token MUST be
         rejected.

     These defenses are conjunctive.  Even if an attacker overcomes one
     layer (e.g., extracts a JIT token before it expires), the remaining
     layers (DPoP binding, environment binding, nonce exhaustion)
     independently prevent misuse.

  4.2.  Context Spoofing

     Context spoofing occurs when an agent or its operator falsifies
     environmental signals to obtain a more permissive authorization
     decision.  For example, an agent operating on a public network could
     claim to be executing within a corporate-office context to bypass
     geofencing policies.

     CAAM mitigates context spoofing through the following requirements:









  Barney, et al.           Expires 28 August 2026                [Page 19]


  Internet-Draft                    CAAM                     February 2026


     *  Self-Asserted Context Prohibition: The CAAM Verifier MUST NOT
        accept self-asserted context claims from the agent.  All
        environmental context (location, network posture, platform
        integrity) MUST be derived from independently verifiable sources:
        RATS Attestation Evidence RFC9334 from a hardware-rooted Attester,
        or corroborating signals from the SSF receiver.

     *  Attestation Evidence Validation: The Verifier MUST validate RATS
        Evidence against manufacturer Endorsements and the SPIRE trust
        domain's Reference Values.  Evidence that cannot be traced to a
        trusted Endorser MUST be rejected, and the CRS MUST be set to the
        Critical tier (S >= 0.7), triggering mandatory HITL escalation.

     *  Coarse-Grained Context Defaults: To reduce the attack surface for
        context spoofing, context signals MUST be expressed at the
        coarsest granularity sufficient for the authorization decision.
        Implementations MUST use categorical labels (e.g., "corporate",
        "in-transit", "public") rather than precise measurements (e.g.,
        GPS coordinates) unless the requested scope explicitly demands
        higher precision.  This reduces the number of forgeable dimensions
        available to an attacker.

     *  Context Freshness: The Verifier MUST reject Attestation Evidence
        older than the deployment-configured freshness threshold.  Stale
        evidence MAY indicate that an attacker captured a legitimate
        attestation from a trusted environment and is replaying it from an
        untrusted one.

  4.3.  Proof-of-Possession Binding

     Bearer tokens are insufficient for agentic authorization because they
     can be used by any party that obtains them.  CAAM requires that all
     JIT Scoped Tokens be sender-constrained.

     The CAAM sidecar MUST implement the DPoP mechanism RFC9449 as
     follows:

     1.  Key Generation: During ARDP registration, each agent's CAAM
         sidecar generates an asymmetric key pair.  The private key MUST
         be stored in a non-exportable hardware-backed keystore (TPM 2.0,
         HSM, or Cloud KMS).  The public key is published as part of the
         agent's ARDP Capability Block.

     2.  Token Binding: When the CAAM Vault synthesizes a JIT Scoped
         Token, it includes a "cnf" (confirmation) claim containing the
         "jkt" (JWK Thumbprint) of the agent's DPoP key:





  Barney, et al.           Expires 28 August 2026                [Page 20]


  Internet-Draft                    CAAM                     February 2026


     {
       "cnf": {
         "jkt": "sha256:0ZcOCORZNYy-..."
       }
     }

     1.  Proof Presentation: On every tool call, the agent MUST present a
         DPoP proof JWT alongside the JIT Scoped Token.  The proof JWT is
         signed with the agent's private key and includes the HTTP method,
         target URI, and a fresh "jti" to prevent replay.

     2.  Verification: The Relying Party MUST verify that the DPoP proof
         JWT was signed by the key whose thumbprint matches the "jkt" in
         the token's "cnf" claim.  If the proof is missing, expired, or
         signed by a different key, the token MUST be rejected.

     This binding ensures that a stolen JIT token cannot be used by an
     attacker who does not possess the agent's hardware-protected private
     key.

  4.4.  Prompt Injection as Privilege Escalation

     Prompt injection attacks are a primary threat to autonomous systems.
     CAAM treats prompt injection as a Semantic Elevation of Privilege
     attack.  The CAAM sidecar MUST remain isolated from the agent's
     reasoning space (Out-of-Band Policy Enforcement).

     Even if an agent's internal state is compromised via prompt injection
     and it attempts an unauthorized action, the sidecar intercepts the
     resulting tool call.  Because the sidecar's decision logic is
     deterministic and based on the externally verified SCO, it MUST block
     the action regardless of the agent's internal belief state.

  4.5.  Multi-Hop Identity Dilution

     In an N-hop chain (User -> Agent A -> Agent B -> Agent C), each hop
     introduces a new trust boundary.  Traditional OAuth 2.0 tokens, if
     not managed with Scope Attenuation, can allow an agent at the end of
     the chain to inherit the full permissions of the original user
     without explicit intent.

     CAAM mitigates this by requiring that every token exchange include a
     "purpose" claim matching the original intent.  The sidecar MUST
     verify that each sub-task was authorized in the original SCO.
     Combined with Scope Attenuation and Depth-Limited Tokens
     ("max_hops"), authority MUST degrade gracefully across hops rather
     than accumulating.




  Barney, et al.           Expires 28 August 2026                [Page 21]


  Internet-Draft                    CAAM                     February 2026


  4.6.  Confused Deputy Prevention

     The Confused Deputy attack in agentic systems occurs when a malicious
     or compromised Agent A passes a crafted intent to a higher-privileged
     Agent B, tricking B into performing an action that A is not
     authorized to request.  A related attack is token replay, where a
     captured JIT token is presented in a different environment or session
     context.

     CAAM prevents both attacks through Contextual Binding -- the
     cryptographic coupling of every JIT Scoped Token to the specific SCO,
     environment attestation, DPoP key, and nonce from which it was
     derived:

     *  Environment Binding: The JIT token embeds a hash of the RATS
        Attestation Result that was current at synthesis time.  If an
        attacker replays the token from a different environment, the
        Relying Party's Attestation Result will not match the embedded
        hash, and the token MUST be rejected.

     *  Session Binding: The JIT token includes the SCO's "jti" (JWT ID)
        and "session_id".  A token synthesized for Session X MUST NOT be
        accepted in Session Y.  The sidecar MUST validate that the
        presented token's session binding matches the active Contextual
        Session.

     *  Nonce Binding: Each JIT token is bound to a single-use
        cryptographic nonce.  After the first use, the nonce is recorded
        in a replay cache.  Any subsequent presentation of the same nonce
        MUST be rejected.

     *  Sender Binding: The JIT token is bound to the agent's DPoP key via
        the "cnf"/"jkt" claim per dpop-binding.  Even if Agent A obtains a
        token intended for Agent B, A cannot produce a valid DPoP proof
        because A does not possess B's private key.

     *  Intent Binding: The JIT token carries the "purpose" and
        "sub_purpose" from the SCO.  Agent B's sidecar MUST verify that
        the requested action falls within the stated purpose before
        executing.  A crafted intent from Agent A that requests an out-of-
        scope action will fail this check even if Agent B has the
        technical capability to perform it.

     These five bindings are conjunctive: all MUST hold for a JIT token to
     be accepted.  The failure of any single binding invalidates the
     token.





  Barney, et al.           Expires 28 August 2026                [Page 22]


  Internet-Draft                    CAAM                     February 2026


  4.7.  Data-in-Use Protection (Future Work)

     While CAAM provides robust controls for data-at-rest and data-in-
     transit via access policies, the next frontier is protecting data-in-
     use during processing by the agent's LLM or inference engine.

     As technology matures, agent workloads MAY be executed within
     Confidential Computing environments (e.g., secure enclaves such as
     Intel SGX or AMD SEV).  Executing the agent within a Trusted
     Execution Environment (TEE) protects the "Observation" and reasoning
     phases from inspection or tampering by a compromised host OS or
     hypervisor.  This provides cryptographic assurance against active
     data leakage and some forms of prompt injection at the execution
     layer itself.

     Because deploying large, GPU-accelerated LLM workloads within secure
     enclaves is currently technically difficult, this is identified as an
     optional, future capability rather than a strict requirement for -00
     implementations.

  4.8.  Policy and Knowledge Graph Integrity

     The security of the CAAM mesh relies entirely on the correctness of
     the authorization policy (e.g., OPA or Cedar) and the accuracy of the
     Knowledge Graph.  Implementations MUST adopt a Zero Trust approach to
     policy lifecycle management.

     This approach SHOULD include:

     *  Signed Policy Bundles: All policy updates MUST be
        cryptographically signed and verified by the sidecar before
        enforcement.

     *  Verifiable Audit Trails: All mutations to the Knowledge Graph MUST
        be appended to a tamper- evident log.

     *  Policy-as-Code Pipelines: Changes to the ruleset MUST pass through
        automated CI/CD pipelines with mandatory security reviews and
        conflict-detection tests to prevent the introduction of overly
        permissive rules.

  4.9.  Agent Supply Chain Security

     While RATS secures the agent's runtime environment, a comprehensive
     Zero Trust model MUST also scrutinize the agent's software
     provenance.





  Barney, et al.           Expires 28 August 2026                [Page 23]


  Internet-Draft                    CAAM                     February 2026


     The CAAM framework SHOULD be extended to verify the software supply
     chain of discovered agents.  Before initiating the Post-Discovery
     Handshake, the sidecar MAY require the agent (or the ARDP Registrar)
     to provide a signed Software Bill of Materials (SBOM).  The sidecar
     can then verify that the agent's components, including the specific
     LLM model weights and inference dependencies, contain no known
     critical vulnerabilities before allowing execution.

  4.10.  Formal Threat Model

     The following threats are specific to multi-agent orchestration.  For
     each threat, the table identifies the attack vector, the primary CAAM
     mitigation, and the relevant section of this document.






































  Barney, et al.           Expires 28 August 2026                [Page 24]


  Internet-Draft                    CAAM                     February 2026


     +===========+=============+================+========================+
     |Threat     |Vector       | Mitigation     | Ref                    |
     +===========+=============+================+========================+
     |Token Theft|Runtime      | DPoP+Vault+60s | token-theft            |
     |           |exfil        |                |                        |
     +-----------+-------------+----------------+------------------------+
     |Context    |Fake env     | RATS+coarse    | context-spoofing       |
     |Spoof      |             | ctx            |                        |
     +-----------+-------------+----------------+------------------------+
     |Confused   |Intent A->B  | 5-way binding  | confused-deputy        |
     |Deputy     |             |                |                        |
     +-----------+-------------+----------------+------------------------+
     |Signal     |Fake TEE/geo | TPM Evidence   | context-spoofing       |
     |Spoof      |             |                |                        |
     +-----------+-------------+----------------+------------------------+
     |Deleg Loop |Circular     | max_hops+cycle | sco-definition         |
     |           |chain        |                |                        |
     +-----------+-------------+----------------+------------------------+
     |Token      |Captured JIT | Nonce+DPoP     | dpop-binding           |
     |Replay     |             |                |                        |
     +-----------+-------------+----------------+------------------------+
     |Infer      |Cross-source | Firewall+DP    | minimal-disclosure     |
     |Bypass     |             |                |                        |
     +-----------+-------------+----------------+------------------------+
     |Prompt     |Manipulated  | OOB enforce    | N/A                    |
     |Inject     |LLM          |                |                        |
     +-----------+-------------+----------------+------------------------+
     |Data-in-Use|Host OS/     | TEE (Future/   | data-in-use-protection |
     |Exfil      |Hyper        | Opt)           |                        |
     +-----------+-------------+----------------+------------------------+
     |Policy     |Malicious    | Signed Bundles | policy-integrity       |
     |Tampering  |Rules        |                |                        |
     +-----------+-------------+----------------+------------------------+
     |Vulnerable |Compromised  | Signed SBOM    | supply-chain-security  |
     |Agent      |Dep          |                |                        |
     +-----------+-------------+----------------+------------------------+

                                    Table 5

  5.  Privacy Considerations

  5.1.  Inference Isolation

     A unique challenge in agentic security is Fuzzy Search Leakage: an
     agent with authorized access to multiple datasets may combine them in
     its internal memory to draw unauthorized inferences.





  Barney, et al.           Expires 28 August 2026                [Page 25]


  Internet-Draft                    CAAM                     February 2026


     CAAM implements a Contextual Firewall that enforces isolation within
     the agent's reasoning context.  If an agent retrieves data from
     Source A, the sidecar MUST restrict access to Source B for the
     duration of that sub-task if the combination is flagged as a high-
     risk inference vector in the Inference Boundary.

  5.2.  Minimal Disclosure

     Context Providers -- entities that supply environmental, behavioral,
     or relational signals to the CAAM mesh -- MUST adhere to the
     principle of Minimal Disclosure.

  5.2.1.  Coarse-Grained Context by Default

     All context signals MUST be expressed at the coarsest granularity
     sufficient for the authorization decision by default.  The following
     table illustrates the REQUIRED default granularities:

           +==========+===========================+===============+
           | Signal   | Coarse (Default)          | Fine (Opt-in) |
           +==========+===========================+===============+
           | Location | "corporate" / "public"    | Country code  |
           +----------+---------------------------+---------------+
           | Network  | "trusted" / "untrusted"   | CIDR block    |
           +----------+---------------------------+---------------+
           | Time     | "business-hours" / "off"  | ISO 8601      |
           +----------+---------------------------+---------------+
           | Platform | "attested" / "unattested" | PCR values    |
           +----------+---------------------------+---------------+

                                   Table 6

     A Context Provider MUST NOT disclose fine-grained context unless both
     of the following conditions are met:

     1.  The requested OAuth scope explicitly requires the finer
         granularity (e.g., a geofencing scope that specifies country-
         level).

     2.  The current CRS is in the Nominal tier (S < 0.3).  At Elevated or
         Critical CRS, the Verifier MUST reject fine-grained context
         requests and fall back to coarse defaults to reduce the
         information surface.








  Barney, et al.           Expires 28 August 2026                [Page 26]


  Internet-Draft                    CAAM                     February 2026


  5.2.2.  Additional Disclosure Constraints

     *  The SCO's "ctx" claim MUST NOT carry raw sensor data, biometric
        measurements, or personally identifiable information (PII) unless
        the requested scope explicitly requires it and the CRS permits it.

     *  Implementations SHOULD support selective disclosure mechanisms
        (e.g., SD-JWT) to enable verifiers to request only the claims they
        require from the SCO.

     *  When RATS Evidence is included in the SCO, the Verifier SHOULD
        produce an Attestation Result that abstracts the raw Evidence into
        a trust score or categorical assessment, ensuring that detailed
        platform measurements are not propagated beyond the Verifier.

     *  The CAAM mesh MUST NOT log or persist the full contents of the
        "ctx" claim beyond the lifetime of the Contextual Session.
        Implementations SHOULD retain only the CRS value and remediation
        tier for audit purposes.

     The principle of Minimal Disclosure ensures that the CAAM mesh does
     not itself become a vector for privacy leakage by aggregating and
     propagating more context than is necessary for each authorization
     decision.

  6.  IANA Considerations

     This section requests registration of claims, parameters, and a new
     registry with IANA.

  6.1.  JSON Web Token Claims Registration

     This specification defines one new claim for registration in the
     "JSON Web Token Claims" registry established by Section 10.1 of
     RFC7519.

  6.1.1.  Registry Contents

     Claim Name:  ctx

     Claim Description:  CAAM Contextual Assertion.  A JSON object
        containing purpose, scope ceiling, delegation depth, consistency
        token, attestation result reference, and contextual risk score for
        agentic authorization decisions.

     Change Controller:  IETF

     Specification Document(s):  sco-definition of this document



  Barney, et al.           Expires 28 August 2026                [Page 27]


  Internet-Draft                    CAAM                     February 2026


     Claim Value Type:  JSON object

     The "ctx" claim is used within the Session Context Object (SCO)
     defined in sco-definition.  Its value is a JSON object with the
     following members:

     *  "purpose" (string, REQUIRED): Human-readable intent of the agentic
        task.  MUST NOT be modified by intermediate agents.

     *  "scope_ceiling" (array of strings, REQUIRED): Maximum OAuth scope
        derived from the original delegation grant.

     *  "max_hops" (integer, REQUIRED): Remaining delegation depth.
        Decremented by 1 at each hop.

     *  "zookie" (string, OPTIONAL): Consistency token for Knowledge Graph
        queries.

     *  "rats_result" (string, OPTIONAL): URI reference to the Verifier's
        Attestation Result per RFC9334.

     *  "crs" (number, REQUIRED): Contextual Risk Score in the range [0,
        1].

     The following is a non-normative example of the "ctx" claim value:

     {
       "purpose": "Q4 revenue audit",
       "scope_ceiling": [
         "finance:read",
         "crm:read"
       ],
       "max_hops": 3,
       "zookie": "zk_v1_998877",
       "rats_result":
         "https://verifier.corp.internal/abc",
       "crs": 0.22
     }

  6.2.  OAuth Parameters Registration

     IANA is requested to register the following entry in the "OAuth
     Parameters" registry established by RFC 6749:

     Parameter Name:  caam

     Parameter Usage Location:  authorization request, token request




  Barney, et al.           Expires 28 August 2026                [Page 28]


  Internet-Draft                    CAAM                     February 2026


     Change Controller:  IETF

     Specification Document(s):  This document

     The "caam" parameter carries a reference to the Session Context
     Object that MUST be validated by the authorization server before
     issuing tokens in a CAAM-compliant deployment.

  6.3.  OAuth Token Introspection Response

     IANA is requested to register the following entry in the "OAuth Token
     Introspection Response" registry:

     Response Parameter:  ctx

     Change Controller:  IETF

     Specification Document(s):  sco-definition of this document

     When a CAAM-compliant authorization server responds to an
     introspection request for a JIT Scoped Token, it SHOULD include the
     "ctx" claim to enable the Relying Party to perform contextual
     validation.

  6.4.  CAAM Agent Discovery Metadata Registry

     IANA is requested to create a new registry titled "CAAM Agent
     Discovery Security Metadata" under the "CAAM" registry group.

  6.4.1.  Registration Policy

     New entries require Specification Required per RFC 8126.

  6.4.2.  Initial Registry Contents

           +=====================+==================+=============+
           | Attribute           | Description      | Req         |
           +=====================+==================+=============+
           | caam_v1_supported   | CAAM support     | REQUIRED    |
           +---------------------+------------------+-------------+
           | sc_object_hash      | SCO hash         | OPTIONAL    |
           +---------------------+------------------+-------------+
           | inf_boundary_v1     | Inference limits | RECOMMENDED |
           +---------------------+------------------+-------------+
           | authz_policy_uri    | Policy URI       | REQUIRED    |
           +---------------------+------------------+-------------+
           | spiffe_trust_domain | Trust domain     | REQUIRED    |
           +---------------------+------------------+-------------+



  Barney, et al.           Expires 28 August 2026                [Page 29]


  Internet-Draft                    CAAM                     February 2026


           | rats_evidence_type  | Evidence type    | RECOMMENDED |
           +---------------------+------------------+-------------+
           | crs_threshold       | Max CRS w/o MFA  | OPTIONAL    |
           +---------------------+------------------+-------------+
           | max_delegation_hops | Max depth        | RECOMMENDED |
           +---------------------+------------------+-------------+
           | dpop_jwk_uri        | DPoP public key  | REQUIRED    |
           +---------------------+------------------+-------------+

                                   Table 7

  6.4.3.  ARDP Registry Extensions

     Additionally, this document requests the following new attributes for
     the ARDP registry defined by I-D.pioli-agent-discovery:

     *  Policy Compliance Hash: A cryptographic hash of the agent's active
        policy set, allowing clients to verify governance.

     *  Inference Boundary Declaration: A formal specification of the
        agent's semantic limits.

     *  Trust Anchor Reference: A pointer to the authority responsible for
        the agent's identity and behavioral attestation.

  7.  References

  7.1.  Normative References

     [I-D.pioli-agent-discovery]
                Pioli, R., "Agent Registration and Discovery Protocol
                (ARDP)", 2026, <https://datatracker.ietf.org/doc/draft-
                pioli-agent-discovery/>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
                Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
                2015, <https://www.rfc-editor.org/rfc/rfc7515>.

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7519>.





  Barney, et al.           Expires 28 August 2026                [Page 30]


  Internet-Draft                    CAAM                     February 2026


     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
                "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
                May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

     [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
                and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
                DOI 10.17487/RFC8693, January 2020,
                <https://www.rfc-editor.org/rfc/rfc8693>.

     [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, <https://www.rfc-editor.org/rfc/rfc9334>.

     [RFC9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
                Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
                Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
                September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

  7.2.  Informative References

     [CEDAR]    Amazon Web Services, "Cedar Policy Language", n.d.,
                <https://www.cedarpolicy.com/>.

     [HEXA]     "Hexa Policy Orchestrator", n.d.,
                <https://github.com/hexa-org/policy-orchestrator>.

     [IPSIE]    OpenID Foundation, "Interoperability Profiling for Secure
                Identity in the Enterprise", n.d.,
                <https://openid.net/wg/ipsie/>.

     [OPA]      "Open Policy Agent", n.d.,
                <https://www.openpolicyagent.org/>.

     [RFC9635]  Richer, J., Ed. and F. Imbault, "Grant Negotiation and
                Authorization Protocol (GNAP)", RFC 9635,
                DOI 10.17487/RFC9635, October 2024,
                <https://www.rfc-editor.org/rfc/rfc9635>.

     [SPIFFE]   "Secure Production Identity Framework for Everyone", n.d.,
                <https://spiffe.io/>.

     [ZANZIBAR] Pang, R. and R. Lanber, "Zanzibar: Google's Consistent,
                Global Authorization System", USENIX ATC 2019, 2019.



  Barney, et al.           Expires 28 August 2026                [Page 31]


  Internet-Draft                    CAAM                     February 2026


  Appendix A.  Appendix A.  Mathematical Models for Inference Isolation

     Let X be the agent's internal state, S_1 and S_2 be two data sources,
     and B be the inference boundary defined by policy.  The sidecar
     ensures that for any inference I drawn by the agent:

       P(I | S_1, S_2, X) = P(I | Auth(S_1, S_2), X)

     Where the Auth function represents the set of permissible inferences
     under boundary B.  If the combination is unauthorized, the sidecar
     applies a privacy-preserving transformation T such that the mutual
     information within the scratchpad is minimized:

       I(T(S_1); T(S_2)) <= epsilon

     Where epsilon is the privacy budget defined by enterprise policy.

  Appendix B.  Acknowledgments

     The authors thank the IETF community and the contributors to the
     Agent Registration and Discovery Protocol for foundational work that
     informed this specification.

  Appendix C.  Document History

  C.1.  draft-barney-caam-00

     *  Initial submission.

  Authors' Addresses

     Jonathan M. Barney
     Independent
     United States of America
     Email: jonathan.barney@gmail.com
     URI:   https://github.com/jmbarney5/Contextual-Agent-Authorization-
     Mesh


     Roberto Pioli
     Independent
     Italy
     Email: roberto.pioli@gmail.com
     URI:   https://github.com/roberto-pioli/agent-registration-discovery







  Barney, et al.           Expires 28 August 2026                [Page 32]


  Internet-Draft                    CAAM                     February 2026


     Darron Watson
     Independent
     United States of America
     Email: drwatson0874@gmail.com















































  Barney, et al.           Expires 28 August 2026                [Page 33]


name: draft-nennemann-wimse-ect
rev: 00
title: Execution Context Tokens for Distributed Agentic Workflows
time: 2026-02-25T22:56:09Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-29T22:56:09Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-03T15:50:09.773559+00:00
abstract:
  This document defines Execution Context Tokens (ECTs), a JWT-based
     extension to the WIMSE architecture that records task execution
     across distributed agentic workflows.  Each ECT is a signed record of
     a single task, linked to predecessor tasks through a directed acyclic
     graph (DAG).  ECTs reuse the WIMSE signing model and are transported
     in a new Execution-Context HTTP header field alongside existing WIMSE
     identity headers.

full_text:
  WIMSE                                                       C. Nennemann
  Internet-Draft                                    Independent Researcher
  Intended status: Standards Track                        25 February 2026
  Expires: 29 August 2026


         Execution Context Tokens for Distributed Agentic Workflows
                        draft-nennemann-wimse-ect-00

  Abstract

     This document defines Execution Context Tokens (ECTs), a JWT-based
     extension to the WIMSE architecture that records task execution
     across distributed agentic workflows.  Each ECT is a signed record of
     a single task, linked to predecessor tasks through a directed acyclic
     graph (DAG).  ECTs reuse the WIMSE signing model and are transported
     in a new Execution-Context HTTP header field alongside existing WIMSE
     identity headers.

  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 29 August 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.











  Nennemann                Expires 29 August 2026                 [Page 1]


  Internet-Draft           WIMSE Execution Context           February 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
       1.1.  Scope and Applicability . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     3.  Execution Context Token Format  . . . . . . . . . . . . . . .   4
       3.1.  JOSE Header . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.  JWT Claims  . . . . . . . . . . . . . . . . . . . . . . .   5
         3.2.1.  Standard JWT Claims . . . . . . . . . . . . . . . . .   5
         3.2.2.  Execution Context . . . . . . . . . . . . . . . . . .   6
         3.2.3.  Data Integrity  . . . . . . . . . . . . . . . . . . .   6
         3.2.4.  Extensions  . . . . . . . . . . . . . . . . . . . . .   7
       3.3.  Complete ECT Example  . . . . . . . . . . . . . . . . . .   7
     4.  HTTP Header Transport . . . . . . . . . . . . . . . . . . . .   7
       4.1.  Execution-Context Header Field  . . . . . . . . . . . . .   8
     5.  DAG Validation  . . . . . . . . . . . . . . . . . . . . . . .   8
     6.  Signature and Token Verification  . . . . . . . . . . . . . .   9
       6.1.  Verification Procedure  . . . . . . . . . . . . . . . . .   9
     7.  Audit Ledger Interface  . . . . . . . . . . . . . . . . . . .  11
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
       8.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  12
       8.2.  Self-Assertion Limitation . . . . . . . . . . . . . . . .  12
       8.3.  Signature Verification  . . . . . . . . . . . . . . . . .  12
       8.4.  Replay Attack Prevention  . . . . . . . . . . . . . . . .  13
       8.5.  Man-in-the-Middle Protection  . . . . . . . . . . . . . .  13
       8.6.  Key Compromise  . . . . . . . . . . . . . . . . . . . . .  13
       8.7.  Collusion and DAG Integrity . . . . . . . . . . . . . . .  13
       8.8.  Privilege Escalation via ECTs . . . . . . . . . . . . . .  14
       8.9.  Denial of Service . . . . . . . . . . . . . . . . . . . .  14
       8.10. Timestamp Accuracy  . . . . . . . . . . . . . . . . . . .  14
       8.11. ECT Size Constraints  . . . . . . . . . . . . . . . . . .  14
     9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  14
       9.1.  Data Exposure in ECTs . . . . . . . . . . . . . . . . . .  14
       9.2.  Data Minimization . . . . . . . . . . . . . . . . . . . .  15
       9.3.  Storage and Access Control  . . . . . . . . . . . . . . .  15
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
       10.1.  Media Type Registration  . . . . . . . . . . . . . . . .  15
       10.2.  HTTP Header Field Registration . . . . . . . . . . . . .  16
       10.3.  JWT Claims Registration  . . . . . . . . . . . . . . . .  16



  Nennemann                Expires 29 August 2026                 [Page 2]


  Internet-Draft           WIMSE Execution Context           February 2026


     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  17
       11.2.  Informative References . . . . . . . . . . . . . . . . .  18
     Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
       Cross-Organization Financial Trading  . . . . . . . . . . . . .  19
     Related Work  . . . . . . . . . . . . . . . . . . . . . . . . . .  21
       WIMSE Workload Identity . . . . . . . . . . . . . . . . . . . .  21
       OAuth 2.0 Token Exchange and the "act" Claim  . . . . . . . . .  21
       Transaction Tokens  . . . . . . . . . . . . . . . . . . . . . .  21
       Distributed Tracing (OpenTelemetry) . . . . . . . . . . . . . .  22
       W3C Provenance Data Model (PROV)  . . . . . . . . . . . . . . .  22
       SCITT (Supply Chain Integrity, Transparency, and Trust) . . . .  23
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  23
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

  1.  Introduction

     The WIMSE framework [I-D.ietf-wimse-arch] and its service-to- service
     protocol [I-D.ietf-wimse-s2s-protocol] authenticate workloads across
     call chains but do not record what those workloads actually did.
     This document defines Execution Context Tokens (ECTs), a JWT-based
     extension that fills the gap between workload identity and execution
     accountability.  Each ECT is a signed record of a single task, linked
     to predecessor tasks through a directed acyclic graph (DAG).

  1.1.  Scope and Applicability

     This document defines:

     *  The Execution Context Token (ECT) format (Section 3)

     *  DAG structure for task dependency ordering (Section 5)

     *  An HTTP header for ECT transport (Section 4)

     *  Audit ledger interface requirements (Section 7)

     The following are out of scope and are handled by WIMSE:

     *  Workload authentication and identity provisioning

     *  Key distribution and management

     *  Trust domain establishment and management

     *  Credential lifecycle management





  Nennemann                Expires 29 August 2026                 [Page 3]


  Internet-Draft           WIMSE Execution Context           February 2026


  2.  Conventions and Definitions

     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.

     The following terms are used in this document:

     Agent:  An autonomous workload, as defined by WIMSE
        [I-D.ietf-wimse-arch], that executes tasks within a workflow.

     Task:  A discrete unit of agent work that consumes inputs and
        produces outputs.

     Directed Acyclic Graph (DAG):  A graph structure representing task
        dependency ordering where edges are directed and no cycles exist.

     Execution Context Token (ECT):  A JSON Web Token [RFC7519] defined by
        this specification that records task execution details.

     Audit Ledger:  An append-only, immutable log of all ECTs within a
        workflow or set of workflows, used for audit and verification.

     Workload Identity Token (WIT):  A WIMSE credential proving a
        workload's identity within a trust domain.

     Workload Proof Token (WPT):  A WIMSE proof-of-possession token used
        for request-level authentication.

     Trust Domain:  A WIMSE concept representing an organizational
        boundary with a shared identity issuer, corresponding to a SPIFFE
        [SPIFFE] trust domain.

  3.  Execution Context Token Format

     An Execution Context Token is a JSON Web Token (JWT) [RFC7519] signed
     as a JSON Web Signature (JWS) [RFC7515].  ECTs MUST use JWS Compact
     Serialization (the base64url-encoded header.payload.signature format)
     so that they can be carried in a single HTTP header value.










  Nennemann                Expires 29 August 2026                 [Page 4]


  Internet-Draft           WIMSE Execution Context           February 2026


     ECTs reuse the WIMSE signing model.  The ECT MUST be signed with the
     same private key associated with the agent's WIT.  The JOSE header
     "kid" parameter MUST reference the public key identifier from the
     agent's WIT, and the "alg" parameter MUST match the algorithm used in
     the corresponding WIT.  In WIMSE deployments, the ECT "iss" claim
     SHOULD use the WIMSE workload identifier format (a SPIFFE ID
     [SPIFFE]).

  3.1.  JOSE Header

     The ECT JOSE header MUST contain the following parameters:

     {
       "alg": "ES256",
       "typ": "wimse-exec+jwt",
       "kid": "agent-a-key-id-123"
     }

                       Figure 1: ECT JOSE Header Example

     alg:  REQUIRED.  The digital signature algorithm used to sign the
        ECT.  MUST match the algorithm in the corresponding WIT.
        Implementations MUST support ES256 [RFC7518].  The "alg" value
        MUST NOT be "none".  Symmetric algorithms (e.g., HS256, HS384,
        HS512) MUST NOT be used, as ECTs require asymmetric signatures for
        non-repudiation.

     typ:  REQUIRED.  MUST be set to "wimse-exec+jwt" to distinguish ECTs
        from other JWT types, consistent with the WIMSE convention for
        type parameter values.

     kid:  REQUIRED.  The key identifier referencing the public key from
        the agent's WIT [RFC7517].  Used by verifiers to look up the
        correct public key for signature verification.

  3.2.  JWT Claims

  3.2.1.  Standard JWT Claims

     An ECT MUST contain the following standard JWT claims [RFC7519]:

     iss:  REQUIRED.  StringOrURI.  A URI identifying the issuer of the
        ECT.  In WIMSE deployments, this SHOULD be the workload's SPIFFE
        ID in the format spiffe://<trust-domain>/<path>, matching the
        "sub" claim of the agent's WIT.  Non-WIMSE deployments MAY use
        other URI schemes (e.g., HTTPS URLs or URN:UUID identifiers).

     aud:  REQUIRED.  StringOrURI or array of StringOrURI.  The intended



  Nennemann                Expires 29 August 2026                 [Page 5]


  Internet-Draft           WIMSE Execution Context           February 2026


        recipient(s) of the ECT.  The "aud" claim SHOULD contain the
        identifiers of all entities that will verify the ECT.  When an ECT
        must be verified by both the next agent and the audit ledger
        independently, "aud" MUST be an array containing both identifiers.
        Each verifier checks that its own identity appears in "aud".

     iat:  REQUIRED.  NumericDate.  The time at which the ECT was issued.

     exp:  REQUIRED.  NumericDate.  The expiration time of the ECT.
        Implementations SHOULD set this to 5 to 15 minutes after "iat".

     jti:  REQUIRED.  String.  A unique identifier for both the ECT and
        the task it records, in UUID format [RFC9562].  The "jti" serves
        as both the token identifier (for replay detection) and the task
        identifier (for DAG parent references in "par").  Receivers MUST
        reject ECTs whose "jti" has already been seen within the
        expiration window.  When "wid" is present, uniqueness is scoped to
        the workflow; when "wid" is absent, uniqueness MUST be enforced
        globally across the ECT store.

  3.2.2.  Execution Context

     The following claims are defined by this specification:

     wid:  OPTIONAL.  String.  A workflow identifier that groups related
        ECTs into a single workflow.  When present, MUST be a UUID
        [RFC9562].

     exec_act:  REQUIRED.  String.  The action or task type identifier
        describing what the agent performed (e.g., "process_payment",
        "validate_safety").  This claim name avoids collision with the
        "act" (Actor) claim registered by [RFC8693].

     par:  REQUIRED.  Array of strings.  Parent task identifiers
        representing DAG dependencies.  Each element MUST be the "jti"
        value of a previously verified ECT.  An empty array indicates a
        root task with no dependencies.  A workflow MAY contain multiple
        root tasks.

  3.2.3.  Data Integrity

     The following claims provide integrity verification for task inputs
     and outputs without revealing the data itself:

     inp_hash:  OPTIONAL.  String.  The base64url encoding (without






  Nennemann                Expires 29 August 2026                 [Page 6]


  Internet-Draft           WIMSE Execution Context           February 2026


        padding) of the SHA-256 hash of the input data, computed over the
        raw octets of the input.  SHA-256 is the mandatory algorithm with
        no algorithm prefix in the value, consistent with [RFC9449] and
        [I-D.ietf-wimse-s2s-protocol].

     out_hash:  OPTIONAL.  String.  The base64url encoding (without
        padding) of the SHA-256 hash of the output data, using the same
        format as "inp_hash".

  3.2.4.  Extensions

     ext:  OPTIONAL.  Object.  A general-purpose extension object for
        domain-specific claims not defined by this specification.
        Implementations that do not understand extension claims MUST
        ignore them.  Extension key names SHOULD use reverse domain
        notation (e.g., "com.example.custom_field") to avoid collisions.
        The serialized "ext" object SHOULD NOT exceed 4096 bytes and
        SHOULD NOT exceed a nesting depth of 5 levels.

  3.3.  Complete ECT Example

     The following is a complete ECT payload example:

     {
       "iss": "spiffe://example.com/agent/clinical",
       "aud": "spiffe://example.com/agent/safety",
       "iat": 1772064150,
       "exp": 1772064750,
       "jti": "550e8400-e29b-41d4-a716-446655440001",

       "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
       "exec_act": "recommend_treatment",
       "par": [],

       "inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
       "out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",

       "ext": {
         "com.example.trace_id": "abc123"
       }
     }

                     Figure 2: Complete ECT Payload Example

  4.  HTTP Header Transport






  Nennemann                Expires 29 August 2026                 [Page 7]


  Internet-Draft           WIMSE Execution Context           February 2026


  4.1.  Execution-Context Header Field

     This specification defines the Execution-Context HTTP header field
     [RFC9110] for transporting ECTs between agents.

     The header field value is the ECT in JWS Compact Serialization format
     [RFC7515].  The value consists of three Base64url-encoded parts
     separated by period (".") characters.

     An agent sending a request to another agent includes the Execution-
     Context header alongside the WIMSE Workload-Identity header.  When a
     Workload Proof Token (WPT) is available per
     [I-D.ietf-wimse-s2s-protocol], agents SHOULD include it alongside the
     WIT and ECT.

     GET /api/safety-check HTTP/1.1
     Host: safety-agent.example.com
     Workload-Identity: eyJhbGci...WIT...
     Execution-Context: eyJhbGci...ECT...

                     Figure 3: HTTP Request with ECT Header

     When multiple parent tasks contribute context to a single request,
     multiple Execution-Context header field lines MAY be included, each
     carrying a separate ECT in JWS Compact Serialization format.

     When a receiver processes multiple Execution-Context headers, it MUST
     individually verify each ECT per the procedure in Section 6.  If any
     single ECT fails verification, the receiver MUST reject the entire
     request.  The set of verified parent task IDs across all received
     ECTs represents the complete set of parent dependencies available for
     the receiving agent's subsequent ECT.

  5.  DAG Validation

     ECTs form a Directed Acyclic Graph (DAG) where each task references
     its parent tasks via the "par" claim.  DAG validation is performed
     against the ECT store — either an audit ledger or the set of parent
     ECTs received inline.

     When receiving and verifying an ECT, implementations MUST perform the
     following DAG validation steps:

     1.  Task ID Uniqueness: The "jti" claim MUST be unique within the
         applicable scope (the workflow identified by "wid", or the entire
         ECT store if "wid" is absent).  If an ECT with the same "jti"
         already exists, the ECT MUST be rejected.




  Nennemann                Expires 29 August 2026                 [Page 8]


  Internet-Draft           WIMSE Execution Context           February 2026


     2.  Parent Existence: Every task identifier listed in the "par" array
         MUST correspond to a task that is available in the ECT store
         (either previously recorded in the ledger or received inline as a
         verified parent ECT).  If any parent task is not found, the ECT
         MUST be rejected.

     3.  Temporal Ordering: The "iat" value of every parent task MUST NOT
         be greater than the "iat" value of the current task plus a
         configurable clock skew tolerance (RECOMMENDED: 30 seconds).
         That is, for each parent: parent.iat < child.iat +
         clock_skew_tolerance.  The tolerance accounts for clock skew
         between agents; it does not guarantee strict causal ordering from
         timestamps alone.  Causal ordering is primarily enforced by the
         DAG structure (parent existence in the ECT store), not by
         timestamps.  If any parent task violates this constraint, the ECT
         MUST be rejected.

     4.  Acyclicity: Following the chain of parent references MUST NOT
         lead back to the current ECT's "jti".  If a cycle is detected,
         the ECT MUST be rejected.

     5.  Trust Domain Consistency: Parent tasks SHOULD belong to the same
         trust domain or to a trust domain with which a federation
         relationship has been established.

     To prevent denial-of-service via extremely deep or wide DAGs,
     implementations SHOULD enforce a maximum ancestor traversal limit
     (RECOMMENDED: 10000 nodes).  If the limit is reached before cycle
     detection completes, the ECT SHOULD be rejected.

     In distributed deployments, a parent ECT may not yet be available
     locally due to replication lag.  Implementations MAY defer validation
     to allow parent ECTs to arrive, but MUST NOT treat the ECT as
     verified until all parent references are resolved.

  6.  Signature and Token Verification

  6.1.  Verification Procedure

     When an agent receives an ECT, it MUST perform the following
     verification steps in order:

     1.   Parse the JWS Compact Serialization to extract the JOSE header,
          payload, and signature components per [RFC7515].

     2.   Verify that the "typ" header parameter is "wimse-exec+jwt".





  Nennemann                Expires 29 August 2026                 [Page 9]


  Internet-Draft           WIMSE Execution Context           February 2026


     3.   Verify that the "alg" header parameter appears in the verifier's
          configured allowlist of accepted signing algorithms.  The
          allowlist MUST NOT include "none" or any symmetric algorithm
          (e.g., HS256, HS384, HS512).  Implementations MUST include ES256
          in the allowlist; additional asymmetric algorithms MAY be
          included per deployment policy.

     4.   Verify the "kid" header parameter references a known, valid
          public key from a WIT within the trust domain.

     5.   Retrieve the public key identified by "kid" and verify the JWS
          signature per [RFC7515] Section 5.2.

     6.   Verify that the signing key identified by "kid" has not been
          revoked within the trust domain.  Implementations MUST check the
          key's revocation status using the trust domain's key lifecycle
          mechanism (e.g., certificate revocation list, OCSP, or SPIFFE
          trust bundle updates).

     7.   Verify the "alg" header parameter matches the algorithm in the
          corresponding WIT.

     8.   Verify the "iss" claim matches the "sub" claim of the WIT
          associated with the "kid" public key.

     9.   Verify the "aud" claim contains the verifier's own workload
          identity.  When "aud" is an array, it is sufficient that the
          verifier's identity appears as one element; the presence of
          other audience values does not cause verification failure.  When
          the verifier is the audit ledger, the ledger's own identity MUST
          appear in "aud".

     10.  Verify the "exp" claim indicates the ECT has not expired.

     11.  Verify the "iat" claim is not unreasonably far in the past
          (implementation-specific threshold, RECOMMENDED maximum of 15
          minutes) and is not unreasonably far in the future (RECOMMENDED:
          no more than 30 seconds ahead of the verifier's current time, to
          account for clock skew).

     12.  Verify all required claims ("jti", "exec_act", "par") are
          present and well-formed.

     13.  Perform DAG validation per Section 5.

     14.  If all checks pass and an audit ledger is deployed, the ECT
          SHOULD be appended to the ledger.




  Nennemann                Expires 29 August 2026                [Page 10]


  Internet-Draft           WIMSE Execution Context           February 2026


     If any verification step fails, the ECT MUST be rejected and the
     failure MUST be logged for audit purposes.  Error messages SHOULD NOT
     reveal whether specific parent task IDs exist in the ECT store, to
     prevent information disclosure.

     When ECT verification fails during HTTP request processing, the
     receiving agent SHOULD respond with HTTP 403 (Forbidden) if the WIT
     is valid but the ECT is invalid, and HTTP 401 (Unauthorized) if the
     ECT signature verification fails.  The response body SHOULD include a
     generic error indicator without revealing which specific verification
     step failed.  The receiving agent MUST NOT process the requested
     action when ECT verification fails.

  7.  Audit Ledger Interface

     ECTs MAY be recorded in an immutable audit ledger for compliance
     verification and post-hoc analysis.  A ledger is RECOMMENDED for
     regulated environments but is not required for point-to-point
     operation.  This specification does not mandate a specific storage
     technology.  Implementations MAY use append-only logs, databases with
     cryptographic commitment schemes, distributed ledgers, or any storage
     mechanism that provides the required properties.

     When an audit ledger is deployed, the implementation MUST provide:

     1.  Append-only semantics: Once an ECT is recorded, it MUST NOT be
         modified or deleted.

     2.  Ordering: The ledger MUST maintain a total ordering of ECT
         entries via a monotonically increasing sequence number.

     3.  Lookup by ECT ID: The ledger MUST support efficient retrieval of
         ECT entries by "jti" value.

     4.  Integrity verification: The ledger SHOULD provide a mechanism to
         verify that no entries have been tampered with (e.g., hash chains
         or Merkle trees).

     The ledger SHOULD be maintained by an entity independent of the
     workflow agents to reduce the risk of collusion.

  8.  Security Considerations









  Nennemann                Expires 29 August 2026                [Page 11]


  Internet-Draft           WIMSE Execution Context           February 2026


  8.1.  Threat Model

     The threat model considers: (1) a malicious agent that creates false
     ECT claims, (2) an agent whose private key has been compromised, (3)
     a ledger tamperer attempting to modify recorded entries, and (4) a
     time manipulator altering timestamps to affect perceived ordering.

  8.2.  Self-Assertion Limitation

     ECTs are self-asserted by the executing agent.  The agent claims what
     it did, and this claim is signed with its private key.  A compromised
     or malicious agent could create ECTs with false claims (e.g.,
     claiming an action was performed when it was not).

     ECTs do not independently verify that:

     *  The claimed execution actually occurred as described

     *  The input/output hashes correspond to the actual data processed

     *  The agent faithfully performed the stated action

     The trustworthiness of ECT claims depends on the trustworthiness of
     the signing agent and the integrity of the broader deployment
     environment.  ECTs provide a technical mechanism for execution
     recording; they do not by themselves satisfy any specific regulatory
     compliance requirement.

  8.3.  Signature Verification

     ECTs MUST be signed with the agent's private key using JWS [RFC7515].
     The signature algorithm MUST match the algorithm specified in the
     agent's WIT.  Receivers MUST verify the ECT signature against the WIT
     public key before processing any claims.  Receivers MUST verify that
     the signing key has not been revoked within the trust domain (see
     step 6 in Section 6).

     If signature verification fails or if the signing key has been
     revoked, the ECT MUST be rejected entirely and the failure MUST be
     logged.

     Implementations MUST use established JWS libraries and MUST NOT
     implement custom signature verification.








  Nennemann                Expires 29 August 2026                [Page 12]


  Internet-Draft           WIMSE Execution Context           February 2026


  8.4.  Replay Attack Prevention

     ECTs include short expiration times (RECOMMENDED: 5-15 minutes) and
     audience restriction via "aud" to limit replay attacks.
     Implementations MUST maintain a cache of recently-seen "jti" values
     and MUST reject ECTs with duplicate "jti" values.  Each ECT is
     cryptographically bound to the issuing agent via "kid"; verifiers
     MUST confirm that "kid" resolves to the "iss" agent's key (step 8 in
     Section 6).

  8.5.  Man-in-the-Middle Protection

     ECTs MUST be transmitted over TLS or mTLS connections.  When used
     with [I-D.ietf-wimse-s2s-protocol], transport security is already
     established.

  8.6.  Key Compromise

     If an agent's private key is compromised, an attacker can forge ECTs
     that appear to originate from that agent.  Mitigations:

     *  Implementations SHOULD use short-lived keys and rotate them
        frequently.

     *  Private keys SHOULD be stored in hardware security modules or
        equivalent secure key storage.

     *  Trust domains MUST support rapid key revocation.

     ECTs recorded before key revocation remain valid historical records
     but SHOULD be flagged for audit purposes.  New ECTs MUST NOT
     reference a parent ECT whose signing key is known to be revoked at
     creation time.

  8.7.  Collusion and DAG Integrity

     A single malicious agent cannot forge parent task references because
     DAG validation requires parent tasks to exist in the ECT store.
     However, multiple colluding agents could create a false execution
     history.  Additionally, a malicious agent may omit actual parent
     dependencies from "par" to hide influences on its output; because
     ECTs are self-asserted (Section 8.2), no mechanism can force complete
     dependency declaration.

     Mitigations include:

     *  The ledger SHOULD be maintained by an entity independent of the
        workflow agents.



  Nennemann                Expires 29 August 2026                [Page 13]


  Internet-Draft           WIMSE Execution Context           February 2026


     *  Multiple independent ledger replicas can be compared for
        consistency.

     *  External auditors can compare the declared DAG against expected
        workflow patterns.

     Verifiers SHOULD validate that the declared "wid" of parent ECTs
     matches the "wid" of the child ECT, rejecting cross-workflow parent
     references unless explicitly permitted by deployment policy.

  8.8.  Privilege Escalation via ECTs

     ECTs record execution history; they do not convey authorization.
     Verifiers MUST NOT interpret the presence of an ECT, or a particular
     set of parent references in "par", as an authorization grant.
     Authorization decisions MUST remain with the identity and
     authorization layer (WIT, WPT, and deployment policy).

  8.9.  Denial of Service

     Implementations SHOULD apply rate limiting to prevent excessive ECT
     submissions.  DAG validation SHOULD be performed after signature
     verification to avoid wasting resources on unsigned tokens.

  8.10.  Timestamp Accuracy

     Implementations SHOULD use synchronized time sources (e.g., NTP) and
     SHOULD allow a configurable clock skew tolerance (RECOMMENDED: 30
     seconds).  Cross-organizational deployments MAY require a higher
     tolerance and SHOULD document the configured value.

  8.11.  ECT Size Constraints

     Implementations SHOULD limit the "par" array to a maximum of 256
     entries.  See Section 3.2.4 for "ext" size limits.

  9.  Privacy Considerations

  9.1.  Data Exposure in ECTs

     ECTs necessarily reveal:

     *  Agent identities ("iss", "aud") for accountability purposes

     *  Action descriptions ("exec_act") for audit trail completeness

     *  Timestamps ("iat", "exp") for temporal ordering




  Nennemann                Expires 29 August 2026                [Page 14]


  Internet-Draft           WIMSE Execution Context           February 2026


     ECTs are designed to NOT reveal:

     *  Actual input or output data values (replaced with cryptographic
        hashes via "inp_hash" and "out_hash")

     *  Internal computation details or intermediate steps

     *  Proprietary algorithms or intellectual property

     *  Personally identifiable information (PII)

  9.2.  Data Minimization

     Implementations SHOULD minimize the information included in ECTs.
     The "exec_act" claim SHOULD use structured identifiers (e.g.,
     "process_payment") rather than natural language descriptions.
     Extension keys in "ext" (Section 3.2.4) deserve particular attention:
     human-readable values risk exposing sensitive operational details.
     See Section 3.2.4 for guidance on using structured identifiers.

  9.3.  Storage and Access Control

     ECTs stored in audit ledgers SHOULD be access-controlled so that only
     authorized auditors can read them.  Implementations SHOULD consider
     encryption at rest for ledger storage.  ECTs provide structural
     records of execution ordering; they are not intended for public
     disclosure.

     Full input and output data (corresponding to the hashes in ECTs)
     SHOULD be stored separately from the ledger with additional access
     controls, since auditors may need to verify hash correctness but
     general access to the data values is not needed.

  10.  IANA Considerations

  10.1.  Media Type Registration

     This document requests registration of the following media type in
     the "Media Types" registry maintained by IANA:

     Type name:  application

     Subtype name:  wimse-exec+jwt

     Required parameters:  none

     Optional parameters:  none




  Nennemann                Expires 29 August 2026                [Page 15]


  Internet-Draft           WIMSE Execution Context           February 2026


     Encoding considerations:  8bit; an ECT is a JWT that is a JWS using
        the Compact Serialization, which is a sequence of Base64url-
        encoded values separated by period characters.

     Security considerations:  See the Security Considerations section of
        this document.

     Interoperability considerations:  none

     Published specification:  This document

     Applications that use this media type:  Applications that implement
        agentic workflows requiring execution context tracing and audit
        trails.

     Additional information:  Magic number(s): none File extension(s):
        none Macintosh file type code(s): none

     Person and email address to contact for further information:  Christi
        an Nennemann, ietf@nennemann.de

     Intended usage:  COMMON

     Restrictions on usage:  none

     Author:  Christian Nennemann

     Change controller:  IETF

  10.2.  HTTP Header Field Registration

     This document requests registration of the following header field in
     the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
     maintained by IANA:

     Field name:  Execution-Context

     Status:  permanent

     Specification document:  This document, Section 4

  10.3.  JWT Claims Registration

     This document requests registration of the following claims in the
     "JSON Web Token Claims" registry maintained by IANA:






  Nennemann                Expires 29 August 2026                [Page 16]


  Internet-Draft           WIMSE Execution Context           February 2026


     +============+=====================+===================+===========+
     | Claim Name | Claim Description   | Change Controller | Reference |
     +============+=====================+===================+===========+
     |    wid     | Workflow Identifier |        IETF       |  Section  |
     |            |                     |                   |   3.2.2   |
     +------------+---------------------+-------------------+-----------+
     |  exec_act  | Action/Task Type    |        IETF       |  Section  |
     |            |                     |                   |   3.2.2   |
     +------------+---------------------+-------------------+-----------+
     |    par     | Parent Task         |        IETF       |  Section  |
     |            | Identifiers         |                   |   3.2.2   |
     +------------+---------------------+-------------------+-----------+
     |  inp_hash  | Input Data Hash     |        IETF       |  Section  |
     |            |                     |                   |   3.2.3   |
     +------------+---------------------+-------------------+-----------+
     |  out_hash  | Output Data Hash    |        IETF       |  Section  |
     |            |                     |                   |   3.2.3   |
     +------------+---------------------+-------------------+-----------+
     |    ext     | Extension Object    |        IETF       |  Section  |
     |            |                     |                   |   3.2.4   |
     +------------+---------------------+-------------------+-----------+

                      Table 1: JWT Claims Registrations

  11.  References

  11.1.  Normative References

     [I-D.ietf-wimse-arch]
                Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
                "Workload Identity in a Multi System Environment (WIMSE)
                Architecture", Work in Progress, Internet-Draft, draft-
                ietf-wimse-arch-06, 30 September 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
                arch-06>.

     [I-D.ietf-wimse-s2s-protocol]
                Campbell, B., Salowey, J. A., Schwenkschuster, A., and Y.
                Sheffer, "WIMSE Workload-to-Workload Authentication", Work
                in Progress, Internet-Draft, draft-ietf-wimse-s2s-
                protocol-07, 16 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
                s2s-protocol-07>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.



  Nennemann                Expires 29 August 2026                [Page 17]


  Internet-Draft           WIMSE Execution Context           February 2026


     [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
                Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
                2015, <https://www.rfc-editor.org/rfc/rfc7515>.

     [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
                DOI 10.17487/RFC7517, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7517>.

     [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
                DOI 10.17487/RFC7518, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7518>.

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7519>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

     [RFC9562]  Davis, K., Peabody, B., and P. Leach, "Universally Unique
                IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
                2024, <https://www.rfc-editor.org/rfc/rfc9562>.

  11.2.  Informative References

     [I-D.ietf-oauth-transaction-tokens]
                Tulshibagwale, A., Fletcher, G., and P. Kasselman,
                "Transaction Tokens", Work in Progress, Internet-Draft,
                draft-ietf-oauth-transaction-tokens-07, 24 January 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
                transaction-tokens-07>.

     [I-D.ietf-scitt-architecture]
                Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
                Y., and S. Lasker, "An Architecture for Trustworthy and
                Transparent Digital Supply Chains", Work in Progress,
                Internet-Draft, draft-ietf-scitt-architecture-22, 10
                October 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-scitt-architecture-22>.






  Nennemann                Expires 29 August 2026                [Page 18]


  Internet-Draft           WIMSE Execution Context           February 2026


     [I-D.oauth-transaction-tokens-for-agents]
                Raut, A., "Transaction Tokens For Agents", Work in
                Progress, Internet-Draft, draft-oauth-transaction-tokens-
                for-agents-04, 10 February 2026,
                <https://datatracker.ietf.org/doc/html/draft-oauth-
                transaction-tokens-for-agents-04>.

     [OPENTELEMETRY]
                Cloud Native Computing Foundation, "OpenTelemetry
                Specification",
                <https://opentelemetry.io/docs/specs/otel/>.

     [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
                and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
                DOI 10.17487/RFC8693, January 2020,
                <https://www.rfc-editor.org/rfc/rfc8693>.

     [RFC9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
                Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
                Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
                September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

     [SPIFFE]   "Secure Production Identity Framework for Everyone
                (SPIFFE)",
                <https://spiffe.io/docs/latest/spiffe-about/overview/>.

  Use Cases

     This section describes a representative use case demonstrating how
     ECTs provide structured execution records.

     Note: task identifiers in this section are abbreviated for
     readability.  In production, all "jti" values are required to be
     UUIDs per Section 3.2.2.

  Cross-Organization Financial Trading

     In a cross-organization trading workflow, an investment bank's agents
     coordinate with an external credit rating agency.  The agents operate
     in separate trust domains with a federation relationship.  The DAG
     records that independent assessments from both organizations were
     completed before trade execution.









  Nennemann                Expires 29 August 2026                [Page 19]


  Internet-Draft           WIMSE Execution Context           February 2026


     Trust Domain: bank.example
       Agent A1 (Portfolio Risk):
         jti: task-001    par: []
         iss: spiffe://bank.example/agent/risk
         exec_act: analyze_portfolio_risk

     Trust Domain: ratings.example (external)
       Agent B1 (Credit Rating):
         jti: task-002    par: []
         iss: spiffe://ratings.example/agent/credit
         exec_act: assess_credit_rating

     Trust Domain: bank.example
       Agent A2 (Compliance):
         jti: task-003    par: [task-001, task-002]
         iss: spiffe://bank.example/agent/compliance
         exec_act: verify_trade_compliance

       Agent A3 (Execution):
         jti: task-004    par: [task-003]
         iss: spiffe://bank.example/agent/execution
         exec_act: execute_trade

                 Figure 4: Cross-Organization Trading Workflow

     The resulting DAG:

     task-001 (analyze_portfolio_risk)   task-002 (assess_credit_rating)
       [bank.example]                      [ratings.example]
               \                              /
                v                            v
              task-003 (verify_trade_compliance)
                [bank.example]
                         |
                         v
              task-004 (execute_trade)
                [bank.example]

                        Figure 5: Cross-Organization DAG

     Task 003 has two parents from different trust domains, demonstrating
     cross-organizational fan-in.  The compliance agent verifies both
     parent ECTs — one signed by a local key and one by a federated key
     from the rating agency's trust domain.







  Nennemann                Expires 29 August 2026                [Page 20]


  Internet-Draft           WIMSE Execution Context           February 2026


  Related Work

  WIMSE Workload Identity

     The WIMSE architecture [I-D.ietf-wimse-arch] and service-to- service
     protocol [I-D.ietf-wimse-s2s-protocol] provide the identity
     foundation upon which ECTs are built.  WIT/WPT answer "who is this
     agent?" and "does it control the claimed key?" while ECTs record
     "what did this agent do?"  Together they form an identity-plus-
     accountability framework for regulated agentic systems.

  OAuth 2.0 Token Exchange and the "act" Claim

     [RFC8693] defines the OAuth 2.0 Token Exchange protocol and registers
     the "act" (Actor) claim in the JWT Claims registry.  The "act" claim
     creates nested JSON objects representing a delegation chain: "who is
     acting on behalf of whom."  While the nesting superficially resembles
     a chain, it is strictly linear (each "act" object contains at most
     one nested "act"), represents authorization delegation rather than
     task execution, and carries no task identifiers or input/output
     integrity data.  The "act" chain cannot represent branching (fan-out)
     or convergence (fan-in) and therefore cannot form a DAG.

     ECTs intentionally use the distinct claim name "exec_act" for the
     action/task type to avoid collision with the "act" claim.  The two
     concepts are orthogonal: "act" records "who authorized whom," ECTs
     record "what was done, in what order."

  Transaction Tokens

     OAuth Transaction Tokens [I-D.ietf-oauth-transaction-tokens]
     propagate authorization context across workload call chains.  The
     Txn-Token "req_wl" claim accumulates a comma-separated list of
     workloads that requested replacement tokens, which is the closest
     existing mechanism to call-chain recording.

     However, "req_wl" cannot form a DAG because:

     *  It is linear: a comma-separated string with no branching or
        merging representation.  When a workload fans out to multiple
        downstream services, each receives the same "req_wl" value and the
        branching is invisible.

     *  It is incomplete: only workloads that request a replacement token
        from the Transaction Token Service appear in "req_wl"; workloads
        that forward the token unchanged are not recorded.





  Nennemann                Expires 29 August 2026                [Page 21]


  Internet-Draft           WIMSE Execution Context           February 2026


     *  It carries no task-level granularity, no parent references, and no
        execution content.

     *  It cannot represent convergence (fan-in): when two independent
        paths must both complete before a dependent task proceeds, a
        linear "req_wl" string cannot express that relationship.

     Extensions for agentic use cases
     ([I-D.oauth-transaction-tokens-for-agents]) add agent identity and
     constraints ("agentic_ctx") but no execution ordering or DAG
     structure.

     ECTs and Transaction Tokens are complementary: a Txn-Token propagates
     authorization context ("this request is authorized for scope X on
     behalf of user Y"), while an ECT records execution accountability
     ("task T was performed, depending on tasks P1 and P2").  An agent
     request could carry both a Txn-Token for authorization and an ECT for
     execution recording.  The WPT "tth" claim defined in
     [I-D.ietf-wimse-s2s-protocol] can hash-bind a WPT to a co-present
     Txn-Token; a similar binding mechanism for ECTs is a potential future
     extension.

  Distributed Tracing (OpenTelemetry)

     OpenTelemetry [OPENTELEMETRY] and similar distributed tracing systems
     provide observability for debugging and monitoring.  ECTs differ in
     several important ways: ECTs are cryptographically signed per-task
     with the agent's private key; ECTs are tamper-evident through JWS
     signatures; ECTs enforce DAG validation rules; and ECTs are designed
     for regulatory audit rather than operational monitoring.
     OpenTelemetry data is typically controlled by the platform operator
     and can be modified or deleted without detection.  ECTs and
     distributed traces are complementary: traces provide observability
     while ECTs provide signed execution records.  ECTs may reference
     OpenTelemetry trace identifiers in the "ext" claim for correlation.

  W3C Provenance Data Model (PROV)

     The W3C PROV Data Model defines an Entity-Activity-Agent ontology for
     representing provenance information.  PROV's concepts map closely to
     ECT structures: PROV Activities correspond to ECT tasks, PROV Agents
     correspond to WIMSE workloads, and PROV's "wasInformedBy" relation
     corresponds to ECT "par" references.  However, PROV uses RDF/OWL
     ontologies designed for post-hoc documentation, while ECTs are
     runtime-embeddable JWT tokens with cryptographic signatures.  ECT
     audit data could be exported to PROV format for interoperability with
     provenance-aware systems.




  Nennemann                Expires 29 August 2026                [Page 22]


  Internet-Draft           WIMSE Execution Context           February 2026


  SCITT (Supply Chain Integrity, Transparency, and Trust)

     The SCITT architecture [I-D.ietf-scitt-architecture] defines a
     framework for transparent and auditable supply chain records.  ECTs
     and SCITT are complementary: the ECT "wid" claim can serve as a
     correlation identifier in SCITT Signed Statements, linking an ECT
     audit trail to a supply chain transparency record.

  Acknowledgments

     The author thanks the WIMSE working group for their foundational work
     on workload identity in multi-system environments.  The concepts of
     Workload Identity Tokens and Workload Proof Tokens provide the
     identity foundation upon which execution context tracing is built.

  Author's Address

     Christian Nennemann
     Independent Researcher
     Email: ietf@nennemann.de































  Nennemann                Expires 29 August 2026                [Page 23]


name: draft-mw-spice-actor-chain
rev: 00
title: Cryptographically Verifiable Actor Chain for OAuth 2.0 Token Exchange
time: 2026-02-26T03:12:31Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-30T03:12:31Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:06.864929+00:00
abstract:
  This document defines an extension to OAuth 2.0 Token Exchange
     [[RFC8693]] that addresses the problem of *Delegation Auditability
     Gaps* in multi-hop service environments.  Current standards treat
     prior actors in a delegation chain as "informational only," providing
     no cryptographic proof of the actual delegation path.  This document
     proposes a new actor_chain claim — a *Cryptographically Verifiable
     Actor Chain* — that replaces the informational-only nested act claim
     with a tamper-evident, ordered record of all actors.  This solution
     enables high-assurance data-plane policy enforcement and forensic
     auditability, particularly for dynamic AI agent-to-agent
     workloads—where susceptibility to *prompt injection attacks* can lead
     to unauthorized delegation paths — the security posture of the entire
     delegation chain is critical for authorization decisions.

full_text:
  SPICE                                                          A. Prasad
  Internet-Draft                                                    Oracle
  Intended status: Informational                               R. Krishnan
  Expires: 29 August 2026                              JPMorgan Chase & Co
                                                                  D. Lopez
                                                                Telefonica
                                                              S. Addepalli
                                                                    Aryaka
                                                          25 February 2026


   Cryptographically Verifiable Actor Chain for OAuth 2.0 Token Exchange
                       draft-mw-spice-actor-chain-00

  Abstract

     This document defines an extension to OAuth 2.0 Token Exchange
     [[RFC8693]] that addresses the problem of *Delegation Auditability
     Gaps* in multi-hop service environments.  Current standards treat
     prior actors in a delegation chain as "informational only," providing
     no cryptographic proof of the actual delegation path.  This document
     proposes a new actor_chain claim — a *Cryptographically Verifiable
     Actor Chain* — that replaces the informational-only nested act claim
     with a tamper-evident, ordered record of all actors.  This solution
     enables high-assurance data-plane policy enforcement and forensic
     auditability, particularly for dynamic AI agent-to-agent
     workloads—where susceptibility to *prompt injection attacks* can lead
     to unauthorized delegation paths — the security posture of the entire
     delegation chain is critical for authorization decisions.

  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 29 August 2026.





  Prasad, et al.           Expires 29 August 2026                 [Page 1]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 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
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  The Problem: RFC 8693 Actor Limitations . . . . . . . . . . .   5
       3.1.  Single-Actor Semantics  . . . . . . . . . . . . . . . . .   5
       3.2.  AI Agent Delegation Chains  . . . . . . . . . . . . . . .   5
       3.3.  Structural Limitations of Nested act  . . . . . . . . . .   5
         3.3.1.  Selective Disclosure (SD-JWT) . . . . . . . . . . . .   6
     4.  The Solution: The Cryptographically Verifiable actor_chain
             Claim . . . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.  Claim Definition  . . . . . . . . . . . . . . . . . . . .   6
       4.3.  Example Tokens  . . . . . . . . . . . . . . . . . . . . .   8
         4.3.1.  AS-Attested Mode  . . . . . . . . . . . . . . . . . .   8
         4.3.2.  Self-Attested Mode  . . . . . . . . . . . . . . . . .   9
       4.4.  Token Exchange Flow . . . . . . . . . . . . . . . . . . .  10
         4.4.1.  Disclosure Propagation in SD-JWT  . . . . . . . . . .  11
         4.4.2.  When Chain Signatures Are Produced  . . . . . . . . .  11
       4.5.  Data-Plane Policy Enforcement . . . . . . . . . . . . . .  12
         4.5.1.  Policy Examples . . . . . . . . . . . . . . . . . . .  13
         4.5.2.  Integration with Data-Plane Proxies . . . . . . . . .  13
     5.  Chain Integrity Verification  . . . . . . . . . . . . . . . .  14
     6.  Relation to Other IETF Work . . . . . . . . . . . . . . . . .  14
       6.1.  East-West vs. North-South Security  . . . . . . . . . . .  16
       6.2.  Backward Compatibility with RFC 8693  . . . . . . . . . .  16
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
       7.1.  Token Signature vs. Per-Entry Chain Signatures  . . . . .  16
       7.2.  Chain Integrity . . . . . . . . . . . . . . . . . . . . .  17
       7.3.  Replay Protection . . . . . . . . . . . . . . . . . . . .  18
       7.4.  Chain Depth Limits  . . . . . . . . . . . . . . . . . . .  18
       7.5.  Key Management  . . . . . . . . . . . . . . . . . . . . .  18
       7.6.  Privacy of Prior Actors . . . . . . . . . . . . . . . . .  18
         7.6.1.  Pseudonymous Identifiers  . . . . . . . . . . . . . .  19



  Prasad, et al.           Expires 29 August 2026                 [Page 2]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


         7.6.2.  Selective Disclosure (SD-JWT) . . . . . . . . . . . .  19
         7.6.3.  Identity Bridging for Anonymity . . . . . . . . . . .  19
         7.6.4.  Targeted Selective Disclosure . . . . . . . . . . . .  19
         7.6.5.  Encryption (JWE)  . . . . . . . . . . . . . . . . . .  20
       7.7.  Confused Deputy Mitigation  . . . . . . . . . . . . . . .  20
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
       8.1.  JSON Web Token Claims Registration  . . . . . . . . . . .  20
       8.2.  CBOR Web Token Claims Registration  . . . . . . . . . . .  20
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

  1.  Introduction

     This document defines an extension to OAuth 2.0 Token Exchange
     [[RFC8693]] to support high-assurance *East-West* identity delegation
     through cryptographically verifiable actor chains.

     In modern multi-service and AI-agent environments, a workload often
     delegates its authority to another agent, which may in turn delegate
     to others.  While [[RFC8693]] provides the act (actor) claim to
     represent delegation, it explicitly restricts prior actors in a
     nested chain to be "informational only," excluding them from access
     control considerations.  This creates a significant *Delegation
     Auditability Gap*: Resource Servers cannot verify the full path of
     authority, and attackers can potentially hide lateral movement or
     *prompt injection-induced hijacking* within unverified informational
     claims.

     By providing a standardized *Cryptographically Verifiable Actor
     Chain*, this extension replaces the informal nested act structure
     with a policy-enforceable, ordered, and tamper-evident record of all
     participants.  This establishes an *"East-West"* axis of
     accountability, ensuring that any service in a global delegation
     chain can be verified for identity, integrity, and (optionally)
     physical residency.

     This solution addresses several critical gaps in [[RFC8693]]:

     1.  *Cryptographic Audit Trail*: Proves that each prior actor
         actually participated in the delegation chain and that the
         sequence has not been tampered with.
     2.  *Data-Plane Policy Enforcement*: Enables Resource Servers to
         write fine-grained authorization policies based on any actor in
         the path (e.g., "originating actor must be X").
     3.  *Dynamic AI Agent Topologies*: Provides a scalable architecture
         for the unpredictable and deep delegation chains common in
         autonomous agent networks.





  Prasad, et al.           Expires 29 August 2026                 [Page 3]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


     4.  *Data-Plane Efficiency*: Uses a flat, ordered array structure
         optimized for high-throughput parsing and indexing in cloud-
         native proxies (e.g., Envoy).

     This extension is designed to be backward-compatible and format-
     agnostic, supporting both JSON/JWS (JWT [[RFC7519]]) and CBOR/COSE
     (CWT [[RFC8392]]) representations.

  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.

     This document leverages the terminology defined in OAuth 2.0 Token
     Exchange [[RFC8693]], the SPICE Architecture [[!I-D.ietf-spice-
     arch]], and the RATS Architecture [[RFC9334]].

     Actor Chain:  A Cryptographically Verifiable Actor Chain — an ordered
        sequence of Actor Chain Entries representing the complete
        delegation path from the originating actor to the current actor.
        The chain is integrity-protected either by the AS's JWT signature
        (AS-Attested Mode) or by per-actor cryptographic signatures (Self-
        Attested Mode).
     Actor Chain Entry:  A JSON object or CBOR map identifying a single
        actor in the delegation chain, including its identity claims and a
        cryptographic signature binding it to the chain state at the point
        of its participation.
     Chain Digest:  A cumulative cryptographic hash computed over the
        delegation history.  For any entry at index N, the chain_digest is
        computed over the concatenation of the current entry's identity
        claims and the chain_digest of the preceding entry (at index N-1).
        For the entry at index 0, the digest is computed over that entry's
        identity claims alone.  Each actor produces a per-actor signature
        over its chain_digest, cryptographically anchoring itself to the
        entire preceding history.
     Chain Depth:  The total number of Actor Chain Entries in an actor
        chain.  Used by policy engines to enforce maximum delegation
        depth.
     Proof of Residency (PoR):  A cryptographic proof (as defined in [[!I-
        D.draft-mw-spice-transitive-attestation]]) binding a workload to a
        specific, verified local environment.  When present in an Actor
        Chain Entry, it provides hardware-rooted assurance of the actor's
        execution context.





  Prasad, et al.           Expires 29 August 2026                 [Page 4]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


  3.  The Problem: RFC 8693 Actor Limitations

  3.1.  Single-Actor Semantics

     [[RFC8693]] Section 4.1 defines the act claim as a JSON object
     identifying *the* current actor.  While nesting is permitted to
     represent prior actors, the specification explicitly limits their
     utility.  Only the outermost act claim—representing the current
     actor—is relevant for access control.  All prior actors exist solely
     for informational purposes.

     This design was appropriate for traditional web service delegation
     where chains are short (typically one or two hops) and the identity
     of the immediate caller is sufficient for authorization.  It is
     insufficient for the emerging class of workloads described below.

  3.2.  AI Agent Delegation Chains

     Modern AI systems increasingly operate as networks of specialized
     agents.  A typical interaction may involve:

    User -> Orchestrator Agent -> Planning Agent -> Tool Agent -> Data API

     At each hop, the agent performs a token exchange ([[RFC8693]]) to
     obtain credentials appropriate for calling the next service.  Under
     current [[RFC8693]] semantics, by the time the request reaches the
     Data API, only the Tool Agent is identified as the actor.  The
     Orchestrator Agent and Planning Agent—which may have been manipulated
     via *prompt injection* into delegating authority they should not
     have—are invisible to policy enforcement.

     This creates several concrete risks:

     *  *Lateral Movement*: A compromised agent deep in the chain can
        impersonate the authority of the originating actor without any
        cryptographic evidence of the actual delegation path.
     *  *Policy Bypass*: Fine-grained policies like "only allow data
        access when the orchestrator is a known, trusted entity" cannot be
        expressed because the orchestrator's identity is not available for
        policy evaluation at the data plane.
     *  *Audit Gaps*: Post-incident forensic analysis cannot reliably
        reconstruct the delegation path because the nested act claims are
        self-reported and unsigned.

  3.3.  Structural Limitations of Nested act

     Beyond the semantic restriction, the nested object structure of act
     in [[RFC8693]] has practical limitations:



  Prasad, et al.           Expires 29 August 2026                 [Page 5]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


     1.  *Parsing Complexity*: Each prior actor requires traversing one
         additional level of JSON nesting.  In high-throughput data-plane
         proxies (e.g., Envoy, Istio sidecars), deep nesting imposes
         parsing overhead.
     2.  *Indexing*: It is not possible to efficiently query "the actor at
         position N" without recursively unwinding the nested structure.
     3.  *Size Predictability*: The depth of nesting is unbounded, making
         it difficult to predict token sizes and allocate parsing buffers.
     4.  *No Integrity*: Each nested act is a plain JSON object with no
         signature or hash binding.  Any intermediary could insert,
         remove, or reorder prior actors without detection.

  3.3.1.  Selective Disclosure (SD-JWT)

  4.  The Solution: The Cryptographically Verifiable actor_chain Claim

  4.1.  Overview

     This document defines a new claim, actor_chain, that provides a
     Cryptographically Verifiable Actor Chain.  When used in a JWT, its
     value is a JSON array of Actor Chain Entries.  When used in a CWT,
     its value is a CBOR array of Actor Chain Entries.  The array is
     ordered chronologically: index 0 represents the originating actor,
     and the last index represents the current actor.

     The actor_chain claim supports two operational modes:

     1.  *AS-Attested Mode*: The Authorization Server (AS) validates each
         actor at token exchange time and constructs the actor_chain.  The
         AS's signature over the entire token (JWS or COSE) provides
         integrity protection for the chain.  Per-actor chain_sig fields
         are omitted.

     2.  *Self-Attested Mode*: Each Actor Chain Entry additionally
         includes a chain_sig field: a cryptographic signature (compact
         JWS [[RFC7515]] or COSE_Sign1 [[RFC9052]]) computed by that actor
         over a Chain Digest of all preceding entries.  This creates a
         hash-chain structure providing tamper evidence and non-
         repudiation independent of the AS.

  4.2.  Claim Definition

     The actor_chain claim is a JSON array.  Each element of the array is
     a JSON object (an Actor Chain Entry) with the following members.  To
     support diverse privacy requirements, Selective Disclosure (SD-JWT)
     is configurable at two levels of granularity: - *Per-Actor*: An
     Authorization Server MAY choose to hide entire Actor Chain Entries or
     only specific actors in the chain. - *Per-Field*: Within a single



  Prasad, et al.           Expires 29 August 2026                 [Page 6]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


     Actor Chain Entry, a subset of members (e.g., sub) MAY be hidden
     using an _sd claim while others (e.g., iat or por) remain in
     cleartext.  These fields typically correspond to the identity claims
     present in the *Actor Token* or client credentials used during the
     token exchange flow.

     sub:  REQUIRED (or selectively disclosed).  A string identifying the
        actor, as defined in [[RFC7519]] Section 4.1.2.
     iss:  REQUIRED (or selectively disclosed).  A string identifying the
        issuer of the actor's identity, as defined in [[RFC7519]]
        Section 4.1.1.
     iat:  REQUIRED (or selectively disclosed).  The time at which this
        actor was appended to the chain, represented as a NumericDate as
        defined in [[RFC7519]] Section 4.1.6.
     por:  OPTIONAL.  A JSON object containing a Proof of Residency
        binding this actor to a verified execution environment.  The
        structure of this object is defined in [[!I-D.draft-mw-spice-
        transitive-attestation]].
     chain_digest:  OPTIONAL.  A Base64url-encoded cumulative
        cryptographic hash (SHA-256).  For any entry at index N, the hash
        is computed over the canonical serialization of the union of the
        current entry's identity claims (e.g., sub, iss, iat, _sd hashes)
        and the chain_digest of the preceding entry (index N-1).  For the
        entry at index 0, the hash is computed over its identity claims
        alone.  This recursive structure ensures that a chain_sig at any
        point in the chain provides proof of participation for all prior
        actors.  REQUIRED in Self-Attested Mode.  MUST be omitted in AS-
        Attested Mode.

     |  [!IMPORTANT] When Selective Disclosure is used, the SD-JWT
     |  *Disclosure strings* (the cleartext salts/values) MUST NOT be
     |  included in the canonical serialization used for hashing.  The
     |  chain_digest is computed exclusively over the Actor Chain Entry
     |  object, which contains the stable _sd hashes.  This ensures the
     |  signature remains valid regardless of which disclosures are
     |  subsequently provided to different recipients.

     chain_sig:  OPTIONAL.  A compact JWS [[RFC7515]] signature produced
        by this actor's private key over the chain_digest value.  The JWS
        header MUST include the jwk or kid member to identify the signing
        key.  REQUIRED in Self-Attested Mode.  MUST be omitted in AS-
        Attested Mode.
     chain_mode:  OPTIONAL.  A top-level string claim (sibling to
        actor_chain) indicating the operational mode.  Values are
        as_attested or self_attested.  If omitted, the mode is inferred
        from the presence or absence of chain_sig fields in the Actor
        Chain Entries.




  Prasad, et al.           Expires 29 August 2026                 [Page 7]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


  4.3.  Example Tokens

  4.3.1.  AS-Attested Mode

     In this mode, the AS constructs the actor_chain array and the JWT's
     own signature provides integrity.  No per-entry chain_sig or
     chain_digest fields are present.  This is the simplest deployment
     model.

     {
       "aud": "https://data-api.example.com",
       "iss": "https://auth.example.com",
       "exp": 1700000100,
       "nbf": 1700000000,
       "sub": "user@example.com",
       "actor_chain": [
         {
           "sub": "https://orchestrator.example.com",
           "iss": "https://auth.example.com",
           "iat": 1700000010,
           "por": {
             "wia_kid": "spiffe://example.com/wia/node-1",
             "env_hash": "sha256:abc123..."
           }
         },
         {
           "sub": "https://planner.example.com",
           "iss": "https://auth.example.com",
           "iat": 1700000030
         },
         {
           "sub": "https://tool-agent.example.com",
           "iss": "https://auth.example.com",
           "iat": 1700000050,
           "por": {
             "wia_kid": "spiffe://example.com/wia/node-3",
             "env_hash": "sha256:ghi789..."
           }
         }
       ]
     }

     The integrity of the chain rests on the AS's JWT signature.  The
     Relying Party trusts the AS to have correctly validated each actor at
     the time of each token exchange.






  Prasad, et al.           Expires 29 August 2026                 [Page 8]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


  4.3.2.  Self-Attested Mode

     In this mode, each Actor Chain Entry additionally carries a
     chain_digest and chain_sig, forming a hash chain with per-actor non-
     repudiation.  This mode is appropriate for federated deployments,
     multi-AS environments, or when Relying Parties require cryptographic
     proof of each actor's participation independent of any single AS.

     {
       "aud": "https://data-api.example.com",
       "iss": "https://auth.example.com",
       "exp": 1700000100,
       "nbf": 1700000000,
       "sub": "user@example.com",
       "actor_chain": [
         {
           "sub": "https://orchestrator.example.com",
           "iss": "https://auth.example.com",
           "iat": 1700000010,
           "por": {
             "wia_kid": "spiffe://example.com/wia/node-1",
             "env_hash": "sha256:abc123..."
           },
           "chain_digest": "sha256:mno345...",
           "chain_sig": "eyJhbGciOiJFUzI1NiIsImt..."
         },
         {
           "sub": "https://planner.example.com",
           "iss": "https://auth.example.com",
           "iat": 1700000030,
           "chain_digest": "sha256:def456...",
           "chain_sig": "eyJhbGciOiJFUzI1NiIsImt..."
         },
         {
           "sub": "https://tool-agent.example.com",
           "iss": "https://auth.example.com",
           "iat": 1700000050,
           "por": {
             "wia_kid": "spiffe://example.com/wia/node-3",
             "env_hash": "sha256:ghi789..."
           },
           "chain_digest": "sha256:jkl012...",
           "chain_sig": "eyJhbGciOiJFUzI1NiIsImt..."
         }
       ]
     }

     In the Self-Attested example:



  Prasad, et al.           Expires 29 August 2026                 [Page 9]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


     *  *Index 0* (Orchestrator): The originating actor.  Its chain_digest
        is SHA-256(canonical_json({sub, iss, iat})) — a self-hash of its
        own identity claims.  Its chain_sig is computed over this digest.
        It includes a PoR binding it to node-1.
     *  *Index 1* (Planning Agent): Its chain_digest is SHA-
        256(canonical_json(actor_chain[0])).  Its chain_sig is produced by
        the Planning Agent's key over this digest.  No PoR is present (the
        agent may be running in a non-TEE environment).
     *  *Index 2* (Tool Agent): Its chain_digest is SHA-
        256(canonical_json(actor_chain[0..1])).  Its chain_sig is produced
        by the Tool Agent's key over this digest.  It includes a PoR for
        node-3.

  4.4.  Token Exchange Flow

     When an actor (Service B) receives a token containing an actor_chain
     and needs to call a downstream service (Service C), the following
     token exchange flow occurs:

     1.  *Service B* sends a token exchange request to the Authorization
         Server (AS) per [[RFC8693]] Section 2.1.
     2.  The subject_token contains the existing actor_chain.
     3.  The actor_token identifies Service B.
     4.  The AS validates the existing actor_chain:
         *  In Self-Attested Mode: verifies each chain_sig against the
            corresponding actor's public key and each chain_digest against
            the hash of preceding entries.
         *  In AS-Attested Mode: verifies the JWT signature and validates
            the actor identities through its own policy (e.g., client
            registration, mTLS certificate).
         *  In both modes: enforces any max_chain_depth policy.
     5.  The AS constructs a new actor_chain for the issued token by:
         *  Copying all existing Actor Chain Entries from the
            subject_token.
         *  Appending a new Actor Chain Entry for Service B.
         *  In Self-Attested Mode: the new entry's chain_digest is
            computed over all preceding entries, and its chain_sig is
            produced by Service B's key (provided via the actor_token or
            client credentials).
         *  In AS-Attested Mode: the new entry contains only the identity
            claims (sub, iss, iat) and optional por.
     6.  The AS issues a new token with the extended actor_chain.









  Prasad, et al.           Expires 29 August 2026                [Page 10]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


  4.4.1.  Disclosure Propagation in SD-JWT

     When Selective Disclosure (SD-JWT) [[!I-D.ietf-oauth-selective-
     disclosure-jwt]] is used for any Actor Chain Entry, the Authorization
     Server (AS) acts as the Discloser during token exchange.  The
     propagation of the underlying cleartext identities is managed as
     follows:

     1.  *Disclosure Inclusion*: When the AS issues a token for a
         downstream recipient (Service B), it determines based on policy
         which hidden identifiers in the actor_chain should be visible to
         that recipient.  For each visible actor, the AS appends the
         corresponding SD-JWT Disclosure string (containing the salt and
         cleartext value) to the issued token.
     2.  *Hop-by-Hop Visibility*: In a chain a -> b -> c -> d -> e, if a
         is to be visible to b, c, and d, the AS includes a's disclosure
         string in the tokens issued to b, c, and d during their
         respective token exchanges.
     3.  *Selective Redaction*: When the final exchange occurs for
         recipient e (the end of the trust zone), the AS simply omits the
         disclosure string for a from the issued token.
     4.  *Validation*: Each recipient in the chain can independently
         verify the hash of any disclosed claim against the _sd array in
         the Actor Chain Entry.  If a disclosure is missing, the recipient
         sees only the hash, but can still verify the entry's geographic
         and residency properties through other claims.

     This mechanism ensures that the "key" to unlock a hidden identity is
     passed only to authorized actors in the chain, while the underlying
     cryptographically signed JWT structure remains identical for all
     recipients.

  4.4.2.  When Chain Signatures Are Produced

     In Self-Attested Mode, a critical distinction is that each actor's
     chain_sig is produced *during the token exchange request*, before the
     final issued token exists.  Consider a scenario where Service A calls
     Service B, and Service B later needs to call Service C:

     1.  Service A calls Service B, presenting a token containing
         actor_chain with chain [A].
     2.  Service B receives the token and performs its work.
     3.  *When Service B needs to call downstream Service C*, it initiates
         a token exchange with the AS.  At this point — not before —
         Service B:
         *  Computes chain_digest over the existing chain entries from the
            received token.
         *  Signs this chain_digest with its own key, producing chain_sig.



  Prasad, et al.           Expires 29 August 2026                [Page 11]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


         *  Submits both values to the AS as part of the token exchange
            request, alongside the subject_token (containing chain [A])
            and its own actor_token.
     4.  The AS validates the existing chain, then assembles the new
         actor_chain (prior entries + Service B's signed entry) into the
         issued JWT.
     5.  The AS signs the *entire JWT* (including the actor_chain) with
         the AS's own key and returns the token to Service B.
     6.  Service B uses this new token (containing chain [A, B]) to call
         Service C.

     Consequently, each chain_sig covers only the *actor chain state* at
     that actor's point of participation — not the enclosing JWT's other
     claims such as aud, exp, or sub.  This is by design: the actor chain
     and the token are concerns of different parties.  The actor signs the
     chain to prove its participation; the AS signs the token to assert
     the token's validity.  This separation allows the AS to set audience,
     expiry, and other claims independently without invalidating any
     actor's chain signature.

       Svc A        Auth Server        Svc B        Svc C
         |               |               |             |
         |-- token ------>|               |             |
         |  (chain=[A])   |               |             |
         |               |-- issued tok ->|             |
         |               |  (chain=[A])   |             |
         |               |               |             |
         |               |<- exchange req-|             |
         |               |  subj_tok:     |             |
         |               |   chain=[A]    |             |
         |               |  actor_tok=B   |             |
         |               |               |             |
         |               |-- issued tok ->|             |
         |               |  (chain=[A,B]) |             |
         |               |               |             |
         |               |               |-- request ->|
         |               |               | token has   |
         |               |               | chain=[A,B] |

  4.5.  Data-Plane Policy Enforcement

     Unlike the nested act claim in [[RFC8693]], the actor_chain claim is
     explicitly designed to be used in access control decisions.  Resource
     Servers and data-plane proxies MAY apply authorization policies based
     on any entry in the actor chain.






  Prasad, et al.           Expires 29 August 2026                [Page 12]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


  4.5.1.  Policy Examples

     The following are illustrative examples of policies that become
     expressible with the actor_chain claim:

     *Origin-Based Policy*: Allow access only if the originating actor
     (index 0) is a trusted orchestrator:

     actor_chain[0].sub == "https://orchestrator.example.com"

     *Domain Restriction*: Deny access if any actor in the chain belongs
     to an untrusted domain:

     for_all(entry in actor_chain):
       entry.iss in ["https://auth.example.com",
                      "https://auth.partner.com"]

     *Chain Depth Limit*: Reject tokens with delegation chains longer than
     a configured maximum:

     len(actor_chain) <= 5

     *Residency Requirement*: Require that all actors in the chain have a
     valid Proof of Residency:

     for_all(entry in actor_chain):
       entry.por is present AND entry.por is valid

     *Path-Based Policy*: Allow access only through a specific delegation
     path:

     actor_chain[0].sub == "https://orchestrator.example.com" AND
     actor_chain[1].sub == "https://planner.example.com"

  4.5.2.  Integration with Data-Plane Proxies

     The flat array structure of actor_chain is designed for efficient
     processing by data-plane proxies such as Envoy, Istio sidecars, and
     API gateways.  Proxies can:

     1.  Extract the actor_chain array from the JWT payload with a single
         JSON path expression.
     2.  Iterate linearly over the entries without recursive descent.
     3.  Index specific entries by position (e.g., actor_chain[0] for the
         originator).
     4.  Compute len(actor_chain) for depth-based policies without parsing
         nested structures.




  Prasad, et al.           Expires 29 August 2026                [Page 13]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


     5.  Emit structured log entries per Actor Chain Entry for distributed
         tracing and forensic analysis.

  5.  Chain Integrity Verification

     A Relying Party receiving a token with the actor_chain claim MUST
     perform the following verification steps:

     1.  *JWT Signature Verification*: Verify the outer JWT signature per
         standard JWT processing rules.  This is REQUIRED in both modes
         and provides baseline integrity for the entire token, including
         the actor_chain.

     2.  *Structural Validation*: Verify that actor_chain is a JSON array
         with at least one element.  Verify that each element contains the
         required identity fields (sub, iss, iat).

     3.  *Per-Entry Signature Verification* (Self-Attested Mode only).
         For each entry at index i:

         *  *Compute expected digest*: If i == 0, compute expected_digest
            = SHA-256(canonical_json({sub, iss, iat})) from the entry's
            own identity claims.  If i > 0, compute expected_digest = SHA-
            256(canonical_json(actor_chain[0..i-1])).
         *  *Verify chain_digest*: Confirm that the entry's chain_digest
            matches expected_digest.
         *  *Verify chain_sig*: Verify chain_sig against chain_digest
            using the actor's public key.

     4.  *PoR Verification* (if present):

         *  Verify each PoR assertion according to [[!I-D.draft-mw-spice-
            transitive-attestation]].

     5.  *Policy Evaluation*:

         *  Apply local authorization policy against the verified actor
            chain.

     If any verification step fails, the Relying Party MUST reject the
     token.

  6.  Relation to Other IETF Work

     This proposal extends and complements several ongoing efforts:






  Prasad, et al.           Expires 29 August 2026                [Page 14]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


     +================+=================================================+
     | Specification  | Relationship                                    |
     +================+=================================================+
     | *RFC 8693*     | This document extends [[RFC8693]] by defining   |
     | [[RFC8693]]    | actor_chain as a replacement for the            |
     |                | informational-only nested act claim.  The       |
     |                | actor_chain claim is backward-compatible: an AS |
     |                | MAY populate both act (for legacy consumers)    |
     |                | and actor_chain (for chain-aware consumers).    |
     +----------------+-------------------------------------------------+
     | *Transitive    | Provides the "North-South" residency proof      |
     | Attestation*   | (agent to local WIA) that complements the       |
     | [[!I-D.draft-  | "East-West" delegation proof (agent to actor-   |
     | mw-spice-      | chain) provided by this document.               |
     | transitive-    |                                                 |
     | attestation]]  |                                                 |
     +----------------+-------------------------------------------------+
     | *SPICE         | Defines the overarching workload identity       |
     | Architecture*  | architecture within which this extension        |
     | [[!I-D.ietf-   | operates.                                       |
     | spice-arch]]   |                                                 |
     +----------------+-------------------------------------------------+
     | *WIMSE         | This proposal aligns with the WIMSE delegation  |
     | Architecture*  | and impersonation patterns for distributed      |
     | [[!I-D.ietf-   | microservices architectures.                    |
     | wimse-arch]]   |                                                 |
     +----------------+-------------------------------------------------+
     | *Attestation-  | Provides the client-to-AS attestation mechanism |
     | Based Auth*    | that can be leveraged to populate the hardware- |
     | [[!I-D.ietf-   | rooted por claims in Actor Chain Entries.       |
     | oauth-         |                                                 |
     | attestation-   |                                                 |
     | based-client-  |                                                 |
     | auth]]         |                                                 |
     +----------------+-------------------------------------------------+
     | *SCITT* [[!I-  | Verifiable actor chains can be recorded in      |
     | D.ietf-scitt-  | SCITT transparency logs to provide long-term,   |
     | architecture]] | tamper-proof auditability of delegation paths.  |
     +----------------+-------------------------------------------------+
     | *RATS*         | Provides the attestation foundation for PoR     |
     | [[RFC9334]]    | assertions embedded in Actor Chain Entries.     |
     +----------------+-------------------------------------------------+
     | *DPoP*         | actor_chain complements DPoP by providing       |
     | [[RFC9449]]    | delegation-chain context alongside proof-of-    |
     |                | possession.                                     |
     +----------------+-------------------------------------------------+

                                   Table 1



  Prasad, et al.           Expires 29 August 2026                [Page 15]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


  6.1.  East-West vs. North-South Security

     This specification addresses the *East-West* axis of agent-to-agent
     communication, providing a cryptographically verifiable trail of
     identity delegation across a network of services.  In contrast,
     Transitive Attestation [[!I-D.draft-mw-spice-transitive-attestation]]
     addresses the *North-South* axis of an agent's relationship with its
     local hosting environment (e.g., a Workload Identity Agent on a TEE-
     enabled node).

     By embedding "North-South" Proofs of Residency (PoR) within "East-
     West" Actor Chain Entries, a Relying Party gains end-to-end assurance
     that every entity in a global delegation chain is both a recognized
     identity and is executing within a verified, secure environment.

  6.2.  Backward Compatibility with RFC 8693

     An Authorization Server implementing this extension SHOULD populate
     both the act claim (per [[RFC8693]] Section 4.1) and the actor_chain
     claim in issued tokens.  This ensures that:

     *  *Legacy consumers* that understand only act continue to function
        correctly, seeing the current actor in the top-level act claim.
     *  *Chain-aware consumers* can use actor_chain for fine-grained
        policy enforcement and audit.

     The act claim, when present alongside actor_chain, MUST identify the
     same entity as the last entry in the actor_chain array.

  7.  Security Considerations

  7.1.  Token Signature vs. Per-Entry Chain Signatures

     A natural question arises: since the JWT containing the actor_chain
     is already signed by the Authorization Server (AS), is per-entry
     chain_sig redundant?

     The answer depends on what each signature proves and when it is
     produced:

     *  The *JWT outer signature* is produced by the AS when the final
        token is issued.  It proves that the AS issued this specific token
        with this specific payload.  It covers the entire token: sub, aud,
        exp, actor_chain, and all other claims.







  Prasad, et al.           Expires 29 August 2026                [Page 16]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


     *  Each *chain_sig* is produced by an individual actor during token
        exchange, before the final token exists (see Section "When Chain
        Signatures Are Produced").  It covers only the chain_digest—the
        hash of the actor chain state at that actor's point of
        participation.  It proves that this specific actor participated in
        this specific chain.

     The JWT outer signature does NOT prove that each individual actor
     actually participated in the delegation.  A compromised or malicious
     AS could construct any chain it desires.  The two modes address
     different trust assumptions:

     *  *AS-Attested Mode* is appropriate when all participants trust the
        AS to faithfully record the chain.  The AS validates each actor at
        exchange time, and its JWT signature provides integrity.  This is
        the common single-organization deployment where the AS is a
        trusted internal service (e.g., a corporate identity provider).
        Per-actor signatures are omitted, keeping token sizes smaller and
        reducing cryptographic overhead.

     *  *Self-Attested Mode* is appropriate when the chain crosses trust
        boundaries or when stronger guarantees are needed:

        -  *Federated/Multi-AS environments*: The token may be issued by
           AS-1 but consumed by a Relying Party that trusts AS-2.  Per-
           actor signatures allow the RP to verify actor participation
           independently of the issuing AS.
        -  *Non-repudiation*: Each actor's signature provides
           cryptographic evidence that it participated in the
           chain—evidence that the actor cannot deny and that the AS
           cannot fabricate.
        -  *Zero-trust posture*: In adversarial environments, the Relying
           Party may not fully trust any single AS.  Per-actor signatures
           provide defense-in-depth.
        -  *Forensic analysis*: Post-breach investigations can verify the
           chain using each actor's public key, independent of the AS's
           continued availability or trustworthiness.

     Deployments SHOULD select the mode that matches their trust model.
     An AS MAY enforce a specific mode via policy.

  7.2.  Chain Integrity

     In AS-Attested Mode, chain integrity is provided by the JWT outer
     signature.  The Relying Party trusts the AS to have correctly
     constructed the chain.





  Prasad, et al.           Expires 29 August 2026                [Page 17]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


     In Self-Attested Mode, the hash-chain structure provides additional
     tamper evidence.  Insertion, deletion, or reordering of entries
     invalidates the chain_digest and chain_sig fields of all subsequent
     entries.  An attacker who compromises a single actor in the chain
     cannot retroactively alter the entries of prior actors without
     possessing their signing keys.

  7.3.  Replay Protection

     Each Actor Chain Entry includes an iat (issued-at) timestamp.
     Relying Parties SHOULD enforce a maximum age on Actor Chain Entries
     to prevent replay of stale chains.  Additionally, the standard JWT
     claims exp and nbf on the enclosing token provide overall token-level
     freshness.

  7.4.  Chain Depth Limits

     Unbounded actor chains pose a risk of token size explosion and
     processing overhead.  Authorization Servers SHOULD enforce a
     configurable maximum chain depth (max_chain_depth).  A RECOMMENDED
     default maximum is 10 entries.  Relying Parties MAY independently
     enforce their own chain depth limits.

  7.5.  Key Management

     Each actor in the chain signs its entry with its own key.  The
     security of the entire chain depends on the security of each actor's
     key material.  Actors SHOULD use short-lived keys and/or hardware-
     protected keys (e.g., via the PoR mechanism).  The use of PoR in
     Actor Chain Entries provides additional assurance that the signing
     key is bound to a verified execution environment.

  7.6.  Privacy of Prior Actors

     The actor_chain expose the identities of all actors in the delegation
     path to every Relying Party that receives the token.  While this is
     necessary for certain audit and policy requirements, it may conflict
     with privacy goals.  For example, in a chain a -> b -> c -> d -> e,
     the originating actor a may require its identity to be hidden from e
     while still ensuring the integrity of the delegation.

     Deployments SHOULD consider the following anonymization and privacy-
     preserving techniques:








  Prasad, et al.           Expires 29 August 2026                [Page 18]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


  7.6.1.  Pseudonymous Identifiers

     Instead of using globally unique or stable identifiers (like email
     addresses or client IDs), the Authorization Server (AS) can issue
     pairwise pseudonyms for actors.  In the chain a -> b -> c -> d -> e:
     - The AS replaces sub: "a" with a pseudonym sub: "pseudo-xyz" that is
     only meaningful to the AS. - Relying Party e sees that the chain
     started with a verified actor, but does not know it was a. - The AS
     maintains a mapping to allow for forensic reconstruction if
     authorized.

  7.6.2.  Selective Disclosure (SD-JWT)

     The actor_chain MAY be implemented using Selective Disclosure for
     JWTs [[!I-D.ietf-oauth-selective-disclosure-jwt]].  This allows
     individual Actor Chain Entries to be hashed with unique salts,
     enabling verification of the entry's integrity without revealing its
     cleartext content unless a corresponding disclosure is provided.

  7.6.3.  Identity Bridging for Anonymity

     An Identity Bridge [[!I-D.ietf-spice-arch]] MAY act as an
     "Anonymizer" by performing a token exchange that replaces sensitive
     predecessor entries in the actor_chain with generic or pseudonymous
     identifiers, while still vouching for the chain's security
     properties.

  7.6.4.  Targeted Selective Disclosure

     A more advanced privacy model involves disclosing actor identities
     only to trusted intermediate parties.  In the chain a -> b -> c -> d
     -> e, actor a may be visible to b, c, and d, but hidden from e.

     This is achieved through *Targeted Disclosure* using SD-JWT: - The AS
     generates the actor_chain with actor a's identity hashed and salted.
     - Alongside the JWT, the AS provides a "Disclosure" string (the salt
     and cleartext value) for actor a. - When the AS issues a token for b,
     c, or d, it includes this disclosure string.  This allows these
     "internal" actors to "unlock" the hash and see a's true identity. -
     When the final token is exchanged for recipient e, the AS (or the
     last internal actor d) simply omits the disclosure string for actor
     a. - Actor e receives the same JWT but without the "key" to unlock a.
     e can verify the cryptographic integrity of the entire chain (proving
     that a verified, though anonymous, actor started it) without ever
     seeing a's identity.






  Prasad, et al.           Expires 29 August 2026                [Page 19]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


     +===========+===============+======================+================+
     | Recipient | JWT Payload   | Disclosure provided? | Interpretation |
     +===========+===============+======================+================+
     | *Actor b* | _sd:          | *Yes*                | b sees sub: a  |
     |           | [hash_a]      |                      |                |
     +-----------+---------------+----------------------+----------------+
     | *Actor e* | _sd:          | *No*                 | e sees sub:    |
     |           | [hash_a]      |                      | <hidden>       |
     +-----------+---------------+----------------------+----------------+

                                    Table 2

  7.6.5.  Encryption (JWE)

     The entire actor_chain claim can be encrypted using JWE [[RFC7516]]
     so that only the final intended audience e can decrypt it, preventing
     intermediate actors like b, c, and d from seeing the IDs of their
     predecessors.  Alternatively, the chain can be nestedly encrypted for
     different parties in the path.

  7.7.  Confused Deputy Mitigation

     In both modes, a confused deputy attack—where a legitimate actor is
     tricked into delegating to a malicious downstream—is detectable
     because the malicious downstream actor's identity appears in the
     chain, providing forensic evidence of the attack path.  In Self-
     Attested Mode, the malicious actor's own cryptographic signature
     provides non-repudiable evidence of its participation.

  8.  IANA Considerations

  8.1.  JSON Web Token Claims Registration

     This document requests registration of the following claim in the
     "JSON Web Token Claims" registry established by [[RFC7519]]:

     *  *Claim Name*: actor_chain
     *  *Claim Description*: A Cryptographically Verifiable Actor Chain —
        an ordered array of actor entries representing the complete
        delegation chain with optional per-entry cryptographic signatures.
     *  *Change Controller*: IETF
     *  *Specification Document(s)*: [this document]

  8.2.  CBOR Web Token Claims Registration

     This document requests registration of the following claim in the
     "CBOR Web Token (CWT) Claims" registry established by [[RFC8392]]:




  Prasad, et al.           Expires 29 August 2026                [Page 20]


  Internet-Draft              SPICE-ACTOR-CHAIN              February 2026


     *  *Claim Name*: actor_chain
     *  *Claim Description*: A Cryptographically Verifiable Actor Chain.
     *  *CBOR Key*: TBD (e.g., 40)
     *  *Claim Type*: array
     *  *Change Controller*: IETF
     *  *Specification Document(s)*: [this document]

  Authors' Addresses

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


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


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


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
























  Prasad, et al.           Expires 29 August 2026                [Page 21]


name: draft-bradleylundberg-cfrg-arkg
rev: 10
title: The Asynchronous Remote Key Generation (ARKG) algorithm
time: 2026-02-27T15:32:37Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-31T15:32:37Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:06.864933+00:00
abstract:
  Asynchronous Remote Key Generation (ARKG) is an abstract algorithm
     that enables delegation of asymmetric public key generation without
     giving access to the corresponding private keys.  This capability
     enables a variety of applications: a user agent can generate
     pseudonymous public keys to prevent tracking; a message sender can
     generate ephemeral recipient public keys to enhance forward secrecy;
     two paired authentication devices can each have their own private
     keys while each can register public keys on behalf of the other.

     This document provides three main contributions: a specification of
     the generic ARKG algorithm using abstract primitives; a set of
     formulae for instantiating the abstract primitives using concrete
     primitives; and an initial set of fully specified concrete ARKG
     instances.  We expect that additional instances will be defined in
     the future.

full_text:
  Crypto Forum                                            E. Lundberg, Ed.
  Internet-Draft                                                J. Bradley
  Intended status: Informational                                    Yubico
  Expires: 31 August 2026                                 27 February 2026


          The Asynchronous Remote Key Generation (ARKG) algorithm
                     draft-bradleylundberg-cfrg-arkg-10

  Abstract

     Asynchronous Remote Key Generation (ARKG) is an abstract algorithm
     that enables delegation of asymmetric public key generation without
     giving access to the corresponding private keys.  This capability
     enables a variety of applications: a user agent can generate
     pseudonymous public keys to prevent tracking; a message sender can
     generate ephemeral recipient public keys to enhance forward secrecy;
     two paired authentication devices can each have their own private
     keys while each can register public keys on behalf of the other.

     This document provides three main contributions: a specification of
     the generic ARKG algorithm using abstract primitives; a set of
     formulae for instantiating the abstract primitives using concrete
     primitives; and an initial set of fully specified concrete ARKG
     instances.  We expect that additional instances will be defined in
     the future.

  About This Document

     This note is to be removed before publishing as an RFC.

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-bradleylundberg-cfrg-arkg/.

     Source for this draft and an issue tracker can be found at
     https://github.com/Yubico/arkg-rfc.

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





  Lundberg & Bradley       Expires 31 August 2026                 [Page 1]


  Internet-Draft                    ARKG                     February 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 31 August 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.  Requirements Language . . . . . . . . . . . . . . . . . .   5
       1.2.  Notation  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.  The Asynchronous Remote Key Generation (ARKG) algorithm . . .   5
       2.1.  Instance parameters . . . . . . . . . . . . . . . . . . .   6
       2.2.  The function ARKG-Derive-Seed . . . . . . . . . . . . . .   8
         2.2.1.  Nondeterministic variants . . . . . . . . . . . . . .   9
       2.3.  The function ARKG-Derive-Public-Key . . . . . . . . . . .   9
         2.3.1.  Nondeterministic variants . . . . . . . . . . . . . .  10
       2.4.  The function ARKG-Derive-Private-Key  . . . . . . . . . .  11
       2.5.  Using ctx values longer than 64 bytes . . . . . . . . . .  12
     3.  Generic ARKG instantiations . . . . . . . . . . . . . . . . .  12
       3.1.  Using elliptic curve addition for key blinding  . . . . .  12
       3.2.  Using HMAC to adapt a KEM without ciphertext integrity  .  14
       3.3.  Using ECDH as the KEM . . . . . . . . . . . . . . . . . .  16
       3.4.  Using X25519 or X448 as the KEM . . . . . . . . . . . . .  17
       3.5.  Using the same key for both key blinding and KEM  . . . .  18
     4.  Concrete ARKG instantiations  . . . . . . . . . . . . . . . .  19
       4.1.  ARKG-P256 . . . . . . . . . . . . . . . . . . . . . . . .  19
       4.2.  ARKG-P384 . . . . . . . . . . . . . . . . . . . . . . . .  19
       4.3.  ARKG-P521 . . . . . . . . . . . . . . . . . . . . . . . .  20
       4.4.  ARKG-P256k  . . . . . . . . . . . . . . . . . . . . . . .  20
     5.  COSE bindings . . . . . . . . . . . . . . . . . . . . . . . .  21
       5.1.  COSE key type: ARKG public seed . . . . . . . . . . . . .  21
       5.2.  COSE algorithms . . . . . . . . . . . . . . . . . . . . .  23



  Lundberg & Bradley       Expires 31 August 2026                 [Page 2]


  Internet-Draft                    ARKG                     February 2026


       5.3.  COSE signing arguments  . . . . . . . . . . . . . . . . .  25
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
     7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  27
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
       8.1.  COSE Key Types Registrations  . . . . . . . . . . . . . .  27
       8.2.  COSE Key Type Parameters Registrations  . . . . . . . . .  27
       8.3.  COSE Algorithms Registrations . . . . . . . . . . . . . .  28
       8.4.  COSE Signing Arguments Algorithm Parameters
             Registrations . . . . . . . . . . . . . . . . . . . . . .  30
     9.  Design rationale  . . . . . . . . . . . . . . . . . . . . . .  31
       9.1.  Using a MAC . . . . . . . . . . . . . . . . . . . . . . .  31
     10. Implementation Status . . . . . . . . . . . . . . . . . . . .  32
       10.1.  Related Internet-Drafts  . . . . . . . . . . . . . . . .  34
       10.2.  Future Work  . . . . . . . . . . . . . . . . . . . . . .  35
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  35
       11.2.  Informative References . . . . . . . . . . . . . . . . .  37
     Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .  38
       A.1.  ARKG-P256 . . . . . . . . . . . . . . . . . . . . . . . .  38
       A.2.  Other instances . . . . . . . . . . . . . . . . . . . . .  41
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  42
     Document History  . . . . . . . . . . . . . . . . . . . . . . . .  42
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  46
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  46

  1.  Introduction

     Asynchronous Remote Key Generation (ARKG) introduces a mechanism to
     generate public keys without access to the corresponding private
     keys.  Such a mechanism is useful for many scenarios when a new
     public key is needed but the private key holder is not available to
     perform the key generation.  This may occur when private keys are
     stored in a hardware security device, which may be unavailable or
     locked at the time a new public key is needed.

     Some motivating use cases of ARKG include:

     *  *Single-use asymmetric keys*: Envisioned for the European Union's
        digital identity framework, which is set to use single-use
        asymmetric keys to prevent colluding verifiers from using public
        keys as correlation handles.  Each digital identity credential
        would thus be issued with a single-use proof-of-possession key,
        used only once to present the credential to a verifier.  ARKG
        empowers both online and offline usage scenarios: for offline
        scenarios, ARKG enables pre-generation of public keys for single-
        use credentials without needing to access the hardware security
        device that holds the private keys.  For online scenarios, ARKG
        gives the credential issuer assurance that all derived private



  Lundberg & Bradley       Expires 31 August 2026                 [Page 3]


  Internet-Draft                    ARKG                     February 2026


        keys are bound to the same secure hardware element.  In both
        cases, application performance may be improved since public keys
        can be generated in a general-purpose execution environment
        instead of a secure enclave.

     *  *Enhanced forward secrecy*: The use of ARKG can facilitate forward
        secrecy in certain contexts.  For instance, section 8.5.4 of RFC
        9052 (https://www.rfc-editor.org/rfc/rfc9052.html#name-direct-key-
        agreement) notes that "Since COSE is designed for a store-and-
        forward environment rather than an online environment, [...]
        forward secrecy (see [RFC4949]) is not achievable.  A static key
        will always be used for the receiver of the COSE object."  As
        opposed to workarounds like exchanging a large number of keys in
        advance, ARKG enables the the sender to generate ephemeral
        recipient public keys on demand.

     *  *Backup key generation*: For example, the W3C Web Authentication
        API [WebAuthn] (WebAuthn) generates a new key pair for each
        account on each web site.  ARKG could allow for simultaneously
        generating a backup public key when registering a new public key.
        A primary authenticator could generate both a key pair for itself
        and a public key for a paired backup authenticator.  The backup
        authenticator only needs to be paired with the primary
        authenticator once, and can then be safely stored until it is
        needed.

     ARKG consists of three procedures:

     *  *Initialization*: The _delegating party_ generates a _seed pair_
        and discloses the _public seed_ to a _subordinate party_, while
        securely retaining the _private seed_.

     *  *Public key generation*: The subordinate party uses the public
        seed to autonomously generate a new public key along with a unique
        _key handle_ for the public key.  This can be repeated any number
        of times.

     *  *Private key derivation*: The delegating party uses a key handle
        and the private seed to derive the private key corresponding to
        the public key generated along with the key handle.  This can be
        repeated with any number of key handles.

     Notably, ARKG can be built entirely using established cryptographic
     primitives.  The required primitives are a public key blinding scheme
     and a key encapsulation mechanism (KEM), which may in turn use a key
     derivation function (KDF) and a message authentication code (MAC)
     scheme.  Both conventional primitives and quantum-resistant
     alternatives exist that meet these requirements.  [ASIACCS_SteWil24]



  Lundberg & Bradley       Expires 31 August 2026                 [Page 4]


  Internet-Draft                    ARKG                     February 2026


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

  1.2.  Notation

     The following notation is used throughout this document:

     *  The symbol || represents octet string concatenation.

     *  Literal text strings and octet strings are denoted using the CDDL
        syntax defined in Section 3.1 of [RFC8610].

     *  Elliptic curve operations are written in additive notation: +
        denotes point addition, i.e., the curve group operation; * denotes
        point multiplication, i.e., repeated point addition; and + also
        denotes scalar addition modulo the curve order. * has higher
        precedence than +, i.e., a + b * C is equivalent to a + (b * C).

     *  LEN(x) is the length, in octets, of the octet string x.

     *  The function I2OSP converts a nonnegative integer into an octet
        string as defined in Section 4.1 of [RFC8017].

  2.  The Asynchronous Remote Key Generation (ARKG) algorithm

     The ARKG algorithm consists of three functions, each performed by one
     of two participants: the _delegating party_ or the _subordinate
     party_. The delegating party generates an ARKG _seed pair_ and emits
     the _public seed_ to the subordinate party while keeping the _private
     seed_ secret.  The subordinate party can then use the public seed to
     generate derived public keys and _key handles_, and the delegating
     party can use the private seed and a key handle to derive the
     corresponding private key.

     This construction of ARKG is fully deterministic, extracting input
     entropy as explicit parameters, as opposed to the internal random
     sampling typically used in the academic literature [CCS_FGKLMN20]
     [Wilson2023] [AC_BreCleFis24].  Implementations MAY choose to instead
     implement the ARKG-Derive-Seed and KEM-Encaps functions as
     nondeterministic procedures omitting their respective ikm parameters
     and sampling random entropy internally; this choice does not affect
     interoperability between the functions ARKG-Derive-Seed, ARKG-Derive-
     Public-Key and ARKG-Derive-Private-Key.



  Lundberg & Bradley       Expires 31 August 2026                 [Page 5]


  Internet-Draft                    ARKG                     February 2026


     The following subsections define the abstract instance parameters
     used to construct the three ARKG functions, followed by the
     definitions of the three ARKG functions.

  2.1.  Instance parameters

     ARKG is composed of a suite of other algorithms.  The parameters of
     an ARKG instance are:

     *  BL: An asymmetric key blinding scheme [Wilson2023], consisting of:

        -  Function BL-Generate-Keypair() -> (pk, sk): Generate a blinding
           key pair.

           Input consists of input keying material entropy ikm.

           Output consists of a blinding public key pk and a blinding
           private key sk.

        -  Function BL-PRF(ikm_tau, ctx) -> tau: Derive a pseudorandom
           blinding factor.

           Input consists of input entropy ikm_tau and a domain separation
           parameter ctx.

           Output consists of the blinding factor tau.

        -  Function BL-Blind-Public-Key(pk, tau) -> pk_tau:
           Deterministically compute a blinded public key.

           Input consists of a blinding public key pk, and a blinding
           factor tau.

           Output consists of the blinded public key pk_tau.

        -  Function BL-Blind-Private-Key(sk, tau) -> sk_tau:
           Deterministically compute a blinded private key.

           Input consists of a blinding private key sk, and the blinding
           factor tau.

           Output consists of the blinded private key sk_tau.

        ikm is an opaque octet string of a suitable length as defined by
        the ARKG instance. ikm_tau is an opaque octet string generated as
        the k output of KEM-Encaps and KEM-Decaps. ctx is an opaque octet
        string of arbitrary length.




  Lundberg & Bradley       Expires 31 August 2026                 [Page 6]


  Internet-Draft                    ARKG                     February 2026


        The representations of pk and pk_tau are defined by the protocol
        that invokes ARKG.  The representations of sk, tau and sk_tau are
        undefined implementation details.

        See [Wilson2023] for definitions of security properties required
        of the key blinding scheme BL.

     *  KEM: A key encapsulation mechanism [Shoup], consisting of the
        functions:

        -  KEM-Derive-Key-Pair(ikm) -> (pk, sk): Derive a key
           encapsulation key pair.

           Input consists of input keying material entropy ikm.

           Output consists of public key pk and private key sk.

        -  KEM-Encaps(pk, ikm, ctx) -> (k, c): Derive a key encapsulation.

           Input consists of an encapsulation public key pk, input entropy
           ikm and a domain separation parameter ctx.

           Output consists of a shared secret k and an encapsulation
           ciphertext c.

        -  KEM-Decaps(sk, c, ctx) -> k: Decapsulate a shared secret.

           Input consists of encapsulation private key sk, encapsulation
           ciphertext c and a domain separation parameter ctx.

           Output consists of the shared secret k on success, or an error
           otherwise.

        ikm is an opaque octet string of a suitable length as defined by
        the ARKG instance. k, c and ctx are opaque octet strings of
        arbitrary length.  The representation of pk is defined by the
        protocol that invokes ARKG.  The representation of sk is an
        undefined implementation detail.

        The KEM MUST guarantee integrity of the ciphertext, meaning that
        knowledge of the public key pk and the domain separation parameter
        ctx is required in order to create any ciphertext c that can be
        successfully decapsulated by the corresponding private key sk.
        Section 3.2 describes a general formula for how any KEM can be
        adapted to include this guarantee.  Section 9.1 discusses the
        reasons for this requirement.





  Lundberg & Bradley       Expires 31 August 2026                 [Page 7]


  Internet-Draft                    ARKG                     February 2026


        See [ASIACCS_SteWil24] for definitions of additional security
        properties required of the key encapsulation mechanism KEM.

     A concrete ARKG instantiation MUST specify the instantiation of each
     of the above functions.

     The output keys of the BL scheme are also the output keys of the ARKG
     instance as a whole.  For example, if BL-Blind-Public-Key and BL-
     Blind-Private-Key output ECDSA keys, then the ARKG instance will also
     output ECDSA keys.

     We denote a concrete ARKG instance by the pattern ARKG-NAME,
     substituting for NAME some description of the chosen instantiation
     for BL and KEM.  Note that this pattern cannot in general be
     unambiguously parsed; implementations MUST NOT attempt to construct
     an ARKG instance by parsing such a pattern string.  Concrete ARKG
     instances MUST always be identified by lookup in a registry of fully
     specified ARKG instances.  This is to prevent usage of algorithm
     combinations that may be incompatible or insecure.

  2.2.  The function ARKG-Derive-Seed

     This function is performed by the delegating party.  The delegating
     party derives the ARKG seed pair (pk, sk) and keeps the private seed
     sk secret, while the public seed pk is provided to the subordinate
     party.  The subordinate party will then be able to derive public keys
     on behalf of the delegating party.

     ARKG-Derive-Seed(ikm_bl, ikm_kem) -> (pk, sk)
         ARKG instance parameters:
             BL        A key blinding scheme.
             KEM       A key encapsulation mechanism.

         Inputs:
             ikm_bl    Input keying material entropy for BL.
             ikm_kem   Input keying material entropy for KEM.

         Output:
             (pk, sk)  An ARKG seed pair with public seed pk
                         and private seed sk.

         The output (pk, sk) is calculated as follows:

         (pk_bl,  sk_bl)  = BL-Derive-Key-Pair(ikm_bl)
         (pk_kem, sk_kem) = KEM-Derive-Key-Pair(ikm_kem)
         pk = (pk_bl, pk_kem)
         sk = (sk_bl, sk_kem)




  Lundberg & Bradley       Expires 31 August 2026                 [Page 8]


  Internet-Draft                    ARKG                     February 2026


  2.2.1.  Nondeterministic variants

     Applications that do not need a deterministic interface MAY choose to
     instead implement ARKG-Derive-Seed, KEM-Derive-Key-Pair and BL-
     Derive-Key-Pair as nondeterministic procedures omitting their
     respective ikm parameters and sampling random entropy internally;
     this choice does not affect interoperability with ARKG-Derive-Public-
     Key and ARKG-Derive-Private-Key.

  2.3.  The function ARKG-Derive-Public-Key

     This function is performed by the subordinate party, which holds the
     ARKG public seed pk = (pk_bl, pk_kem).  The resulting public key pk'
     can be provided to external parties to use in asymmetric cryptography
     protocols, and the resulting key handle kh can be used by the
     delegating party to derive the private key corresponding to pk'.

     This function may be invoked any number of times with the same public
     seed, using different ikm or ctx arguments, in order to generate any
     number of public keys.































  Lundberg & Bradley       Expires 31 August 2026                 [Page 9]


  Internet-Draft                    ARKG                     February 2026


     ARKG-Derive-Public-Key((pk_bl, pk_kem), ikm, ctx) -> (pk', kh)
         ARKG instance parameters:
             BL        A key blinding scheme.
             KEM       A key encapsulation mechanism.

         Inputs:
             pk_bl     A key blinding public key.
             pk_kem    A key encapsulation public key.
             ikm       Input entropy for KEM encapsulation.
             ctx       An octet string of length at most 64,
                         containing optional context and
                         application specific information
                         (can be a zero-length string).

         Output:
             pk'       A blinded public key.
             kh        A key handle for deriving the blinded
                         private key sk' corresponding to pk'.

         The output (pk', kh) is calculated as follows:

         if LEN(ctx) > 64:
             Abort with an error.

         ctx'    = I2OSP(LEN(ctx), 1) || ctx
         ctx_bl  = 'ARKG-Derive-Key-BL.'  || ctx'
         ctx_kem = 'ARKG-Derive-Key-KEM.' || ctx'

         (ikm_tau, c) = KEM-Encaps(pk_kem, ikm, ctx_kem)
         tau = BL-PRF(ikm_tau, ctx_bl)
         pk' = BL-Blind-Public-Key(pk_bl, tau)

         kh = c

     If this procedure aborts due to an error, the procedure can safely be
     retried with the same (pk_bl, pk_kem) and ctx arguments but a new ikm
     argument.

     See Section 2.5 for guidance on using ctx arguments longer than 64
     bytes.

  2.3.1.  Nondeterministic variants

     Applications that do not need a deterministic interface MAY choose to
     instead implement ARKG-Derive-Public-Key and KEM-Encaps as
     nondeterministic procedures omitting their respective ikm parameter
     and sampling random entropy internally; this choice does not affect
     interoperability with ARKG-Derive-Private-Key.



  Lundberg & Bradley       Expires 31 August 2026                [Page 10]


  Internet-Draft                    ARKG                     February 2026


     BL-PRF and BL-Blind-Public-Key must always be deterministic for
     compatibility with ARKG-Derive-Private-Key.

  2.4.  The function ARKG-Derive-Private-Key

     This function is performed by the delegating party, which holds the
     ARKG private seed (sk_bl, sk_kem).  The resulting private key sk' can
     be used in asymmetric cryptography protocols to prove possession of
     sk' to an external party that has the corresponding public key.

     This function may be invoked any number of times with the same
     private seed, in order to derive the same or different private keys
     any number of times.

     ARKG-Derive-Private-Key((sk_bl, sk_kem), kh, ctx) -> sk'
         ARKG instance parameters:
             BL        A key blinding scheme.
             KEM       A key encapsulation mechanism.

         Inputs:
             sk_bl     A key blinding private key.
             sk_kem    A key encapsulation private key.
             kh        A key handle output from ARKG-Derive-Public-Key.
             ctx       An octet string of length at most 64,
                         containing optional context and
                         application specific information
                         (can be a zero-length string).

         Output:
             sk'       A blinded private key.

         The output sk' is calculated as follows:

         if LEN(ctx) > 64:
             Abort with an error.

         ctx'    = I2OSP(LEN(ctx), 1) || ctx
         ctx_bl  = 'ARKG-Derive-Key-BL.'  || ctx'
         ctx_kem = 'ARKG-Derive-Key-KEM.' || ctx'

         ikm_tau = KEM-Decaps(sk_kem, kh, ctx_kem)
         If decapsulation failed:
             Abort with an error.

         tau = BL-PRF(ikm_tau, ctx_bl)
         sk' = BL-Blind-Private-Key(sk_bl, tau)





  Lundberg & Bradley       Expires 31 August 2026                [Page 11]


  Internet-Draft                    ARKG                     February 2026


     Errors in this procedure are typically unrecoverable.  For example,
     KEM-Decaps may fail to decapsulate the KEM ciphertext kh if it fails
     an integrity check.  ARKG instantiations SHOULD be chosen in a way
     that such errors are impossible if kh was generated by an honest and
     correct implementation of ARKG-Derive-Public-Key. Incorrect or
     malicious implementations of ARKG-Derive-Public-Key do not degrade
     the security of an honest and correct implementation of ARKG-Derive-
     Private-Key. See also Section 9.1.

     See Section 2.5 for guidance on using ctx arguments longer than 64
     bytes.

  2.5.  Using ctx values longer than 64 bytes

     The ctx parameter of ARKG-Derive-Public-Key and ARKG-Derive-Private-
     Key is limited to a length of at most 64 bytes.  This is because this
     value needs to be communicated from the _subordinate party_ to the
     _delegating party_ to use the same argument value in both functions,
     therefore it is necessary in some contexts to limit the size of this
     parameter in order to limit the size of overall protocol messages.

     If applications require ctx values longer than 64 bytes, implementors
     MAY use techniques such as that described in Section 5.3.3 of
     [RFC9380].  Precise procedure definitions are left as an application-
     specific implementation detail.

  3.  Generic ARKG instantiations

     This section defines generic formulae for instantiating the
     individual ARKG parameters, which can be used to define concrete ARKG
     instantiations.

  3.1.  Using elliptic curve addition for key blinding

     Instantiations of ARKG whose output keys are elliptic curve keys can
     use elliptic curve addition as the key blinding scheme BL
     [CCS_FGKLMN20] [Wilson2023].  This section defines a general formula
     for such instantiations of BL.

     This formula has the following parameters:

     *  crv: An elliptic curve.

     *  hash-to-crv-suite: A hash-to-curve suite [RFC9380] suitable for
        hashing to the scalar field of crv.

     *  DST_ext: A domain separation tag.




  Lundberg & Bradley       Expires 31 August 2026                [Page 12]


  Internet-Draft                    ARKG                     February 2026


     Then the BL parameter of ARKG may be instantiated as follows:

     *  G is the generator of the prime order subgroup of crv.

     *  N is the order of G.

     *  The function hash_to_field is defined in Section 5 of [RFC9380].

     BL-Derive-Key-Pair(ikm) -> (pk, sk)

         DST_bl_sk = 'ARKG-BL-EC-KG.' || DST_ext
         sk = hash_to_field(ikm, 1) with the parameters:
             DST: DST_bl_sk
             F: GF(N), the scalar field
                of the prime order subgroup of crv
             p: N
             m: 1
             L: The L defined in hash-to-crv-suite
             expand_message: The expand_message function
                             defined in hash-to-crv-suite

         pk = sk * G


     BL-PRF(ikm_tau, ctx) -> tau

         DST_tau = 'ARKG-BL-EC.' || DST_ext || ctx
         tau = hash_to_field(ikm_tau, 1) with the parameters:
             DST: DST_tau
             F: GF(N), the scalar field
                of the prime order subgroup of crv
             p: N
             m: 1
             L: The L defined in hash-to-crv-suite
             expand_message: The expand_message function
                             defined in hash-to-crv-suite


     BL-Blind-Public-Key(pk, tau) -> pk_tau

         pk_tau = pk + tau * G


     BL-Blind-Private-Key(sk, tau) -> sk_tau

         sk_tau_tmp = sk + tau
         If sk_tau_tmp = 0, abort with an error.
         sk_tau = sk_tau_tmp



  Lundberg & Bradley       Expires 31 August 2026                [Page 13]


  Internet-Draft                    ARKG                     February 2026


  3.2.  Using HMAC to adapt a KEM without ciphertext integrity

     Not all key encapsulation mechanisms guarantee ciphertext integrity,
     meaning that a valid KEM ciphertext can be created only with
     knowledge of the KEM public key.  This section defines a general
     formula for adapting any KEM to guarantee ciphertext integrity by
     prepending a MAC to the KEM ciphertext.

     For example, ECDH does not guarantee ciphertext integrity - any
     elliptic curve point is a valid ECDH ciphertext and can be
     successfully decapsulated using any elliptic curve private scalar.

     This formula has the following parameters:

     *  Hash: A cryptographic hash function.

     *  DST_ext: A domain separation parameter.

     *  Sub-Kem: A key encapsulation mechanism as described for the KEM
        parameter in Section 2.1, except Sub-Kem MAY ignore the ctx
        parameter and MAY not guarantee ciphertext integrity.  Sub-Kem
        defines the functions Sub-Kem-Derive-Key-Pair, Sub-Kem-Encaps and
        Sub-Kem-Decaps.

     The KEM parameter of ARKG may be instantiated using Sub-Kem, HMAC
     [RFC2104] and HKDF [RFC5869] as follows:

     *  L is the output length of Hash in octets.

     *  LEFT(X, n) is the first n bytes of the byte array X.

     *  DROP_LEFT(X, n) is the byte array X without the first n bytes.

     We truncate the HMAC output to 128 bits (16 octets) because as
     described in Section 9.1, ARKG needs ciphertext integrity only to
     ensure correctness, not for security.  Extendable-output functions
     used as the Hash parameter SHOULD still be instantiated with an
     output length appropriate for the desired security level, in order to
     not leak information about the Sub-Kem shared secret key.

     KEM-Derive-Key-Pair(ikm) -> (pk, sk)

         (pk, sk) = Sub-Kem-Derive-Key-Pair(ikm)


     KEM-Encaps(pk, ikm, ctx) -> (k, c)

         ctx_sub = 'ARKG-KEM-HMAC.' || DST_ext || ctx



  Lundberg & Bradley       Expires 31 August 2026                [Page 14]


  Internet-Draft                    ARKG                     February 2026


         (k', c') = Sub-Kem-Encaps(pk, ikm, ctx_sub)

         prk = HKDF-Extract with the arguments:
             Hash: Hash
             salt: not set
             IKM: k'

         info_mk = 'ARKG-KEM-HMAC-mac.' || DST_ext || ctx
         mk = HKDF-Expand with the arguments:
             Hash: Hash
             PRK: prk
             info: info_mk
             L: L
         t = HMAC-Hash-128(K=mk, text=c')

         info_k = 'ARKG-KEM-HMAC-shared.' || DST_ext || ctx
         k = HKDF-Expand with the arguments:
             Hash: Hash
             PRK: prk
             info: info_k
             L: The length of k' in octets.
         c = t || c'


     KEM-Decaps(sk, c, ctx) -> k

         t = LEFT(c, 16)
         c' = DROP_LEFT(c, 16)
         ctx_sub = 'ARKG-KEM-HMAC.' || DST_ext || ctx
         k' = Sub-Kem-Decaps(sk, c', ctx_sub)

         prk = HKDF-Extract with the arguments:
             Hash: Hash
             salt: not set
             IKM: k'

         mk = HKDF-Expand with the arguments:
             Hash: Hash
             PRK: prk
             info: 'ARKG-KEM-HMAC-mac.' || DST_ext || ctx
             L: L

         t' = HMAC-Hash-128(K=mk, text=c')
         If t = t':
             k = HKDF-Expand with the arguments:
                 Hash: Hash
                 PRK: prk
                 info: 'ARKG-KEM-HMAC-shared.' || DST_ext || ctx



  Lundberg & Bradley       Expires 31 August 2026                [Page 15]


  Internet-Draft                    ARKG                     February 2026


                 L: The length of k' in octets.
         Else:
             Abort with an error.

     In concrete instances where Sub-Kem-Encaps and Sub-Kem-Decaps ignore
     the ctx parameter, implementations MAY eliminate the parameter and
     omit the computation of ctx_sub.

  3.3.  Using ECDH as the KEM

     Instantiations of ARKG can use ECDH [RFC6090] as the key
     encapsulation mechanism KEM [CCS_FGKLMN20] [ASIACCS_SteWil24].  This
     section defines a general formula for such instantiations of KEM.

     This formula has the following parameters:

     *  crv: an elliptic curve valid for use with ECDH [RFC6090].

     *  Hash: A cryptographic hash function.

     *  hash-to-crv-suite: A hash-to-curve suite [RFC9380] suitable for
        hashing to the scalar field of crv.

     *  DST_ext: A domain separation parameter.

     The above parameters define the following intermediate value:

     *  DST_aug: 'ARKG-ECDH.' || DST_ext.

     The KEM parameter of ARKG may be instantiated as described in section
     Section 3.2 with the parameters:

     *  Hash: Hash.

     *  DST_ext: DST_aug.

     *  Sub-Kem: The functions Sub-Kem-Derive-Key-Pair, Sub-Kem-Encaps and
        Sub-Kem-Decaps defined as follows:

        -  Elliptic-Curve-Point-to-Octet-String and Octet-String-to-
           Elliptic-Curve-Point are the conversion routines defined in
           sections 2.3.3 and 2.3.4 of [SEC1], without point compression.

        -  ECDH(pk, sk) represents the compact output of ECDH [RFC6090]
           using public key (curve point) pk and private key (exponent)
           sk.

        -  G is the generator of the prime order subgroup of crv.



  Lundberg & Bradley       Expires 31 August 2026                [Page 16]


  Internet-Draft                    ARKG                     February 2026


        -  N is the order of G.

        Sub-Kem-Derive-Key-Pair(ikm) -> (pk, sk)

            DST_kem_sk = 'ARKG-KEM-ECDH-KG.' || DST_aug
            sk = hash_to_field(ikm, 1) with the parameters:
                DST: DST_kem_sk
                F: GF(N), the scalar field
                  of the prime order subgroup of crv
                p: N
                m: 1
                L: The L defined in hash-to-crv-suite
                expand_message: The expand_message function
                                defined in hash-to-crv-suite

            pk = sk * G


        Sub-Kem-Encaps(pk, ikm, ctx) -> (k, c)

            (pk', sk') = Sub-Kem-Derive-Key-Pair(ikm)

            k = ECDH(pk, sk')
            c = Elliptic-Curve-Point-to-Octet-String(pk')


        Sub-Kem-Decaps(sk, c, ctx) -> k

            pk' = Octet-String-to-Elliptic-Curve-Point(c)
            k = ECDH(pk', sk)

     Note: This instance intentionally ignores the ctx parameter of Sub-
     Kem-Encaps and Sub-Kem-Decaps.

  3.4.  Using X25519 or X448 as the KEM

     Instantiations of ARKG can use X25519 or X448 [RFC7748] as the key
     encapsulation mechanism KEM.  This section defines a general formula
     for such instantiations of KEM.

     This formula has the following parameters:

     *  DH-Function: the function X25519 or the function X448 [RFC7748].

     *  DST_ext: A domain separation parameter.

     The KEM parameter of ARKG may be instantiated as described in section
     Section 3.2 with the parameters:



  Lundberg & Bradley       Expires 31 August 2026                [Page 17]


  Internet-Draft                    ARKG                     February 2026


     *  Hash: SHA-512 [FIPS 180-4] if DH-Function is X25519, or SHAKE256
        [FIPS 202] with output length 64 octets if DH-Function is X448.

     *  DST_ext: 'ARKG-ECDHX.' || DST_ext.

     *  Sub-Kem: The functions Sub-Kem-Derive-Key-Pair, Sub-Kem-Encaps and
        Sub-Kem-Decaps defined as follows:

        -  G is the octet string h'0900000000000000 0000000000000000
           0000000000000000 0000000000000000' if DH-Function is X25519, or
           the octet string h'0500000000000000 0000000000000000
           0000000000000000 0000000000000000 0000000000000000
           0000000000000000 0000000000000000' if DH-Function is X448.

           These are the little-endian encodings of the integers 9 and 5,
           which is the u-coordinate of the generator point of the
           respective curve group.

        Sub-Kem-Derive-Key-Pair(ikm) -> (pk, sk)

            sk = ikm
            pk = DH-Function(sk, G)


        Sub-Kem-Encaps(pk, ikm, ctx) -> (k, c)

            (pk', sk') = Sub-Kem-Derive-Key-Pair(ikm)

            k = DH-Function(sk', pk)
            c = pk'


        Sub-Kem-Decaps(sk, c, ctx) -> k

            k = DH-Function(sk, c)

     Note: This instance intentionally ignores the ctx parameter of Sub-
     Kem-Encaps and Sub-Kem-Decaps.

  3.5.  Using the same key for both key blinding and KEM

     When an ARKG instance uses the same type of key for both the key
     blinding and the KEM - for example, if elliptic curve arithmetic is
     used for key blinding as described in Section 3.1 and ECDH is used as
     the KEM as described in Section 3.3 [CCS_FGKLMN20] - then the two
     keys MAY be the same key.  Representations of such an ARKG seed MAY
     allow for omitting the second copy of the constituent key, but such
     representations MUST clearly identify that the single constituent key



  Lundberg & Bradley       Expires 31 August 2026                [Page 18]


  Internet-Draft                    ARKG                     February 2026


     is to be used both as the key blinding key and the KEM key.

  4.  Concrete ARKG instantiations

     This section defines an initial set of concrete ARKG instantiations.

     TODO: IANA registry?  COSE/JOSE?

  4.1.  ARKG-P256

     The identifier ARKG-P256 represents the following ARKG instance:

     *  BL: Elliptic curve addition as described in Section 3.1 with the
        parameters:

        -  crv: The NIST curve secp256r1 [SEC2].

        -  hash-to-crv-suite: P256_XMD:SHA-256_SSWU_RO_ [RFC9380].

        -  DST_ext: 'ARKG-P256'.

     *  KEM: ECDH as described in Section 3.3 with the parameters:

        -  crv: The NIST curve secp256r1 [SEC2].

        -  Hash: SHA-256 [FIPS 180-4].

        -  hash-to-crv-suite: P256_XMD:SHA-256_SSWU_RO_ [RFC9380].

        -  DST_ext: 'ARKG-P256'.

     Each ikm_bl, ikm_kem and ikm input to the procedures in this ARKG
     instance SHOULD contain at least 256 bits of entropy.

  4.2.  ARKG-P384

     The identifier ARKG-P384 represents the following ARKG instance:

     *  BL: Elliptic curve addition as described in Section 3.1 with the
        parameters:

        -  crv: The NIST curve secp384r1 [SEC2].

        -  hash-to-crv-suite: P384_XMD:SHA-384_SSWU_RO_ [RFC9380].

        -  DST_ext: 'ARKG-P384'.

     *  KEM: ECDH as described in Section 3.3 with the parameters:



  Lundberg & Bradley       Expires 31 August 2026                [Page 19]


  Internet-Draft                    ARKG                     February 2026


        -  crv: The NIST curve secp384r1 [SEC2].

        -  Hash: SHA-384 [FIPS 180-4].

        -  hash-to-crv-suite: P384_XMD:SHA-384_SSWU_RO_ [RFC9380].

        -  DST_ext: 'ARKG-P384'.

     Each ikm_bl, ikm_kem and ikm input to the procedures in this ARKG
     instance SHOULD contain at least 384 bits of entropy.

  4.3.  ARKG-P521

     The identifier ARKG-P521 represents the following ARKG instance:

     *  BL: Elliptic curve addition as described in Section 3.1 with the
        parameters:

        -  crv: The NIST curve secp521r1 [SEC2].

        -  hash-to-crv-suite: P521_XMD:SHA-512_SSWU_RO_ [RFC9380].

        -  DST_ext: 'ARKG-P521'.

     *  KEM: ECDH as described in Section 3.3 with the parameters:

        -  crv: The NIST curve secp521r1 [SEC2].

        -  Hash: SHA-512 [FIPS 180-4].

        -  hash-to-crv-suite: P521_XMD:SHA-512_SSWU_RO_ [RFC9380].

        -  DST_ext: 'ARKG-P521'.

     Each ikm_bl, ikm_kem and ikm input to the procedures in this ARKG
     instance SHOULD contain at least 512 bits of entropy.

  4.4.  ARKG-P256k

     The identifier ARKG-P256k represents the following ARKG instance:

     *  BL: Elliptic curve addition as described in Section 3.1 with the
        parameters:

        -  crv: The SECG curve secp256k1 [SEC2].

        -  hash-to-crv-suite: secp256k1_XMD:SHA-256_SSWU_RO_ [RFC9380].




  Lundberg & Bradley       Expires 31 August 2026                [Page 20]


  Internet-Draft                    ARKG                     February 2026


        -  DST_ext: 'ARKG-P256k'.

     *  KEM: ECDH as described in Section 3.3 with the parameters:

        -  crv: The SECG curve secp256k1 [SEC2].

        -  Hash: SHA-256 [FIPS 180-4].

        -  hash-to-crv-suite: secp256k1_XMD:SHA-256_SSWU_RO_ [RFC9380].

        -  DST_ext: 'ARKG-P256k'.

     Each ikm_bl, ikm_kem and ikm input to the procedures in this ARKG
     instance SHOULD contain at least 256 bits of entropy.

  5.  COSE bindings

     This section proposes additions to COSE [RFC9052] to support ARKG use
     cases.  These consist of a new key type to represent ARKG public
     seeds, algorithm identifiers for signing using an ARKG-derived
     private key, and new COSE_Sign_Args [I-D.lundberg-cose-split-algs]
     algorithm parameters for ARKG.

  5.1.  COSE key type: ARKG public seed

     An ARKG public seed is represented as a COSE_Key structure [RFC9052]
     with kty value TBD (placeholder value -65537).  Table 1 defines key
     type parameters pkbl (-1) and pkkem (-2) for the BL and KEM public
     key, respectively, as well as key type parameter dkalg (-3),
     representing the algorithm that derived public and private keys are
     to be used with.




















  Lundberg & Bradley       Expires 31 August 2026                [Page 21]


  Internet-Draft                    ARKG                     February 2026


     +=======+=======+==========+===========+============================+
     | Name  | Label | Value    | Required? | Description                |
     |       |       | type     |           |                            |
     +=======+=======+==========+===========+============================+
     | pkbl  | -1    | COSE_Key | Required  | BL key of ARKG public      |
     |       |       |          |           | seed                       |
     +-------+-------+----------+-----------+----------------------------+
     | pkkem | -2    | COSE_Key | Required  | KEM key of ARKG            |
     |       |       |          |           | public seed                |
     +-------+-------+----------+-----------+----------------------------+
     | dkalg | -3    | int /    | Optional  | alg parameter of           |
     |       |       | tstr     |           | public and private         |
     |       |       |          |           | keys derived from          |
     |       |       |          |           | this ARKG public seed      |
     +-------+-------+----------+-----------+----------------------------+

          Table 1: COSE key type parameters for the ARKG-pub key type.

     When dkalg (-3) is present in an ARKG public seed, the alg (3)
     parameter of public keys derived using ARKG-Derive-Public-Key with
     that seed SHOULD be set to the dkalg (-3) value of the seed.

     The alg (3) parameter, when present, identifies the ARKG instance
     this public seed is to be used with.  An initial set of COSE
     algorithm identifiers for this purpose is defined in Section 5.2.

     The following CDDL [RFC8610] example represents an ARKG-P256 public
     seed restricted to generating derived keys for use with the ESP256
     [RFC9864] signature algorithm:






















  Lundberg & Bradley       Expires 31 August 2026                [Page 22]


  Internet-Draft                    ARKG                     February 2026


     {
       1: -65537,   ; kty: ARKG-pub (placeholder value)
                    ; kid: Opaque identifier
       2: h'60b6dfddd31659598ae5de49acb220d8
            704949e84d484b68344340e2565337d2',
       3: -65700,   ; alg: ARKG-P256 (placeholder value)

       -1: {        ; BL public key
         1: 2,      ; kty: EC2
         -1: 1,     ; crv: P256
         -2: h'69380FC1C3B09652134FEEFBA61776F9
               7AF875CE46CA20252C4165102966EBC5',
         -3: h'8B515831462CCB0BD55CBA04BFD50DA6
               3FAF18BD845433622DAF97C06A10D0F1',
       },

       -2: {        ; KEM public key
         1: 2,      ; kty: EC2
         -1: 1,     ; crv: P256
         -2: h'5C099BEC31FAA581D14E208250D3FFDA
               9EC7F543043008BC84967A8D875B5D78',
         -3: h'539D57429FCB1C138DA29010A155DCA1
               4566A8F55AC2F1780810C49D4ED72D58',
       },

       -3: -9       ; Derived key algorithm: ESP256
     }

     The following is the same example encoded as CBOR:

     h'a6013a0001000002582060b6dfddd31659598ae5de49acb220d8704949e84d48
       4b68344340e2565337d2033a000100a320a40102200121582069380fc1c3b096
       52134feefba61776f97af875ce46ca20252c4165102966ebc52258208b515831
       462ccb0bd55cba04bfd50da63faf18bd845433622daf97c06a10d0f121a40102
       20012158205c099bec31faa581d14e208250d3ffda9ec7f543043008bc84967a
       8d875b5d78225820539d57429fcb1c138da29010a155dca14566a8f55ac2f178
       0810c49d4ed72d582228'

  5.2.  COSE algorithms

     This section defines COSE algorithm identifiers [RFC9052] for ARKG
     instances, and for signature algorithms combined with using a signing
     private key derived using ARKG.

     Table 2 defines algorithm identifiers to represent ARKG instances.






  Lundberg & Bradley       Expires 31 August 2026                [Page 23]


  Internet-Draft                    ARKG                     February 2026


       +============+==================+==============================+
       | Name       | Value            | Description                  |
       +============+==================+==============================+
       | ARKG-P256  | TBD (placeholder | The ARKG instance ARKG-P256  |
       |            | -65700)          | defined in Section 4.1.      |
       +------------+------------------+------------------------------+
       | ARKG-P384  | TBD (placeholder | The ARKG instance ARKG-P384  |
       |            | -65701)          | defined in Section 4.2.      |
       +------------+------------------+------------------------------+
       | ARKG-P521  | TBD (placeholder | The ARKG instance ARKG-P521  |
       |            | -65702)          | defined in Section 4.3.      |
       +------------+------------------+------------------------------+
       | ARKG-P256k | TBD (placeholder | The ARKG instance ARKG-P256k |
       |            | -65703)          | defined in Section 4.4.      |
       +------------+------------------+------------------------------+

           Table 2: COSE algorithm identifiers for ARKG instances.

     Table 3 defines algorithm identifiers to represent signing
     algorithms.  These MAY be used to negotiate algorithm selection
     between a _digester_ and _signer_ as described in Section 2 of
     [I-D.lundberg-cose-split-algs], and in key representations exchanged
     between such _digesters_ and _signers_, but SHOULD NOT appear in COSE
     structures consumed by signature verifiers.  COSE structures consumed
     by signature verifiers SHOULD instead use the corresponding algorithm
     identifier listed in the "verification algorithm" column.

























  Lundberg & Bradley       Expires 31 August 2026                [Page 24]


  Internet-Draft                    ARKG                     February 2026


     +===========+============+============+==============================+
     |Name       |Value       |Verification|Description                   |
     |           |            |algorithm   |                              |
     +===========+============+============+==============================+
     |ESP256-ARKG|TBD         |-9 (ESP256) |ESP256 [RFC9864] using private|
     |           |            |            |key derived by ARKG-P256      |
     |           |            |            |(Section 4.1).                |
     +-----------+------------+------------+------------------------------+
     |ESP256-    |TBD         |-9 (ESP256) |ESP256-split                  |
     |split-ARKG |(placeholder|            |[I-D.lundberg-cose-split-algs]|
     |           |-65539)     |            |using private key derived by  |
     |           |            |            |ARKG-P256 (Section 4.1).      |
     +-----------+------------+------------+------------------------------+
     |ESP384-ARKG|TBD         |-51 (ESP384)|ESP384 [RFC9864] using private|
     |           |            |            |key derived by ARKG-P384      |
     |           |            |            |(Section 4.2).                |
     +-----------+------------+------------+------------------------------+
     |ESP384-    |TBD         |-51 (ESP384)|ESP384-split                  |
     |split-ARKG |            |            |[I-D.lundberg-cose-split-algs]|
     |           |            |            |using private key derived by  |
     |           |            |            |ARKG-P384 (Section 4.2).      |
     +-----------+------------+------------+------------------------------+
     |ESP512-ARKG|TBD         |-52 (ESP512)|ESP512 [RFC9864] using private|
     |           |            |            |key derived by ARKG-P521      |
     |           |            |            |(Section 4.3).                |
     +-----------+------------+------------+------------------------------+
     |ESP512-    |TBD         |-52 (ESP512)|ESP512-split                  |
     |split-ARKG |            |            |[I-D.lundberg-cose-split-algs]|
     |           |            |            |using private key derived by  |
     |           |            |            |ARKG-P521 (Section 4.3).      |
     +-----------+------------+------------+------------------------------+
     |ES256K-ARKG|TBD         |-47 (ES256K)|ES256K [RFC8812] using private|
     |           |            |            |key derived by ARKG-P256k     |
     |           |            |            |(Section 4.4).                |
     +-----------+------------+------------+------------------------------+

         Table 3: COSE algorithms for signing with an ARKG-derived key.

  5.3.  COSE signing arguments

     This section defines ARKG-specific parameters for the COSE_Sign_Args
     structure [I-D.lundberg-cose-split-algs].  These consist of the
     parameters -1 and -2 respectively for the kh and ctx parameters of
     ARKG-Derive-Private-Key. Table 4 defines these algorithm parameters
     for COSE_Sign_args. kh and ctx are both REQUIRED for all the relevant
     alg values.





  Lundberg & Bradley       Expires 31 August 2026                [Page 25]


  Internet-Draft                    ARKG                     February 2026


     +======+=======+======+===========+===================+=============+
     | Name | Label | Type | Required? | Algorithm         | Description |
     +======+=======+======+===========+===================+=============+
     | kh   | -1    | bstr | Required  | ESP256-ARKG,      | kh argument |
     |      |       |      |           | ESP256-           | to ARKG-    |
     |      |       |      |           | split-ARKG,       | Derive-     |
     |      |       |      |           | ESP384-ARKG,      | Private-    |
     |      |       |      |           | ESP384-           | Key.        |
     |      |       |      |           | split-ARKG,       |             |
     |      |       |      |           | ESP512-ARKG,      |             |
     |      |       |      |           | ESP512-           |             |
     |      |       |      |           | split-ARKG,       |             |
     |      |       |      |           | ES256K-ARKG       |             |
     +------+-------+------+-----------+-------------------+-------------+
     | ctx  | -2    | bstr | Required  | ESP256-ARKG,      | ctx         |
     |      |       |      |           | ESP256-           | argument to |
     |      |       |      |           | split-ARKG,       | ARKG-       |
     |      |       |      |           | ESP384-ARKG,      | Derive-     |
     |      |       |      |           | ESP384-           | Private-    |
     |      |       |      |           | split-ARKG,       | Key.        |
     |      |       |      |           | ESP512-ARKG,      |             |
     |      |       |      |           | ESP512-           |             |
     |      |       |      |           | split-ARKG,       |             |
     |      |       |      |           | ES256K-ARKG       |             |
     +------+-------+------+-----------+-------------------+-------------+

               Table 4: Algorithm parameters for COSE_Sign_Args.

     The following CDDL example conveys the kh and ctx arguments for
     signing data using the ESP256-split algorithm
     [I-D.lundberg-cose-split-algs] and a key derived using ARKG-P256:

     {
       3: -65539,   ; alg: ESP256-split with ARKG-P256 (placeholder value)

                    ; ARKG-P256 key handle
                    ; (HMAC-SHA-256-128 followed by
                       SEC1 uncompressed ECDH public key)
       -1: h'27987995f184a44cfa548d104b0a461d
             0487fc739dbcdabc293ac5469221da91b220e04c681074ec4692a76ffacb9043de
               c2847ea9060fd42da267f66852e63589f0c00dc88f290d660c65a65a50c86361',

                    ; info argument to ARKG-Derive-Private-Key
       -2: 'ARKG-P256.test vectors',
     }

     The following is the same example encoded as CBOR:




  Lundberg & Bradley       Expires 31 August 2026                [Page 26]


  Internet-Draft                    ARKG                     February 2026


     h'a3033a0001000220585127987995f184a44cfa548d104b0a461d0487fc739dbc
       dabc293ac5469221da91b220e04c681074ec4692a76ffacb9043dec2847ea906
       0fd42da267f66852e63589f0c00dc88f290d660c65a65a50c86361215641524b
       472d503235362e7465737420766563746f7273'

  6.  Security Considerations

     TODO

  7.  Privacy Considerations

     TODO

  8.  IANA Considerations

  8.1.  COSE Key Types Registrations

     This section registers the following values in the IANA "COSE Key
     Types" registry [IANA.cose].

     *  Name: ARKG-pub

        -  Value: TBD (Placeholder -65537)

        -  Description: ARKG public seed

        -  Capabilities: [kty(-65537), pk_bl, pk_kem]

        -  Reference: Section 5.1 of this document

  8.2.  COSE Key Type Parameters Registrations

     This section registers the following values in the IANA "COSE Key
     Type Parameters" registry [IANA.cose].

     *  Key Type: TBD (ARKG-pub, placeholder -65537)

        -  Name: pk_bl

        -  Label: -1

        -  CBOR Type: COSE_Key

        -  Description: ARKG key blinding public key

        -  Reference: Section 5.1 of this document

     *  Key Type: TBD (ARKG-pub, placeholder -65537)



  Lundberg & Bradley       Expires 31 August 2026                [Page 27]


  Internet-Draft                    ARKG                     February 2026


        -  Name: pk_kem

        -  Label: -2

        -  CBOR Type: COSE_Key

        -  Description: ARKG key encapsulation public key

        -  Reference: Section 5.1 of this document

  8.3.  COSE Algorithms Registrations

     This section registers the following values in the IANA "COSE
     Algorithms" registry [IANA.cose].

     *  Name: ARKG-P256

        -  Value: TBD (placeholder -65700)

        -  Description: ARKG using ECDH and additive blinding on secp256r1

        -  Reference: Section 5.2 of this document

        -  Recommended: TBD

     *  Name: ARKG-P384

        -  Value: TBD (placeholder -65701)

        -  Description: ARKG using ECDH and additive blinding on secp384r1

        -  Reference: Section 5.2 of this document

        -  Recommended: TBD

     *  Name: ARKG-P521

        -  Value: TBD (placeholder -65702)

        -  Description: ARKG using ECDH and additive blinding on secp521r1

        -  Reference: Section 5.2 of this document

        -  Recommended: TBD

     *  Name: ARKG-P256k

        -  Value: TBD (placeholder -65703)



  Lundberg & Bradley       Expires 31 August 2026                [Page 28]


  Internet-Draft                    ARKG                     February 2026


        -  Description: ARKG using ECDH and additive blinding on secp256k1

        -  Reference: Section 5.2 of this document

        -  Recommended: TBD

     *  Name: ESP256-ARKG

        -  Value: TBD

        -  Description: ESP256 using private key derived by ARKG-P256

        -  Reference: [RFC9864], Section 5.2 of this document

        -  Recommended: TBD

     *  Name: ESP256-split-ARKG

        -  Value: TBD (placeholder -65539)

        -  Description: ESP256-split using private key derived by
           ARKG-P256

        -  Reference: [I-D.lundberg-cose-split-algs], Section 5.2 of this
           document

        -  Recommended: TBD

     *  Name: ESP384-ARKG

        -  Value: TBD

        -  Description: ESP384 using private key derived by ARKG-P384

        -  Reference: [RFC9864], Section 5.2 of this document

        -  Recommended: TBD

     *  Name: ESP384-split-ARKG

        -  Value: TBD

        -  Description: ESP384-split using private key derived by
           ARKG-P384

        -  Reference: [I-D.lundberg-cose-split-algs], Section 5.2 of this
           document




  Lundberg & Bradley       Expires 31 August 2026                [Page 29]


  Internet-Draft                    ARKG                     February 2026


        -  Recommended: TBD

     *  Name: ESP512-ARKG

        -  Value: TBD

        -  Description: ESP512 using private key derived by ARKG-P521

        -  Reference: [RFC9864], Section 5.2 of this document

        -  Recommended: TBD

     *  Name: ESP512-split-ARKG

        -  Value: TBD

        -  Description: ESP512-split using private key derived by
           ARKG-P521

        -  Reference: [I-D.lundberg-cose-split-algs], Section 5.2 of this
           document

        -  Recommended: TBD

     *  Name: ESP256K-ARKG

        -  Value: TBD

        -  Description: ESP256K using private key derived by ARKG-P256k

        -  Reference: [RFC8812], Section 5.2 of this document

        -  Recommended: TBD

  8.4.  COSE Signing Arguments Algorithm Parameters Registrations

     This section registers the following values in the IANA "COSE Signing
     Arguments Algorithm Parameters" registry
     [I-D.lundberg-cose-split-algs] (TODO):

     *  Name: kh

        -  Label: -1

        -  Type: bstr

        -  Required: yes




  Lundberg & Bradley       Expires 31 August 2026                [Page 30]


  Internet-Draft                    ARKG                     February 2026


        -  Algorithm: ESP256-ARKG, ESP256-split-ARKG, ESP384-ARKG, ESP384-
           split-ARKG, ESP512-ARKG, ESP512-split-ARKG, ES256K-ARKG

        -  Description: kh argument to ARKG-Derive-Private-Key.

        -  Capabilities: [alg(-65539, TBD)]

        -  Change Controller: IETF

        -  Reference: Section 5.3 of this document

     *  Name: ctx

        -  Label: -2

        -  Type: bstr

        -  Required: yes

        -  Algorithm: ESP256-ARKG, ESP256-split-ARKG, ESP384-ARKG, ESP384-
           split-ARKG, ESP512-ARKG, ESP512-split-ARKG, ES256K-ARKG

        -  Description: ctx argument to ARKG-Derive-Private-Key.

        -  Capabilities: [alg(-65539, TBD)]

        -  Change Controller: IETF

        -  Reference: Section 5.3 of this document

  9.  Design rationale

  9.1.  Using a MAC

     The ARKG construction by Stebila et al.  [ASIACCS_SteWil24] omits the
     MAC and instead encodes application context in the PRF labels,
     arguing that this leads to invalid keys/signatures in cases that
     would have a bad MAC.  We choose to keep the MAC from the
     construction by Frymann et al.  [CCS_FGKLMN20], but allow it to be
     omitted in case the chosen KEM already guarantees ciphertext
     integrity.

     The reason for this is to ensure that the delegating party can
     distinguish key handles that belong to its ARKG seed.  For example,
     this is important for applications using the W3C Web Authentication
     API [WebAuthn], which do not know beforehand which authenticators are
     connected and available.  Instead, authentication requests may
     include references to several eligible authenticators, and the one to



  Lundberg & Bradley       Expires 31 August 2026                [Page 31]


  Internet-Draft                    ARKG                     February 2026


     use is chosen opportunistically by the WebAuthn client depending on
     which are available at the time.  Consider using ARKG in such a
     scenario to sign some data with a derived private key: a user may
     have several authenticators and thus several ARKG seeds, so the
     signing request might include several well-formed ARKG key handles,
     but only one of them belongs to the ARKG seed of the authenticator
     that is currently connected.  Without an integrity check, choosing
     the wrong key handle might cause the ARKG-Derive-Private-Key
     procedure to silently derive the wrong key instead of returning an
     explicit error, which would in turn lead to an invalid signature or
     similar final output.  This would make it difficult or impossible to
     diagnose the root cause of the issue and present actionable user
     feedback.  For this reason, we require the KEM to guarantee
     ciphertext integrity so that ARKG-Derive-Private-Key can fail early
     if the key handle belongs to a different ARKG seed.

     It is straightforward to see that adding the MAC to the construction
     by Wilson does not weaken the security properties defined by Frymann
     et al.  [CCS_FGKLMN20]: the construction by Frymann et al. can be
     reduced to the ARKG construction in this document by instantiating BL
     as described in Section 3.1 and KEM as described in Section 3.3.  The
     use of hash_to_field in Section 3.1 corresponds to the KDF_1
     parameter in [CCS_FGKLMN20], and the use of HMAC and HKDF in
     Section 3.2 corresponds to the MAC and KDF_2 parameters in
     [CCS_FGKLMN20].  Hence if one can break PK-unlinkability or SK-
     security of the ARKG construction in this document, one can also
     break the same property of the construction by Frymann et al.

  10.  Implementation Status

     This section is to be removed from the specification by the RFC
     Editor before publication as an RFC.

     There are currently two known implementations using features defined
     by this specification:

     *  wwWallet (https://github.com/wwWallet), an EU Digital Identity
        pilot project. wwWallet was entered into the "EUDI Wallet
        Prototypes" competition held by SprinD GmbH
        (https://www.sprind.org/en/actions/challenges/eudi-wallet-
        prototypes), and a branch of the wallet was submitted in the
        competition.  The competition entry implements ARKG for
        efficiently generating single-use hardware-bound holder binding
        keys.

        The implementation (https://github.com/gunet/funke-s3a-wallet-
        frontend/blob/stage-3/src/services/keystore.ts) uses the
        COSE_Key_Ref data structure defined in version 01 of



  Lundberg & Bradley       Expires 31 August 2026                [Page 32]


  Internet-Draft                    ARKG                     February 2026


        [I-D.lundberg-cose-split-algs] in order to send ARKG inputs to a
        WebAuthn authenticator, and uses the placeholder value for ESP256-
        split-ARKG defined in Section 5.2 to negotiate creation and usage
        of ARKG-derived keys for signing operations.  Work to update the
        implementation to instead use COSE_Sign_Args as defined in version
        05 of [I-D.lundberg-cose-split-algs] is ongoing.

     *  Yubico (https://www.yubico.com/), a hardware security key vendor,
        has produced limited-availability prototypes of their YubiKey
        product with an ARKG implementation interoperable with wwWallet.
        The YubiKey implementation uses the COSE_Sign_Args data structure
        defined in version 05 of [I-D.lundberg-cose-split-algs] to receive
        ARKG inputs from a WebAuthn Relying Party, and uses the
        placeholder value for ESP256-split-ARKG defined in Section 5.2 to
        negotiate creation and usage of ARKG-derived keys for signing
        operations.

     Table 5 summarizes implementation status for individual features.

































  Lundberg & Bradley       Expires 31 August 2026                [Page 33]


  Internet-Draft                    ARKG                     February 2026


                   +===================+==================+
                   | Feature           | Implementations  |
                   +===================+==================+
                   | ARKG-P256         | wwWallet, Yubico |
                   +-------------------+------------------+
                   | ARKG-P384         | -                |
                   +-------------------+------------------+
                   | ARKG-P521         | -                |
                   +-------------------+------------------+
                   | ARKG-P256k        | -                |
                   +-------------------+------------------+
                   | ESP256-ARKG       | -                |
                   +-------------------+------------------+
                   | ESP256-split-ARKG | wwWallet, Yubico |
                   +-------------------+------------------+
                   | ESP384-ARKG       | -                |
                   +-------------------+------------------+
                   | ESP384-split-ARKG | -                |
                   +-------------------+------------------+
                   | ESP512-ARKG       | -                |
                   +-------------------+------------------+
                   | ESP512-split-ARKG | -                |
                   +-------------------+------------------+
                   | ES256K-ARKG       | -                |
                   +-------------------+------------------+
                   | COSE_Sign_Args    | wwWallet, Yubico |
                   +-------------------+------------------+

                      Table 5: Implementation status of
                             individual features.

  10.1.  Related Internet-Drafts

     Parts of this specification depend upon definitions from
     [I-D.lundberg-cose-split-algs]:

     *  The algorithm identifiers ESP256-split-ARKG, ESP384-split-ARKG and
        ESP512-split-ARKG defined in Section 5.2 depend respectively on
        the algorithm identifiers ESP256-split, ESP384-split and
        ESP512-split defined in [I-D.lundberg-cose-split-algs].

     *  The ARKG-specific COSE_Sign_Args parameter definitions in
        Section 5.3 depend on [I-D.lundberg-cose-split-algs] for the
        definition of the COSE_Sign_Args structure.







  Lundberg & Bradley       Expires 31 August 2026                [Page 34]


  Internet-Draft                    ARKG                     February 2026


  10.2.  Future Work

     Hierarchical Deterministic Keys (HDK) [I-D.dijkhuis-cfrg-hdkeys] is a
     possible application of ARKG which has identified a limitation in the
     present construction, as discussed in HDK GitHub issue #94
     (https://github.com/sander/hierarchical-deterministic-keys/
     issues/94).  ARKG can be used recursively - for example, ARKG-P256
     can be used to derive P-256 keys that are themselves used as ARKG
     seeds - but then requires one invocation of ARKG-Derive-Private-Key
     per layer of recursion in order to derive higher-layer private keys.
     This can be an issue if the base ARKG private seed is hardware-bound,
     since it would require multiple calls to the secure hardware device,
     especially if each of those calls requires a user gesture for
     authorization.  Therefore a modified ARKG construction has been
     proposed, along with a draft for a potential security proof
     (https://github.com/Yubico/arkg-rfc/blob/pqarkg-h/pqarkg-h-security/
     pqarkg-h.pdf), which enables multiple layers of recursive ARKG to be
     condensed into a single invocation of ARKG-Derive-Private-Key. We
     would have liked to use this modified construction in this
     specification, but have not been able to get the potential proof
     appropriately peer reviewed in a timely manner, so prototypes have
     moved forward with the present construction.  The modified
     construction may be revisited in the future if there is demand for
     applications, in which case new algorithm identifiers and such can be
     defined for the modified construction.

  11.  References

  11.1.  Normative References

     [I-D.lundberg-cose-split-algs]
                Lundberg, E. and M. B. Jones, "Split signing algorithms
                for COSE", Work in Progress, Internet-Draft, draft-
                lundberg-cose-two-party-signing-algs-05, 23 February 2026,
                <https://datatracker.ietf.org/doc/html/draft-lundberg-
                cose-two-party-signing-algs-05>.

     [IANA.cose]
                IANA, "CBOR Object Signing and Encryption (COSE)",
                <https://www.iana.org/assignments/cose>.

     [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
                Hashing for Message Authentication", RFC 2104,
                DOI 10.17487/RFC2104, February 1997,
                <https://www.rfc-editor.org/rfc/rfc2104>.






  Lundberg & Bradley       Expires 31 August 2026                [Page 35]


  Internet-Draft                    ARKG                     February 2026


     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
                FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
                <https://www.rfc-editor.org/rfc/rfc4949>.

     [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
                Key Derivation Function (HKDF)", RFC 5869,
                DOI 10.17487/RFC5869, May 2010,
                <https://www.rfc-editor.org/rfc/rfc5869>.

     [RFC6090]  McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
                Curve Cryptography Algorithms", RFC 6090,
                DOI 10.17487/RFC6090, February 2011,
                <https://www.rfc-editor.org/rfc/rfc6090>.

     [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
                for Security", RFC 7748, DOI 10.17487/RFC7748, January
                2016, <https://www.rfc-editor.org/rfc/rfc7748>.

     [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
                "PKCS #1: RSA Cryptography Specifications Version 2.2",
                RFC 8017, DOI 10.17487/RFC8017, November 2016,
                <https://www.rfc-editor.org/rfc/rfc8017>.

     [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
                Signature Algorithm (EdDSA)", RFC 8032,
                DOI 10.17487/RFC8032, January 2017,
                <https://www.rfc-editor.org/rfc/rfc8032>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
                Definition Language (CDDL): A Notational Convention to
                Express Concise Binary Object Representation (CBOR) and
                JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
                June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

     [RFC8812]  Jones, M., "CBOR Object Signing and Encryption (COSE) and
                JSON Object Signing and Encryption (JOSE) Registrations
                for Web Authentication (WebAuthn) Algorithms", RFC 8812,
                DOI 10.17487/RFC8812, August 2020,
                <https://www.rfc-editor.org/rfc/rfc8812>.



  Lundberg & Bradley       Expires 31 August 2026                [Page 36]


  Internet-Draft                    ARKG                     February 2026


     [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", STD 96, RFC 9052,
                DOI 10.17487/RFC9052, August 2022,
                <https://www.rfc-editor.org/rfc/rfc9052>.

     [RFC9380]  Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S.,
                and C. A. Wood, "Hashing to Elliptic Curves", RFC 9380,
                DOI 10.17487/RFC9380, August 2023,
                <https://www.rfc-editor.org/rfc/rfc9380>.

     [RFC9864]  Jones, M.B. and O. Steele, "Fully-Specified Algorithms for
                JSON Object Signing and Encryption (JOSE) and CBOR Object
                Signing and Encryption (COSE)", RFC 9864,
                DOI 10.17487/RFC9864, October 2025,
                <https://www.rfc-editor.org/rfc/rfc9864>.

     [SEC1]     Certicom Research, "SEC 1: Elliptic Curve Cryptography",
                2009, <http://www.secg.org/sec1-v2.pdf>.

     [SEC2]     Certicom Research, "SEC 2: Recommended Elliptic Curve
                Domain Parameters", 2010,
                <http://www.secg.org/sec2-v2.pdf>.

  11.2.  Informative References

     [AC_BreCleFis24]
                Brendel, J., Clermont, S., and M. Fischlin, "Post-Quantum
                Asynchronous Remote Key Generation for FIDO2 Account
                Recovery. ASIACRYPT '24", 2023,
                <https://eprint.iacr.org/2023/1275>.

     [ASIACCS_SteWil24]
                Stebila, D. and S. M. Wilson, "Quantum-Safe Account
                Recovery for WebAuthn. ASIACCS '24", 2023,
                <https://eprint.iacr.org/2024/678>.

     [BIP32]    Wuille, P., "BIP 32 Hierarchical Deterministic Wallets",
                2012, <https://github.com/bitcoin/bips/blob/master/bip-
                0032.mediawiki>.

     [CCS_FGKLMN20]
                Frymann, N., Gardham, D., Kiefer, F., Lundberg, E.,
                Manulis, M., and D. Nilsson, "Asynchronous Remote Key
                Generation: An Analysis of Yubico's Proposal for W3C
                WebAuthn. CCS '20: Proceedings of the 2020 ACM SIGSAC
                Conference on Computer and Communications Security", 2020,
                <https://eprint.iacr.org/2020/1004>.




  Lundberg & Bradley       Expires 31 August 2026                [Page 37]


  Internet-Draft                    ARKG                     February 2026


     [EUROSP_FryGarMan23]
                Frymann, N., Gardham, D., and M. Manulis, "Asynchronous
                Remote Key Generation for Post-Quantum Cryptosystems from
                Lattices. 2023 IEEE 8th European Symposium on Security and
                Privacy", 2023, <https://eprint.iacr.org/2023/419>.

     [I-D.dijkhuis-cfrg-hdkeys]
                Dijkhuis, S., "Hierarchical Deterministic Keys", Work in
                Progress, Internet-Draft, draft-dijkhuis-cfrg-hdkeys-06,
                19 January 2025, <https://datatracker.ietf.org/doc/html/
                draft-dijkhuis-cfrg-hdkeys-06>.

     [Shoup]    Shoup, V., "A Proposal for an ISO Standard for Public Key
                Encryption (version 2.0)", 2001,
                <https://www.shoup.net/papers/iso-2.pdf>.

     [WebAuthn-Recovery]
                Lundberg, E. and D. Nilsson, "WebAuthn recovery extension:
                Asynchronous delegated key generation without shared
                secrets. GitHub", 2019,
                <https://github.com/Yubico/webauthn-recovery-extension>.

     [Wilson2023]
                Wilson, S. M., "Post-Quantum Account Recovery for
                Passwordless Authentication. Master's thesis", 2023,
                <http://hdl.handle.net/10012/19316>.

  Appendix A.  Test Vectors

     This section lists test vectors for validating implementations.

     Test vectors are listed in CDDL [RFC8610] syntax using variable names
     defined in Section 2 and Section 3.  Elliptic curve points are
     encoded using the Elliptic-Curve-Point-to-Octet-String procedure
     defined in section 2.3.3 of [SEC1], without point compression.

  A.1.  ARKG-P256














  Lundberg & Bradley       Expires 31 August 2026                [Page 38]


  Internet-Draft                    ARKG                     February 2026


     ; Inputs:
     ctx         = 'ARKG-P256.test vectors'
     ikm_bl      = h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f'
     ikm_kem     = h'202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f'
     ikm         = h'404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f'

     ; Derive-Seed:
     DST_bl_sk   = h'41524b472d424c2d45432d4b472e41524b472d50323536'
     DST_kem_sk  = h'41524b472d4b454d2d454344482d4b472e41524b472d454344482e41524b472d50323536'
     pk_bl       = h'046d3bdf31d0db48988f16d47048fdd24123cd286e42d0512daa9f726b4ecf18df
                       65ed42169c69675f936ff7de5f9bd93adbc8ea73036b16e8d90adbfabdaddba7'
     pk_kem      = h'04c38bbdd7286196733fa177e43b73cfd3d6d72cd11cc0bb2c9236cf85a42dcff5
                       dfa339c1e07dfcdfda8d7be2a5a3c7382991f387dfe332b1dd8da6e0622cfb35'
     sk_bl       = 0xd959500a78ccf850ce46c80a8c5043c9a2e33844232b3829df37d05b3069f455
     sk_kem      = 0x74e0a4cd81ca2d24246ff75bfd6d4fb7f9dfc938372627feb2c2348f8b1493b5

     ; Derive-Public-Key:
     ctx_bl      = h'41524b472d4465726976652d4b65792d424c2e1641524b472d503235362e7465737420766563746f7273'
     ctx_kem     = h'41524b472d4465726976652d4b65792d4b454d2e1641524b472d503235362e7465737420766563746f7273'
     ctx_sub     = h'41524b472d4b454d2d484d41432e41524b472d454344482e41524b472d5032353641524b472d4465726976652d4b65792d4b454d2e1641524b472d503235362e7465737420766563746f7273'
     DST_kem_sk  = h'41524b472d4b454d2d454344482d4b472e41524b472d454344482e41524b472d50323536'
     k_prime     = h'fa027ebc49603a2a41052479f6e9f6d046175df2f00cecb403f53ffcd1cc698f'
     c_prime     = h'0487fc739dbcdabc293ac5469221da91b220e04c681074ec4692a76ffacb9043dec2847ea9060fd42da267f66852e63589f0c00dc88f290d660c65a65a50c86361'
     info_mk     = h'41524b472d4b454d2d484d41432d6d61632e41524b472d454344482e41524b472d5032353641524b472d4465726976652d4b65792d4b454d2e1641524b472d503235362e7465737420766563746f7273'
     mk          = h'796c615d19ca0044df0a22d64ba8d5367dca18da32b871a3e255db0af7eb53c9'
     t           = h'27987995f184a44cfa548d104b0a461d'
     info_k      = h'41524b472d4b454d2d484d41432d7368617265642e41524b472d454344482e41524b472d5032353641524b472d4465726976652d4b65792d4b454d2e1641524b472d503235362e7465737420766563746f7273'
     k           = h'cf5e8ddbb8078a6a0144d4412f22f89407ecee30ec128ce07836af9fc51c05d0'
     c           = h'27987995f184a44cfa548d104b0a461d0487fc739dbcdabc293ac5469221da91b220e04c681074ec4692a76ffacb9043dec2847ea9060fd42da267f66852e63589f0c00dc88f290d660c65a65a50c86361'
     ikm_tau     = h'cf5e8ddbb8078a6a0144d4412f22f89407ecee30ec128ce07836af9fc51c05d0'
     DST_tau     = h'41524b472d424c2d45432e41524b472d5032353641524b472d4465726976652d4b65792d424c2e1641524b472d503235362e7465737420766563746f7273'
     tau         = 0x9e042fde2e12c1f4002054a8feac60088cc893b4838423c26a20af686c8c16e3
     pk_prime    = h'04572a111ce5cfd2a67d56a0f7c684184b16ccd212490dc9c5b579df749647d107
                       dac2a1b197cc10d2376559ad6df6bc107318d5cfb90def9f4a1f5347e086c2cd'
     kh          = h'27987995f184a44cfa548d104b0a461d0487fc739dbcdabc293ac5469221da91b220e04c681074ec4692a76ffacb9043dec2847ea9060fd42da267f66852e63589f0c00dc88f290d660c65a65a50c86361'

     ; Derive-Private-Key:
     sk_prime    = 0x775d7fe9a6dfba43ce671cb38afca3d272c4d14aff97bd67559eb500a092e5e7













  Lundberg & Bradley       Expires 31 August 2026                [Page 39]


  Internet-Draft                    ARKG                     February 2026


     ; Inputs:
     ctx         = 'ARKG-P256.test vectors'
     ikm_bl      = h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f'
     ikm_kem     = h'202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f'
     ikm         = h'a0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebf'

     ; Derive-Seed:
     DST_bl_sk   = h'41524b472d424c2d45432d4b472e41524b472d50323536'
     DST_kem_sk  = h'41524b472d4b454d2d454344482d4b472e41524b472d454344482e41524b472d50323536'
     pk_bl       = h'046d3bdf31d0db48988f16d47048fdd24123cd286e42d0512daa9f726b4ecf18df
                       65ed42169c69675f936ff7de5f9bd93adbc8ea73036b16e8d90adbfabdaddba7'
     pk_kem      = h'04c38bbdd7286196733fa177e43b73cfd3d6d72cd11cc0bb2c9236cf85a42dcff5
                       dfa339c1e07dfcdfda8d7be2a5a3c7382991f387dfe332b1dd8da6e0622cfb35'
     sk_bl       = 0xd959500a78ccf850ce46c80a8c5043c9a2e33844232b3829df37d05b3069f455
     sk_kem      = 0x74e0a4cd81ca2d24246ff75bfd6d4fb7f9dfc938372627feb2c2348f8b1493b5

     ; Derive-Public-Key:
     ctx_bl      = h'41524b472d4465726976652d4b65792d424c2e1641524b472d503235362e7465737420766563746f7273'
     ctx_kem     = h'41524b472d4465726976652d4b65792d4b454d2e1641524b472d503235362e7465737420766563746f7273'
     ctx_sub     = h'41524b472d4b454d2d484d41432e41524b472d454344482e41524b472d5032353641524b472d4465726976652d4b65792d4b454d2e1641524b472d503235362e7465737420766563746f7273'
     DST_kem_sk  = h'41524b472d4b454d2d454344482d4b472e41524b472d454344482e41524b472d50323536'
     k_prime     = h'38c79546fc4a144ae2068ff0b515fc9af032b8255a78a829e71be47676a63117'
     c_prime     = h'0457fd1e438280c127dd55a6138d1baf0a35e3e9671f7e42d8345f47374afa83247a078fa2196cd69497aed59ef92c05cb6b03d306ec24f2f4ff2db09cd95d1b11'
     info_mk     = h'41524b472d4b454d2d484d41432d6d61632e41524b472d454344482e41524b472d5032353641524b472d4465726976652d4b65792d4b454d2e1641524b472d503235362e7465737420766563746f7273'
     mk          = h'0806abac4c1d205c3a8826cd178fbf7f91741268e3ca73634035efd76085d2a9'
     t           = h'b7507a82771776fbac41a18d94e19a7e'
     info_k      = h'41524b472d4b454d2d484d41432d7368617265642e41524b472d454344482e41524b472d5032353641524b472d4465726976652d4b65792d4b454d2e1641524b472d503235362e7465737420766563746f7273'
     k           = h'dcdd95c742ddf25b8a95f3d76326cb3593b7860bb3e04c5e5b25cc15ce1e5c84'
     c           = h'b7507a82771776fbac41a18d94e19a7e0457fd1e438280c127dd55a6138d1baf0a35e3e9671f7e42d8345f47374afa83247a078fa2196cd69497aed59ef92c05cb6b03d306ec24f2f4ff2db09cd95d1b11'
     ikm_tau     = h'dcdd95c742ddf25b8a95f3d76326cb3593b7860bb3e04c5e5b25cc15ce1e5c84'
     DST_tau     = h'41524b472d424c2d45432e41524b472d5032353641524b472d4465726976652d4b65792d424c2e1641524b472d503235362e7465737420766563746f7273'
     tau         = 0x88cf9464b041a52cf2b837281afc67302ec9cb32da1fe515381b79c0d0c92322
     pk_prime    = h'04ea7d962c9f44ffe8b18f1058a471f394ef81b674948eefc1865b5c021cf858f5
                       77f9632b84220e4a1444a20b9430b86731c37e4dcb285eda38d76bf758918d86'
     kh          = h'b7507a82771776fbac41a18d94e19a7e0457fd1e438280c127dd55a6138d1baf0a35e3e9671f7e42d8345f47374afa83247a078fa2196cd69497aed59ef92c05cb6b03d306ec24f2f4ff2db09cd95d1b11'

     ; Derive-Private-Key:
     sk_prime    = 0x6228e470290e9d7cc0feff32a74caafa14c608c956337eba23997f5904cff226













  Lundberg & Bradley       Expires 31 August 2026                [Page 40]


  Internet-Draft                    ARKG                     February 2026


     ; Inputs:
     ctx         = 'ARKG-P256.test vectors.0'
     ikm_bl      = h'000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f'
     ikm_kem     = h'202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f'
     ikm         = h'404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f'

     ; Derive-Seed:
     DST_bl_sk   = h'41524b472d424c2d45432d4b472e41524b472d50323536'
     DST_kem_sk  = h'41524b472d4b454d2d454344482d4b472e41524b472d454344482e41524b472d50323536'
     pk_bl       = h'046d3bdf31d0db48988f16d47048fdd24123cd286e42d0512daa9f726b4ecf18df
                       65ed42169c69675f936ff7de5f9bd93adbc8ea73036b16e8d90adbfabdaddba7'
     pk_kem      = h'04c38bbdd7286196733fa177e43b73cfd3d6d72cd11cc0bb2c9236cf85a42dcff5
                       dfa339c1e07dfcdfda8d7be2a5a3c7382991f387dfe332b1dd8da6e0622cfb35'
     sk_bl       = 0xd959500a78ccf850ce46c80a8c5043c9a2e33844232b3829df37d05b3069f455
     sk_kem      = 0x74e0a4cd81ca2d24246ff75bfd6d4fb7f9dfc938372627feb2c2348f8b1493b5

     ; Derive-Public-Key:
     ctx_bl      = h'41524b472d4465726976652d4b65792d424c2e1841524b472d503235362e7465737420766563746f72732e30'
     ctx_kem     = h'41524b472d4465726976652d4b65792d4b454d2e1841524b472d503235362e7465737420766563746f72732e30'
     ctx_sub     = h'41524b472d4b454d2d484d41432e41524b472d454344482e41524b472d5032353641524b472d4465726976652d4b65792d4b454d2e1841524b472d503235362e7465737420766563746f72732e30'
     DST_kem_sk  = h'41524b472d4b454d2d454344482d4b472e41524b472d454344482e41524b472d50323536'
     k_prime     = h'fa027ebc49603a2a41052479f6e9f6d046175df2f00cecb403f53ffcd1cc698f'
     c_prime     = h'0487fc739dbcdabc293ac5469221da91b220e04c681074ec4692a76ffacb9043dec2847ea9060fd42da267f66852e63589f0c00dc88f290d660c65a65a50c86361'
     info_mk     = h'41524b472d4b454d2d484d41432d6d61632e41524b472d454344482e41524b472d5032353641524b472d4465726976652d4b65792d4b454d2e1841524b472d503235362e7465737420766563746f72732e30'
     mk          = h'd342e45f224a7278f11cf1468922c8879f4529125181d4159e4bf9ee69842f04'
     t           = h'81c4e65b552e52350b49864b98b87d51'
     info_k      = h'41524b472d4b454d2d484d41432d7368617265642e41524b472d454344482e41524b472d5032353641524b472d4465726976652d4b65792d4b454d2e1841524b472d503235362e7465737420766563746f72732e30'
     k           = h'cde7e271f8da72e5fd2557de362420ddb170dce520362131670eb1080823a113'
     c           = h'81c4e65b552e52350b49864b98b87d510487fc739dbcdabc293ac5469221da91b220e04c681074ec4692a76ffacb9043dec2847ea9060fd42da267f66852e63589f0c00dc88f290d660c65a65a50c86361'
     ikm_tau     = h'cde7e271f8da72e5fd2557de362420ddb170dce520362131670eb1080823a113'
     DST_tau     = h'41524b472d424c2d45432e41524b472d5032353641524b472d4465726976652d4b65792d424c2e1841524b472d503235362e7465737420766563746f72732e30'
     tau         = 0x513ea417b6cdc3536178fa81da36b4e5ecdc142c2d46a52e05257f21794e3789
     pk_prime    = h'04b79b65d6bbb419ff97006a1bd52e3f4ad53042173992423e06e52987a037cb61
                       dd82b126b162e4e7e8dc5c9fd86e82769d402a1968c7c547ef53ae4f96e10b0e'
     kh          = h'81c4e65b552e52350b49864b98b87d510487fc739dbcdabc293ac5469221da91b220e04c681074ec4692a76ffacb9043dec2847ea9060fd42da267f66852e63589f0c00dc88f290d660c65a65a50c86361'

     ; Derive-Private-Key:
     sk_prime    = 0x2a97f4232f9abba32fbfc28c6686f8afd2d851c2a95a3ed2f0a384b9ad55068d

  A.2.  Other instances

     TODO









  Lundberg & Bradley       Expires 31 August 2026                [Page 41]


  Internet-Draft                    ARKG                     February 2026


  Acknowledgements

     ARKG was first proposed under this name by Frymann et al.
     [CCS_FGKLMN20], who analyzed a proposed extension to W3C Web
     Authentication by Lundberg and Nilsson [WebAuthn-Recovery], which was
     in turn inspired by a similar construction by Wuille [BIP32] used to
     create privacy-preserving Bitcoin addresses.  Frymann et al.
     [CCS_FGKLMN20] generalized the constructions by Lundberg, Nilsson and
     Wuille from elliptic curves to any discrete logarithm (DL) problem,
     and also proved the security of arbitrary asymmetric protocols
     composed with ARKG.  Further generalizations to include quantum-
     resistant instantiations were developed independently by Brendel et
     al.  [AC_BreCleFis24], Frymann et al.  [EUROSP_FryGarMan23] and
     Wilson [Wilson2023].

     This document adopts the construction proposed by Wilson
     [Wilson2023], modified by the inclusion of a MAC in the key handles
     as done in the original construction by Frymann et al.
     [CCS_FGKLMN20].  The construction by Wilson [Wilson2023] was later
     refined by Stebila et al.  [ASIACCS_SteWil24], but this revision
     replaced the "key blinding scheme" component with a "key-blinding
     signature scheme" component which is not one-for-one compatible with
     the construction in the present revision of this specification.

     The authors would like to thank all of these authors for their
     research and development work that led to the creation of this
     document.

  Document History

     -10

     *  Fixed tau misspelled as tau' in body of BL-Blind-Private-Key in
        section "Using elliptic curve addition for key blinding".

     *  Fixed definitions and references misspelling ESP512 as ESP521.

     *  Minor editorial clarifications.

     *  Updated informative references to research papers and changed
        citation style for the same.

     *  Made "Acknowledgements" and "Document History" sections un-
        numbered.

     *  Added Implementation Status section.

     -09



  Lundberg & Bradley       Expires 31 August 2026                [Page 42]


  Internet-Draft                    ARKG                     February 2026


     *  Fixed hash_to_field argument ikm_tau misnamed as tau in section
        "Using elliptic curve addition for key blinding".

     *  Updated to match draft -02 of [I-D.lundberg-cose-split-algs].

        -  COSE algorithm identifier definitions for ARKG instances moved
           from section "COSE key type: ARKG public seed" to new section
           "COSE algorithms".

        -  Added COSE algorithm identifier definitions for signature
           algorithms with key derived using ARKG.

        -  COSE key type Ref-ARKG-Derived deleted in favour of new
           COSE_Sign_Args algorithm parameters.

        -  Section "COSE key reference type: ARKG derived private key"
           replaced with "COSE signing arguments".

        -  Added section "COSE Signing Arguments Algorithm Parameters
           Registrations".

     -08

     *  Fixed incorrectly swapped ikm_bl and ikm_kem arguments in ARKG-
        Derive-Seed definition.

     *  Extracted parameter function BL-PRF and modified signatures of BL-
        Blind-Public-Key and BL-Blind-Private-Key accordingly.  This is an
        editorial refactorization; overall operation of concrete ARKG
        instances is unchanged.

     *  Removed three redundant sets of ARKG-P256 test vectors.

     *  Added intermediate values to ARKG-P256 test vectors.

     *  Changed second set of ARKG-P256 test vectors to use a 32-byte ikm
        instead of h'00'.

     *  Clarified in sections "Using HMAC to adapt a KEM without
        ciphertext integrity", "Using ECDH as the KEM" and "Using X25519
        or X448 as the KEM" that ctx_sub is intentionally ignored in those
        instances.

     -07

     *  Fixed hash_to_field DST in Sub-Kem-Derive-Key-Pair in section
        "Using ECDH as the KEM" to agree with test vectors.




  Lundberg & Bradley       Expires 31 August 2026                [Page 43]


  Internet-Draft                    ARKG                     February 2026


     -06

     *  Changed DST construction in section "Using ECDH as the KEM" to
        include the "ARKG-ECDH." prefix everywhere in the formula.
        Previously the prefix was added in the argument to the "Using HMAC
        to adapt a KEM without ciphertext integrity" formula but not in
        the Sub-Kem functions defined in "Using ECDH as the KEM".

     -05

     *  Deleted concrete instances ARKG-curve25519ADD-X25519, ARKG-
        curve448ADD-X448, ARKG-edwards25519ADD-X25519 and ARKG-
        edwards448ADD-X448 since implementations with a non-prime order
        generator, including EdDSA, are incompatible with the additive
        blinding scheme defined in section "Using elliptic curve addition
        for key blinding".

     *  Remodeled procedures to be fully deterministic:

        -  BL-Generate-Keypair() replaced with BL-Derive-Key-Pair(ikm).

        -  KEM-Generate-Keypair() replaced with KEM-Derive-Key-Pair(ikm).

        -  ARKG-Generate-Seed() replaced with ARKG-Derive-Seed(ikm_bl,
           ikm_kem).

        -  Parameter ikm added to ARKG-Derive-Public-Key.

        -  Instance parameter hash-to-crv-suite added to generic formula
           "Using ECDH as the KEM", affecting concrete instances ARKG-
           P256ADD-ECDH, ARKG-P384ADD-ECDH, ARKG-P521ADD-ECDH and ARKG-
           P256kADD-ECDH.

        -  Section "Deterministic key generation" deleted.

     *  Flipped order of (pk_bl, pk_kem) and (sk_bl, sk_kem) parameter and
        return value tuples for consistent ordering between BL and KEM
        throughout document.

     *  info parameter renamed to ctx.

     *  ctx length limited to at most 64 bytes.

     *  Encoding of ctx in ARKG-Derive-Public-Key and ARKG-Derive-Private-
        Key now embeds the length of ctx.

     *  Renamed concrete instances and corresponding DST_ext values:




  Lundberg & Bradley       Expires 31 August 2026                [Page 44]


  Internet-Draft                    ARKG                     February 2026


        -  ARKG-P256ADD-ECDH to ARKG-P256

        -  ARKG-P384ADD-ECDH to ARKG-P384

        -  ARKG-P521ADD-ECDH to ARKG-P521

        -  ARKG-P256kADD-ECDH to ARKG-P256k

     *  Added ARKG-P256 test vectors.

     -04

     *  Extracted COSE_Key_Ref definition and COSE algorithm registrations
        to draft-lundberg-cose-two-party-signing-algs.

     *  Redefined alg (3) parameter and added dkalg (-3) in ARKG-pub
        COSE_Key.

     *  Defined alg (3) and inst (-3) parameters of Ref-ARKG-derived COSE
        key type.

     -03

     *  Renamed section "Using HMAC to adapt a KEM without {integrity
        protection => ciphertext integrity}".

     *  Fixed info argument to HMAC in section "Using HMAC to adapt a KEM
        without ciphertext integrity".

     *  Added reference to Shoup for definition of key encapsulation
        mechanism.

     *  Added CDDL definition of COSE_Key_Ref.

     *  Editorial fixes to references.

     *  Renamed proposed COSE Key Types.

     -02

     *  Rewritten introduction.

     *  Renamed ARKG-Derive-Secret-Key to ARKG-Derive-Private-Key.

     *  Overhauled EC instantiations to use hash_to_field and account for
        non-prime order curve key generation.

     *  Eliminated top-level MAC and KDF instance parameters.



  Lundberg & Bradley       Expires 31 August 2026                [Page 45]


  Internet-Draft                    ARKG                     February 2026


     *  Added info parameter to instance parameter functions.

     *  Added requirement of KEM ciphertext integrity and generic formula
        for augmenting any KEM using HMAC.

     *  Added curve/edwards25519/448 instances.

     *  Added proposal for COSE bindings and key reference types.

     -01

     *  Editorial fixes to formatting and references

     -00

     *  Initial Version

  Contributors

     Dain Nilsson
     Yubico


     Peter Altmann
     Agency for Digital Government
     Sweden


     Michael B. Jones
     Self-Issued Consulting
     United States
     URI:   https://self-issued.info/


     Sander Dijkhuis
     Cleverbase
     Netherlands


  Authors' Addresses

     Emil Lundberg (editor)
     Yubico
     Gävlegatan 22
     Stockholm
     Sweden
     Email: emil@emlun.se




  Lundberg & Bradley       Expires 31 August 2026                [Page 46]


  Internet-Draft                    ARKG                     February 2026


     John Bradley
     Yubico
     Email: ve7jtb@ve7jtb.com
















































  Lundberg & Bradley       Expires 31 August 2026                [Page 47]


name: draft-ietf-roll-enrollment-priority
rev: 15
title: Controlling Secure Network Enrollment in RPL networks
time: 2026-02-20T15:43:37Z
group_uri: /api/v1/group/group/1730/
expires: 2026-07-28T19:17:14Z
ad: /api/v1/person/person/122823/
shepherd: /api/v1/person/email/mariainesrobles@googlemail.com/
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/13/", "/api/v1/doc/state/44/"]
categories: ["Agent discovery/reg", "Autonomous netops"]
tags: []
fetched_at: 2026-02-27T22:56:07.990704+00:00
abstract:
  [RFC9032] defines a method by which a potential [RFC9031] enrollment
     proxy can announce itself as available for new RPL nodes to enroll on
     a network.  The announcement includes a priority for enrollment.
     This document provides a mechanism by which a Routing Protocol for
     Low-Power and Lossy Networks (RPL) Root can globally disable
     enrollment announcements or adjust the base priority for enrollment
     operations.

full_text:
  ROLL Working Group                                         M. Richardson
  Internet-Draft                                  Sandelman Software Works
  Intended status: Standards Track                            R. A. Jadhav
  Expires: 28 July 2026                                        Huawei Tech
                                                                P. Thubert
                                                             Cisco Systems
                                                               K. Iwanicki
                                                      University of Warsaw
                                                           24 January 2026


           Controlling Secure Network Enrollment in RPL networks
                   draft-ietf-roll-enrollment-priority-15

  Abstract

     [RFC9032] defines a method by which a potential [RFC9031] enrollment
     proxy can announce itself as available for new RPL nodes to enroll on
     a network.  The announcement includes a priority for enrollment.
     This document provides a mechanism by which a Routing Protocol for
     Low-Power and Lossy Networks (RPL) Root can globally disable
     enrollment announcements or adjust the base priority for enrollment
     operations.

  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 28 July 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.






  Richardson, et al.        Expires 28 July 2026                  [Page 1]


  Internet-Draft                 join-metric                  January 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Motivation and Overview . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Protocol Definition . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Option Format . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.  Option Processing . . . . . . . . . . . . . . . . . . . .   5
       3.3.  Upwards Compatibility . . . . . . . . . . . . . . . . . .   6
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   8
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
       8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     [RFC7554] describes the use of the Time-Slotted Channel Hopping
     (TSCH) mode of [ieee802154].  [RFC9031] and [RFC9032] describe
     mechanisms by which a new node (the "Pledge") can use a nearby router
     as a Join Proxy.  [RFC9032] describes an extension to the 802.15.4
     Enhanced Beacon that is used by a Join Proxy to announce its
     existence such that Pledges can find them.

  1.1.  Motivation and Overview

     Not every routing member of a mesh ought to announce itself as a
     _Join Proxy_. There are a variety of local reasons for which a
     6LowPAN Router (6LR) might not want to provide the _Join Proxy_
     function.  Some reasons include low available battery power, already
     high committed network bandwidth, and lack of available free memory
     for Neighbor Cache Entry (NCE) slots.  An NCE entry is needed in
     order to maintain communication with the Pledge nodes trying to
     enroll.





  Richardson, et al.        Expires 28 July 2026                  [Page 2]


  Internet-Draft                 join-metric                  January 2026


     There are other situations where the operator of the network would
     like to selectively enable or disable the enrollment process in a
     specific Destination Oriented Directed Acyclic Graph (DODAG).  In
     particular, as the enrollment process involves permitting unencrypted
     traffic into the best effort part of a network, it would be better to
     turn the enrollment process off when no new nodes are expected.

     This document describes a Routing Protocol for Low-Power and Lossy
     Networks (RPL) Destination Information Object (DIO) option that can
     be used to set a minimum enrollment priority.  The minimum priority
     expresses the inability of the RPL DODAG globally to accept new
     joins.  It may derive from multiple constraining factors, for
     instance, the size of the DODAG, the occupancy of the bandwidth at
     the DODAG Root, the memory capacity at the Root, or an administrative
     decision.  Each potential _Join Proxy_ utilizes this value as a base
     on which to add values relating to local conditions, such as its Rank
     and number of pending joins.  As explained in [RFC9032], higher
     values decrease the likelihood of an unenrolled node sending
     enrollment traffic via this _Join Proxy_. In particular, by setting
     the minimum enrollment priority to the maximum value allowed, a
     network operator can globally disable all new enrollment traffic.

     Moreover, when a RPL domain is composed of multiple DODAGs, a node at
     the edge of more than one such DODAG may not only join any of the
     DODAGs but also move between them in order to keep their relative
     sizes balanced.  For this, the approximate knowledge of the size of
     the DODAGs is also an essential metric.  Depending on the network
     policy, the size of the DODAG may or may not affect the minimum
     enrollment priority.  Therefore, since making one proportional to the
     other would be limiting their value, the current size of the DODAG is
     advertised separately in the new option.

     Updates to the option propagate through the network according to the
     trickle algorithm.  The contents of the option are generated at the
     DODAG Root and do not change at any hop.  If the contents represent
     an update that is considered important (e.g., quickly disabling any
     enrollments), the option can trigger trickle timer resets at the
     nodes to speed up its propagation.

  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.





  Richardson, et al.        Expires 28 July 2026                  [Page 3]


  Internet-Draft                 join-metric                  January 2026


     The term 6LR means 6LowPAN Router, and is defined in [RFC6606].  It
     refers to a router that forwards packets in a 6LowPAN network.

     The terms DAO, DODAG, DODAG root, DIO, trickle timer are from
     [RFC6550].  The lollipop counter function comes from [RFC6550],
     Section 7.2.

     The term (1)"Join" has been used in documents such as [RFC9031] to
     denote the activity of a new node authenticating itself to the
     network to obtain authorization to become a member of the network.

     In the context of the [RFC6550] RPL protocol, the term (2)"Join" has
     an alternative meaning: that of a node (already authenticated to the
     network, and already authorized to be a member of the network),
     deciding which part of the RPL DODAG to attach to.  This term "Join"
     has to do with preferred parent selection processes.

     In order to avoid the ambiguity of this term, this document refers to
     the process (1)"Join" as enrollment, leaving the term "Join" to mean
     (2)"Join".  The term "onboarding" (or "IoT Onboarding") is
     increasingly used to describe what is now called (1)Join in other
     documents, and is called enrollment in this document.  However, the
     term _Join Proxy_ is retained with its (1)"Join" meaning from
     [RFC9031].

  3.  Protocol Definition

     This document uses the extensions mechanism specified by [RFC6550].
     No mechanism is needed to enable it.

  3.1.  Option Format

     The following option is defined for transmission in DIOs issued by
     the DODAG Root to be propagated within the DODAG.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Type = TBD01  |Opt Length = 4 |Version Number |T| Min Priority|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Exp  |DODAGSz|
        +-+-+-+-+-+-+-+-+

     Type  To be assigned by IANA.

     Version Number  An 8-bit unsigned integer set by the DODAG root and





  Richardson, et al.        Expires 28 July 2026                  [Page 4]


  Internet-Draft                 join-metric                  January 2026


        denoting the version number of the contents of the option.  The
        version number is interpreted as a lollipop counter (see
        Section 7.2 of [RFC6550]).

     T  A bit indicating whether the particular version of the option is
        important in that adopting its contents should trigger a trickle
        timer reset at the node.

     Min Priority  A 7-bit field providing a base value for the Enhanced
        Beacon Join priority.  A value of 0x7f (127) disables the _Join
        Proxy_ function entirely.

     Exp  A 4-bit unsigned integer indicating the power of 2 that defines
        the unit of the DODAG Size, such that (unit = 2^Exp).

     DODAGSz  A 4-bit unsigned integer expressing the size of the DODAG in
        units that depend on the Exp field.

     The DODAG Size is calculated as (DODAGSz * 2^Exp).

     The DODAG Size can be measured by the Root based on the DAO activity.
     In such a case, it represents the number of routes not the number of
     nodes, and can thus be used to infer the load only in a network where
     each node advertises roughly the same number of addresses and
     generates roughly the same amount of traffic.

     As the DODAG Size is always a multiple of a power of 2, when the
     actual size falls between two such values, the DODAG Root is to
     always round up.

     Future work such as [I-D.ietf-roll-capabilities] will enable
     collection of capabilities such as this one in reports to the DODAG
     Root.

     In any case, the DODAG Size may slightly change between one DIO and
     the next, so the value transmitted is considered as an approximation.

  3.2.  Option Processing

     The contents of the option MUST be generated by the DODAG Root.  A
     6LR MUST NOT change the option when propagating it.

     Whenever the DODAG root changes the values of Min Priority or DODAG
     Size in the option, it MUST also increment the value of Version
     Number.  Moreover, if the change is considered important (i.e., it is
     expected to propagate in the DODAG quickly), the DODAG Root SHOULD
     also set the T bit to 1; otherwise, it MUST set the bit to 0.




  Richardson, et al.        Expires 28 July 2026                  [Page 5]


  Internet-Draft                 join-metric                  January 2026


     Upon receiving the option, a 6LR first checks the value of the
     Version Number field in the option, _vr_, versus the value of the
     Version Number it has last adopted locally, _vl_.

     *  If _vl_ is greater than _vr_ (in the lollipop counter order), then
        the 6LR MUST ignore the received option.

     *  Otherwise, the 6LR MUST adopt the contents of the option (i.e.,
        the values of Version Number, Min Priority, DODAG Size, and the T
        bit) as its local ones.  Moreover, if _vl_ was smaller than _vr_
        (in the lollipop counter order) and the T bit in the received
        option was set, then the 6LR MUST reset its DIO trickle timer.

     A 6LR, which would otherwise be willing to act as a _Join Proxy_,
     will examine the locally adopted value of Min Priority and to that
     number add any additional local consideration (such as upstream
     congestion, number of NCE slots available, etc.).

     The maximum resulting value any 6LR can obtain this way is 0x7f.

     The resulting priority, if less than 0x7f, should enable the _Join
     Proxy_ function.

  3.3.  Upwards Compatibility

     A 6LR that did not support this option would not act on it or
     propagate it in its DIO messages.  In effect, the 6LR's subtree nodes
     could not receive any telemetry.  Therefore, 6LRs that support this
     option but do not receive it via any path SHOULD assume a default
     value of 0x40 as their base value for the Enhanced Beacon Join
     Priority.

     A 6LR downstream of a 6LR where there was such an interruption in the
     telemetry could err in two directions:

     *  If the value implied by the base value of 0x40 was too low, then
        the 6LR might continue to attract enrollment traffic when none
        should have been collected.  This is a stressor for the network,
        but this would also be what would occur without this option at
        all.











  Richardson, et al.        Expires 28 July 2026                  [Page 6]


  Internet-Draft                 join-metric                  January 2026


     *  If the value implied by the base value of 0x40 was too high, then
        the 6LR might deflect enrollment traffic to other parts of the
        DODAG, possibly refusing any enrollment traffic at all.  In order
        for this to happen, some significant congestion must be seen in
        the sub-DODAG where the implied 0x40 was introduced.  The 0x40 is
        only the half-way point, so if such an amount of congestion was
        present, then this sub-DODAG of the DODAG simply winds up being
        more cautious than it needed to be.

     It is possible that the temporal alternation of the above two
     situations might introduce cycles of accepting and then rejecting
     enrollment traffic.  This is something an operator should consider if
     they incrementally deploy this option to an existing Low-power/Lossy-
     Network (LLN).  In addition, an operator would be unable to turn off
     enrollment traffic by sending a maximum value enrollment priority to
     the sub-DODAG.  This situation is unfortunate, but without this
     option, the situation would occur all over the DODAG, rather than
     just in the sub-DODAG that the option did not reach.

  4.  Security Considerations

     As per [RFC7416], RPL control frames either run over a secured layer
     2 or use the [RFC6550] Secure DIO methods at layer 3.  This option
     can be placed into either a "clear" (layer-2 secured) DIO or a
     layer-3 Secure DIO.

     In most deployments involving wireless technology, layer 2 is always
     encrypted using a layer-2 specific technology, and so privacy of this
     option is available.

     However, a malicious node that was part of the RPL control plane
     (i.e., had been enrolled into the layer-2 security) would be able to
     see the values of this option and, based upon the observed minimal
     enrollment priority, could signal a confederate that it was a good
     time to send malicious join traffic.

     What is more, such a malicious node, being already part of the RPL
     control plane, could also send DIOs with a different minimal
     enrollment priority, which would cause downstream mesh routers to
     change their _Join Proxy_ behavior: lower minimal priorities would
     cause downstream nodes to accept more Pledges than the network was
     expecting; higher minimal priorities could cause the enrollment
     process to stall.

     The use of layer-2 or layer-3 security for RPL control messages
     prevents the two aforementioned attacks by non-participating nodes by
     preventing malicious nodes from becoming part of the control plane.




  Richardson, et al.        Expires 28 July 2026                  [Page 7]


  Internet-Draft                 join-metric                  January 2026


     Nevertheless, a node that is attacked and has malware placed on it
     creates vulnerabilities in the same way such an attack on any node
     involved in Internet routing protocol does.  The rekeying provisions
     of [RFC9031] exist to permit an operator to remove such nodes from
     the network.

  5.  Privacy Considerations

     There are no new privacy issues caused by this extension.

  6.  IANA Considerations

     Allocate a new number TBD01 from Registry RPL Control Message
     Options.  This entry should be called Minimum Enrollment Priority.

  7.  Acknowledgements

     This has been reviewed by Charlie Perkins, Rifaat Shehk-Yusek, Dave
     Thaler, and Thomas Watteyne.

     Huimin She contributed text about expressing the DODAG size.

  8.  References

  8.1.  Normative References

     [ieee802154]
                IEEE standard for Information Technology, "IEEE Std.
                802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
                and Physical Layer (PHY) Specifications for Low-Rate
                Wireless Personal Area Networks", n.d.,
                <http://standards.ieee.org/findstds/
                standard/802.15.4-2015.html>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
                Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
                JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
                Low-Power and Lossy Networks", RFC 6550,
                DOI 10.17487/RFC6550, March 2012,
                <https://www.rfc-editor.org/rfc/rfc6550>.






  Richardson, et al.        Expires 28 July 2026                  [Page 8]


  Internet-Draft                 join-metric                  January 2026


     [RFC7416]  Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
                and M. Richardson, Ed., "A Security Threat Analysis for
                the Routing Protocol for Low-Power and Lossy Networks
                (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
                <https://www.rfc-editor.org/rfc/rfc7416>.

     [RFC7554]  Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
                IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
                Internet of Things (IoT): Problem Statement", RFC 7554,
                DOI 10.17487/RFC7554, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7554>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC9031]  Vučinić, M., Ed., Simon, J., Pister, K., and M.
                Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH",
                RFC 9031, DOI 10.17487/RFC9031, May 2021,
                <https://www.rfc-editor.org/rfc/rfc9031>.

     [RFC9032]  Dujovne, D., Ed. and M. Richardson, "Encapsulation of
                6TiSCH Join and Enrollment Information Elements",
                RFC 9032, DOI 10.17487/RFC9032, May 2021,
                <https://www.rfc-editor.org/rfc/rfc9032>.

  8.2.  Informative References

     [I-D.ietf-roll-capabilities]
                Jadhav, R., Thubert, P., Richardson, M., and R. N. Sahoo,
                "RPL Capabilities", Work in Progress, Internet-Draft,
                draft-ietf-roll-capabilities-09, 9 November 2021,
                <https://datatracker.ietf.org/doc/html/draft-ietf-roll-
                capabilities-09>.

     [RFC6606]  Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
                Statement and Requirements for IPv6 over Low-Power
                Wireless Personal Area Network (6LoWPAN) Routing",
                RFC 6606, DOI 10.17487/RFC6606, May 2012,
                <https://www.rfc-editor.org/rfc/rfc6606>.

  Authors' Addresses

     Michael Richardson
     Sandelman Software Works
     Email: mcr+ietf@sandelman.ca





  Richardson, et al.        Expires 28 July 2026                  [Page 9]


  Internet-Draft                 join-metric                  January 2026


     Rahul Arvind Jadhav
     Huawei Tech
     Email: rahul.ietf@gmail.com


     Pascal Thubert
     Cisco Systems
     Email: pthubert@cisco.com


     Konrad Iwanicki
     University of Warsaw
     Email: iwanicki@mimuw.edu.pl






































  Richardson, et al.        Expires 28 July 2026                 [Page 10]


name: draft-contario-totp-secure-enrollment
rev: 02
title: TOTP Secure Enrollment
time: 2025-09-27T00:30:24Z
group_uri: /api/v1/group/group/1027/
expires: 2026-03-31T00:30:24Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment"]
tags: []
fetched_at: 2026-02-27T22:56:07.990725+00:00
abstract:
  This document describes a secure key exchange scheme that extends the
     Time-Based One-Time Password (TOTP) [RFC6238] de facto enrollment
     method to prevent compromise of the non-expiring TOTP key by
     photographic capture of the QR code or by intentional or
     unintentional persistence of the key string in email, SMS, or other
     systems outside of the TOTP authenticator system itself.

full_text:
  Network Working Group                                        B. Contario
  Internet-Draft                                             Silent Sector
  Intended status: Informational                         27 September 2025
  Expires: 31 March 2026


                           TOTP Secure Enrollment
                  draft-contario-totp-secure-enrollment-02

  Abstract

     This document describes a secure key exchange scheme that extends the
     Time-Based One-Time Password (TOTP) [RFC6238] de facto enrollment
     method to prevent compromise of the non-expiring TOTP key by
     photographic capture of the QR code or by intentional or
     unintentional persistence of the key string in email, SMS, or other
     systems outside of the TOTP authenticator system itself.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at https://Silent-
     Sector.github.io/totp-secure-enrollment/draft-contario-totp-secure-
     enrollment.html.  Status information for this document may be found
     at https://datatracker.ietf.org/doc/draft-contario-totp-secure-
     enrollment/.

     Source for this draft and an issue tracker can be found at
     https://github.com/Silent-Sector/totp-secure-enrollment.

  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 31 March 2026.




  Contario                  Expires 31 March 2026                 [Page 1]


  Internet-Draft           totp-secure-enrollment           September 2025


  Copyright Notice

     Copyright (c) 2025 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.  Terminologies . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     2.  TOTP Background . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  TOTP Enrollment . . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.  Hexadecimal String Enrollment . . . . . . . . . . . . . .   6
       3.3.  QR Code Enrollment  . . . . . . . . . . . . . . . . . . .   6
     4.  Enrollment Vulnerabilities  . . . . . . . . . . . . . . . . .   7
       4.1.  Hexadecimal String Enrollment Vulnerabilities . . . . . .   7
       4.2.  QR Code Enrollment Vulnerabilities  . . . . . . . . . . .   8
       4.3.  Elevated Risk for QR Code Enrollment  . . . . . . . . . .   8
     5.  TOTP Secure Enrollment  . . . . . . . . . . . . . . . . . . .   9
       5.1.  Mechanism of Operation  . . . . . . . . . . . . . . . . .   9
       5.2.  Device Enrollment Data  . . . . . . . . . . . . . . . . .  10
       5.3.  Secure Enrollment QR code Workflow  . . . . . . . . . . .  12
       5.4.  Secure Enrollment Copy Paste Workflow . . . . . . . . . .  13
       5.5.  Workflow Notes  . . . . . . . . . . . . . . . . . . . . .  14
       5.6.  Requirements  . . . . . . . . . . . . . . . . . . . . . .  14
       5.7.  Reference Code  . . . . . . . . . . . . . . . . . . . . .  16
       5.8.  Exclusions  . . . . . . . . . . . . . . . . . . . . . . .  16
       5.9.  Alternative Network Transports  . . . . . . . . . . . . .  16
       5.10. Applicability to Other Algorithms . . . . . . . . . . . .  17
     6.  Related Enhancements  . . . . . . . . . . . . . . . . . . . .  17
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
       7.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .  17
       7.2.  TOTP secret key exchange  . . . . . . . . . . . . . . . .  17
       7.3.  Secret key harvesting . . . . . . . . . . . . . . . . . .  18
       7.4.  Secure Enrollment Flag  . . . . . . . . . . . . . . . . .  18
     8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  18
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19



  Contario                  Expires 31 March 2026                 [Page 2]


  Internet-Draft           totp-secure-enrollment           September 2025


       10.1.  Normative References . . . . . . . . . . . . . . . . . .  19
       10.2.  Informative References . . . . . . . . . . . . . . . . .  19
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  20
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  21

  1.  Introduction

     The common practice of presenting a QR Code for Time-Based One-Time
     Password (TOTP) enrollment exposes the actual shared TOTP secret key
     used by the TOTP algorithm for multi-factor authentication.  A
     fallback method of showing the key string to be typed or copied and
     pasted into a multi-factor authenticator application also exposes the
     key.  In both cases the key that is exposed is the permanent shared
     TOTP secret key that, by current standards and processes, is expected
     to never expire.

     The below process instead replaces the secret key in the QR code with
     a URL to the TOTP service for the authenticator application to
     request the secret key over a secure network transport without
     authentication.  The URL provided uses an atomic one-time use data
     token (nonce) so only one request for the secret key is honored.  If
     both the user and an attacker use the URL, only one will get the
     secret key, and only the user will have an active session to complete
     enrollment by entering the proper TOTP value derived from the secret
     key.  If the attacker gets the secret key, the user will not and the
     user will be forced to generate a new QR code with a URL to a new
     secret key until they successfully get the secret key and complete
     TOTP Verification by entering the current one-time password, meaning
     the attacker will be guaranteed to not have the same secret key.  In
     cases where the URL to the TOTP service is not accessible, the legacy
     shared TOTP secret key exchange via QR Code or text string may be
     offered as a fallback with appropriate warnings displayed against key
     exposure.

  1.1.  Terminologies

     TOTP:  Time-Based One-Time Password as described in [RFC6238], and by
        itself in this document referring only to the algorithm, not the
        implementation.

     TOTP secret key:  the hexadecimal [RFC6238] string representing a
        value unique to each prover, per [RFC6238] section 3.

     hardware token:  Usually a dedicated-purpose hardware device that is
        issued to users.  In this document it refers to a device that is
        pre-set with a TOTP secret key used to display one-time passwords
        that provide prover functionality.




  Contario                  Expires 31 March 2026                 [Page 3]


  Internet-Draft           totp-secure-enrollment           September 2025


     soft token:  Usually a software application that provides enrollment
        and prover functionality without dedicated hardware, usually
        running on a smartphone, tablet, personal computer, or password
        manager application.  In this document it refers specifically to
        an application that stores a TOTP secret key and provides TOTP
        prover functionality.  Sometimes referred to in other documents as
        a “soft token” or “software token”, as opposed to a “hardware
        token”.

     prover:  In this document referring to an implementation of the TOTP
        protocol that provides a periodically changing one-time password
        based on the time and a TOTP secret key.  A prover may be
        implemented as an authenticator application (software token) or
        implemented as a hardware token.

     nonce:  a randomly-generated cryptographic data token that is used to
        prevent replay attacks by only allowing the value to be used once,
        somewhat analogous to a paper ticket that is torn in half or
        scanned and invalidated when presented for admission to a venue to
        prevent reuse.

     TOTP service:  A service used to enroll and verify the TOTP one-time
        password provided by a prover and associated with a specific
        authentication request.  Also referred to as a “verifier” in
        [RFC6238], as described below.

     verifier:  Per [RFC6238] section 3.R1, an authentication or
        validation server, and in this case for TOTP.

     enrollment:  also referred to as _provisioning_ per [RFC6238] section
        4.2, and _registration_ in [draft-strbac-totp2], the exchange of
        the TOTP secret key between the verifier and the prover, followed
        by the verification of the prover's one-time password by the
        verifier, and the respective secure storage and linking of TOTP
        secret key to an identity for MFA.

     URL:  used explicitly in this document to specify a "Uniform Resource
        Locator" providing a location and means of access to obtain
        information via a transfer request.  In this document expect the
        URL to require a transfer using the specified protocol to get the
        desired information.

     otpauth URI:  used explicitly in this document to specify a "Uniform
        Resource Identifier" providing information for immediate use for
        TOTP enrollment, per [totp-uri-format] and
        [draft-linuxgemini-otpauth-uri].  In this document expect the
        otpauth URI to convey the desired information in a single step
        without an additional transfer step required.



  Contario                  Expires 31 March 2026                 [Page 4]


  Internet-Draft           totp-secure-enrollment           September 2025


  1.2.  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.  TOTP Background

     The basis of Time-Based One-Time Password (TOTP) [RFC6238] is a
     symmetric algorithm for both the prover and the verifier to combine a
     string containing a shared TOTP secret key and the current Unix epoch
     seconds [RFC3339] which are hashed using SHA-1 or a similar
     cryptographic hash algorithm.  The result is converted to a decimal
     number and truncated, typically to 6 digits, to be used as the one-
     time password value that the prover supplies and the verifier accepts
     as valid only if it calculates the same one-time password value.

     TOTP requires that the TOTP secret key, as defined in [RFC6238]
     section 3 requirement R2, must be known by both the prover and the
     verifier.  The original implementation of TOTP may have been intended
     for use primarily in hardware tokens that were factory-issued with an
     unchangeable TOTP secret key, which was a common practice for
     hardware tokens, since [RFC6238] did not define a protocol for the
     TOTP secret key exchange.  However, increased use of mobile devices
     that synchronize their time with wireless communication providers and
     NTP servers have allowed for the proliferation of authenticator
     applications running on mobile devices, laptops, and desktop
     computers, all of which require receiving a unique TOTP secret key
     from each new verifier.  Therefore, a protocol evolved as a de facto
     industry standard for enrollment to exchange the TOTP secret key,
     described in the next section.

  3.  TOTP Enrollment

  3.1.  Overview

     For consistency and specificity, the remainder of this document will
     use the term “TOTP service” in place of “verifier”.

     For TOTP enrollment using an authenticator application, it is most
     logical for the TOTP service to generate the shared TOTP secret key
     using cryptographically secure random number generators to ensure
     that each prover has a unique TOTP secret key that has not been used
     elsewhere.  Therefore it is an accepted standard for the TOTP service
     to generate the key and store it securely, and for the authenticator
     application to simply accept and store the key in a secure manner.



  Contario                  Expires 31 March 2026                 [Page 5]


  Internet-Draft           totp-secure-enrollment           September 2025


     The current TOTP enrollment protocol was likely influenced or
     established by the [GoogleAuth] project, which provided a working
     reference system of two complementary methods for the TOTP service to
     share the TOTP secret key with the prover during enrollment,
     described as follows.

  3.2.  Hexadecimal String Enrollment

     The TOTP secret key itself is expressed as a hexadecimal string of an
     arbitrary length chosen by the TOTP service.  During enrollment the
     TOTP service can display the randomly generated hexadecimal string to
     the user for them to type or paste into an authenticator application.
     Typical strengths are >= 160 bits.

  3.3.  QR Code Enrollment

     To avoid typographic errors when the user enters the TOTP secret key
     into the prover that was provided by the TOTP service, the use of a
     [QR_Code] was introduced so that manual data entry was not required
     by the user.  The QR Code encodes an otpauth URI scheme, per the
     [totp-uri-format] and proposed as a draft IETF standard
     [draft-linuxgemini-otpauth-uri] with the following parameters:

     algorithm=(SHA1|SHA256|SHA512)
       OPTIONAL, defaults to SHA1.

     secret=[websafe Base32 encoded TOTP secret key, no padding]
       REQUIRED, 128 bits or more.

     digits=(6|8)
       OPTIONAL, defaults to 6.

     period=N  (totp specific)
       OPTIONAL, defaults to 30.

     The otpauth URI also includes a human-readable Label to identify the
     issuer and account name.  Some TOTP services also supply a "user"
     parameter.  Both the account name and user parameter could disclose
     the complete identity that the TOTP secret key applies to.  Below is
     a fictitious example otpauth URI that could be encoded into a QR Code
     for the user "human@domain.com" using the ExampleCorp service:

  otpauth://totp/ExampleCorp%3Ahuman%40domain.com?secret=bl4gbf4ab5l3rj3d6htrxc6bqhrx3m7u&issuer=ExampleCorp

     and a urldecoded version of the text:

  otpauth://totp/ExampleCorp:human@domain.com?secret=bl4gbf4ab5l3rj3d6htrxc6bqhrx3m7u&issuer=ExampleCorp




  Contario                  Expires 31 March 2026                 [Page 6]


  Internet-Draft           totp-secure-enrollment           September 2025


     Of particular note is that the TOTP secret key value of the "secret"
     parameter is provided in BASE32 plaintext with no cryptographic
     protections of any kind, and no expiration or method of revocation
     for the TOTP secret key if the QR Code or otpauth URI is stored,
     copied, or transmitted beyond the intended use, or if the TOTP secret
     key is discovered compromised in any other way.

  4.  Enrollment Vulnerabilities

     The above two enrollment methods do not follow the recommendations
     listed in [RFC6238] section 5.1 stating:

        All the communications SHOULD take place over a secure channel,
        e.g., Secure Socket Layer/Transport Layer Security (SSL/TLS)
        [RFC5246] or IPsec connections [RFC4301].

     This results in a wide range of vulnerabilities.

  4.1.  Hexadecimal String Enrollment Vulnerabilities

     Hexadecimal String Enrollment where the TOTP secret key string is
     visibly presented to the user is often vulnerable to compromise by
     the following non-exhaustive list of vectors:

     1.  a nearby observer viewing and remembering the visible TOTP secret
         key

     2.  a nearby observer photographing the visible TOTP secret key

     3.  the user copying the key to the computer's clipboard and then
         pasting the TOTP secret key into the prover during enrollment
         (which exposes the key to potentially malicious applications that
         monitor the clipboard contents)

     4.  the user copying the TOTP secret key to the computer's clipboard
         and then pasting the TOTP secret key into an email, instant
         message, or SMS message to send to another user for enrollment
         (which may persist the TOTP secret key in external or internal
         systems indefinitely)

     5.  the user copying the TOTP secret key to a computer's clipboard
         and then pasting into a file for later use (which which may
         persist the TOTP secret key to local or cloud storage)








  Contario                  Expires 31 March 2026                 [Page 7]


  Internet-Draft           totp-secure-enrollment           September 2025


  4.2.  QR Code Enrollment Vulnerabilities

     Enrollment via [QR_Code] where the encoded TOTP secret key is visible
     presented to the user is often vulnerable to compromise by the
     following non-exhaustive list of vectors:

     1.  a nearby observer photographing the QR Code

     2.  the user copying the QR Code image into an email or SMS message
         to send to another user for enrollment (which may persist the
         TOTP secret key in external or internal systems indefinitely)

     3.  the user photographing the QR Code image on their mobile device
         for later use by the authenticator application (which may persist
         the TOTP secret key in external or internal systems indefinitely)

     4.  the user photographing the QR Code image on their mobile device
         to send to another user via email, instant message, cloud
         service, or SMS for enrollment (which may persist the TOTP secret
         key in external or internal systems indefinitely)

     5.  the user printing the QR Code image to complete enrollment later

  4.3.  Elevated Risk for QR Code Enrollment

     As described earlier, the string encoded in the QR Code is a
     [RFC3986] URI that contains all of the needed information to link the
     key to the TOTP service and the user with which it is associated,
     referred to in this document as an otpauth URI.  The information
     provided in the QR Code greatly simplifies the TOTP enrollment since
     the user does not need to name the entry in their authenticator
     application or type in a hexadecimal string, so most users opt for
     the QR Code enrollment method.

     However, the tradeoff for this convenience is that the QR Code
     potentially contains all of the information needed by an attacker to
     log in to the associated target system as the associated user, except
     for the user's first factor password.  If the target system is
     internet-facing and the login page can be identified by name or other
     intelligence, and the user's identifier is an email address that can
     be found in a database of accounts with compromised passwords, then
     having the TOTP secret key, also in the QR Code, potentially gives
     the attacker all of the factors needed to log in as the user to the
     target system.







  Contario                  Expires 31 March 2026                 [Page 8]


  Internet-Draft           totp-secure-enrollment           September 2025


     Because of the vectors by which the QR Code could be unintentionally
     exposed or stored on systems outside of the user's control for later
     harvesting, a secure enrollment method that does not expose the TOTP
     secret key is needed.

  5.  TOTP Secure Enrollment

     The following method protects the TOTP secret key via HTTPS/TLS as
     recommended in [RFC6238] section 5.1 when the TOTP service is
     accessible on a public or private network via a URL that can be
     generated by the TOTP service.

     Since this document is dealing only with TOTP implementations, the
     remainder of this document will prefer the shortened form of “Secure
     Enrollment” in place of “TOTP Secure Enrollment”, and “authenticator
     application” in place of “TOTP authenticator application”

  5.1.  Mechanism of Operation

     The "secret" parameter of the otpauth URI, as described in
     [totp-uri-format], normally only accepts a BASE32 encoded hexadecimal
     secret key.  However, in a “Secure Enrollment otpauth URI”, the
     “secret” parameter MUST accept a urlencoded URL with a HTTPS protocol
     string.  This URL, referred to from here forward as the “Secure
     Enrollment URL”, is how the authenticator application connects to the
     TOTP service to get a copy of the legacy otpauth URI that contains
     the secret key.

     The [RFC3986] URL specification requires the protocol in a URL be
     separated by a colon (“:”) which is urlencoded into “%3A”.  Because
     both the “%” and “:” characters are not valid in BASE32 encoding,
     their presence in the “secret” parameter can effectively be used as a
     signal that the value of the “secret” parameter should be urldecoded
     and the resulting value used as the Secure Enrollment URL to request
     the original format TOTP otpauth URI containing the plaintext TOTP
     secret key via a network connection.

     To minimize the data that is stored in the Secure Enrollment QR code,
     all of the optional fields SHOULD NOT be included in the Secure
     Enrollment otpauth URI.  Only the “secret” parameter of the otpauth
     URI should be populated (as shown below).

     *The actual enrollment data, in the form of an otpauth URI, used by
     the authenticator application does not change.  The enrollment data
     simply gets delivered via HTTPS instead of embedded in a QR code.*






  Contario                  Expires 31 March 2026                 [Page 9]


  Internet-Draft           totp-secure-enrollment           September 2025


     The Secure Enrollment URL MUST include a nonce value that will be
     marked as invalid after first use by the TOTP service to insure that
     the request is only ever responded to one time only (not more than
     once).  The Secure Enrollment URL gets added to the “Secure
     Enrollment otpauth URI”, then encoded into a QR Code, then displayed
     to the user, and then decoded by the user's authenticator
     application.

     A sample Secure Enrollment otpauth URI for ExampleCorp:

  otpauth://totp/?secret=https%3A%2F%2Fexamplecorp.com%2Fapi%2Fenrollmfa%2F16062671560671769238465892

     The Secure Enrollment URL portion of the URI follows the “?secret=”
     portion and decodes to:

     https://examplecorp.com/api/enrollmfa/16062671560671769238465892

     The authenticator application MUST make a HTTP POST request using the
     Secure Enrollment URL to retrieve the otpauth URI text string in the
     same legacy format used by authenticator applications prior to
     adoption of TOTP Secure Enrollment.

     It should also be noted that the use of a QR code is not required for
     Secure Enrollment.  The user’s authenticator application could accept
     the Secure Enrollment URL via QR code, copy and paste, or manual
     entry of the Secure Enrollment URL text itself.

  5.2.  Device Enrollment Data

     TOTP enrollment has historically been a “blind” process because there
     was no direct interaction between the authenticator application and
     the TOTP service.  Administrators had no information to help end-
     users that forgot what device or authenticator application they to
     use to get their 6 digit TOTP codes.

     Now the authenticator application makes a HTTP POST request to the
     TOTP service during Secure Enrollment, so there is an opportunity to
     send and capture information for administrators to provide hints
     about which device and authenticator application an end user should
     use to log in.

     When the authenticator application makes the POST request it SHOULD
     send a request body with device enrollment data in JSON format using
     Content-Type set to “application/json”.  The sending of this
     enrollment data is optional.  The recommended content of the JSON
     data is as follows:





  Contario                  Expires 31 March 2026                [Page 10]


  Internet-Draft           totp-secure-enrollment           September 2025


     {
         "event_type":"totp-secure-enrollment",
         "time_local":"Sun, 22 Sep 2024 23:46:30 -0400",
         "time_utc":"2024-09-23T03:46:30.637Z",
         "device_model":"F990",
         "device_manufacturer":"Foo",
         "os_name":"android",
         "os_version":"12",
         "application_name":"Aegis",
         "application_version":"3.1.1",
         "location_description":"Cincinnati, Ohio, USA",
         "location_longitude":"-84.512",
         "location_latitude":"39.103"
     }

     All element values should be evaluated as strings and contain the
     following information:

     event_type:  always the literal string "totp-secure-enrollment" for
        easy identification by humans and machine

     time_local:  time of enrollment, recommended formatted as RFC 1123
        Date Time for local time of the device for human readability

     time_utc:  time of enrollment, ISO-8601 instant format recommended
        for machine readability

     device_model:  the device model name or the model number

     device_manufacturer:  the device manufacturer name

     os_name:  the operating system name

     os_version:  the operating system version in human readable form

     application_name:  the authenticator application name or title

     application_version:  the authenticator application version in human
        readable form

     location_description:  if available and permitted, a descriptive name
        for the location of the device at the time of enrollment,
        preferably showing country, region / state / province, and
        municipality

     location_longitude:  if available and permitted, the coarse longitude
        of the device at the time of enrollment




  Contario                  Expires 31 March 2026                [Page 11]


  Internet-Draft           totp-secure-enrollment           September 2025


     location_latitude:  if available and permitted, the coarse latitude
        of the device at the time of enrollment

     It is also optional, but recommended, for the TOTP service to store
     and/or parse the device enrollment data for future use.  The data can
     be used for both end user assistance and administrative review of the
     different devices being used for TOTP Secure Enrollment.

  5.3.  Secure Enrollment QR code Workflow

     The Secure Enrollment ideal workflow will follow these general steps
     when using a QR code is viable:

     1.  *Enrollment Request*: The user initiates the enrollment process
         for TOTP for 2FA or MFA on their account.  The user experience is
         then passed to the TOTP service.

     2.  *Secure Enrollment Preparation*: The TOTP service generates a
         nonce and a random TOTP secret key, storing them both temporarily
         in a secure location with a configurable validity period
         (expiration) for human interaction, such as 5 minutes.

     3.  *Secure Enrollment Presentation*: The TOTP service generates and
         presents to the user a QR Code that contains an otpauth URI in
         the format established by [GoogleAuth], but instead of the
         "secret" parameter containing the TOTP secret key, it contains a
         urlencoded network-accessible HTTPS URL with only a nonce and no
         secret key.

     4.  *User Interaction*: The user interacts with the TOTP
         authenticator application to scan the QR Code presented.

     5.  *Secure Key Request*: When the authenticator application detects
         a “%” or “:” character in the "secret" parameter value of the
         otpauth URI, the authenticator application performs the new
         Secure Enrollment functionality by urldecoding the “secret”
         parameter and using that value in a HTTP POST request.














  Contario                  Expires 31 March 2026                [Page 12]


  Internet-Draft           totp-secure-enrollment           September 2025


     6.  *Secure Key Response*: When the TOTP service receives the HTTP
         POST request with the nonce, the redeem is atomic.  The TOTP
         service looks up the nonce from temporary secure storage and if
         the nonce is not expired it atomically expires the nonce and
         returns the response (over the HTTPS/TLS secure channel) with the
         otpauth URI containing the secret key in the legacy de facto
         format, the same data that would normally be provided in the QR
         Code by the [GoogleAuth] code prior to implementation of Secure
         Enrollment.  At the same time, the TOTP service optionally stores
         the JSON device enrollment data contained in the POST request
         body for future use.

     7.  *TOTP Enrollment*: The authenticator application extracts the
         "issuer", "secret", "digits", and other parameters from the
         otpauth URI and registers a new entry in the authenticator
         application.  This step is unchanged from the previous process,
         except the otpauth URI with the secret key is delivered via HTTPS
         rather than the QR Code.

     8.  *TOTP Verification*: The TOTP service presents a user interface
         that requires the user to enter the current one-time password and
         verify it before considering the user fully enrolled.

     9.  *Secure Enrollment Flag*: It is RECOMMENDED that in addition to
         the new TOTP secret key, the enrollment data stored by the TOTP
         service should include a Secure Enrollment Flag to indicate that
         this enrollment was completed over a secure channel.  This can be
         used for auditing purposes and to force users to re-enroll their
         TOTP authenticator application entries that were not completed in
         a secure manner in the past.

  5.4.  Secure Enrollment Copy Paste Workflow

     The Secure Enrollment ideal workflow will follow the same general
     steps as the above QR code workflow when it is easier to copy and
     paste a text string than to use a QR code, with the exception of the
     following two steps which are slightly modified and used instead of
     the same numbered steps: 3. *Secure Enrollment Presentation*: The
     TOTP service displays in selectable text the otpauth URI in the
     format established by [GoogleAuth], but instead of the "secret"
     parameter containing the TOTP secret key, it contains a urlencoded
     network-accessible HTTPS URL with only a nonce and no actual secret
     key.  The user optionally copies the otpauth URI text into the
     clipboard or transfers it electronically. 4. *User Interaction*: The
     user interacts with the authenticator application by pasting or
     typing in the otpauth URI text and submitting it.





  Contario                  Expires 31 March 2026                [Page 13]


  Internet-Draft           totp-secure-enrollment           September 2025


  5.5.  Workflow Notes

     In both the Copy Paste Workflow and the QR code Workflow, the final
     secret key that is enrolled is never exposed to the user, attackers,
     or other systems.  The secret key is directly exchanged via HTTPS
     between the TOTP service and the authenticator application.

  5.6.  Requirements

     Secure Enrollment requires the following that is not already defined
     in [RFC6238]:

     1.   The TOTP service MUST be able to create a Secure Enrollment URL
          to an API endpoint that can accept an anonymous HTTPS POST
          request.

     2.   The TOTP service API endpoint SHOULD be configured to require
          non-deprecated TLS ciphers via HTTPS.

     3.   The Secure Enrollment URL MUST be resolvable and accessible to
          the authenticator application via internet or private network
          connection at the time of enrollment.

     4.   The TOTP service MUST generate a cryptographically secure random
          string data token to be used as a nonce to both include in the
          URL and store in secure temporary storage to be accessed by the
          API endpoint.  It is recommended that the nonce have at least 96
          bits of entropy.  Newly-generated GUID v4 or UUID v4 values with
          122 bits of entropy are acceptable nonce values at the time of
          this writing.

     5.   The TOTP service MUST set a nonce validity period (expiration)
          for completion of the human actions.  The nonce validity period
          SHOULD be reasonable for authorized users, such as 5 minutes
          into the future.

     6.   The TOTP service MUST NOT permanently store the generated secret
          key as enrolled until after the user has completed TOTP
          Verification by entering the current one-time password as a part
          of an existing user session authenticated with a previous
          factor.

     7.   The TOTP service MUST generate an otpauth URI whose secret
          parameter value is the Secure Enrollment URL, percent-encoded
          per [RFC3986] section 2.  The Secure Enrollment URL MUST NOT
          include credentials and MUST only include the nonce and
          necessary routing parameters.




  Contario                  Expires 31 March 2026                [Page 14]


  Internet-Draft           totp-secure-enrollment           September 2025


     8.   The TOTP service MUST exclude optional parts (per
          [totp-uri-format]) from the Secure Enrollment otpauth URI that
          is presented to the end user as a QR code or text string to
          limit data exposure.

     9.   The TOTP service SHOULD NOT issue http redirects.  Redirects
          MUST NOT downgrade confidentiality (e.g., to http).

     10.  The authenticator application MUST NOT follow http redirects.

     11.  The authenticator application MUST allow the otpauth QR code to
          exclude all optional data from the otpauth URI, including the
          Label and user/account parameter, only providing the “secret”
          parameter that is populated with the Secure Enrollment URL.

     12.  The TOTP service API endpoint MUST invalidate the nonce after
          its expiration period or atomically redeem it upon first use by
          the API endpoint, whichever comes first, using appropriate
          concurrency locking mechanisms to avoid race conditions.

     13.  The TOTP service MUST generate a new secret key any time a new
          nonce value is generated for a Secure Enrollment URL.  To avoid
          any race conditions or other security concerns, if the user
          requests a new QR code or refreshes the page containing the
          otpauth URI or QR code, a new secret key and nonce value MUST be
          generated and supplied.

     14.  The TOTP service API endpoint MUST NOT respond with an actual
          secret key unless the nonce is found in secure temporary
          storage, is unused, and the current time is within the validity
          period.  On success, the endpoint MUST return HTTP 200 with a
          body containing the otpauth URI in the same format established
          by [GoogleAuth] as described in [totp-uri-format] with the
          “secret” parameter containing the BASE32 encoded secret key.
          The response SHOULD include Cache-Control: no-store and SHOULD
          include Pragma: no-cache.  Implementations MUST NOT log the
          returned secret key or full otpauth URI.

     15.  The TOTP service API endpoint SHOULD respond with a uniform HTTP
          4xx series response error code and message whether the nonce is
          invalid or expired, preferably a 403 Forbidden response.  In
          environments with specialized security needs the TOTP service
          API endpoint MAY choose to respond with any other non-usable
          response, including a TCP disconnect, 200 success code with a
          blank response, a URL with a decoy TOTP secret key, or any other
          response that serves the purpose of thwarting an attacker with a
          false positive response.




  Contario                  Expires 31 March 2026                [Page 15]


  Internet-Draft           totp-secure-enrollment           September 2025


     16.  The TOTP service MAY offer a user-initiated option in the UI to
          switch to legacy enrollment.  Prior to redirecting the user to
          legacy enrollment the UI SHOULD display a localizable message
          that warns the user to protect the legacy QR Code and/or the
          TOTP secret key string from observation and photographic or
          video capture, and avoid saving, sending, or transmitting them
          in any form to prevent compromise of the TOTP secret key.

  5.7.  Reference Code

     Pull requests illustrating reference implementations based on working
     open source code bases can be found here:

     TOTP Secure Enrollment authenticator application reference code
     [totp-secure-enrollment-reference-authenticator]

     TOTP Secure Enrollment server framework demo code
     [totp-secure-enrollment-reference-server]

  5.8.  Exclusions

     TOTP Secure Enrollment does not claim or provide any additional
     benefit in the following non-exhaustive list of areas:

     1.  Protection of the secret key once it is stored in the
         authenticator application after successful Secure Enrollment.

     2.  If the device containing the authenticator application is
         obtained by an attacker or is compromised by malware.

     3.  Assisting in inventorying or tracking enrolled systems to
         invalidate the enrolled secret key.

     4.  Purposefully setting up the same TOTP enrollment on multiple
         authenticator applications for redundancy or shared accounts.
         This is a usage scenario for TOTP outside of industry best
         practices and incurs elevated risk.  Secure Enrollment is not
         intended to protect or facilitate this.

  5.9.  Alternative Network Transports

     This specification defines Secure Enrollment only over HTTPS.  Use of
     other transports is out of scope.  Implementations MAY define private
     extensions, but interoperability is not expected.







  Contario                  Expires 31 March 2026                [Page 16]


  Internet-Draft           totp-secure-enrollment           September 2025


  5.10.  Applicability to Other Algorithms

     Other multi-factor authentication algorithms / protocols could
     benefit by adapting this secure enrollment process to exchange shared
     secrets.  The following is a non-exhaustive list of possible
     candidates:

     *  HMAC-based One-Time Password (HOTP) [RFC4226]

     *  OATH Challenge-Response Algorithm (OCRA) [RFC6287]

  6.  Related Enhancements

     There are other efforts to improve the TOTP experience and security,
     such as proposed in draft [draft-strbac-totp2].  It is believed that
     the Secure Enrollment method described here can work in conjunction
     with and enhance the enrollment / registration process as described
     in [draft-strbac-totp2] section "3.  Authentication Scheme Overview"
     to improve the security of the "TOTP2 Registration" step.

  7.  Security Considerations

  7.1.  General

     All security considerations for the execution of TOTP and storage of
     the TOTP secret key are covered in [RFC6238].

  7.2.  TOTP secret key exchange

     The secure exchange of the TOTP secret key MUST use a secure network
     transport protocol, such as HTTPS.  The implementation of the
     protocol SHOULD follow industry best practices, such as:

     1.  TOTP service API endpoints SHOULD only allow HTTPS TLS ciphers
         that are not deprecated by the industry.

     2.  TOTP service API endpoints and authenticator applications SHOULD
         negotiate the supported ciphers in preferred order of perceived
         security by traditional and quantum standards at the time of the
         exchange, always preferring ciphers that are deemed the most
         secure against "harvest now, decrypt later" attacks.

     3.  Clients and servers SHOULD perform certificate validation per the
         HTTPS PKI; endpoints SHOULD enable HSTS; deployments SHOULD avoid
         user-modifiable TLS downgrade mechanisms.






  Contario                  Expires 31 March 2026                [Page 17]


  Internet-Draft           totp-secure-enrollment           September 2025


  7.3.  Secret key harvesting

     Once it is common knowledge that the legacy QR codes used for TOTP
     enrollment have no encryption or safeguards, and they can be reused
     since they contain the non-expiring secret key, attackers may start
     scanning images in cloud storage or sent via MMS that contain QR
     codes to harvest the secret key, along with the other details in the
     QR code otpauth URI.  Identification of a target QR code is trivial
     once decoded into a text string since they all start with
     “otpauth://”.

  7.4.  Secure Enrollment Flag

     It is RECOMMENDED in the workflow above that in addition to the new
     TOTP secret key, the enrollment data stored by the TOTP service
     should include a Secure Enrollment Flag to indicate that this
     enrollment was completed over a secure channel.  It is also
     RECOMMENDED that action be taken against user accounts that do not
     have the Secure Enrollment Flag set on their accounts.  This action
     could include, but is not limited to, one or more of the following
     options that could be happen after a given date for each option:

     1.  Manual human intervention and verification that the authorized
         user completes the new Secure Enrollment process.

     2.  Disable the user accounts until option 1 is performed.

     3.  When the TOTP service detects success for a user with the Secure
         Enrollment Flag set to false, fail the login, and send the user
         through the Secure Enrollment process.  Once they complete it,
         the Secure Enrollment Flag will be set to true and they will be
         able to log in normally using TOTP authentication.

  8.  Privacy Considerations

     This protocol proposes processing enrollment data (the one-time
     Secure Enrollment URL/nonce, server-observed timing/network data, and
     optional client metadata such as device class/OS version and coarse
     location).  Consistent with [RFC6973], servers SHOULD minimize
     collection and use enrollment data only to complete enrollment and
     related security functions (e.g., abuse detection); clients SHOULD
     NOT transmit optional metadata unless the user has clearly opted in
     or a managed-device policy authorizes it; if location is sent, it
     SHOULD be coarse (no precise coordinates).







  Contario                  Expires 31 March 2026                [Page 18]


  Internet-Draft           totp-secure-enrollment           September 2025


  9.  IANA Considerations

     This document has no IANA actions.

  10.  References

  10.1.  Normative References

     [GoogleAuth]
                "Google Authenticator OpenSource", n.d.,
                <https://github.com/google/google-authenticator>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
                Resource Identifier (URI): Generic Syntax", STD 66,
                RFC 3986, DOI 10.17487/RFC3986, January 2005,
                <https://www.rfc-editor.org/rfc/rfc3986>.

     [RFC6238]  M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP:
                Time-Based One-Time Password Algorithm", RFC 6238,
                DOI 10.17487/RFC6238, May 2011,
                <https://www.rfc-editor.org/rfc/rfc6238>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [totp-uri-format]
                "TOTP URI Format", n.d., <https://github.com/google/
                google-authenticator/wiki/Key-Uri-Format>.

  10.2.  Informative References

     [draft-linuxgemini-otpauth-uri]
                Gemini, L., "The otpauth URI Scheme", I-D draft-
                linuxgemini-otpauth-uri, August 2023,
                <https://datatracker.ietf.org/doc/draft-linuxgemini-
                otpauth-uri/>.

     [draft-strbac-totp2]
                "TOTP2 Authentication Scheme", n.d.,
                <https://datatracker.ietf.org/submit/status/135578/>.





  Contario                  Expires 31 March 2026                [Page 19]


  Internet-Draft           totp-secure-enrollment           September 2025


     [QR_Code]  "ISO/IEC 18004, currently ISO/IEC 18004:2015 Information
                technology — Automatic identification and data capture
                techniques — QR Code bar code symbology specification",
                n.d., <https://www.iso.org/standard/62021.html>.

     [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
                Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
                <https://www.rfc-editor.org/rfc/rfc3339>.

     [RFC4226]  M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
                O. Ranen, "HOTP: An HMAC-Based One-Time Password
                Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005,
                <https://www.rfc-editor.org/rfc/rfc4226>.

     [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
                Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
                December 2005, <https://www.rfc-editor.org/rfc/rfc4301>.

     [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
                (TLS) Protocol Version 1.2", RFC 5246,
                DOI 10.17487/RFC5246, August 2008,
                <https://www.rfc-editor.org/rfc/rfc5246>.

     [RFC6287]  M'Raihi, D., Rydell, J., Bajaj, S., Machani, S., and D.
                Naccache, "OCRA: OATH Challenge-Response Algorithm",
                RFC 6287, DOI 10.17487/RFC6287, June 2011,
                <https://www.rfc-editor.org/rfc/rfc6287>.

     [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
                Morris, J., Hansen, M., and R. Smith, "Privacy
                Considerations for Internet Protocols", RFC 6973,
                DOI 10.17487/RFC6973, July 2013,
                <https://www.rfc-editor.org/rfc/rfc6973>.

     [totp-secure-enrollment-reference-authenticator]
                "TOTP Secure Enrollment reference authenticator
                application pull request", n.d.,
                <https://github.com/silentbrianc/Aegis/pull/1/>.

     [totp-secure-enrollment-reference-server]
                "TOTP Secure Enrollment reference server pull request",
                n.d.,
                <https://github.com/silentbrianc/aspnetcore/pull/2/>.

  Acknowledgments

     Thank you to Lauro Chavez and Zach Fuller at Silent Sector for their
     reviews, suggestions, and support.



  Contario                  Expires 31 March 2026                [Page 20]


  Internet-Draft           totp-secure-enrollment           September 2025


     Thank you to Al Katawazi and Craig Tulli of Blueshift Technologies
     for reviews and feedback.

     Thank you to Mike Amundsen of Amundsen.com for guidance in starting
     the IETF draft process.

  Author's Address

     Brian Contario
     Silent Sector
     Email: bcontario@silentsector.com








































  Contario                  Expires 31 March 2026                [Page 21]


