# drafts

name: draft-wang-hjs-accountability
rev: 00
title: HJS: An Accountability Layer for AI Agents
time: 2026-02-21T08:31:59Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-25T08:31:59Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "AI safety/alignment", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:06.864912+00:00
abstract:
This document defines HJS (Human Judgment System), a standalone
accountability layer for AI agents. HJS provides four primitives
(Judgment/Delegation/Termination/Verification) for recording
complete responsibility chains, and uses OTS (Open Timestamp) proofs
anchored to the Bitcoin blockchain to create immutable, court-
admissible evidence. While HJS can complement other protocols (e.g.,
AIIP) by providing the evidence they require, it is designed to be
independent and usable with any AI agent communication framework.

full_text:
Internet-Draft                                          Y. Wang
Intended status: Informational                          HUMAN JUDGMENT SYSTEMS FOUNDATION LTD.
Expires: 21 August 2026                            21 February 2026


                     HJS: An Accountability Layer
                           for AI Agents

                     draft-wang-hjs-accountability-00

Abstract
This document defines HJS (Human Judgment System), a standalone
accountability layer for AI agents. HJS provides four primitives
(Judgment/Delegation/Termination/Verification) for recording
complete responsibility chains, and uses OTS (Open Timestamp) proofs
anchored to the Bitcoin blockchain to create immutable, court-
admissible evidence. While HJS can complement other protocols (e.g.,
AIIP) by providing the evidence they require, it is designed to be
independent and usable with any AI agent communication framework.

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


Wang                     Expires 21 August 2026                 [Page 1]

Internet-Draft          HJS Accountability Layer         21 February 2026

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3. The Four Primitives . . . . . . . . . . . . . . . . . . . . .   3
     3.1. Judgment . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2. Delegation . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3. Termination . . . . . . . . . . . . . . . . . . . . . . .   4
     3.4. Verification . . . . . . . . . . . . . . . . . . . . . .   5
     3.5. Responsibility Chain . . . . . . . . . . . . . . . . . .   5
   4. OTS Evidence Chain . . . . . . . . . . . . . . . . . . . . . .   6
     4.1. OTS Proof Overview . . . . . . . . . . . . . . . . . . .   6
     4.2. Locking the Chain . . . . . . . . . . . . . . . . . . . .   6
   5. Evidence Format  . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1. Complete Evidence Structure  . . . . . . . . . . . . . .   7
     5.2. Verification Process  . . . . . . . . . . . . . . . . . .   8
   6. Relationship with Other Protocols  . . . . . . . . . . . . . .   8
     6.1. Complementing AIIP . . . . . . . . . . . . . . . . . . .   8
     6.2. Independence . . . . . . . . . . . . . . . . . . . . . .   9
   7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1. Regulatory Compliance . . . . . . . . . . . . . . . . . .   9
     7.2. Dispute Resolution . . . . . . . . . . . . . . . . . . .  10
     7.3. Audit Trail . . . . . . . . . . . . . . . . . . . . . . .  10
   8. Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   10. Normative References . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction

   As AI agents become increasingly autonomous, the need for a
   comprehensive accountability layer becomes critical. Current
   protocols focus on how agents communicate and execute tasks, but
   they do not address the fundamental question: who is responsible
   for what, and how can it be proven?

   This document defines HJS (Human Judgment System), a standalone
   accountability layer for AI agents that provides:

   1. Four primitives (Judgment, Delegation, Termination, Verification)
      for recording complete responsibility chains. These capture not
      just what happened, but why it happened, who was involved, and
      how it was verified.


Wang                     Expires 21 August 2026                 [Page 2]

Internet-Draft          HJS Accountability Layer         21 February 2026

   2. OTS evidence chain that anchors cryptographic hashes of the
      primitives to the Bitcoin blockchain, creating immutable, court-
      admissible evidence.

   3. Complete evidence locking that binds all components together into
      a verifiable package.

   HJS is designed to be independent - it does not require any specific
   communication protocol and can be used with any AI agent framework.
   It can also complement existing protocols (such as AIIP
   [draft-sogomonian-aiip-architecture-03]) by providing the
   accountability layer they lack.

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.

3. The Four Primitives

   HJS defines four primitives that together form a complete
   responsibility chain for any AI agent action.

3.1. Judgment

   The Judgment primitive records the basis on which an AI agent made
   its decision. This includes:

   o Input data (or cryptographic commitment to input)
   o Model identifier and version
   o Parameters and configuration
   o Reasoning path (optional)

   Example:

   {
     "judgment": {
       "input_commitment": "base64url(sha256(input))",
       "model_id": "gpt-4-2026-02",
       "parameters": { "temperature": 0.7, "max_tokens": 500 }
     }
   }


Wang                     Expires 21 August 2026                 [Page 3]

Internet-Draft          HJS Accountability Layer         21 February 2026

3.2. Delegation

   The Delegation primitive records the chain of responsibility from
   the original requester to the executing agent:

   o Delegator identifier
   o Agent identifier
   o Delegation time
   o Scope and constraints

   Example:

   {
     "delegation": {
       "from": "aiip://user.phone",
       "to": "aiip://agent.service",
       "time": 1734149100000,
       "scope": "make_call",
       "constraints": { "max_duration": 30000 }
     }
   }

3.3. Termination

   The Termination primitive records the final outcome of the task:

   o Status (success/failure/abort)
   o Reason (if failure)
   o Output commitment
   o Duration

   Example:

   {
     "termination": {
       "status": "success",
       "output_commitment": "base64url(sha256(output))",
       "duration_ms": 2345
     }
   }


Wang                     Expires 21 August 2026                 [Page 4]

Internet-Draft          HJS Accountability Layer         21 February 2026

3.4. Verification

   The Verification primitive records how the result was verified:

   o Verifier identifier
   o Verification method
   o Verification time
   o Result

   Example:

   {
     "verification": {
       "verifier": "aiip://audit.service",
       "method": "ots_verify",
       "time": 1734149110000,
       "result": "valid"
     }
   }

3.5. Responsibility Chain

   The four primitives, when combined, form a complete responsibility
   chain that answers:

   o Why was this done? (Judgment)
   o Who requested it? (Delegation)
   o What happened? (Termination)
   o How was it verified? (Verification)

   Implementations MUST include all four primitives to form a complete
   chain. Each primitive MAY be hashed individually to allow selective
   disclosure while maintaining chain integrity.

4. OTS Evidence Chain

   While the four primitives provide structure for accountability,
   they must be made immutable and verifiable to serve as evidence.
   HJS uses OTS (Open Timestamp) proofs anchored to the Bitcoin
   blockchain for this purpose.

4.1. OTS Proof Overview

   OTS proofs work as follows:

   1. Compute SHA-256 hash of the data to be proven
   2. Submit the hash to the Bitcoin network via Open Timestamp
   3. A Bitcoin transaction includes the hash, creating an immutable
      timestamp
   4. Generate an OTS proof file for verification


Wang                     Expires 21 August 2026                 [Page 5]

Internet-Draft          HJS Accountability Layer         21 February 2026

   Key properties:

   o Decentralized: No trusted third party required
   o Immutable: Once anchored, cannot be altered
   o Publicly verifiable: Anyone can verify with Bitcoin data
   o Court-admissible: Recognized in multiple jurisdictions

4.2. Locking the Chain

   HJS does not simply prove individual primitives - it locks the
   entire responsibility chain together:

   1. Hash each primitive individually (allowing selective disclosure)
   2. Combine the four hashes into a chain hash
   3. Generate an OTS proof of the chain hash
   4. The OTS proof becomes the evidence lock that binds all components
      together

   This ensures that:

   o Any tampering with any primitive breaks the chain
   o Partial disclosure is possible without breaking trust
   o The entire chain has a single, verifiable timestamp

5. Evidence Format

5.1. Complete Evidence Structure

   The complete HJS evidence package includes:

   {
     "hjs": {
       "version": "1.0",
       "primitives": {
         "judgment": { ... },
         "delegation": { ... },
         "termination": { ... },
         "verification": { ... }
       },
       "hashes": {
         "judgment_hash": "base64url(sha256(judgment))",
         "delegation_hash": "base64url(sha256(delegation))",
         "termination_hash": "base64url(sha256(termination))",
         "verification_hash": "base64url(sha256(verification))",
         "chain_hash": "base64url(sha256(judgment_hash + delegation_hash + termination_hash + verification_hash))"
       },
       "evidence": {
         "ots_proof": "base64url(ots-proof-data)",
         "bitcoin_txid": "txid",
         "timestamp": 1734149123000
       }
     }
   }


Wang                     Expires 21 August 2026                 [Page 6]

Internet-Draft          HJS Accountability Layer         21 February 2026

5.2. Verification Process

   To verify an HJS evidence package:

   1. Verify the OTS proof using standard OTS tools
   2. Confirm the OTS proof matches the chain_hash
   3. Recompute each primitive's hash and verify against stored hashes
   4. Optionally, verify individual primitives without accessing others
   5. Check that the chain_hash matches recomputed combination

   This process can be performed by anyone with access to Bitcoin
   blockchain data, without requiring access to the original AI system.

6. Relationship with Other Protocols

6.1. Complementing AIIP

   The AIIP architecture [draft-sogomonian-aiip-architecture-03]
   defines execution receipts and requires attestation evidence.
   HJS naturally complements AIIP by providing exactly what AIIP
   requires but does not specify:

   | AIIP Requirement          | HJS Solution                          |
   |---------------------------|---------------------------------------|
   | Attestation evidence      | OTS proofs anchored to Bitcoin        |
   | Execution receipt         | Can be extended with HJS primitives   |
   | Auditability              | Complete responsibility chain         |
   | External anchoring        | Bitcoin blockchain                    |

   However, HJS is not a subset or extension of AIIP. It is a complete,
   standalone accountability layer that can:

   o Be used with AIIP by embedding HJS evidence in AIIP receipts
   o Be used with any other communication protocol
   o Be used entirely independently for logging and audit purposes

6.2. Independence

   HJS makes no assumptions about:

   o How agents communicate (HTTP, AIIP, custom protocols)
   o What AI models are used
   o Where execution happens (cloud, edge, TEE)
   o Which jurisdiction applies

   It provides a jurisdiction-agnostic, protocol-independent
   accountability layer that can be added to any AI system.


Wang                     Expires 21 August 2026                 [Page 7]

Internet-Draft          HJS Accountability Layer         21 February 2026

7. Use Cases

7.1. Regulatory Compliance

   Organizations subject to regulations (finance, healthcare, EU AI Act)
   can use HJS to demonstrate compliance by maintaining verifiable
   records of AI agent decisions, including:

   o What data was used (Judgment)
   o Who authorized the action (Delegation)
   o What happened (Termination)
   o How it was verified (Verification)
   o Immutable proof of all of the above (OTS evidence)

7.2. Dispute Resolution

   When disputes arise about AI agent actions, HJS provides:

   o Cryptographic proof of what happened
   o Court-admissible evidence recognized in multiple jurisdictions
   o Ability to verify without accessing the original AI system

7.3. Audit Trail

   HJS creates a complete, immutable audit trail for AI agent
   operations, enabling:

   o Internal audits
   o Third-party audits
   o Regulatory examinations
   o Forensic analysis

8. Security Considerations

   The security of HJS evidence depends on:

   o Bitcoin blockchain: As of this writing, Bitcoin has never been
     successfully reorganized to alter confirmed transactions,
     providing strong assurance of immutability.

   o Hash functions: Implementations MUST use SHA-256 or stronger hash
     functions.

   o Key management: If signing is used (e.g., for verifier identity),
     implementations MUST follow best practices for key security.

   o Selective disclosure: The ability to verify individual primitive
     hashes without revealing their content enables privacy-preserving
     audits.


Wang                     Expires 21 August 2026                 [Page 8]

Internet-Draft          HJS Accountability Layer         21 February 2026

9. IANA Considerations

   This document has no IANA actions.

10. Normative References

   [draft-sogomonian-aiip-architecture-03]
              Sogomonian, A., "Artificial Intelligence Internet
              Protocol (AIIP) Architecture", Work in Progress,
              draft-sogomonian-aiip-architecture-03, December 2025.

   [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/info/rfc2119>.

   [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/info/rfc8174>.

   [opentimestamp]
              Open Timestamp Protocol, "Open Timestamp Protocol
              Specification", <https://opentimestamps.org/>, 2016.

   [hjs-github]
              Wang, Y., "HJS Protocol Implementation", MIT License,
              <https://github.com/schchit/hjs-api>.

Author's Address

   Yuqiang Wang
   HUMAN JUDGMENT SYSTEMS FOUNDATION LTD.
   Email: signal@humanjudgment.org
   GitHub: https://github.com/schchit


name: draft-ravikiran-clawdentity-protocol
rev: 00
title: Clawdentity: Cryptographic Identity and Trust Protocol for AI Agent Communication
time: 2026-02-21T14:47:26Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-25T14:47:26Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:06.864915+00:00
abstract:
This document specifies the Clawdentity protocol, a cryptographic
   identity and trust layer for AI agent-to-agent communication.
   Clawdentity provides per-agent Ed25519 identity, registry-issued
   credentials (Agent Identity Tokens), proof-of-possession request
   signing, bilateral trust establishment via pairing ceremonies,
   authenticated relay transport over WebSocket, and certificate
   revocation.  The protocol enables AI agents to prove their identity,
   verify peers, and exchange messages without exposing private keys,
   shared tokens, or backend infrastructure.

full_text:
Independent Submission                                      R. K. Vemula
Internet-Draft                                                       CAW
Intended status: Informational                          21 February 2026
Expires: 25 August 2026


  Clawdentity: Cryptographic Identity and Trust Protocol for AI Agent
                             Communication
                draft-ravikiran-clawdentity-protocol-00

Abstract

   This document specifies the Clawdentity protocol, a cryptographic
   identity and trust layer for AI agent-to-agent communication.
   Clawdentity provides per-agent Ed25519 identity, registry-issued
   credentials (Agent Identity Tokens), proof-of-possession request
   signing, bilateral trust establishment via pairing ceremonies,
   authenticated relay transport over WebSocket, and certificate
   revocation.  The protocol enables AI agents to prove their identity,
   verify peers, and exchange messages without exposing private keys,
   shared tokens, or backend infrastructure.

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

Copyright Notice

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








Vemula                   Expires 25 August 2026                 [Page 1]

Internet-Draft                 Clawdentity                 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Architecture Overview . . . . . . . . . . . . . . . . . .   4
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   5
   3.  Identity Model  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  DID Format  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Cryptographic Primitives  . . . . . . . . . . . . . . . .   6
     3.3.  Key Generation  . . . . . . . . . . . . . . . . . . . . .   7
     3.4.  Ownership Model . . . . . . . . . . . . . . . . . . . . .   7
   4.  Agent Identity Token (AIT)  . . . . . . . . . . . . . . . . .   7
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.2.  JOSE Header . . . . . . . . . . . . . . . . . . . . . . .   8
     4.3.  Claims  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.4.  Confirmation Claim  . . . . . . . . . . . . . . . . . . .   9
     4.5.  Validation Rules  . . . . . . . . . . . . . . . . . . . .  10
   5.  HTTP Request Signing  . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.2.  Canonical Request Format  . . . . . . . . . . . . . . . .  11
     5.3.  Signature Computation . . . . . . . . . . . . . . . . . .  11
     5.4.  Request Headers . . . . . . . . . . . . . . . . . . . . .  11
     5.5.  Verification Procedure  . . . . . . . . . . . . . . . . .  12
   6.  The "Claw" Authentication Scheme  . . . . . . . . . . . . . .  13
   7.  Agent Registration  . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Registration Flow . . . . . . . . . . . . . . . . . . . .  13
     7.2.  Registration Proof  . . . . . . . . . . . . . . . . . . .  14
     7.3.  AIT Refresh . . . . . . . . . . . . . . . . . . . . . . .  14
   8.  Trust Establishment (Pairing) . . . . . . . . . . . . . . . .  14
     8.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.2.  Pairing Flow  . . . . . . . . . . . . . . . . . . . . . .  14
     8.3.  Pairing Ticket  . . . . . . . . . . . . . . . . . . . . .  15
     8.4.  Peer Profile  . . . . . . . . . . . . . . . . . . . . . .  15
     8.5.  Ownership Verification  . . . . . . . . . . . . . . . . .  16
     8.6.  Trust Store . . . . . . . . . . . . . . . . . . . . . . .  16
   9.  Relay Transport . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.2.  WebSocket Connection  . . . . . . . . . . . . . . . . . .  17
     9.3.  Frame Protocol  . . . . . . . . . . . . . . . . . . . . .  17
     9.4.  Heartbeat Frames  . . . . . . . . . . . . . . . . . . . .  17
     9.5.  Deliver Frames  . . . . . . . . . . . . . . . . . . . . .  18



Vemula                   Expires 25 August 2026                 [Page 2]

Internet-Draft                 Clawdentity                 February 2026


     9.6.  Enqueue Frames  . . . . . . . . . . . . . . . . . . . . .  18
     9.7.  Local Agent Delivery  . . . . . . . . . . . . . . . . . .  19
     9.8.  Reconnection  . . . . . . . . . . . . . . . . . . . . . .  20
     9.9.  Outbound Queue Persistence  . . . . . . . . . . . . . . .  20
   10. Certificate Revocation  . . . . . . . . . . . . . . . . . . .  20
     10.1.  CRL Format . . . . . . . . . . . . . . . . . . . . . . .  20
     10.2.  CRL Distribution . . . . . . . . . . . . . . . . . . . .  21
     10.3.  CRL Caching  . . . . . . . . . . . . . . . . . . . . . .  22
     10.4.  Revocation Scope . . . . . . . . . . . . . . . . . . . .  22
   11. Registry Key Discovery  . . . . . . . . . . . . . . . . . . .  22
   12. Endpoint Reference  . . . . . . . . . . . . . . . . . . . . .  23
     12.1.  Registry Endpoints . . . . . . . . . . . . . . . . . . .  23
     12.2.  Proxy Endpoints  . . . . . . . . . . . . . . . . . . . .  24
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  24
     13.1.  Private Key Protection . . . . . . . . . . . . . . . . .  24
     13.2.  Replay Protection  . . . . . . . . . . . . . . . . . . .  24
     13.3.  Transport Security . . . . . . . . . . . . . . . . . . .  25
     13.4.  Connector Isolation  . . . . . . . . . . . . . . . . . .  25
     13.5.  Trust Store Integrity  . . . . . . . . . . . . . . . . .  25
     13.6.  CRL Freshness Window . . . . . . . . . . . . . . . . . .  25
     13.7.  Human-Anchored Trust . . . . . . . . . . . . . . . . . .  26
   14. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . .  26
     14.1.  Authentication Errors (401)  . . . . . . . . . . . . . .  26
     14.2.  Authorization Errors (403) . . . . . . . . . . . . . . .  27
     14.3.  Service Unavailable Errors (503) . . . . . . . . . . . .  27
   15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
     15.1.  DID Method Registration  . . . . . . . . . . . . . . . .  27
     15.2.  HTTP Authentication Scheme Registration  . . . . . . . .  28
     15.3.  JWT "typ" Header Parameter Values  . . . . . . . . . . .  28
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  28
     16.2.  Informative References . . . . . . . . . . . . . . . . .  29
   Appendix A.  Example: Complete Message Flow . . . . . . . . . . .  30
   Appendix B.  Comparison with Existing Standards . . . . . . . . .  31
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  31
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  31

1.  Introduction

1.1.  Problem Statement

   Current AI agent frameworks rely on shared bearer tokens for inter-
   agent communication.  A single token leak compromises all agents in
   the system.  There is no mechanism to distinguish which agent sent a
   request, revoke a single agent without rotating the shared token,
   enforce per-agent access control, or keep backend services private.
   These limitations become critical as multi-agent systems scale.




Vemula                   Expires 25 August 2026                 [Page 3]

Internet-Draft                 Clawdentity                 February 2026


1.2.  Design Goals

   Clawdentity addresses these problems with six design goals:

   1.  *Individual identity:* Each agent has a unique cryptographic
       keypair and DID.

   2.  *Proof of possession:* Every request proves the sender holds the
       private key via Ed25519 signatures.

   3.  *Selective revocation:* One agent can be revoked without
       affecting others.

   4.  *Zero-trust relay:* Agents communicate through authenticated
       proxies; backend services remain unexposed.

   5.  *Human-anchored trust:* Trust originates from human approval, not
       agent self-certification.

   6.  *Framework agnostic:* Works with any AI agent framework.

1.3.  Architecture Overview

   The protocol defines four component roles:

   Registry  Central identity authority.  Issues Agent Identity Tokens
      (AITs), manages signing keys, publishes the Certificate Revocation
      List (CRL).

   Proxy  Per-owner edge service.  Verifies identity, enforces trust
      policy, rate-limits requests, and relays messages between agents.

   Connector  Local bridge process between the proxy and the agent
      framework.  Maintains a persistent WebSocket connection to the
      proxy.  Never exposed publicly.

   Agent  The AI agent itself.  Has no direct knowledge of the protocol;
      the connector handles all cryptographic operations.













Vemula                   Expires 25 August 2026                 [Page 4]

Internet-Draft                 Clawdentity                 February 2026


     +-------------+         +-------------+         +--------------+
     |   Agent A   |         |  Registry   |         |   Agent B    |
     |  (private)  |         |  (central)  |         |  (private)   |
     +------+------+         +------+------+         +------+-------+
            |                       |                       |
     +------+------+                |                +------+-------+
     | Connector A |                |                | Connector B  |
     |  (local)    |                |                |  (local)     |
     +------+------+                |                +------+-------+
            |  WebSocket            |                       | WebSocket
     +------+------+                |                +------+-------+
     |   Proxy A   |<---------------+--------------->|   Proxy B    |
     |  (edge)     |                |                |  (edge)      |
     +-------------+                |                +--------------+
                                    |
                       +------------+------------+
                       | .well-known/claw-keys   |
                       | /v1/crl                 |
                       | /v1/agents              |
                       +-------------------------+

                      Figure 1: Component Architecture

2.  Conventions and 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 uses the following terms:

   AIT  Agent Identity Token.  A signed JWT credential (Section 4)
      binding an agent DID to a public key.

   CRL  Certificate Revocation List.  A signed JWT (Section 10)
      containing a list of revoked AITs.

   DID  Decentralized Identifier as defined in [W3C.DID], using the
      "cdi" method.

   PoP  Proof of Possession.  An Ed25519 signature proving the sender
      controls the private key corresponding to a public key.

   Pairing  Mutual trust establishment between two agents via a ticket-
      based ceremony.




Vemula                   Expires 25 August 2026                 [Page 5]

Internet-Draft                 Clawdentity                 February 2026


   Trust Store  Per-proxy persistent storage of known agents and
      approved trust pairs.

   ULID  Universally Unique Lexicographically Sortable Identifier
      [ULID].

3.  Identity Model

3.1.  DID Format

   Clawdentity uses a custom DID method with the scheme "did:cdi"
   (Clawdentity Identity).  The method-specific identifier consists of a
   registry host and a ULID, separated by a colon:

   cdi-did         = "did:cdi:" registry-host ":" ulid
   registry-host   = 1*( unreserved / "." / "-" )
   ulid            = 26ALPHA  ; Crockford Base32, see [ULID]

   The registry-host identifies which registry issued the DID.  The
   entity type (agent or human) is resolved by the registry, not encoded
   in the DID.

   +======+===========================================================+
   |Entity|Example                                                    |
   +======+===========================================================+
   |Agent |did:cdi:registry.clawdentity.com:01HG8ZBU11X7X8DN8O4X6GEYU5|
   +------+-----------------------------------------------------------+
   |Human |did:cdi:registry.clawdentity.com:01HF7YAT00W6W7CM7N3W5FDXT4|
   +------+-----------------------------------------------------------+
   |Self- |did:cdi:id.acme.corp:01HK9ABC22Y8Y9EO9P5Y7HFZV6            |
   |hosted|                                                           |
   +------+-----------------------------------------------------------+

                                 Table 1

   Implementations MUST reject DIDs where the registry-host is empty or
   where the ULID component does not conform to the ULID specification
   [ULID].

3.2.  Cryptographic Primitives

   The protocol uses Ed25519 [RFC8032] as the sole signing algorithm.
   Implementations MUST NOT support other signature algorithms.








Vemula                   Expires 25 August 2026                 [Page 6]

Internet-Draft                 Clawdentity                 February 2026


      +================+===========+===========+===================+
      | Primitive      | Algorithm | Reference | Usage             |
      +================+===========+===========+===================+
      | Signing        | Ed25519   | [RFC8032] | Identity, request |
      |                |           |           | signing           |
      +----------------+-----------+-----------+-------------------+
      | Body hash      | SHA-256   | [RFC6234] | Request body      |
      |                |           |           | integrity         |
      +----------------+-----------+-----------+-------------------+
      | Token format   | JWS       | [RFC7515] | AIT and CRL       |
      |                | Compact   |           | tokens            |
      +----------------+-----------+-----------+-------------------+
      | Key encoding   | Base64url | [RFC4648] | Keys, signatures, |
      |                | (no pad)  | Section 5 | hashes            |
      +----------------+-----------+-----------+-------------------+
      | Key            | JWK (OKP/ | [RFC8037] | Public keys in    |
      | representation | Ed25519)  |           | AITs              |
      +----------------+-----------+-----------+-------------------+

                                 Table 2

3.3.  Key Generation

   Each agent locally generates an Ed25519 keypair consisting of a
   32-byte public key and a 64-byte secret key.  The secret key MUST be
   stored exclusively on the agent's local machine and MUST NOT be
   transmitted over any network.  Only the public key is registered with
   the registry, encoded as base64url within the AIT's confirmation
   claim (Section 4.4).

3.4.  Ownership Model

   Every agent DID is bound to exactly one human DID (the "ownerDid").
   This binding is recorded in the AIT claims and enforced by the
   registry during registration and refresh operations.  A human MAY own
   multiple agents.  An agent MUST have exactly one owner.

     Human (did:cdi:registry.clawdentity.com:01HF7...)
       +-- Agent A (did:cdi:registry.clawdentity.com:01HG8...)
       +-- Agent B (did:cdi:registry.clawdentity.com:01HG9...)
       +-- Agent C (did:cdi:registry.clawdentity.com:01HGA...)

4.  Agent Identity Token (AIT)








Vemula                   Expires 25 August 2026                 [Page 7]

Internet-Draft                 Clawdentity                 February 2026


4.1.  Overview

   The Agent Identity Token (AIT) is a JSON Web Token [RFC7519] that
   serves as an agent's credential.  It is issued by the registry,
   signed with a registry Ed25519 key, and binds the agent's DID to the
   agent's public key via a confirmation claim ("cnf"), following the
   pattern established by DPoP [RFC9449].

4.2.  JOSE Header

   The AIT's JOSE protected header MUST contain:

   alg  REQUIRED.  MUST be "EdDSA" per [RFC8037].

   typ  REQUIRED.  MUST be "AIT".

   kid  REQUIRED.  The key identifier of the registry signing key used
      to sign this AIT.  This allows the verifier to locate the correct
      registry public key.

   {
     "alg": "EdDSA",
     "typ": "AIT",
     "kid": "reg-key-2026-01"
   }

                     Figure 2: AIT JOSE Header Example

4.3.  Claims

   The AIT payload MUST contain the following claims.  No additional
   claims are permitted (strict validation).



















Vemula                   Expires 25 August 2026                 [Page 8]

Internet-Draft                 Clawdentity                 February 2026


   +===========+======+========+======================================+
   |Claim      |Type  |Required| Description                          |
   +===========+======+========+======================================+
   |iss        |string|REQUIRED| Registry issuer URL (e.g.,           |
   |           |      |        | "https://registry.clawdentity.com")  |
   +-----------+------+--------+--------------------------------------+
   |sub        |string|REQUIRED| Agent DID.  MUST be                  |
   |           |      |        | "did:cdi:<registry-host>:<ulid>"     |
   +-----------+------+--------+--------------------------------------+
   |ownerDid   |string|REQUIRED| Owner DID.  MUST be                  |
   |           |      |        | "did:cdi:<registry-host>:<ulid>"     |
   +-----------+------+--------+--------------------------------------+
   |name       |string|REQUIRED| Agent name. 1-64 characters matching |
   |           |      |        | [A-Za-z0-9._ -]                      |
   +-----------+------+--------+--------------------------------------+
   |framework  |string|REQUIRED| Agent framework identifier. 1-32     |
   |           |      |        | characters, no control characters.   |
   +-----------+------+--------+--------------------------------------+
   |description|string|OPTIONAL| Human-readable description.  Maximum |
   |           |      |        | 280 characters.                      |
   +-----------+------+--------+--------------------------------------+
   |cnf        |object|REQUIRED| Confirmation claim.  See             |
   |           |      |        | Section 4.4.                         |
   +-----------+------+--------+--------------------------------------+
   |iat        |number|REQUIRED| Issued-at time (NumericDate per      |
   |           |      |        | [RFC7519]).                          |
   +-----------+------+--------+--------------------------------------+
   |nbf        |number|REQUIRED| Not-before time (NumericDate).       |
   +-----------+------+--------+--------------------------------------+
   |exp        |number|REQUIRED| Expiration time (NumericDate).  MUST |
   |           |      |        | be greater than both nbf and iat.    |
   +-----------+------+--------+--------------------------------------+
   |jti        |string|REQUIRED| Unique token identifier.  MUST be a  |
   |           |      |        | valid ULID.                          |
   +-----------+------+--------+--------------------------------------+

                                 Table 3

4.4.  Confirmation Claim

   The "cnf" (confirmation) claim binds the AIT to the agent's Ed25519
   public key, following the confirmation method pattern described in
   [RFC7800].  It contains a single "jwk" member:








Vemula                   Expires 25 August 2026                 [Page 9]

Internet-Draft                 Clawdentity                 February 2026


   "cnf": {
     "jwk": {
       "kty": "OKP",
       "crv": "Ed25519",
       "x": "<base64url-encoded-32-byte-public-key>"
     }
   }

   The "kty" MUST be "OKP".  The "crv" MUST be "Ed25519".  The "x"
   parameter MUST decode (base64url) to exactly 32 bytes.  The JWK MUST
   NOT contain a "d" (private key) parameter.

4.5.  Validation Rules

   An AIT MUST be rejected if any of the following conditions are true:

   1.   "alg" is not "EdDSA".

   2.   "typ" is not "AIT".

   3.   "kid" does not match any active registry signing key.

   4.   JWS signature verification fails against the registry key
        identified by "kid".

   5.   "sub" is not a valid "did:cdi" DID.

   6.   "ownerDid" is not a valid "did:cdi" DID.

   7.   "cnf.jwk.x" does not decode to exactly 32 bytes.

   8.   "exp" is less than or equal to "nbf" or "iat".

   9.   "jti" is not a valid ULID.

   10.  Current time is before "nbf" or after "exp" (accounting for
        clock skew).

   11.  "jti" appears in the current CRL (Section 10).

5.  HTTP Request Signing










Vemula                   Expires 25 August 2026                [Page 10]

Internet-Draft                 Clawdentity                 February 2026


5.1.  Purpose

   Every authenticated request includes a Proof of Possession (PoP)
   signature that proves the sender controls the private key
   corresponding to the public key in their AIT's "cnf" claim.  This
   mechanism is inspired by DPoP [RFC9449] but uses a canonical request
   signing approach optimized for agent-to-agent communication.

5.2.  Canonical Request Format

   The canonical request string is constructed by joining the following
   fields with newline (0x0A) separators, in the order shown:

   canonical-request = version LF method LF path-with-query LF
                       timestamp LF nonce LF body-hash
   version           = "CLAW-PROOF-V1"
   method            = token          ; HTTP method, uppercased
   path-with-query   = absolute-path [ "?" query ]
   timestamp         = 1*DIGIT        ; Unix epoch seconds
   nonce             = 1*unreserved   ; unique per-request value
   body-hash         = base64url      ; SHA-256 of request body
   LF                = %x0A

   CLAW-PROOF-V1
   POST
   /hooks/agent
   1708531200
   01HG8ZBU11X7X8DN8O4X6GEYU5
   47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU

                    Figure 3: Canonical Request Example

5.3.  Signature Computation

   The PoP signature is computed by signing the UTF-8 encoding of the
   canonical request string with the agent's Ed25519 private key:

   canonical = canonicalize(method, path, timestamp, nonce, body_hash)
   signature = Ed25519_Sign(UTF8_Encode(canonical), secret_key)
   proof     = Base64url_Encode(signature)

   The resulting "proof" is a base64url-encoded 64-byte Ed25519
   signature.

5.4.  Request Headers

   An authenticated request MUST include the following headers:




Vemula                   Expires 25 August 2026                [Page 11]

Internet-Draft                 Clawdentity                 February 2026


    +=====================+=============+=============================+
    | Header              | Status      | Description                 |
    +=====================+=============+=============================+
    | Authorization       | REQUIRED    | "Claw" SP <AIT-JWT>.  See   |
    |                     |             | Section 6.                  |
    +---------------------+-------------+-----------------------------+
    | X-Claw-Timestamp    | REQUIRED    | Unix epoch seconds (integer |
    |                     |             | string).                    |
    +---------------------+-------------+-----------------------------+
    | X-Claw-Nonce        | REQUIRED    | Unique per-request value.   |
    |                     |             | ULID RECOMMENDED.           |
    +---------------------+-------------+-----------------------------+
    | X-Claw-Body-SHA256  | REQUIRED    | SHA-256 hash of the request |
    |                     |             | body, base64url-encoded.    |
    +---------------------+-------------+-----------------------------+
    | X-Claw-Proof        | REQUIRED    | Ed25519 PoP signature       |
    |                     |             | (base64url, 64 bytes).      |
    +---------------------+-------------+-----------------------------+
    | X-Claw-Agent-Access | CONDITIONAL | Session access token.       |
    |                     |             | Required for relay and hook |
    |                     |             | routes.                     |
    +---------------------+-------------+-----------------------------+

                                  Table 4

5.5.  Verification Procedure

   The verifier (proxy) MUST perform the following steps in order:

   1.  Extract the AIT from the "Authorization: Claw <token>" header.

   2.  Verify the AIT's JWS signature against the registry's signing
       keys (Section 4.5).

   3.  Check that the AIT's "jti" is not on the CRL (Section 10.3).

   4.  Extract the agent's public key from the AIT's "cnf.jwk.x" claim.

   5.  Verify X-Claw-Timestamp is within the allowed skew window
       (default: 300 seconds).

   6.  Recompute SHA-256 of the request body; compare with X-Claw-Body-
       SHA256.

   7.  Reconstruct the canonical request (Section 5.2).

   8.  Verify X-Claw-Proof against the canonical request using the
       agent's public key.



Vemula                   Expires 25 August 2026                [Page 12]

Internet-Draft                 Clawdentity                 February 2026


   9.  Check X-Claw-Nonce has not been seen before for this agent DID
       within the timestamp window.

   If any step fails, the request MUST be rejected with HTTP 401.

6.  The "Claw" Authentication Scheme

   This specification introduces the "Claw" HTTP authentication scheme
   for the Authorization header, following the framework defined in
   [RFC9110] Section 11.

credentials = "Claw" SP ait-token
ait-token   = 1*base64url-char "." 1*base64url-char "." 1*base64url-char

   The scheme name "Claw" is case-sensitive.  The token MUST be a valid
   JWS Compact Serialization [RFC7515] representing an AIT as defined in
   Section 4.

7.  Agent Registration

7.1.  Registration Flow

   Agent registration uses a challenge-response protocol to prove that
   the registrant possesses the Ed25519 private key corresponding to the
   public key being registered.

     Agent                                Registry
       |                                      |
       |  POST /v1/agents/challenge           |
       |  { ownerDid }                        |
       |------------------------------------->|
       |                                      |
       |  200 { challengeId, nonce }          |
       |<-------------------------------------|
       |                                      |
       |  [Agent signs registration proof]    |
       |                                      |
       |  POST /v1/agents                     |
       |  { proof, publicKey, name, ... }     |
       |------------------------------------->|
       |                                      |
       |  201 { agentDid, ait }               |
       |<-------------------------------------|

                   Figure 4: Agent Registration Sequence






Vemula                   Expires 25 August 2026                [Page 13]

Internet-Draft                 Clawdentity                 February 2026


7.2.  Registration Proof

   The registration proof is computed by signing a canonical message
   that binds the challenge to the agent's identity parameters:

   clawdentity.register.v1
   challengeId:<challengeId>
   nonce:<nonce>
   ownerDid:<ownerDid>
   publicKey:<base64url-public-key>
   name:<agent-name>
   framework:<framework>
   ttlDays:<ttl-days>

   Optional fields (framework, ttlDays) use empty strings when absent.
   The agent signs this message with Ed25519 and submits the base64url-
   encoded signature as the "proof" in the registration request.

7.3.  AIT Refresh

   AITs have bounded lifetimes.  Before expiration, the connector MUST
   request a fresh AIT:

   POST /v1/agents/auth/refresh HTTP/1.1
   Authorization: Claw <current-AIT>
   X-Claw-Agent-Access: <access-token>

   The registry validates the current AIT and access token, verifies the
   agent is not revoked, and returns a new AIT with an updated
   expiration time.

8.  Trust Establishment (Pairing)

8.1.  Overview

   Before two agents can exchange messages, they MUST establish mutual
   trust through a pairing ceremony.  Trust is anchored by human
   approval: agents cannot self-approve trust relationships.  The
   pairing process uses short-lived tickets exchanged out-of-band (e.g.,
   via QR code or messaging).

8.2.  Pairing Flow









Vemula                   Expires 25 August 2026                [Page 14]

Internet-Draft                 Clawdentity                 February 2026


     Agent A (Initiator)        Proxy         Agent B (Responder)
            |                     |                    |
            | POST /pair/start    |                    |
            | { initiatorProfile, |                    |
            |   ttlSeconds }      |                    |
            |-------------------->|                    |
            |                     |                    |
            | { ticket,           |                    |
            |   expiresAt }       |                    |
            |<--------------------|                    |
            |                     |                    |
            |   (out-of-band ticket exchange)          |
            |   (QR code, message, copy-paste)         |
            |----------------------------------------->|
            |                     |                    |
            |                     | POST /pair/confirm |
            |                     | { ticket,          |
            |                     |   responderProfile}|
            |                     |<-------------------|
            |                     |                    |
            |                     | 201 { paired:true }|
            |                     |------------------->|
            |                     |                    |
            | callback (optional) |                    |
            |<--------------------|                    |

                   Figure 5: Trust Establishment Sequence

8.3.  Pairing Ticket

   The pairing ticket is a signed JWT with a short TTL, created by the
   proxy during the /pair/start request.  The ticket encodes the issuer
   proxy URL, a signing key identifier, and an expiration timestamp.

   Ticket parameters:

             +==================+=============+=============+
             | Parameter        | Default     | Maximum     |
             +==================+=============+=============+
             | TTL (ttlSeconds) | 300 seconds | 900 seconds |
             +------------------+-------------+-------------+

                                 Table 5

8.4.  Peer Profile

   Each side of a pairing provides a profile containing identity
   information for display and routing:



Vemula                   Expires 25 August 2026                [Page 15]

Internet-Draft                 Clawdentity                 February 2026


   {
     "agentName": "kai",
     "humanName": "Ravi",
     "proxyOrigin": "https://proxy.example.com"
   }

   agentName  REQUIRED.  Agent display name.  Maximum 64 characters.  No
      control characters.

   humanName  REQUIRED.  Owner display name.  Maximum 64 characters.  No
      control characters.

   proxyOrigin  OPTIONAL.  The proxy's URL origin, used for cross-proxy
      message routing.

8.5.  Ownership Verification

   When an agent initiates pairing, the proxy MUST verify that the
   authenticated caller (identified by "ownerDid" in the AIT) actually
   owns the claimed initiator agent DID.  This is done by querying the
   registry's internal agent-ownership endpoint.  If ownership cannot be
   verified, the pairing MUST be rejected with HTTP 403.

8.6.  Trust Store

   Each proxy maintains a Trust Store that records:

   *  *Known agents:* Agents that have been authenticated and accepted.

   *  *Approved pairs:* Bidirectional trust relationships between
      agents.

   *  *Pairing tickets:* Pending and completed pairing ceremonies with
      expiration tracking.

   A message from Agent A to Agent B is permitted only if the ordered
   pair (A, B) exists in the proxy's trust store.  The trust store
   SHOULD use a durable, transactional storage backend.

9.  Relay Transport

9.1.  Overview

   Messages between agents are relayed through their respective proxies.
   The connector maintains a persistent WebSocket [RFC6455] connection
   to its proxy.  The proxy authenticates the WebSocket upgrade request
   using the full AIT + PoP verification procedure (Section 5.5).




Vemula                   Expires 25 August 2026                [Page 16]

Internet-Draft                 Clawdentity                 February 2026


9.2.  WebSocket Connection

   The connector initiates a WebSocket connection to:

   GET /v1/relay/connect HTTP/1.1
   Upgrade: websocket
   Connection: Upgrade
   Authorization: Claw <AIT>
   X-Claw-Agent-Access: <access-token>
   X-Claw-Timestamp: <timestamp>
   X-Claw-Nonce: <nonce>
   X-Claw-Body-SHA256: <empty-body-hash>
   X-Claw-Proof: <signature>

9.3.  Frame Protocol

   All WebSocket messages are JSON objects conforming to the Clawdentity
   Frame Protocol version 1.  Every frame contains a common base
   structure:

   {
     "v": 1,
     "type": "<frame-type>",
     "id": "<ULID>",
     "ts": "<ISO-8601-timestamp>"
   }

   v  REQUIRED.  Integer.  Frame protocol version.  MUST be 1.

   type  REQUIRED.  String.  One of: "heartbeat", "heartbeat_ack",
      "deliver", "deliver_ack", "enqueue", "enqueue_ack".

   id  REQUIRED.  String.  Unique frame identifier (ULID).

   ts  REQUIRED.  String.  ISO 8601 timestamp with timezone.

9.4.  Heartbeat Frames

   Either side MAY send heartbeat frames to verify liveness.  The
   default heartbeat interval is 30 seconds.  If a heartbeat
   acknowledgement is not received within 60 seconds, the sender SHOULD
   close the connection and reconnect.

   Heartbeat:

   { "v": 1, "type": "heartbeat", "id": "<ULID>", "ts": "<ISO>" }

   Heartbeat acknowledgement:



Vemula                   Expires 25 August 2026                [Page 17]

Internet-Draft                 Clawdentity                 February 2026


   { "v": 1, "type": "heartbeat_ack", "id": "<ULID>", "ts": "<ISO>",
     "ackId": "<heartbeat-frame-id>" }

9.5.  Deliver Frames

   The proxy sends a "deliver" frame to the connector when an inbound
   message arrives for the local agent:

   {
     "v": 1,
     "type": "deliver",
     "id": "<ULID>",
     "ts": "<ISO>",
     "fromAgentDid": "did:cdi:registry.clawdentity.com:...",
     "toAgentDid": "did:cdi:registry.clawdentity.com:...",
     "payload": { ... },
     "contentType": "application/json",
     "conversationId": "conv-123",
     "replyTo": "https://proxy-a.example.com/v1/relay/delivery-receipts"
   }

   The connector MUST respond with a "deliver_ack" frame indicating
   whether the local agent framework accepted the delivery:

   {
     "v": 1,
     "type": "deliver_ack",
     "id": "<ULID>",
     "ts": "<ISO>",
     "ackId": "<deliver-frame-id>",
     "accepted": true
   }

   If rejected, the "accepted" field is false and an optional "reason"
   string MAY be included.

9.6.  Enqueue Frames

   The connector sends an "enqueue" frame to the proxy for outbound
   messages:











Vemula                   Expires 25 August 2026                [Page 18]

Internet-Draft                 Clawdentity                 February 2026


   {
     "v": 1,
     "type": "enqueue",
     "id": "<ULID>",
     "ts": "<ISO>",
     "toAgentDid": "did:cdi:registry.clawdentity.com:...",
     "payload": { ... },
     "conversationId": "conv-123"
   }

   The proxy responds with "enqueue_ack" after accepting or rejecting
   the message for relay.

9.7.  Local Agent Delivery

   Upon receiving a "deliver" frame, the connector forwards the payload
   to the local agent framework via HTTP POST:

   POST /hooks/agent HTTP/1.1
   Host: 127.0.0.1:18789
   Content-Type: application/json
   x-clawdentity-agent-did: <fromAgentDid>
   x-clawdentity-to-agent-did: <toAgentDid>
   x-clawdentity-verified: true
   x-openclaw-token: <local-hook-token>
   x-request-id: <frame-id>

   The connector implements retry with exponential backoff for transient
   failures (5xx, 429, connection errors):

                    +================+===============+
                    | Parameter      | Default Value |
                    +================+===============+
                    | Max attempts   | 4             |
                    +----------------+---------------+
                    | Initial delay  | 300 ms        |
                    +----------------+---------------+
                    | Max delay      | 2,000 ms      |
                    +----------------+---------------+
                    | Backoff factor | 2             |
                    +----------------+---------------+
                    | Total budget   | 14,000 ms     |
                    +----------------+---------------+

                                 Table 6






Vemula                   Expires 25 August 2026                [Page 19]

Internet-Draft                 Clawdentity                 February 2026


9.8.  Reconnection

   On WebSocket disconnection, the connector MUST attempt to reconnect
   using exponential backoff with jitter:

                    +================+===============+
                    | Parameter      | Default Value |
                    +================+===============+
                    | Minimum delay  | 1,000 ms      |
                    +----------------+---------------+
                    | Maximum delay  | 30,000 ms     |
                    +----------------+---------------+
                    | Backoff factor | 2             |
                    +----------------+---------------+
                    | Jitter ratio   | 0.2 (±20%)    |
                    +----------------+---------------+

                                 Table 7

   On successful reconnection, the connector resets the backoff counter
   and flushes any queued outbound frames.

9.9.  Outbound Queue Persistence

   When the WebSocket connection is unavailable, the connector MUST
   queue outbound "enqueue" frames locally and flush them in FIFO order
   upon reconnection.  The queue SHOULD support optional persistence (to
   disk or database) to survive connector restarts.

10.  Certificate Revocation

10.1.  CRL Format

   The Certificate Revocation List (CRL) is a signed JWT containing a
   list of revoked AITs.  Its JOSE header uses:

   alg  MUST be "EdDSA".

   typ  MUST be "CRL".

   kid  Registry signing key identifier.

   CRL claims:








Vemula                   Expires 25 August 2026                [Page 20]

Internet-Draft                 Clawdentity                 February 2026


       +=============+========+==========+========================+
       | Claim       | Type   | Required | Description            |
       +=============+========+==========+========================+
       | iss         | string | REQUIRED | Registry issuer URL.   |
       +-------------+--------+----------+------------------------+
       | jti         | string | REQUIRED | CRL identifier (ULID). |
       +-------------+--------+----------+------------------------+
       | iat         | number | REQUIRED | Issued-at timestamp.   |
       +-------------+--------+----------+------------------------+
       | exp         | number | REQUIRED | Expiration.  MUST be   |
       |             |        |          | greater than iat.      |
       +-------------+--------+----------+------------------------+
       | revocations | array  | REQUIRED | At least one           |
       |             |        |          | revocation entry.      |
       +-------------+--------+----------+------------------------+

                                 Table 8

   Each revocation entry contains:

       +===========+========+==========+===========================+
       | Field     | Type   | Required | Description               |
       +===========+========+==========+===========================+
       | jti       | string | REQUIRED | Revoked AIT's jti (ULID). |
       +-----------+--------+----------+---------------------------+
       | agentDid  | string | REQUIRED | Revoked agent's DID.      |
       +-----------+--------+----------+---------------------------+
       | reason    | string | OPTIONAL | Human-readable reason.    |
       |           |        |          | Max 280 chars.            |
       +-----------+--------+----------+---------------------------+
       | revokedAt | number | REQUIRED | Revocation timestamp      |
       |           |        |          | (Unix seconds).           |
       +-----------+--------+----------+---------------------------+

                                  Table 9

10.2.  CRL Distribution

   The registry publishes the current CRL at the well-known endpoint:

   GET /v1/crl HTTP/1.1
   Host: registry.clawdentity.com

   Response:

   { "crl": "<signed-CRL-JWT>" }





Vemula                   Expires 25 August 2026                [Page 21]

Internet-Draft                 Clawdentity                 February 2026


10.3.  CRL Caching

   Proxies MUST cache the CRL locally and refresh it periodically.  The
   following parameters control caching behavior:

      +===========+===========+=====================================+
      | Parameter | Default   | Description                         |
      +===========+===========+=====================================+
      | Refresh   | 5 minutes | How often to fetch a fresh CRL.     |
      | interval  |           |                                     |
      +-----------+-----------+-------------------------------------+
      | Max age   | 15        | Maximum staleness before the cache  |
      |           | minutes   | is considered expired.              |
      +-----------+-----------+-------------------------------------+
      | Stale     | fail-open | "fail-open" allows stale CRL use;   |
      | behavior  |           | "fail-closed" rejects all requests. |
      +-----------+-----------+-------------------------------------+

                                  Table 10

   When "fail-open": if the CRL cannot be refreshed and the cached CRL
   is within max age, the stale CRL is used for revocation checks.

   When "fail-closed": if the CRL exceeds max age and cannot be
   refreshed, the proxy MUST reject all authenticated requests with HTTP
   503.

10.4.  Revocation Scope

   Two levels of revocation are defined:

   Global revocation (revoke agent)  The agent's AIT jti is added to the
      CRL by the registry.  The agent can no longer authenticate at any
      proxy.  Only the agent's owner can initiate global revocation.

   Local revocation (remove pair)  A trust relationship is removed from
      a proxy's trust store.  The agent still exists and can communicate
      with other paired agents, but can no longer reach the unpaired
      peer via that proxy.  Either side of the pair can initiate local
      revocation.

11.  Registry Key Discovery

   The registry publishes its active signing keys at a well-known
   endpoint, following the pattern established by OpenID Connect
   Discovery [OIDC.Discovery]:





Vemula                   Expires 25 August 2026                [Page 22]

Internet-Draft                 Clawdentity                 February 2026


   GET /.well-known/claw-keys.json HTTP/1.1
   Host: registry.clawdentity.com

   Response:

   {
     "keys": [
       {
         "kid": "reg-key-2026-01",
         "x": "<base64url-ed25519-public-key>",
         "status": "active",
         "createdAt": "2026-01-01T00:00:00Z"
       }
     ]
   }

   The registry MAY have multiple active signing keys to support key
   rotation.  The AIT and CRL "kid" headers identify which key was used
   to sign a given token.  Proxies SHOULD cache these keys (default TTL:
   1 hour) and refresh them when an unknown "kid" is encountered.

12.  Endpoint Reference

12.1.  Registry Endpoints

      +========+==================+==========+======================+
      | Method | Path             | Auth     | Description          |
      +========+==================+==========+======================+
      | GET    | /.well-known/    | None     | Registry signing     |
      |        | claw-keys.json   |          | keys                 |
      +--------+------------------+----------+----------------------+
      | GET    | /v1/metadata     | None     | Registry metadata    |
      +--------+------------------+----------+----------------------+
      | GET    | /v1/crl          | None     | Current CRL          |
      +--------+------------------+----------+----------------------+
      | POST   | /v1/agents/      | API Key  | Request registration |
      |        | challenge        |          | challenge            |
      +--------+------------------+----------+----------------------+
      | POST   | /v1/agents/auth/ | AIT +    | Refresh AIT          |
      |        | refresh          | Access   |                      |
      +--------+------------------+----------+----------------------+
      | POST   | /v1/agents/auth/ | Internal | Validate agent       |
      |        | validate         |          | access token         |
      +--------+------------------+----------+----------------------+
      | POST   | /v1/invites      | API Key  | Create invite code   |
      +--------+------------------+----------+----------------------+
      | POST   | /v1/invites/     | None     | Redeem invite code   |
      |        | redeem           |          |                      |



Vemula                   Expires 25 August 2026                [Page 23]

Internet-Draft                 Clawdentity                 February 2026


      +--------+------------------+----------+----------------------+

                                  Table 11

12.2.  Proxy Endpoints

       +========+===================+===========+==================+
       | Method | Path              | Auth      | Description      |
       +========+===================+===========+==================+
       | GET    | /health           | None      | Health check     |
       +--------+-------------------+-----------+------------------+
       | POST   | /hooks/agent      | AIT + PoP | Inbound message  |
       |        |                   | + Access  | delivery         |
       +--------+-------------------+-----------+------------------+
       | GET    | /v1/relay/connect | AIT + PoP | WebSocket relay  |
       |        |                   | + Access  |                  |
       +--------+-------------------+-----------+------------------+
       | POST   | /v1/relay/        | AIT + PoP | Delivery receipt |
       |        | delivery-receipts | + Access  | callback         |
       +--------+-------------------+-----------+------------------+
       | POST   | /pair/start       | AIT + PoP | Initiate pairing |
       +--------+-------------------+-----------+------------------+
       | POST   | /pair/confirm     | AIT + PoP | Confirm pairing  |
       +--------+-------------------+-----------+------------------+
       | POST   | /pair/status      | AIT + PoP | Check pairing    |
       |        |                   |           | status           |
       +--------+-------------------+-----------+------------------+

                                  Table 12

13.  Security Considerations

13.1.  Private Key Protection

   Agent Ed25519 private keys MUST be stored exclusively on the agent's
   local machine.  The protocol is designed so that only the public key
   leaves the agent — embedded in the AIT's "cnf" claim and registered
   with the registry.  Implementations SHOULD use operating system key
   storage facilities where available.

13.2.  Replay Protection

   Three mechanisms provide replay protection:

   1.  *Timestamp skew:* Requests with X-Claw-Timestamp outside a
       configurable window (default: 300 seconds) are rejected.





Vemula                   Expires 25 August 2026                [Page 24]

Internet-Draft                 Clawdentity                 February 2026


   2.  *Nonce uniqueness:* Each (agentDid, nonce) pair is tracked per
       proxy.  Duplicate nonces within the timestamp window are
       rejected.

   3.  *AIT expiration:* AITs have bounded lifetimes; expired AITs are
       rejected regardless of signature validity.

13.3.  Transport Security

   TLS 1.2 or later ([RFC8446] for TLS 1.3) is REQUIRED for all proxy-
   to-proxy, proxy-to-registry, and connector-to-proxy communication
   over public networks.  The PoP signature (Section 5) provides an
   additional layer: even if TLS were compromised, a captured AIT cannot
   produce valid request signatures without the private key.

13.4.  Connector Isolation

   The connector MUST only communicate with its own proxy (via
   WebSocket) and the local agent framework (via localhost HTTP).  It
   MUST NOT directly access the registry, other proxies, or any cloud
   infrastructure services (message queues, object storage, databases).
   This constraint minimizes the connector's attack surface and ensures
   it remains a simple, auditable bridge.

13.5.  Trust Store Integrity

   The trust store is the sole authorization source for message relay.
   Implementations SHOULD use a transactional storage backend (e.g.,
   SQLite within a Cloudflare Durable Object) to prevent corruption from
   concurrent access or partial writes.

13.6.  CRL Freshness Window

   There is an inherent propagation delay between AIT revocation and CRL
   distribution.  With default settings, this window is up to 5 minutes.
   Deployments requiring tighter revocation windows SHOULD:

   *  Reduce the CRL refresh interval.

   *  Use push-based CRL invalidation (e.g., message queues).

   *  Combine CRL checks with real-time agent-auth validation for
      sensitive operations.








Vemula                   Expires 25 August 2026                [Page 25]

Internet-Draft                 Clawdentity                 February 2026


13.7.  Human-Anchored Trust

   The protocol explicitly prevents agent self-certification.  An agent
   cannot approve its own work or establish trust without human
   involvement.  The pairing ceremony requires out-of-band ticket
   exchange, and global revocation requires the agent owner's
   credentials.  This design prevents autonomous trust escalation.

14.  Error Codes

   The following error codes are returned in JSON error responses with
   the corresponding HTTP status codes:

14.1.  Authentication Errors (401)

   +==============================+===================================+
   | Code                         | Description                       |
   +==============================+===================================+
   | PROXY_AUTH_MISSING_TOKEN     | No Authorization header provided. |
   +------------------------------+-----------------------------------+
   | PROXY_AUTH_INVALID_SCHEME    | Authorization header is not "Claw |
   |                              | <token>" format.                  |
   +------------------------------+-----------------------------------+
   | PROXY_AUTH_INVALID_AIT       | AIT JWT verification failed.      |
   +------------------------------+-----------------------------------+
   | PROXY_AUTH_INVALID_PROOF     | PoP signature does not match.     |
   +------------------------------+-----------------------------------+
   | PROXY_AUTH_INVALID_TIMESTAMP | X-Claw-Timestamp missing or not a |
   |                              | valid integer.                    |
   +------------------------------+-----------------------------------+
   | PROXY_AUTH_TIMESTAMP_SKEW    | Timestamp outside the allowed     |
   |                              | skew window.                      |
   +------------------------------+-----------------------------------+
   | PROXY_AUTH_REPLAY            | Nonce has been seen before        |
   |                              | (replay detected).                |
   +------------------------------+-----------------------------------+
   | PROXY_AUTH_REVOKED           | AIT jti is on the CRL.            |
   +------------------------------+-----------------------------------+
   | PROXY_AGENT_ACCESS_REQUIRED  | X-Claw-Agent-Access header        |
   |                              | missing.                          |
   +------------------------------+-----------------------------------+
   | PROXY_AGENT_ACCESS_INVALID   | Agent access token is invalid or  |
   |                              | expired.                          |
   +------------------------------+-----------------------------------+

                                 Table 13





Vemula                   Expires 25 August 2026                [Page 26]

Internet-Draft                 Clawdentity                 February 2026


14.2.  Authorization Errors (403)

       +================================+==========================+
       | Code                           | Description              |
       +================================+==========================+
       | PROXY_AUTH_FORBIDDEN           | Agent not in trust store |
       |                                | or pair not approved.    |
       +--------------------------------+--------------------------+
       | PROXY_PAIR_OWNERSHIP_FORBIDDEN | Caller does not own the  |
       |                                | initiator agent DID.     |
       +--------------------------------+--------------------------+

                                  Table 14

14.3.  Service Unavailable Errors (503)

    +===================================+============================+
    | Code                              | Description                |
    +===================================+============================+
    | PROXY_AUTH_DEPENDENCY_UNAVAILABLE | Registry, CRL, or trust    |
    |                                   | store is unreachable.      |
    +-----------------------------------+----------------------------+
    | PROXY_PAIR_STATE_UNAVAILABLE      | Trust store is unreachable |
    |                                   | for pairing operations.    |
    +-----------------------------------+----------------------------+
    | CRL_CACHE_STALE                   | CRL exceeds max age and    |
    |                                   | fail-closed is configured. |
    +-----------------------------------+----------------------------+

                                 Table 15

15.  IANA Considerations

15.1.  DID Method Registration

   This specification introduces the "cdi" DID method.  A registration
   request for the W3C DID Method Registry would include:

   Method Name  cdi

   Method Specific Identifier  <registry-host>:<ulid>

   DID Document  Resolved via the registry identified by the registry-
      host component.







Vemula                   Expires 25 August 2026                [Page 27]

Internet-Draft                 Clawdentity                 February 2026


15.2.  HTTP Authentication Scheme Registration

   This specification registers the "Claw" authentication scheme in the
   "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"
   defined in [RFC9110] Section 16.3:

   Authentication Scheme Name  Claw

   Reference  Section 6 of this document

15.3.  JWT "typ" Header Parameter Values

   This specification registers two JWT "typ" header parameter values in
   the "JSON Web Token Types" sub-registry of the "JSON Web Token (JWT)"
   registry:

        +=============+=============================+============+
        | "typ" Value | Description                 | Reference  |
        +=============+=============================+============+
        | AIT         | Agent Identity Token        | Section 4  |
        +-------------+-----------------------------+------------+
        | CRL         | Certificate Revocation List | Section 10 |
        +-------------+-----------------------------+------------+

                                 Table 16

16.  References

16.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/info/rfc2119>.

   [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/info/rfc8174>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC6234]  3rd, D. E. and T. Hansen, "US Secure Hash Algorithms (SHA
              and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.




Vemula                   Expires 25 August 2026                [Page 28]

Internet-Draft                 Clawdentity                 February 2026


   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, DOI 10.17487/RFC6455, December 2011,
              <https://www.rfc-editor.org/info/rfc6455>.

   [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/info/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/info/rfc7519>.

   [RFC7800]  Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
              Possession Key Semantics for JSON Web Tokens (JWTs)",
              RFC 7800, DOI 10.17487/RFC7800, April 2016,
              <https://www.rfc-editor.org/info/rfc7800>.

   [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/info/rfc8032>.

   [RFC8037]  Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
              and Signatures in JSON Object Signing and Encryption
              (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
              <https://www.rfc-editor.org/info/rfc8037>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

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

16.2.  Informative References

   [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/info/rfc9449>.

   [W3C.DID]  Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele,
              O., and C. Allen, "Decentralized Identifiers (DIDs) v1.0",
              W3C Recommendation, July 2022,
              <https://www.w3.org/TR/did-core/>.





Vemula                   Expires 25 August 2026                [Page 29]

Internet-Draft                 Clawdentity                 February 2026


   [ULID]     Feerasta, A., "Universally Unique Lexicographically
              Sortable Identifier", 2016,
              <https://github.com/ulid/spec>.

   [OIDC.Discovery]
              Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
              Connect Discovery 1.0", November 2014,
              <https://openid.net/specs/openid-connect-discovery-
              1_0.html>.

Appendix A.  Example: Complete Message Flow

   The following describes a complete message relay from Agent A to
   Agent B:

   1.  Agent A's connector creates an "enqueue" frame targeting Agent
       B's DID.

   2.  If connected, the frame is sent over WebSocket to Proxy A;
       otherwise it is queued locally.

   3.  Proxy A receives the enqueue, looks up Agent B's proxy URL from
       the trust store, and signs an HTTP request with Agent A's AIT and
       PoP.

   4.  Proxy A sends POST /hooks/agent to Proxy B with the signed
       request.

   5.  Proxy B verifies the Authorization header (AIT + PoP), checks the
       CRL, and confirms the (A, B) pair exists in its trust store.

   6.  Proxy B creates a "deliver" frame and sends it over WebSocket to
       Connector B.

   7.  Connector B receives the deliver frame and POSTs the payload to
       the local agent framework on localhost.

   8.  Connector B sends a "deliver_ack" (accepted: true) back to Proxy
       B.

   9.  Agent B processes the message.










Vemula                   Expires 25 August 2026                [Page 30]

Internet-Draft                 Clawdentity                 February 2026


Appendix B.  Comparison with Existing Standards

      +================+====================+=======================+
      | Feature        | OAuth 2.0 / DPoP   | Clawdentity           |
      +================+====================+=======================+
      | Identity model | Client credentials | Per-agent DID +       |
      |                | / tokens           | Ed25519 keypair       |
      +----------------+--------------------+-----------------------+
      | Token issuer   | Authorization      | Registry (centralized |
      |                | server             | trust anchor)         |
      +----------------+--------------------+-----------------------+
      | PoP mechanism  | DPoP JWT (RFC      | Canonical request     |
      |                | 9449)              | signing               |
      +----------------+--------------------+-----------------------+
      | Trust model    | Scope-based        | Explicit bilateral    |
      |                | authorization      | pairing               |
      +----------------+--------------------+-----------------------+
      | Revocation     | Token              | Signed CRL with local |
      |                | introspection      | caching               |
      +----------------+--------------------+-----------------------+
      | Transport      | Direct HTTP        | WebSocket relay with  |
      |                |                    | store-and-forward     |
      +----------------+--------------------+-----------------------+
      | Target         | Human-to-service   | Agent-to-agent        |
      |                | auth               | communication         |
      +----------------+--------------------+-----------------------+

                                  Table 17

Acknowledgements

   The Clawdentity protocol was designed as part of the OpenClaw
   ecosystem.  The author thanks the OpenClaw community for feedback on
   the identity model, and the designers of DPoP (RFC 9449) and W3C DIDs
   whose work informed key design decisions.

Author's Address

   Ravi Kiran Vemula
   CAW
   Hyderabad
   India
   Email: vrknetha@gmail.com
   URI:   https://ravi.sh







Vemula                   Expires 25 August 2026                [Page 31]


name: draft-messous-eat-ai
rev: 01
title: Entity Attestation Token (EAT) Profile for Autonomous AI Agents
time: 2026-02-24T00:47:23Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-28T00:47:23Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:06.864917+00:00
abstract:
This document defines a profile for the Entity Attestation Token
   (EAT) to support remote attestation of autonomous AI agents across
   domains.  It specifies a set of standardized claims for attesting the
   integrity of AI model parameters, the provenance of training data,
   and the constraints of inference-time data access policies.  Optional
   extensions for 5G/6G network functions—such as slice-type
   authorization—are included for interoperability with ETSI ENI and
   3GPP architectures.  The profile is encoded in CBOR Web Tokens (CWTs)
   or JSON Web Tokens (JWTs) and is designed to be used within the IETF
   RATS architecture.

full_text:
Network Working Group                                         A. MESSOUS
Internet-Draft                                                Huawei R&D
Intended status: Informational                          23 February 2026
Expires: 27 August 2026


    Entity Attestation Token (EAT) Profile for Autonomous AI Agents
                        draft-messous-eat-ai-01

Abstract

   This document defines a profile for the Entity Attestation Token
   (EAT) to support remote attestation of autonomous AI agents across
   domains.  It specifies a set of standardized claims for attesting the
   integrity of AI model parameters, the provenance of training data,
   and the constraints of inference-time data access policies.  Optional
   extensions for 5G/6G network functions—such as slice-type
   authorization—are included for interoperability with ETSI ENI and
   3GPP architectures.  The profile is encoded in CBOR Web Tokens (CWTs)
   or JSON Web Tokens (JWTs) and is designed to be used within the IETF
   RATS architecture.

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-messous-eat-ai/.

   Source for this draft and an issue tracker can be found at
   https://github.com/https://github.com/mmessous/draft-messous-EAT-AI.

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



MESSOUS                  Expires 27 August 2026                 [Page 1]

Internet-Draft                EAT-AI-Agents                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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Generic AI Agent Attestation  . . . . . . . . . . . . . .   4
     3.2.  5G/6G Network Functions (Optional Context)  . . . . . . .   4
   4.  EAT-AI Claims Definition  . . . . . . . . . . . . . . . . . .   4
     4.1.  Core Claims (Generic, Domain-Agnostic)  . . . . . . . . .   4
       4.1.1.  ai-model-id . . . . . . . . . . . . . . . . . . . . .   6
       4.1.2.  use of cryptography digests . . . . . . . . . . . . .   6
       4.1.3.  ai-sbom-ref . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Optional Domain-Specific Claims (5G/6G) . . . . . . . . .   7
     4.3.  Composite and Multi-Component Attestation . . . . . . . .   8
       4.3.1.  Multi-Agent Platforms:  . . . . . . . . . . . . . . .   8
       4.3.2.  Multi-Model Agents: . . . . . . . . . . . . . . . . .   9
       4.3.3.  Layered Trust:  . . . . . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  EAT Profile Registration  . . . . . . . . . . . . . . . .  14
     7.2.  CWT Claims Registry . . . . . . . . . . . . . . . . . . .  14
     7.3.  JWT Claims Registry . . . . . . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative:  . . . . . . . . . . . . . . . . . . . . . . .  16
     8.2.  Informative:  . . . . . . . . . . . . . . . . . . . . . .  16
   9.  Appendix A.  Example EAT-AI Token (CWT) . . . . . . . . . . .  17
   10. Appendix B.  Relationship to Existing Standards &
           Initiatives . . . . . . . . . . . . . . . . . . . . . . .  17
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  18
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18






MESSOUS                  Expires 27 August 2026                 [Page 2]

Internet-Draft                EAT-AI-Agents                February 2026


1.  Introduction

   Autonomous AI agents—software entities that perceive, reason, and act
   with minimal human oversight—are deployed across cloud, edge,
   enterprise, and telecommunications environments.  Their autonomy
   introduces new trust challenges: if an agent’s model is tampered, its
   training data is non-compliant, or its inference policy is violated,
   the consequences range from service disruption to regulatory
   breaches.

   The Entity Attestation Token (EAT) [[RFC9711]] provides a
   standardized framework for remote attestation.  However, EAT does not
   define claims specific to AI artifacts.  This document fills that gap
   by specifying a *generic EAT profile for AI agents*, with *optional
   telecom-specific claims* for use in 5G/6G networks (e.g., ETSI ENI
   AI-Core [[ETSI-GR-ENI-051]]).

   This profile enables verifiers—such as OAuth resource servers,
   network function orchestrators, or policy enforcement points—to make
   trust decisions based on verifiable evidence about an agent’s: -
   *Model integrity* (weights, architecture), - *Training provenance*
   (dataset, geography, privacy), - *Runtime authorization*
   (capabilities, allowed APIs, slice types).

   This profile does not define a full AI Bill of Materials (AIBOM).
   Instead, it provides a minimal set of *verifiable claims* sufficient
   for remote attestation and policy enforcement.  It assumes that
   richer metadata—such as detailed training data lineage, model cards,
   or complete dependency graphs—is maintained in external documents
   (e.g., an AIBOM or SBOM), which may be referenced via claims like ai-
   sbom-ref or a future ai-bom-ref.  Traditional SBOMs remain essential
   to capture the *software supply chain* (e.g., Python, CUDA, framework
   versions) on which the AI agent depends.  This profile complements,
   but does not replace, those artifacts.

2.  Terminology

   *  *AI Agent*: AI agents are autonomous systems powered by Large
      Language Models (LLMs) that can reason, plan, use tools, maintain
      memory, and take actions to accomplish goals.

   *  *Model Integrity*: The property that AI model weights and
      architecture have not been altered from a known-good state.

   *  *Training Provenance*: Metadata describing the origin, scope, and
      privacy properties of data used to train an AI model.





MESSOUS                  Expires 27 August 2026                 [Page 3]

Internet-Draft                EAT-AI-Agents                February 2026


   *  *Inference Policy*: Constraints defining the authorized input
      context (e.g., slice type, geography) under which an agent may
      operate.

   *  *EAT-AI*: The EAT profile defined in this document.

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

3.  Use Cases

3.1.  Generic AI Agent Attestation

   An enterprise AI agent attests its model hash and data retention
   policy before accessing a protected API.  For a more extensive
   protection, attestation target could also include behavioral
   manifests, identity, prompts, tools and capabilities, SBOM/AIBOMs etc
   in the future.

3.2.  5G/6G Network Functions (Optional Context)

   In ETSI ENI AI-Core, an Execution Agent generates instructions for
   network slice configuration.  The agent should prove: - It runs an
   approved model (ai-model-hash), - It was trained on GDPR-compliant
   data (training-geo-region, dp-epsilon), - It is authorized for
   specific slice types (allowed-slice-types).

      *Note*: Telecom-specific claims are *optional* and *only
      meaningful in 3GPP/ETSI contexts*.

4.  EAT-AI Claims Definition

   Claims are defined for both *CWT (CBOR)* and *JWT (JSON)*. In CWT,
   claims use signed integer keys; in JWT, they use text names (with
   hyphens converted to underscores per convention).

4.1.  Core Claims (Generic, Domain-Agnostic)

   +============+======+=====================+======+======================+
   |Claim Name  |CBOR  |JWT Name             |Type  |Description           |
   |            |Key   |                     |      |                      |
   +============+======+=====================+======+======================+
   |ai-model-id |-75000|ai_model_id          |text  |URN-formatted model   |
   |            |      |                     |      |identifier (e.g.,     |
   |            |      |                     |      |urn:ietf:ai:model:cnn-|
   |            |      |                     |      |v3)                   |



MESSOUS                  Expires 27 August 2026                 [Page 4]

Internet-Draft                EAT-AI-Agents                February 2026


   +------------+------+---------------------+------+----------------------+
   |ai-model-   |-75001|ai_model_hash        |digest|Cryptographic hash of |
   |hash        |      |                     |      |the serialized model  |
   |            |      |                     |      |weights and           |
   |            |      |                     |      |architecture          |
   +------------+------+---------------------+------+----------------------+
   |model-arch- |-75002|model_arch_digest    |digest|Cryptographic hash of |
   |digest      |      |                     |      |model computational   |
   |            |      |                     |      |graph                 |
   +------------+------+---------------------+------+----------------------+
   |training-   |-75003|training_data_id     |text  |Unique ID of training |
   |data-id     |      |                     |      |dataset               |
   +------------+------+---------------------+------+----------------------+
   |dp-epsilon  |-75005|dp_epsilon           |float |Differential privacy  |
   |            |      |                     |      |epsilon used during   |
   |            |      |                     |      |training              |
   +------------+------+---------------------+------+----------------------+
   |input-      |-75006|input_policy_digest  |digest|Cryptographic hash of |
   |policy-     |      |                     |      |inference input policy|
   |digest      |      |                     |      |                      |
   +------------+------+---------------------+------+----------------------+
   |data-       |-75008|data_retention_policy|text  |e.g., "none",         |
   |retention-  |      |                     |      |"session", "24h"      |
   |policy      |      |                     |      |                      |
   +------------+------+---------------------+------+----------------------+
   |owner-id    |-75009|owner_id             |text  |Identity of principal |
   |            |      |                     |      |(e.g., GPSI per 3GPP  |
   |            |      |                     |      |TS 29.222)            |
   +------------+------+---------------------+------+----------------------+
   |capabilities|-75010|capabilities         |array |High-level functions  |
   |            |      |                     |of    |(e.g., "slice-        |
   |            |      |                     |text  |optimization")        |
   +------------+------+---------------------+------+----------------------+
   |allowed-apis|-75011|allowed_apis         |array |Specific endpoints the|
   |            |      |                     |of URI|agent may call        |
   +------------+------+---------------------+------+----------------------+
   |ai-sbom-ref |-75012|ai_sbom_ref          |text /|Reference to a        |
   |            |      |                     |map   |Software Bill of      |
   |            |      |                     |      |Materials (SBOM)      |
   |            |      |                     |      |describing the AI     |
   |            |      |                     |      |agent’s runtime       |
   |            |      |                     |      |dependencies (e.g.,   |
   |            |      |                     |      |Python, CUDA,         |
   |            |      |                     |      |libraries).  MAY be a |
   |            |      |                     |      |URI, digest, or       |
   |            |      |                     |      |embedded SBOM fragment|
   +------------+------+---------------------+------+----------------------+




MESSOUS                  Expires 27 August 2026                 [Page 5]

Internet-Draft                EAT-AI-Agents                February 2026


                    Table 1: Core Domain-Agnostic Claims

4.1.1.  ai-model-id

   *  ai-model-id: A globally unique model identifier encoded as a URN.
      The URN *namespace* urn:ietf:ai:model: is reserved for
      standardized reference models (e.g., defined in RFCs). *Model
      owners SHOULD use their own URN namespace* (e.g., based on domain
      name, PEN, or UUID) to avoid central coordination.  Examples:

      -  urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 (for a private
         model)

      -  urn:ietf:ai:model:llama3-8b (for a well-known public model, if
         later standardized)

      -  urn:dev:example.com:finance-agent-v2 (enterprise-owned model)

4.1.2.  use of cryptography digests

   *  The claims ai-model-hash, model-arch-digest, and input-policy-
      digest represent cryptographic digests of serialized artifacts
      (e.g., model weights, computational graphs, or policy documents).
      To support algorithm agility and avoid ambiguity, each such claim
      is defined as a digest structure rather than a bare byte string.
      A digest structure is encoded as a two-element array:

   cbor [ alg, hash ]

   where: - *alg* is the Hash Algorithm Identifier, using either the
   *integer* or *text string* from the IANA COSE Algorithms registry
   (https://www.iana.org/assignments/cose/cose.xhtml#algorithms),
   indicating the hash function used (e.g., '-16' for SHA-256, -44 for
   SHA-384, -45 for SHA3-256). - *hash* is the byte string output of
   applying that hash function to the canonical serialization of the
   artifact.

   In *CBOR*, the digest is represented as a CBOR array: [ int / tstr,
   bstr ].  In *JWT* (JSON), it is represented as a JSON object: {
   "alg": "...", "hash": "base64url-encoded-hash" }. This design aligns
   with the Detached-Submodule-Digest type defined in [RFC 9711,
   Section 4.2.18.2] and enables future-proof support for multiple hash
   algorithms (e.g., SHA-2, SHA-3, post-quantum secure hashes) without
   requiring new claims or breaking existing parsers.







MESSOUS                  Expires 27 August 2026                 [Page 6]

Internet-Draft                EAT-AI-Agents                February 2026


4.1.3.  ai-sbom-ref

   *  The ai-sbom-ref claim provides a reference to the *Software Bill
      of Materials (SBOM)* associated with the AI agent.  This enables
      verifiers to assess the integrity, license compliance, and
      vulnerability status of the agent’s software supply chain.  The
      value MAY be:

   *  A URI pointing to an SBOM document (e.g., in SPDX or CycloneDX
      format),

   *  A digest (using the structured digest format defined in
      Section 4.1) of an SBOM,

   *  Or a compact embedded representation (e.g., a minimal map of
      critical components).

   Example (CBOR):

   cbor / ai-sbom-ref / -75012: "https://example.com/sboms/agent-
   xyz.spdx.json"

   Example (embedded digest):

   cbor / ai-sbom-ref / -75012: [ -44, h'abcd1234...' ] ; SHA-384 digest
   of SBOM

   When used, the SBOM SHOULD include: - Runtime environment (e.g.,
   Python 3.11, CUDA 12.4), - AI framework versions (e.g., PyTorch 2.3,
   TensorFlow 2.15), - Critical dependencies (e.g., NumPy, cuDNN), -
   Model serialization format (e.g., ONNX v9, SafeTensors v0.4).  This
   claim complements model integrity (ai-model-hash) by attesting to the
   execution context in which the model operates—critical for
   reproducibility and security analysis.

4.2.  Optional Domain-Specific Claims (5G/6G)

   +===================+======+===================+=====+==============+
   |Claim Name         |CBOR  |JWT Name           |Type |Description   |
   |                   |Key   |                   |     |              |
   +===================+======+===================+=====+==============+
   |training-geo-region|-75004|training_geo_region|array|ISO 3166-1    |
   |                   |      |                   |of   |alpha-2 codes |
   |                   |      |                   |text |(e.g., ["DE", |
   |                   |      |                   |     |"FR"])        |
   +-------------------+------+-------------------+-----+--------------+
   |allowed-slice-types|-75007|allowed_slice_types|array|3GPP-defined  |
   |                   |      |                   |of   |slice types   |



MESSOUS                  Expires 27 August 2026                 [Page 7]

Internet-Draft                EAT-AI-Agents                February 2026


   |                   |      |                   |text |(e.g.,        |
   |                   |      |                   |     |"eMBB",       |
   |                   |      |                   |     |"URLLC")      |
   +-------------------+------+-------------------+-----+--------------+

                  Table 2: Optional Domain-Specific Claims

      *Usage*: These claims *SHOULD be used* when attesting agents in
      *ETSI ENI or 3GPP SBA* environments.

4.3.  Composite and Multi-Component Attestation

   This profile utilizes the recursive nesting capability of the submods
   claim (Key 266) to support three specific composite scenarios:

4.3.1.  Multi-Agent Platforms:

   To support a user managing multiple agents with varying
   configurations, we should leverage the recursive nesting capability
   of the submods claim (CBOR key 266) as defined in [RFC 9711].  In
   this architectural pattern, the top-level EAT represents the user's
   platform or trust domain.  Each agent is a submodule of that
   platform, and if an agent uses multiple models, those models are
   further nested as submodules of that specific agent.

   The following CWT example shows a platform hosting two agents.  Agent
   1 is a complex orchestrator using two models, while Agent 2 is a
   simple worker using only one.

   Code snippet





















MESSOUS                  Expires 27 August 2026                 [Page 8]

Internet-Draft                EAT-AI-Agents                February 2026


{
/ ueid / 256: h'0102030405060708',  / User/Platform ID /
    / nonce / 10: h'abcdef1234567890', / Freshness Nonce /
    / submods / 266: {                 / Submodules Section /

    / --- Agent 1: Multi-Model Orchestrator --- /
    "agent-1": {
      / swname / 270: "Orchestrator-Agent-v2",
      / submods / 266: {             / Nested Model Submodules /
        "llm-core": {
          / ai-model-id / -75000: ":uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
          / ai-model-hash / -75001: [-44, h'9a8b...']  / SHA-384 /
        },
        "tool-planner": {
          / ai-model-id / -75000: ":uuid:550e8400-e29b-41d4-a716-446655440000",
          / ai-model-hash / -75001: [-16, h'5e4f...']  / SHA-256 /
        }
      }
    },

    / --- Agent 2: Single-Model Worker --- /
    "agent-2": {
      / swname / 270: "Vision-Worker-v1",
      / ai-model-id / -75000: ":ietf:ai:model:vit-b-16", /
      / ai-model-hash / -75001: [-44, h'd3e2...']            /
    }
  }
}

4.3.2.  Multi-Model Agents:

   A single agent utilizing an orchestrator model and task-specific
   worker models.

   Modern AI agents are not necessarly monolithic; sophesticated Agents
   can consist of an orchestrator model (e.g., a LLM) and several task-
   specific worker models (e.g., image classifiers or encoders).  To
   support these configurations, this profile utilizes the submods claim
   (Key 266) from [RFC 9711].  Each distinct model used by the agent
   SHOULD be represented as an entry within the submods map.  This
   allows for granular policy appraisal where different models may have
   different trust levels, privacy parameters (dp_epsilon), or residency
   requirements.








MESSOUS                  Expires 27 August 2026                 [Page 9]

Internet-Draft                EAT-AI-Agents                February 2026


   When a model is represented in a submodule, it carries its own
   instance of ai-model-id and ai-model-hash.  If the model weights are
   proprietary (e.g., accessed via a cloud API), the submodule SHOULD
   include an ai-model-id that the Verifier can match against a provider
   Endorsement.

   The following example demonstrates an agent employing an orchestrator
   LLM and a specialized vision model.  Note the use of the digest
   format [alg, val] to support different hash types for each model.

   Code snippet

{
  / ueid / 256: h'0102030405060708',
  / nonce / 10: h'abcdef1234567890',
  / submods / 266: {
    "orchestrator-llm": {
      / ai-model-id / -75000: ":uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
      / ai-model-hash / -75001: [-44, h'9a8b7c6d...']  / SHA-384 /
    },
    "vision-classifier": {
      / ai-model-id / -75000: ":ietf:ai:model:vit-b-16",
      / ai-model-hash / -75001: [-16, h'5e4f3a2b...'], / SHA-256 /
      / dp-epsilon / -75005: 0.8
    }
  }
}

4.3.3.  Layered Trust:

   Scenarios where different system components (e.g., hardware TEE, OS
   runtime, and AI model) are owned or managed by different entities.

   *  *Nesting Mechanism:* Components SHOULD be represented as nested
      EATs within the submods claim (Key 266).  Each nested token MAY be
      signed by a different attestation key belonging to the respective
      component owner.

   *  *Verifier Role:* A Verifier receiving a composite EAT SHOULD
      follow the Hierarchical Pattern, where it acts as a Lead Verifier
      and delegates the appraisal of individual submodules to
      specialized verifiers that hold the appropriate Trust Anchors for
      each owner.

   For multi-owner attestation, a *Lead Verifier* SHOULD follow the
   *Hierarchical Pattern*, extracting nested sub-tokens and delegating
   their appraisal to specialized verifiers holding the appropriate
   Trust Anchors.



MESSOUS                  Expires 27 August 2026                [Page 10]

Internet-Draft                EAT-AI-Agents                February 2026


         +-----------------------------------------------------------+
         |  Attesting Device (e.g., Edge Server / 5G UE)             |
         |                                                           |
         |  +----------------------------+                           |
         |  | Hardware Root of Trust     | <--- Signing Key (AK_1)   |
         |  | (RoT)                      |                           |
         |  +-------------+--------------+                           |
         |                | Measures                                 |
         |                v                                          |
         |  +-------------+--------------+                           |
         |  | TEE / Secure OS            | <--- Signing Key (AK_2)   |
         |  | (Submodule 1)              |      (Optional)           |
         |  +-------------+--------------+                           |
         |                | Measures & Isolates                      |
         |                v                                          |
         |  +-------------+--------------+                           |
         |  | AI Agent Environment       |                           |
         |  |                            |                           |
         |  |  +----------------------+  |                           |
         |  |  | AI Model (Target)    |  |                           |
         |  |  | - Weights Hash       |  |                           |
         |  |  | - Config             |  |                           |
         |  |  +----------------------+  |                           |
         |  +----------------------------+                           |
         +-----------------------------------------------------------+

                   Figure 1: Example of a Chain of Trust

   Figure 1 illustrates the Chain of Trust.  The Hardware Root of Trust
   (RoT) measures the integrity of the Trusted Execution Environment
   (TEE) or OS.  The TEE, acting as a transitive verifier, subsequently
   measures the AI Agent's model binaries and policy configurations.
   The resulting EAT token reflects this hierarchy using nested
   submodules, ensuring that the ai-model-hash is reported by a trusted
   parent rather than the agent itself.

   To clarify the hierarchical trust relationships in multi-owner
   attestation scenarios, Figure 2 illustrates the binding of components
   across hardware, runtime, and AI model layers.  Each layer is
   attested by a distinct owner and represented as a nested submodule
   within the top-level EAT per [RFC 9711, Section 4.2.18].










MESSOUS                  Expires 27 August 2026                [Page 11]

Internet-Draft                EAT-AI-Agents                February 2026


   +-----------------------------------------------------------------+
   |  Top-Level EAT (Platform Attester)                              |
   |  • ueid: Platform hardware identity (e.g., TPM/SE)              |
   |  • nonce: Freshness guarantee                                   |
   |  • submods: {                                                   |
   |      "tee-runtime": {  ← Signed by Platform Owner               |
   |          • ueid: TEE instance ID                                |
   |          • swname: "Confidential-VM-v2"                         |
   |          • submods: {                                           |
   |              "ai-agent": {  ← Signed by AI Operator             |
   |                  • swname: "Execution-Agent-v3"                 |
   |                  • ai-model-id: "urn:uuid:..."                  |
   |                  • ai-model-hash: [alg, hash]                   |
   |                  • submods: {                                   |
   |                      "orchestrator": {...},  ← Model Owner A    |
   |                      "vision-model": {...}   ← Model Owner B    |
   |                  }                                              |
   |              }                                                  |
   |          }                                                      |
   |      }                                                          |
   |  }                                                              |
   +-----------------------------------------------------------------+

    Figure 2: Trust hierarchy for layered attestation using EAT submods

4.3.3.1.  *Trust Binding Semantics*

   *  *Hardware → TEE:* The TEE runtime measurement is included in a
      platform-signed attestation report (e.g., AMD SEV-SNP, Intel TDX).
      The top-level EAT's signature binds the tee-runtime submodule to
      this hardware root.

   *  *TEE → AI Agent:* The AI agent's code and configuration are
      measured into the TEE's launch digest.  The ai-agent submodule is
      signed by the AI operator's key, which itself is endorsed by the
      platform owner (via an Endorsement per [RFC 9334]).

   *  *Agent → Models:* Individual models are signed by their respective
      providers.  The agent's runtime verifies model signatures before
      loading; these signatures are reflected in the nested submods
      entries.










MESSOUS                  Expires 27 August 2026                [Page 12]

Internet-Draft                EAT-AI-Agents                February 2026


4.3.3.2.  *Appraisal Delegation*

   Per [RFC 9334, Section 5.3], a Lead Verifier appraising the top-level
   token: 1- Validates the platform signature against a hardware Trust
   Anchor 2- Delegates tee-runtime appraisal to a TEE-specific verifier
   holding platform Endorsements 3- Delegates ai-agent appraisal to an
   AI policy verifier holding operator Trust Anchors 4- Optionally
   delegates model submodules to specialized model catalog verifiers

   A submodule appraisal failure MUST cause rejection of the entire
   attestation unless policy explicitly permits partial trust (e.g.,
   non-critical auxiliary models).  This failure semantics MUST be
   defined by the deployment policy—not by this profile.

5.  Security Considerations

   *  Claims SHOULD be bound to a hardware-rooted attestation where
      available.

   *  *ai-model-hash* SHOULD be computed on the serialized model file
      (e.g., ONNX, PyTorch), not in-memory tensors.

   *  *Verifiers* SHOULD validate claims against authoritative
      registries (e.g., model hash in secure model catalog).

   *  *_Replay attacks_* SHOULD be mitigated using EAT nonce (CWT key
      10) or exp (key 4).

   *  Verifiers SHOULD validate the referenced SBOM against known
      vulnerability databases (e.g., NVD) and reject agents using
      components with unpatched critical flaws.

   *  Verifiers SHOULD validate that ai-model-id values originate from
      trusted namespaces (e.g., known domains, approved PENs, or allow-
      listed UUIDs).  Dynamic model deployment does not require central
      registration, but policy enforcement may restrict acceptable
      namespaces.

   *  Verifiers are expected to combine EAT-AI evidence with external
      SBOM/AIBOM analysis for comprehensive risk assessment.

6.  Privacy Considerations

   *  training-geo-region reveals data origin and SHOULD be minimized.

   *  EAT tokens SHOULD be transmitted over secure channels (e.g., TLS
      1.3).




MESSOUS                  Expires 27 August 2026                [Page 13]

Internet-Draft                EAT-AI-Agents                February 2026


   *  owner-id SHOULD use pseudonymous identifiers (e.g., GPSI per 3GPP
      TS 29.222).

   *  Embedded SBOMs or detailed URIs may reveal deployment topology.
      When privacy is a concern, use opaque digests or pseudonymized
      SBOM identifiers.

   *  High-granularity combinations of training-geo-region + dp-epsilon
      + allowed-apis may uniquely identify a "private" model even if the
      ai-model-id is obscured.

7.  IANA Considerations

7.1.  EAT Profile Registration

   IANA is requested to register in the "Entity Attestation Token (EAT)
   Profiles" registry: - Profile Name: Autonomous AI Agent EAT Profile -
   Reference: [THIS DOCUMENT]

7.2.  CWT Claims Registry

   IANA is requested to register the following in the "CBOR Web Token
   (CWT) Claims" registry [IANA-CWT]:




























MESSOUS                  Expires 27 August 2026                [Page 14]

Internet-Draft                EAT-AI-Agents                February 2026


   +========+=======================+==================================+
   | Value  | Claim Name            | Description                      |
   +========+=======================+==================================+
   | -75000 | ai-model-id           | AI model URN                     |
   +--------+-----------------------+----------------------------------+
   | -75001 | ai-model-hash         | Model weights hash               |
   +--------+-----------------------+----------------------------------+
   | -75002 | model-arch-digest     | Model graph hash                 |
   +--------+-----------------------+----------------------------------+
   | -75003 | training-data-id      | Training dataset ID              |
   +--------+-----------------------+----------------------------------+
   | -75004 | training-geo-region   | Training data regions            |
   +--------+-----------------------+----------------------------------+
   | -75005 | dp-epsilon            | DP epsilon                       |
   +--------+-----------------------+----------------------------------+
   | -75006 | input-policy-digest   | Inference policy hash            |
   +--------+-----------------------+----------------------------------+
   | -75007 | allowed-slice-types   | Authorized slice                 |
   |        |                       | types                            |
   +--------+-----------------------+----------------------------------+
   | -75008 | data-retention-policy | Data retention policy            |
   +--------+-----------------------+----------------------------------+
   | -75009 | owner-id              | Resource owner                   |
   |        |                       | identifier                       |
   +--------+-----------------------+----------------------------------+
   | -75010 | capabilities          | Agent capabilities               |
   +--------+-----------------------+----------------------------------+
   | -75011 | allowed-apis          | Allowed API endpoints            |
   +--------+-----------------------+----------------------------------+
   | -75012 | ai-sbom-ref           | Reference to AI                  |
   |        |                       | agent’s Software Bill            |
   |        |                       | of Materials (SBOM)              |
   +--------+-----------------------+----------------------------------+

                        Table 3: CWT Claims Registry

   The range -75000 to -75012 is reserved for this profile.

7.3.  JWT Claims Registry

   IANA is requested to register the corresponding JWT claim names in
   the "JSON Web Token Claims" registry [IANA-JWT].

8.  References







MESSOUS                  Expires 27 August 2026                [Page 15]

Internet-Draft                EAT-AI-Agents                February 2026


8.1.  Normative:

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

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

   *  [RFC8174 (https://www.ietf.org/rfc/rfc8174.html)] Leiba, B.,
      "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP
      14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

   *  [RFC8392 (https://datatracker.ietf.org/doc/html/rfc8392)] Jones,
      M., et al., "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/
      RFC8392, May 2018.

   *  [RFC9711 (https://datatracker.ietf.org/doc/html/rfc9711)] L.
      Lundblade, G.  Mandyam,J.  O'Donoghue,C.  Wallace, "The Entity
      Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April
      2025.

   *  [RFC9334 (https://datatracker.ietf.org/doc/html/rfc9334)] Birkett,
      M., et al., "Remote ATtestation ProcedureS (RATS) Architecture",
      RFC 9334, DOI 10.17487/RFC9334, January 2023.

   *  [RFC8126 (https://datatracker.ietf.org/doc/html/rfc8126)] Cotton,
      M., et al., "Guidelines for Writing an IANA Considerations
      Section in RFCs", RFC 8126, DOI 10.17487/RFC8126, June 2017.

   *  [[EAT Measured Component] (https://datatracker.ietf.org/doc/draft-
      ietf-rats-eat-measured-component/)] Frost S., et al., "EAT
      Measured Component", Active Internet-Draft (rats WG).

8.2.  Informative:

   *  [ETSI-GR-ENI-051
      (https://www.etsi.org/deliver/etsi_gr/ENI/001_099/051/04.01.01_60/
      gr_ENI051v040101p.pdf)] ETSI, *"Architectural Framework for ENI in
      6G"*, GR ENI 051 V4.1.1, February 2025.

   *  [3GPP-TR-33.898
      (https://portal.3gpp.org/desktopmodules/Specifications/
      SpecificationDetails.aspx?specificationId=4088)] 3GPP, *"Study on
      security and privacy of Artificial Intelligence/Machine Learning
      (AI/ML)-based services and applications in 5G"*, TR 33.898,
      V18.0.1 July 2023.



MESSOUS                  Expires 27 August 2026                [Page 16]

Internet-Draft                EAT-AI-Agents                February 2026


   *  [3GPP-TR-33.784
      (https://portal.3gpp.org/desktopmodules/Specifications/
      SpecificationDetails.aspx?specificationId=4294)] 3GPP, *"Study on
      security aspects of core network enhanced support for Artificial
      Intelligence/Machine Learning (AI/ML)"*, TR 33.784 V0.0.0, April
      2025.

   *  [I-D.huang-rats-agentic-eat-cap-attest
      (https://datatracker.ietf.org/doc/draft-huang-rats-agentic-eat-
      cap-attest/)] Huang, K., et al., *"Capability Attestation
      Extensions for the Entity Attestation Token (EAT) in Agentic AI
      Systems"*, Work in Progress, Internet-Draft, March 2025.

   *  [draft-ni-wimse-ai-agent-identity
      (https://datatracker.ietf.org/doc/draft-ni-wimse-ai-agent-
      identity/)] Yuan, N., Liu, P., *"WIMSE Applicability for AI
      Agents"*, Work in Progress.

   *  [draft-liu-oauth-a2a-profile (https://datatracker.ietf.org/doc/
      draft-liu-oauth-a2a-profile/)] Liu, P., Yuan, N., *"Agent-to-Agent
      (A2A) Profile for OAuth Transaction Tokens"*, Work in Progress.

9.  Appendix A.  Example EAT-AI Token (CWT)

   The following is a CBOR diagnostic notation of an EAT-AI token:

{
/ ueid / 256: h'0102030405060708',
/ swname / 270: "execution-agent-v3",
/ ai-model-id / -75000: "urn:etsi:eni:model:slice-opt-cnn:v3",
/ ai-model-hash / -75001: [-44,h'9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f'],
/ training-geo-region / -75004: ["DE", "FR"],
/ dp-epsilon / -75005: 0.5,
/ input-policy-digest / -75006: [-44,h'a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0'],
/ ai-sbom-ref / -75012: "https://sbom.example.net/agents/slice-opt-v3.spdx.json",
/ nonce / 10: h'abcdef1234567890'
}

10.  Appendix B.  Relationship to Existing Standards & Initiatives

   This document complements: - IETF RATS
   (https://datatracker.ietf.org/doc/html/rfc9334): Provides the
   architectural context for EAT. - ETSI GR ENI 051
   (https://www.etsi.org/deliver/etsi_gr/ENI/001_099/051/04.01.01_60/
   gr_ENI051v040101p.pdf): Defines the AI-Core where these claims are
   applied.





MESSOUS                  Expires 27 August 2026                [Page 17]

Internet-Draft                EAT-AI-Agents                February 2026


   It differs from I-D.huang-rats-agentic-eat-cap-attest
   (https://datatracker.ietf.org/doc/draft-huang-rats-agentic-eat-cap-
   attest/) by specifying measurable, cryptographically verifiable
   claims rather than abstract capabilities.

Appendix A.  Acknowledgments

   TODO

Author's Address

   Ayoub MESSOUS
   Huawei R&D
   Email: ayoub.messous@huaweil.com





































MESSOUS                  Expires 27 August 2026                [Page 18]


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: ["A2A protocols", "Data formats/interop", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:06.864919+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: ["Agent identity/auth", "Policy/governance", "A2A protocols", "AI safety/alignment"]
tags: []
fetched_at: 2026-02-27T22:56:06.864925+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: ["Agent identity/auth", "A2A protocols", "Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:06.864927+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]


